Site migration SEO checklist

Most migrations don't fail because someone forgot a "best practice." They fail because one boring thing is wrong on launch night: a leftover noindex, a sitemap still pointing at staging, or 8,000 URLs all 301'd to the homepage.

This is the cutover workflow we actually use. It's the same sequence the homepage on Scrawl already points at. Google's own site move documentation is the source of truth for the rules. This is the order we run them in, and the places people usually skip.

You do not need a paid crawler to get through it. A desktop spider still helps on a 200k-URL catalog. For a typical site, browser checks plus Search Console are enough.

What counts as a migration

Google treats any change to existing URLs as a site move:

• HTTP to HTTPS
• Domain or hostname change (example.com to example.net, or merging hosts)
• Path changes (/page.php?id=1 to /widget)

A hosting swap with the same URLs is a different job. Don't run a URL-move playbook on that.

Two rules from Google that save arguments later:

1. Change one thing at a time. New domain and new CMS and a redesign in the same weekend is how you lose a month debugging the wrong layer.
2. Rankings wobble while Google recrawls. Medium sites often take a few weeks. Bigger ones take longer. That's expected, not a reason to roll back on day three.

Google also says permanent redirects (301, 308) do not cause a PageRank loss. The damage comes from chains, loops, and dumping everything on the homepage.

Before you touch DNS

1. Verify both properties in Search Console

Old site and new site. www and non-www. HTTP and HTTPS if both still resolve. If Search Console verification is an HTML file or a meta tag, that token has to exist on the new site before you flip traffic. People forget this constantly.

Leave crawl-rate on "Let Googlebot determine." If you ever uploaded a disavow file on the old property, upload it again on the new one. Google does not carry it over.

On a bought domain, check for leftover URL removals and old manual actions. A site-wide removal from a previous owner will make the new site look cursed.

2. Build the old URL list from more than one place

One export is never the whole site. Pull from:

• The XML sitemap (and any child sitemaps)
• Search Console (pages that actually get impressions)
• Analytics (URLs with sessions in the last 12 months, not last week)
• The CMS
• PDFs, images, and other files that rank or get linked

If you only map what the CMS thinks exists, you miss the leftover blog pagination, the old PDF whitepaper, and the parameter URL a partner still links to.

Paste that list into the Bulk URL Checker and save the CSV. You want a pre-launch baseline: what's 200, what's already a 301, what's already dead. After cutover you'll run the same list again and diff it.

Cap is 1,000 URLs per run. For bigger sites, do the money pages first, then the rest in batches. That's fine. Google's process is per-URL anyway.

3. Map every old URL to one new URL

This is the actual work. Everything else is QA.

• Closest equivalent page, not "we'll sort it out later"
• Retired content should 404 or 410 on purpose. Don't invent a destination
• Never 301 a pile of unrelated URLs to /. Google can treat that as a soft 404, and users bounce
• If you merged three old articles into one, all three old URLs can point at the new one. That's a consolidation, not a dump

Keep the map in a spreadsheet with three columns: old URL, new URL, notes. You'll reuse it for internal links, canonicals, and the post-launch crawl.

4. Get staging honest before it becomes production

Staging is where migrations go to die, quietly.

• robots.txt on staging can block everything. That's fine. Have the production robots.txt written and sitting in a tab, ready to deploy. Test it in the Robots.txt Tester against the URLs you care about
• If you used noindex to keep staging out of Google, make a list of every URL that must lose it. Then check the list. The Bulk Meta Robots Checker reads both the meta robots tag and X-Robots-Tag, which is the one people miss because it never shows up in View Source
• Self-referencing canonicals on the new URLs. Not the old ones, not staging, not a parameter variant. Spot-check with the Canonical Checker
• Internal links on the new site should already point at new URLs. Redirects will catch stragglers. Users and crawlers shouldn't have to bounce through them
• Hreflang, if you have it, needs the new URLs in every language annotation. One stale locale cluster will keep the old host alive in the index
• Analytics / tag manager on the new templates. Confirm a hit lands before you celebrate

Google's recommendation if you can swing it: move during a quiet period. Fewer users hit the messy hour, and more server is left for Googlebot, which will crawl harder than usual after the flip.

Launch

5. Turn on server-side permanent redirects

301 or 308. Not a meta refresh. Not JavaScript. Not a 302 you "promise to change later."

Googlebot will follow up to 10 hops. Don't use that as a budget. Their advice is: land on the final URL directly, and if you can't, keep the chain under 3, never more than 5. Extra hops are slow for people and a good way to leak a slice of equity.

Check the ugly ones with the Redirect Chain Checker: old HTTP www, old HTTP apex, a leftover /index.php, anything marketing has been pasting into ads for three years. If A then B then C, write A then C and delete B.

Keep redirects up at least a year. Google says that in plain language. Longer is better for humans clicking old links. Update the high-traffic backlinks you can actually reach so those people stop using the redirect.

6. Change of Address is not a magic wand

Use Search Console's Change of Address only when the hostname changes. example.com to example.net. a.example.com to b.example.com.

Skip it for:

• HTTP to HTTPS
• www to non-www on the same domain
• Path-only reshuffles

It does not replace redirects. Submit it after the 301s are live, and do it for every verified variant of the old host.

7. Sitemaps

Submit a sitemap of the new URLs. You can leave the old sitemap in Search Console for a bit — Google will show "these URLs redirect" warnings. That's the point. Don't treat those warnings as errors.

Then audit the new sitemap so you didn't just publish a list of 301s and noindexed thank-you pages. The Sitemap Auditor flags 404s, redirects, and blocked URLs inside the sitemap. The XML Sitemap Validator is the syntax pass if a plugin wrote the file.

The morning after

8. Re-run the same URL list

Same CSV as step 2. You're looking for:

• Old URLs that are not 301/308
• New URLs that are not 200
• Anything 404 that should have a destination
• Anything 200 on the old host (DNS or cache lying to you)
• Homepage as a surprise destination

If titles, descriptions, or H1s were part of the rebuild, run those URLs through the SEO Content QA Checker against the spec you signed off. Migrations love to ship the right URL with the staging title still in the template.

9. Confirm Google can index the new URLs

Pick 10 to 20 money pages and run them through the Google Index Checker. You're not asking "are we done?" on day one. You're asking "did we leave a noindex, a robots block, a canonical pointing backward, or a redirect loop on the pages that pay the bills?"

URL Inspection in Search Console is the other half of this. Use both. They disagree sometimes, and that disagreement is useful.

10. Watch the two sites at once

Old host traffic should fall. New host traffic should rise. If both go flat, the redirects aren't being hit. If the old host stays busy, something still resolves there — a CDN variant, a forgotten subdomain, ads.

In Search Console, watch:

• Index coverage / pages on both properties
• The new sitemap's indexed count climbing
• A spike in 404s or "crawled, currently not indexed" on the new host
• Queries starting to show new URLs

Server logs matter more than a dashboard screenshot. Googlebot will hit you harder after a move. If the server falls over, crawling slows, and the migration just stretches.

Give it time. Google has to see every old URL and every new URL at least once. There is no SLA.

The mistakes that keep showing up

Staging protections left on. noindex in the header. Disallow: / in robots.txt. A basic-auth wall that only some URLs sit behind. This is still the number one way a "successful" launch stays invisible.

Wrong redirects. Map said /pricing. Server sent people to /pricing-2 which 404s. Crawl a sample. Don't trust the config file you wrote at 1am.

Soft 404 via homepage. It's tempting. It's also how you teach Google the old URLs never had a real home.

Sitemap still listing the old world. Or listing new URLs that redirect. Fix the file, resubmit.

Not enough server. You moved. Googlebot brought friends. Tell hosting before, not after the 502s.

HTTPS move with mixed leftovers. One canonical still on http://, one HSTS hole, one internal link to the old scheme. Treat HTTP to HTTPS as a real URL move, because it is one.

What this checklist does not replace

A browser toolkit will not render every JavaScript route on a 400k-URL site or replay a year of log files. If that's your site, use a desktop crawler for the full graph and use the checks above for the parts that break on launch night: status codes, redirect hops, robots, canonicals, sitemap hygiene, indexability.

Screaming Frog's own migration guide is fine. So is Aleyda Solis' checklist. Google even points at both. The difference here is you can run the QA without a license and without waiting for a crawl to finish.

Tools used in this workflow

• Bulk URL Checker — baseline and post-cutover status codes
• Redirect Chain Checker — hop count, loops
• Robots.txt Tester — production rules before go-live
• Bulk Meta Robots Checker — leftover noindex, including X-Robots-Tag
• Canonical Checker — self-referencing new URLs
• Sitemap Auditor / XML Sitemap Validator
• Google Index Checker — money-page sanity check
• SEO Content QA Checker — titles, descriptions, H1s after the rebuild