How to Track a Site Migration in GSC (So You Know if It Worked)
Most migration damage is discovered months late because nobody froze a baseline. The GSC measurement plan: before, day 0, the transit weeks, and the verdict.
A migration's SEO verdict is decided in Search Console, and the tracking has to start before the switch, because the moment the old URLs die, so does your ability to capture what they earned. The measurement plan in four phases:
- FREEZE THE BASELINE FIRST: Export the old property's queries, pages and totals, save the redirect map beside them, and annotate the migration date. This is the before-photo everything is judged against.
- DAY 0: SWITCH AND TELL GOOGLE: Redirects live before anything else, new property verified in advance, Change of Address for domain moves, new sitemap submitted.
- WEEKS 1 TO 4: WATCH THE HANDOVER: Old property fading while the new one rises is the plan working. Redirect errors in the Pages report are the thing to fix daily.
- MONTHS 2 TO 3: THE VERDICT: Compare the new property's queries and clicks against the frozen baseline, gap by gap. A modest transit dip is normal; a missing query cluster is a casualty with a name.
Keep both properties in GSC forever. The old one's data is evidence, and verifying it costs nothing.
CrawlRaven watches migrations the way this guide does: daily Search Console sync on both properties, the migration date pinned as an annotation, and the crawl verifying the redirect map the data depends on. This is the manual measurement plan, and it works with GSC alone. Try CrawlRaven free: 1 site, no credit card →
Nobody loses a migration on migration day. They lose it quietly, over the following quarter, and discover it months later in a meeting where someone asks why organic is down 30% year over year and nobody can prove what the old site used to earn.
The entire defence is measurement that starts before the switch. Search Console is where a migration's verdict gets decided, and this is the tracking plan: the baseline, day 0, the transit weeks, and the honest comparison at the end.
Four phases of tracking a migration in GSC
Why migration damage gets discovered late
- The before-photo never got taken. Once old URLs die and the old property's window rolls, what the site used to earn becomes unprovable.
- Transit noise gives cover. Everyone expects a dip, so a real loss hides inside the expected one until the expected one should have ended.
- The data splits across two properties. Neither alone shows the true line, and most people watch only the new one.
Step 1: Freeze the baseline before the switch
Everything after depends on this, and it cannot be done retroactively:
- Export the old property's last 12 months: queries, pages, countries and devices, over the API rather than the 1,000-row UI export. The full routine is step 1 of the GSC data retention guide.
- Save the redirect map beside the export. Old URL, new URL, one row each. The comparison in step 4 is only as good as this mapping.
- Verify the new property now, before launch, so day-0 data lands in an account that already exists.
- Annotate the plan. The migration date goes into your SEO annotations before it happens; future-dating planned changes is what annotations are for.
Step 2: Day 0, switch and tell Google
- Redirects live before anything else. Every old URL 301s to its mapped new URL in one hop. This single item decides most migrations.
- Submit the new sitemap in the new property, and leave the old sitemap live for a while so Google recrawls the old URLs and finds their redirects.
- Use Change of Address when it applies (details below).
- Spot-check the map immediately: run a sample of old URLs through our free redirect checker and confirm one-hop 301s to the right destinations, today, while fixes are cheap.
When Change of Address applies
The Change of Address setting tells Google the entire site moved domains, and it accelerates signal transfer for exactly that case:
- Use it for: olddomain.com to newdomain.com, after the redirects are live.
- Not for: HTTP to HTTPS, path restructures on the same domain, design-only relaunches, or partial moves. For those, the redirects and sitemaps are the whole announcement.
Step 3: Weeks 1 to 4, watch the handover
Transit is noisy by design, so the skill is separating normal noise from a real problem. The daily glance is two reports: the new property's Pages report for redirect errors and 404s, and both properties' Performance for the handover shape.
Normal migration noise vs a real problem
During transit, the truthful traffic line is old property plus new property. The old one falling is not loss and the new one rising is not growth; only the sum against the baseline says which way the migration is going.
Step 4: Months 2 to 3, the verdict against baseline
When the handover settles, compare the new property against the frozen baseline, not against memory:
- Totals first: combined clicks in month 3 against the baseline's equivalent month. Within a modest distance is transit; far below is damage.
- Then query clusters: group the baseline's top queries by topic and confirm each cluster reappeared. A cluster that never came back names its own investigation: find its old pages in the map and see what the move did to them.
- Then the pages: the baseline's top 50 URLs, each checked for a ranking successor. This is where content cut during the redesign shows up as the "mystery" loss.
- Log the verdict in the annotation, with numbers. The next migration's plan starts from this one's record.
Tips from migrations that went both ways
- Do not migrate and redesign the content in one move if you can help it. Two changes, one traffic line: when it drops, you cannot tell which one to blame, and the fix list doubles.
- Keep the redirects forever, not for a year. External links and bookmarks never expire, and removing redirects reopens 404s exactly where authority still flows.
- Keep both properties verified forever too. The old Pages report is a free, permanent detector for URLs your map missed.
- Time it against your calendar, not Google's. Avoid your peak season, and avoid launching into a rolling core update when you can; movement inside an update window is unattributable.
- Watch crawl stats the first fortnight. A crawl spike on the old property is Google digesting the redirects, which is what you want to see.
When the recovery stalls, and what to check
- Redirect errors keep appearing? The map has holes Google keeps finding. Pull the failing URLs from the new property's Pages report, map them, and recheck weekly until the report goes quiet.
- Old URLs still ranking at month 2? Confirm they 301 in one hop rather than through chains, and that nothing resurrects them: a stale canonical, an internal link, or a sitemap still listing them.
- New pages indexed but a query cluster missing? Compare the old and new page for that cluster side by side. Content trimmed in the redesign is the usual thief, and restoring the cut sections is the fix.
- Everything correct and still below baseline at month 3? Audit the new site as a site, not a migration: templates, internal linking and speed all changed too, and one of them is the anchor. The migration checklist is the systematic version of that pass.
Tools that make this easier
- Free, on this site: the redirect checker for the day-0 map spot-check, the sitemap comparison tool for confirming the new sitemap covers what the old one did, and the migration checklist for everything beyond measurement.
- CrawlRaven: both properties synced daily, the migration pinned to the timeline as an annotation, and the 200-point crawl verifying the redirect layer the traffic data can only infer: chains, loops, and old URLs that answer 200 instead of redirecting. The join is what connects "this cluster never recovered" to the crawl finding that explains it.
- Honest note: any tool that stores GSC history, SEO Gets included, doubles as migration insurance, because the baseline problem is a retention problem wearing a hard hat.
If the migration is ahead of you: freeze the baseline this week, even if the launch slips. If it is behind you and untracked: export both properties today, annotate the date from memory while it exists, and run the month-3 comparison with what you have. Partial evidence still beats the meeting with none.
Frequently asked questions
How do I track a site migration in Google Search Console?
In four phases. Before the switch: export the old property's queries, pages and totals as a frozen baseline, and verify the new property in advance. Day 0: redirects live, Change of Address for domain moves, new sitemap submitted. Weeks 1 to 4: watch the old property fade and the new one rise, fixing redirect errors daily. Months 2 to 3: compare the new property against the frozen baseline to find what the move actually cost.
How long does a site migration take to recover in Google?
For a clean like-for-like migration with correct redirects, expect several weeks of transit while Google reprocesses every URL, with a modest temporary dip as normal. Judge the outcome at two to three months, not two weeks. Migrations that also change content, structure or design recover on their own slower schedule, because Google is re-evaluating the pages, not just their addresses.
Should I keep the old property in Search Console after migrating?
Yes, permanently. The old property's data is your only record of pre-migration performance once its 16-month window starts rolling, its Pages report shows whether Google is still finding un-redirected URLs, and verification costs nothing to keep. Deleting it is destroying evidence about your own migration.
What is the Change of Address tool and when do I use it?
A Search Console setting that tells Google the whole site moved from one domain to another, speeding up how signals transfer. It applies to domain-level moves only: newdomain.com replacing olddomain.com. It does not apply to HTTP-to-HTTPS moves, path restructures on the same domain, or partial moves; for those, redirects and sitemaps carry the whole message.
Why did my traffic drop after a site migration?
Separate transit from damage by timing and shape. A broad, modest dip in the first weeks that recovers is transit: Google reprocessing every URL. Damage looks different: redirect errors accumulating in the Pages report, a query cluster that never reappears on the new property, or combined clicks still well below baseline at month three. Each of those has a findable cause, usually holes in the redirect map or content lost in the move.
Do I track a migration in one Search Console property or two?
Two, read together. The old property shows the fade-out and, crucially, any URLs Google still hits that your redirects miss. The new property shows indexing progress and the rebuild of queries and clicks. The migration's true line is the sum of both during transit, which is why keeping both verified matters.
15+ years of growing SaaS websites through SEO | Author, 200-Point Audit Checklist
Aditi has spent 15+ years helping SaaS companies scale organic traffic through technical SEO and content strategy. She is the author of the CrawlRaven 200-Point Audit checklist used by agencies and in-house teams to systematically improve search performance.