Site migration SEO checklist: the config checks that decide whether traffic survives

8 min read

Redesigns, replatforms, domain moves and "we're switching to a new framework" all share one risk: a handful of invisible settings decide whether Google keeps sending traffic. Content and design get weeks of review. The robots.txt file usually gets none.

This checklist focuses on the configuration that breaks most often during a migration, in the order you need it.

Before launch

1. Crawl and record the old site

Export every indexable URL (from your sitemap, a crawler, and Search Console's Pages report) together with its status code, canonical, meta robots and title. This is your baseline and your redirect source list. Without it, you can't tell what changed.

2. Build the redirect map

• Every old URL that had traffic or links maps to its closest equivalent new URL with a single 301. Redirecting everything to the home page is treated like a soft 404.
• No chains: old → interim → new should become old → new. Check http→https and non-www→www hops too.
• Keep query-string and trailing-slash behaviour consistent with how the new canonicals are written.

3. Decide how staging is protected

If staging relies on noindex or a Disallow: / robots.txt, those settings are one config value away from shipping to production. Prefer HTTP authentication or an IP allowlist on staging, so production never needs to "turn something off" at launch. (Why this matters: accidental noindex.)

4. Write down the expected production values

For your 10–20 most important URLs, note what each should look like after launch: status 200, no noindex in HTML or headers, self-referencing canonical on the production host, allowed by robots.txt. That list becomes your launch-day test.

Launch day

Run these checks against the key URLs immediately after the switch, and again after any CDN cache purge:

1. robots.txt is the production version and doesn't block important paths for Googlebot. Test specific URLs with the robots.txt tester; it shows the exact deciding line.
2. No noindex in the meta robots tag or the X-Robots-Tag header. The header is easy to miss: here's how to check it.
3. Canonicals are absolute, on the production host and protocol, and self-referencing. No staging or old-domain hostnames (common causes).
4. Redirects from a sample of old URLs land on the right new URL in one hop:

   curl -sIL https://old.example.com/pricing | grep -iE '^(HTTP|location)'

5. XML sitemap lists only new, final, indexable URLs (200, not redirected, not noindexed, not canonicalised elsewhere), and robots.txt points to it (common sitemap breakages).
6. Titles aren't the framework default ("React App", "Home", the CMS name) on templates you didn't hand-check.
7. HTTPS works with a valid certificate on every hostname that receives traffic, including www and the bare domain.

Our free SEO config check checks 1–3 and 7 for a single URL and shows its title and redirect chain, so you can paste in key URLs one by one.

Then, in Search Console: submit the new sitemap, inspect a few key URLs, and, for a domain move, use the Change of address tool on the old property.

The weeks after

• Keep the old redirects for at least a year, ideally permanently. Removing them early throws away the signals they pass on.
• Watch Search Console's Pages report for spikes in "Excluded by 'noindex' tag", "Blocked by robots.txt", "Page with redirect" and "Duplicate, Google chose different canonical than user".
• Compare traffic by page group, not just site-wide. A template-level bug can hide behind overall numbers that look fine.
• Re-run the launch-day checks after every release for the first few weeks, or automate them.

Quick reference