To protect rankings during a site migration, preserve parity and deploy a complete one-to-one 301 redirect map before cutover. Before launch, you also need a full URL inventory, verified Search Console properties, baseline analytics and staging tests. Expect a dip after launch, so start the redirect map and baseline capture today.
TL;DR:
- Include indexed pages missing from navigation in your URL inventory, since they may hold strong backlinks; prioritize redirects by traffic and revenue.
- Use permanent 301s to equivalent pages, collapse redirect chains, and update internal links, canonical tags, hreflang annotations, and sitemaps to final URLs.
- Use Change of Address only for domain or subdomain moves; Google’s tool forwards signals for 180 days, so keep redirects and ownership verification active.
- Expect recovery to take weeks rather than days even when the move is clean, and far longer when redirects or parity are wrong.
- After launch, compare organic sessions, conversions, index coverage, rankings, and server logs with the frozen baseline daily, then investigate redirect, blocking, parity, and tracking failures.
What should you finish before any URL changes?
Most ranking losses trace back to decisions made, or skipped, before launch. Treat this section as a gate: nothing moves to staging until every item below has an owner and a finished deliverable.
Work through these steps in order:
- Define goals and success metrics. Decide what "safe" means before you touch anything. Pick organic sessions, rankings for your top queries, and conversions as the three numbers you will compare after launch.
- Capture baseline data. Export at least several months of organic sessions, landing page performance, conversions and Search Console query data. Without a baseline you cannot tell a normal dip from a real problem.
- Export a full URL inventory. Combine a crawl of the live site with the pages that Search Console and your analytics show receiving impressions and visits. Include indexed URLs that no longer appear in your navigation, because old pages often hold the strongest backlinks.
- Prioritize by traffic and revenue. Tag each URL as critical, important or low value. Critical pages get hand-checked redirects and manual QA, while low-value pages can be handled in bulk.
- Build the one-to-one redirect map. Each old URL points to the new URL that serves the same intent. Redirecting everything to the homepage is the classic shortcut, and it throws away the relevance that earned the ranking.
- Audit backlinks. Identify the external links pointing at your most valuable pages and confirm each one lands on a live, relevant destination after the move.
- Inventory on-page elements. Record titles, meta descriptions, headings, structured data and hreflang annotations so the new build can reproduce them.
What parity actually means
Parity is the idea that a new page should answer the same query at least as well as the old one. That covers more than the URL. It includes the content depth, the heading structure, the internal links and the markup that helped the page earn its position. When a redesign trims a detailed service page down to a hero banner and a few bullets, a perfect redirect will not save the ranking, because the page that receives the signals no longer deserves them.
Use this short list as your parity audit for every critical page:
- The primary topic and search intent of the page are unchanged.
- The title tag and H1 still describe the same offer in similar words.
- The body content is at least as complete as the old version.
- Structured data types (Product, FAQ, LocalBusiness, Article) carry over.
- Internal links from other pages still point to it, using the final URL.
- Images keep descriptive file names and alt text.
Handle the content decisions early
A migration is the moment teams decide to merge, prune or rewrite content. Make those calls in the planning phase, not during build week. If two old articles will merge into one, both old URLs redirect to the merged page, and your map should show that explicitly. If a page is being retired with no equivalent, decide whether it should return a 410 or redirect to the closest relevant category, and record the reasoning so nobody second-guesses it at launch.
Structured data deserves its own line in the plan. Developers often rebuild templates from scratch, and schema markup is exactly the kind of invisible element that disappears. List which templates carry which schema types, and add them to the acceptance criteria for the new build. The same applies to hreflang if you run multiple languages: every annotation needs a return reference on the new URLs, or it will be ignored.
For a broader view of what to verify on a site before and after a build, our technical SEO checklist covers the items teams tend to forget.
Pro Tip: Freeze your baseline export in a read-only spreadsheet with the date in the filename. After launch, nobody remembers what "normal" looked like, and that file settles the argument.
How do you build and deploy the redirect plan?
Redirects are how ranking signals travel from old URLs to new ones. Google's own guidance on site moves and migrations lists implementing redirects and verifying properties among the core pre-move steps, which is why this section carries the most weight in the whole project.
Use permanent redirects, not temporary ones
A 301 tells search engines the move is permanent and that signals should transfer. A temporary redirect says the move is temporary, so the old URL stays the one that matters. Temporary redirects left in place after launch can contribute to a stalled migration. Developers sometimes use them during testing and forget to switch, so make the status code a line item on your launch checklist.
Google also documents how different HTTP status codes affect crawling: redirects are followed up to a limit, 4xx responses typically lead to URLs being dropped over time, and persistent 5xx errors slow crawling. A long chain of redirects is a quiet way to hit that limit.
The build, test and log routine
Follow this sequence for the redirect layer:
- Build the map as a flat table with old URL, new URL, status code and priority tier.
- Test with a crawler by feeding the old URL list into a crawling tool in list mode and checking where each one lands.
- Collapse chains. If A redirects to B and B redirects to C, point A straight to C. Extra hops can add latency and risk dropping the signal.
- Check for loops and soft errors, such as a redirect that lands on a page returning a 404 or an empty template.
- Keep a redirect log that records every rule, who added it and when, so later releases do not overwrite it.
For quick spot checks, a redirect checker that follows every hop shows the full chain and status code for a single URL, which is handy when a developer says a rule is live and you want to see it with your own eyes.
Update everything that points at the old URLs
Redirects are a safety net, not a substitute for clean links. At cutover, update:
- Internal links in navigation, body copy, footers and breadcrumbs.
- XML sitemaps, so they list only the final URLs.
- Canonical tags, which should be self-referencing on the new URLs.
- Hreflang annotations and structured data URLs.
Leaving internal links pointed at old addresses forces crawlers to follow a redirect for every click, which wastes crawl resources and slows how fast Google processes the new structure.
How long should redirects stay live?
Keep them in place for an extended period, and longer for URLs that still receive external links. Keep the old domain registered for an extended period, since letting it lapse lets someone else acquire it and inherit the links pointing to it. Our own rule is simple: if a redirect has any backlink or bookmark traffic behind it, it stays.
Quick checks that validate behavior
- Hop counts on your highest-priority old URLs.
- Server logs showing Googlebot hitting old URLs and receiving 301s.
- URL Inspection in Search Console on the new versions of your critical pages.
- A crawl of the new site confirming no internal link triggers a redirect.
Pro Tip: Sort your redirect map by traffic and test the highest-priority rows by hand in a browser. Automated crawls catch chains, but only a human notices that the page you land on is the wrong page.
What should you test on staging before launch?
Staging is where you catch the expensive mistakes cheaply. The goal is to make launch day boring.
Run this QA sequence:
- Keep staging out of search. Block it with authentication, not just a robots.txt rule, so it can never be crawled or indexed. Then confirm the block is removed from the production build, since a leftover noindex or disallow is a famous cause of post-launch disasters.
- Validate status codes. Every critical URL should return the code you expect: a success status for live pages, 301 for redirects, and an appropriate not-found status for retired ones.
- Check canonicals, hreflang and structured data. Compare them page by page against your parity audit, using a validator for schema.
- Crawl old versus new. Run the same crawler configuration on both sites and diff the results for titles, meta descriptions, headings, word counts and internal link counts. Gaps here are parity failures waiting to become ranking losses.
- Test server behavior under load. Google's crawl budget guidance points to server resources and caching as part of efficient crawling during large site events, and a slow or erroring server at cutover can throttle how fast the new site gets processed. Our note on what to measure and fix for site speed covers the checks worth running here.
- Verify tracking. Fire the key analytics events and conversions on staging, confirm the tag setup carries over, and make sure Search Console ownership is ready for the live property.
Pro Tip: Schedule launch for a low-traffic window and early in the week. If something breaks, you want your developers and SEO lead online, not starting a weekend.
Which Search Console actions matter during the move?
Search Console is where you tell Google what changed and watch how it responds.
- Use Change of Address only for domain or subdomain moves. It is not for URL restructuring within the same domain. Google's Change of Address tool requires verified domain-level properties and should be run only after your redirects and pre-move checks are complete.
- Understand the 180-day window. Once triggered, the tool forwards site-level signals and gives the new site crawling emphasis for 180 days, so keep your redirects and ownership verification intact for at least that long.
- Submit updated sitemaps. Include only final, indexable URLs. Keeping sitemaps accurate is one of the central recommendations in Google's crawl budget documentation.
- Use URL Inspection on priority pages. After launch, inspect your top landing pages and request indexing so they are recrawled sooner.
- Do not block what you need. Review robots.txt so it never disallows sections that should be crawled, and keep unimportant duplicate URLs out of the crawl path.
How do you monitor the migration after launch?
Treat the initial period after launch as an incident window. Check organic sessions, index coverage, top landing pages and conversions daily, then move to weekly reviews once the numbers settle.
Your monitoring checklist:
- Organic sessions and conversions against the frozen baseline.
- Index coverage and crawl stats in Search Console, watching for spikes in errors or excluded pages.
- Rankings for the priority queries you listed in planning.
- Server logs showing Googlebot following redirects and reaching new URLs.
- Backlink tools for high-value links that now point at errors.
- Analytics integrity, including goals, events and referral data.
Use several tools together. Search Console shows what Google thinks, analytics shows what users do, and server logs show what crawlers actually requested. A drop that appears in one but not the others usually points to the cause.
Set expectations carefully. Practitioners generally describe an initial dip that stabilizes within weeks when a migration is well executed, but the long tail is real. A 2026 analysis of 892 domain migrations found:
The spread tells you something: the gap between a three-week recovery and a multi-year one is mostly execution quality, not luck. If nothing has started to improve after a while, stop waiting for indexing to catch up and start looking for structural causes. Keep redirects and domain registration in place throughout, and escalate to a deeper audit when the trend line stays flat.
Why is traffic not recovering, and what do you fix first?
When recovery stalls, work the list from most common to least common. Do not skip ahead to exotic theories before you have ruled out the boring ones.
- Missing redirects, chains and wrong status codes. Re-crawl the old URL list. Any old URL that returns a 404, a 302 or a multi-hop chain is leaking signal. Fix the highest-traffic ones first.
- Accidental blocks. Check robots.txt, meta robots tags and X-Robots-Tag headers for leftover disallow or noindex directives carried over from staging.
- Internal links and sitemaps pointing at old URLs. Crawl the new site and flag any internal link that triggers a redirect. Replace those with final URLs, and confirm sitemaps list only canonical, indexable addresses.
- Lost structured data and metadata. Compare the new templates with your parity audit. Restore titles, descriptions, schema and hreflang where they were dropped.
- Broken tracking. If conversions look like they collapsed, confirm the analytics setup before blaming rankings. A missing tag can mimic a traffic disaster.
Beyond the checklist, watch for what practitioners call migration fatigue: the team finishes the redirects, declares victory, and never returns to content consolidation or parity gaps. If traffic has not begun to recover, the cause may be structural rather than a matter of Google being slow, so resist the urge to simply wait.
Pro Tip: Fix issues in batches and log the date of each change. If you correct ten things in one afternoon, you will never know which one moved the needle.
When should you roll back, and how?
Decide your rollback triggers before launch, while everyone is calm. Examples of objective criteria:
- A sustained, significant traffic loss on your top landing pages.
- Major indexation failures, such as large sections dropping out of the index.
- Critical templates returning errors or the wrong status codes.
- Conversion tracking broken with no quick fix.
If you trigger a rollback, the safe path looks like this:
- Prepare server and DNS rollback procedures in advance, including who has the access and how long propagation takes.
- Re-enable the prior site or restore the previous redirect rules, and avoid creating new chains while doing it.
- If a full rollback is impossible, prioritize signal-restoring fixes: corrected redirects, resubmitted sitemaps and reindex requests for key pages.
- Keep the old domain registered for an extended period and maintain redirect rules until recovery completes.
Our perspective: why cross-team work shortens recovery
Most failed migrations are not technical mysteries. They are handoff failures: design trims a page, development ships a template, and SEO hears about it afterward. Bringing search into planning, QA and launch is the cheapest insurance a team can buy, because the people who know which pages carry the traffic are in the room when decisions are made. A migration run as a shared checklist with named owners beats a heroic cleanup after launch every time. The recovery stories that drag on for months are usually the ones where nobody owned parity.
— Loic
Need a hands-on partner for an SEO-safe migration?
We plan and run migrations as a collaborative project, working alongside your team from the first URL inventory to launch day. That includes technical SEO audits, redirect planning, staging and QA, and analytics monitoring after cutover, all handled in a transparent, hands-on partnership. If you want experienced help protecting your rankings through a redesign or platform change, take a look at our web design and development services and tell us what you are planning.
FAQ
How long does it take to recover after a site migration?
Recovery varies widely. Well-executed migrations often settle within weeks; poorly handled ones can take a year or more. Clean redirects and parity are what separate fast recoveries from slow ones.
Should I use 301 or 302 redirects for a migration?
Use permanent redirects, meaning 301 or 308, for a migration. They tell search engines the move is permanent so signals can transfer. Temporary redirects like 302 keep the old URL as the primary one.
When do I use the Change of Address tool?
Use it only when you move to a new domain or subdomain, and only after your redirects and checks are in place. Google's Change of Address tool forwards signals for 180 days after activation. It does not apply to URL changes within the same domain.
How long should I keep redirects after a migration?
Keep them for an extended period, and longer for URLs that still attract backlinks or bookmarked visits. Keep the old domain registered for an extended period so no one else can acquire it.
