Website Migration SEO: The Pre-Launch Checklist

A redesign moves your pixels. A migration moves your URLs. The agency selling you the redesign usually prices only the first one — and the second one is where the traffic dies.

This is the sequence we'd run before, during, and after a relaunch. It is not glamorous. It is a crawl, a spreadsheet, and a 48-hour check. That boring stack is the difference between a two-week wobble and a six-month rebuild.

Why do most service businesses lose traffic when they redesign?

Three failures cause almost all of it: no redirect map, a staging noindex that shipped to production, or new URLs that quietly dropped the keyword-bearing part of the slug. Every one of them is fully preventable in the week before launch — and every one of them is invisible on launch day, which is exactly why they survive to production.

Google is upfront that some movement is expected. Its site move documentation states that 'the visibility of your content in Search may fluctuate temporarily during the move' and that 'a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer.'

So a dip is normal. A cliff is not. Your job is to know which one you are looking at by week two — and to have the evidence on hand to prove it.

What do you have to crawl and archive BEFORE the old site disappears?

Four artifacts, all captured before launch: a full crawl of every indexable URL, 12 months of Search Console page-and-query data, your top-linked pages, and a rendered copy of the content itself. You cannot build a redirect map from a site that no longer exists — and once the CMS is swapped, the old URL list is gone.

This is the single checklist item that saves people. It costs an afternoon. Skipping it costs a quarter.

• Full crawl of the old site — every URL that returns a 200, with its status code, title, canonical, and meta robots tag. Screaming Frog, Sitebulb, or any crawler will do.
• Search Console export — 12 months of Pages and Queries, so you know which URLs actually earn clicks and which ones nobody has visited since 2023.
• Backlink export — the old URLs with external links pointing at them. These are the redirects you absolutely cannot get wrong.
• Your live XML sitemap, saved as a file. It is the closest thing you have to Google's own view of your URL inventory.
• The content itself — a rendered archive of pages you plan to rebuild, so nothing gets 'lost in the CMS migration.'

Sort the crawl by clicks, not by page count. On most service-business sites, a small slice of pages carries nearly all of the organic traffic — usually the service pages, the top few blog posts, and the location pages. Those get one-to-one redirects and human review. The 200 tag archives from 2019 do not.

If you have never run a crawl of your own site, that is what a technical SEO audit is for, and it is the right thing to do while the old site is still live — not after.

How do you build a redirect map that does not leak equity?

One permanent redirect per old URL, pointing at the closest equivalent new page, resolved in a single hop. Google's redirect documentation is explicit about the difference: with a permanent redirect (301 or 308), 'the indexing pipeline uses the redirect as a signal that the redirect target should be canonical.' With a temporary one (302, 303, 307), 'the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical.'

That one sentence is why a 302 during a permanent migration is a bug, not a shortcut. Google's site-move guidance says to use 'HTTP permanent redirects if possible, such as 301 and 308,' and server-side redirects have, in Google's words, 'the highest chance of being interpreted correctly.'

The rules that keep a redirect map clean:

• No homepage dumps. Redirecting 400 dead URLs to '/' does not preserve anything. Google will read most of them as soft 404s and drop them.
• No chains. Old URL to interim URL to final URL is a chain. Collapse it: every old URL points directly at its final destination.
• Closest equivalent, not closest category. /seo-for-dentists should go to the new dentist page, not to /services.
• Retire nothing silently. If a page is genuinely being killed, decide that on purpose and let it 410 — don't discover it as a 404 in week three.
• JavaScript redirects are a last resort. Google's site-move guidance: 'If none of the server side redirect setups are possible, you can fall back to client side redirects as a last resort.'
• Keep them up. Google's guidance: 'Keep the redirects for as long as possible, generally at least 1 year.' Do not let a developer sweep them out at the next release.

Test the map against the crawl file, not against your memory. Every URL in the pre-launch crawl should resolve to a 200 in one hop after launch. Anything that returns a 404, a 302, or a chain is a defect with a ticket, not a rounding error.

Should you change your URLs at all during a redesign?

If a URL ranks and earns clicks, keep it. The cheapest, safest migration is the one with zero URL changes — Google publishes separate guidance for site moves without URL changes precisely because that path carries far less risk than a URL-changing move.

Designers hate this advice. They want /services/dental instead of /seo-for-dental-practices because it is 'cleaner.' Clean is not a ranking factor. The words in the slug are a relevance signal, and the URL is the thing every backlink you have ever earned points at.

Change your URLs only when there is a real reason: a genuinely broken structure (?p=1427), a domain change, or a consolidation of duplicate pages you actually want merged. 'The new CMS does it differently' is not a reason — it is a configuration you have not fought yet. Any conversion-focused website build that respects your existing organic traffic starts from the old URL list, not from a blank sitemap.

What do you check in the first 48 hours after launch?

Seven checks, in this order, inside 48 hours — most of them take under a minute each. Do them yourself. Do not accept 'the dev team confirmed it's fine.'

• robots.txt — load yoursite.com/robots.txt in a browser. If it says 'Disallow: /', your staging file shipped. This is the fastest, most catastrophic failure to catch.
• noindex — view source on the homepage and three key money pages and search the raw HTML for 'noindex'. Then check the HTTP headers for an X-Robots-Tag.
• Status codes — run your pre-launch crawl file through a status checker. Every old URL should be a 301 to a 200, in one hop.
• Canonicals — the new pages should self-canonicalize to the live https URL, not to a staging domain. A canonical pointing at staging.yoursite.com will deindex the page.
• XML sitemap — regenerated with the new URLs, submitted in Search Console. Google's guidance says to submit the new sitemap and then remove the old one.
• Analytics and conversion tracking — the GA4 tag and form-submit events survived the rebuild. Half of all 'traffic dropped' panics are actually a missing tag.
• Rendering — pull two or three pages through Search Console's URL Inspection tool and confirm Google sees the body copy, not an empty shell.

Then check crawl behavior. Google says that when you change hosting infrastructure, 'it's normal to see a temporary drop in Googlebot's crawl rate immediately after the launch, followed by a steady increase over the next few days.' A crawl-rate dip that recovers is fine. One that keeps falling means Googlebot is hitting something it does not like.

Is a traffic dip after migration normal — and when does it become a failure?

A dip is normal for roughly two to four weeks on a medium-sized site — Google's own wording is that visibility 'may fluctuate temporarily' and that most pages take 'a few weeks' to move in the index. It becomes a failure when the indicators below are still pointing the wrong way at the two-week mark, because at that point the trend is not settling, it is compounding.

Nobody sets this expectation, so owners panic in week one and roll back a fine migration, or stay calm in week four while a real one bleeds out. Use the signals, not your gut:

If two or more columns land on the right-hand side by day 14, stop waiting. That is not the algorithm digesting your move — that is a defect. Work the ranking-drop triage sequence and check whether your old URLs are being read as soft 404s, which is what a homepage redirect dump produces.

And be honest about the baseline: nobody can guarantee a migration lands with zero loss, and any agency that promises it is selling you something. What you can control is whether the loss is a temporary reshuffle or a self-inflicted one.

How do you know if a staging noindex shipped to production?

Load the live page, view the raw HTML source, and search it for the string 'noindex' — then check the HTTP response headers for an X-Robots-Tag. Google's noindex documentation is blunt about the consequence: when Googlebot 'crawls that page and extracts the tag or header, Google will drop that page entirely from Google Search results, regardless of whether other sites link to it.'

Two traps make this harder than it sounds. First, a noindex can live in an HTTP header rather than the HTML, so a browser 'view source' check alone can miss it. Run a header check on your key pages — 'curl -sI https://yoursite.com/ | grep -i x-robots-tag' takes five seconds and catches what the naked eye cannot.

Second, and worse: if you also block the page in robots.txt, Google can never see the noindex at all. Google states that 'if the page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule, and the page can still appear in search results.' The reverse is the failure mode teams actually hit — they remove the robots.txt block on launch day, Googlebot finally crawls the pages, reads the noindex nobody remembered to strip, and drops them.

Google's site-move guidance says it directly: 'Don't forget to remove any noindex or robots.txt blocks that were only needed for the migration.' That means both the robots.txt disallow and the noindex tags. Removing one and forgetting the other is the most expensive half-fix in this checklist.

When do you use Google's Change of Address tool?

Only when your site moves to a different domain or subdomain — and even then, it applies for just 180 days. Google's Change of Address documentation says the effects last '180 days after you start migration in Search Console,' after which Google treats the old and new sites as unrelated.

The tool is explicitly not for HTTP-to-HTTPS moves, for moving pages within the same domain, or for switching between www and non-www. If your redesign keeps the same domain — which is the case for most service businesses — you do not touch it at all.

Two things people misunderstand. Change of Address does not do the work for you: Google states that it 'does not erase the old site from the index,' and old URLs can still show in results if the new site has no equivalent page. And it does not replace redirects — you still need the 301s, and you still need to keep them up for at least a year. If you are moving domains, submit the request for all subdomains and both the www and non-www variants; a partial submission is a partial migration.

What does a safe migration actually cost you?

About one week of extra work spread across the project: a day of crawling and exporting, a day or two building and QA-ing the redirect map, and 48 hours of checks after launch. Against a service business doing $2,500 or more per month in organic-driven work, that week pays for itself the first time a redirect map catches a missing page.

If you are about to relaunch and nobody on the project has said the words 'redirect map' yet, that is your signal. Take our free audit before the new site ships — while the old URLs still exist and the migration is still fixable — or look at how we approach a website rebuild that keeps its rankings. Get my free audit.