Tool

Site migration SEO checklist

By Sunny Patel · Updated 2026-09-20

A site migration SEO checklist is the set of checks that keep a domain, platform, or redesign move from losing pages, rankings, or AI crawler access. The biggest risk is discovering the damage weeks later, after traffic has already dropped and nobody can say exactly which change caused it. The fix is a before-and-after comparison: crawl the old site, crawl the new one, and work from the actual difference instead of checking URLs one at a time from memory.

Run this before you touch the old site. Keep the permalink for reference, since Compare always reads the scan immediately before the one you are viewing, not this original one.

What you get

A crawl snapshot of the current site, with a shareable permalink, taken before the migration starts.
A post-launch rescan and diff of the same domain: added and removed pages, plus per-page flag, click-depth, and AI-score changes of 5 points or more. It does not read arbitrary content or metadata edits, and it does not list redirect chains.
Orphan-page and broken-link counts inside that diff, shown only when both scans are untruncated, meaning the whole site fit inside the free page cap or a usable sitemap.
An optional weekly rescan for the weeks after launch. It needs a confirmation click from your inbox to start, always crawls up to 50 pages, and keeps running until you cancel it or two years pass, whichever comes first.

Free scans cover 20 pages, 50 with an email unlock, or up to 150 URLs when a usable sitemap lists them; a larger site gets partial coverage until a fuller crawl runs, and exports list the URLs actually crawled, not the whole site.

See a worked example action report to see how crawl findings turn into a prioritised, explained action list.

Before: crawl and snapshot the current site

Do this while the old site is still live. This is the only record of what it looked like to a crawler once it is gone.

Run a full crawl and save the snapshot permalink. (why: keep it for reference; Compare always reads the immediately previous snapshot, not this one, and it expires after 90 days.)
Build a URL inventory from Search Console, your CMS, and a sitemap.digital crawl. (why: a redirect map missing a row sends that page straight to a 404 on launch day, and a single crawl may not reach every URL on a large site.)
Build the redirect map, one old URL to one specific new URL. (why: a redirect to the homepage instead of the matching page passes far less ranking value than a direct match.)
Audit canonical tags and noindex rules on the old site, as a separate check from the redirect map. (why: noindex stops a page being indexed, not crawled, and does not by itself decide whether that URL still needs a redirect.)
Check sitemap parity between the URL inventory and the live sitemap.xml. (why: a page missing from the old sitemap is easy to leave out of the migration plan entirely.)

During: build and test on staging

The new site exists but is not public yet. Every check here is about keeping it that way until launch, while still testing it properly.

Crawl the staging environment the same way you crawled the old site. (why: it catches template and navigation problems while they are still cheap to fix.)
Test every redirect from the map on staging, not just a sample. (why: a redirect rule that works for ten test URLs can still fail on a pattern only a few hundred other URLs use.)
Add a robots.txt disallow and a noindex tag to staging, plus a login wall or IP restriction if you can. (why: noindex alone does not stop a page being crawled, only indexed; a real access restriction is what actually keeps staging off search engines and AI crawlers.)
Check for a staging URL leaking into production, such as a hardcoded internal link or a canonical tag. (why: one leaked link can pull a crawler onto a domain that should never be public.)

After: rescan, diff, and confirm

The new site is live. This is where a lot of migration damage actually gets found, because it is the first point you can compare against the pre-migration baseline.

Rescan the live domain and compare it against the pre-migration snapshot. (why: the diff lists which pages were added or removed and which pages changed flags, click depth, or AI score, instead of leaving you to check from memory; this only works when both scans are the same domain.)
Check the removed pages list against your redirect map, then confirm each one directly. (why: a page missing from the new crawl is not automatically proven to 404 or 410; check its live status before treating it as broken.)
Check for new orphan pages the redesign disconnected. (why: a page can survive the migration with a working URL and still lose every internal link that pointed to it; the diff only reports this when both scans are untruncated.)
Manually check any redirected page for a chain longer than one hop, using a redirect-checking tool. (why: sitemap.digital records whether a page redirected, not how many hops the chain took, and each extra hop loses more of the signal the redirect was meant to pass through.)
Check the AI readiness score change of 5 points or more on pages the diff flags. (why: a new template can quietly strip the schema, metadata, or real HTML content a page had before, even when it looks identical in a browser.)
Confirm AI crawler access on the new robots.txt. (why: some deploy processes carry the staging block rules into production by accident and leave the live site invisible.)
Check Search Console for a spike in crawl errors or a drop in indexed pages. (why: it is an independent source that confirms Google actually processed the change, rather than just the change existing on your side.)

How sitemap.digital does the before and after

Run a scan on the old site before the migration starts. That scan gets a shareable permalink, which is what later comparisons read from. Paste the same URL and run a second scan once the new site launches, on the same domain: Compare with previous scan only works between two scans of the same host, so a full domain move needs its two scans viewed side by side rather than diffed automatically.

There is no single button that compares your latest scan against a pinned original baseline. Open a scan and Compare shows the change since the scan immediately before it, so open the newest scan from History to see the change since the previous one, or open any older snapshot to see the change since the one before that. Keep the original permalink regardless, since a stored snapshot expires 90 days after it ran.

The diff matches pages by their final URL, so a renamed URL reads as one removed page and one added page, not a rename; check your own redirect map separately to confirm it really is a rename. Pair the diff with the visual sitemap generator to see the before and after structure as a map instead of a list of rows.

The same scan also offers an optional weekly rescan. It needs a confirmation click from your inbox before it starts, always crawls up to 50 pages regardless of any other unlock, and keeps running every week until you cancel it or two years pass, whichever comes first. Running it for about four weeks after launch is a reasonable rule of thumb for the usual settling period, not a limit the product enforces.

Questions about migration snapshots

Do 301 redirects preserve rankings after a migration?

Mostly, when the redirect map is correct. A one-to-one 301 from every old URL to its direct replacement passes most ranking signals across. A redirect to the wrong page, a chain of several redirects in a row, or an old URL with no redirect at all loses value even when the destination content is fine. Check your redirect map against the old URL inventory rather than assuming the migration tool handled every row.

How long does a migration traffic dip usually last?

It varies by site, but a few weeks is common while search engines recrawl and reprocess every changed URL; a large site or a slow crawl rate can push that longer. A short dip in the first week or two is unsurprising on its own. A dip that keeps widening past several weeks usually points to a specific fault, such as a missed redirect, an accidental noindex, or a broken internal link pattern, rather than the ordinary settling period.

Should I change the content and the design in the same migration?

Not at the same time, where the timeline allows it. Migrate the platform or design first, confirm the site is stable, then run content changes as a separate, later step with its own comparison. Changing both at once makes it harder to tell which change caused a ranking or traffic move if something goes wrong, because the two effects are tangled together in the same before-and-after comparison.

What should I do about the staging site before launch?

Add a robots.txt disallow so crawlers stay off it, and a noindex tag as a second layer in case something still reaches a page; noindex alone does not stop a page being crawled, only being indexed once crawled. A login wall or IP restriction is stronger than either. Check this before launch and again straight after, since some deploy processes copy the staging rules into production by accident and leave the live site noindexed.

How do I find pages a migration lost?

Compare a crawl snapshot taken before the migration against a rescan taken after it, on the same domain. sitemap.digital's diff lists every page that was in the first scan and is missing from the second as a removed page, alongside any page that is now an orphan with no inbound links. Confirm a page is genuinely gone by requesting its URL directly, since dropping out of a capped crawl does not by itself prove a 404 or 410.

Take your pre-migration snapshot now, while the old site is still live.

Scan your site

Want this done for you? The AI Visibility Audit is a fixed-fee consultancy audit from Sunny Patel, the SEO consultant behind sitemap.digital: a full crawl, a written report and a prioritised fix list. From £495.

See the AI Visibility Audit