SEO migration checklist: before, during and after a site move

An SEO migration checklist is the list of things to do before, on and after launch day so a site move keeps its traffic: inventory every old URL, redirect each one in a single 301 to its new equivalent, remove the staging noindex, point canonicals and sitemaps at the new URLs, tell Google, and verify every old address after launch. This page is that checklist, in order, with the getReport checks that confirm each step and a printable table at the end. It works for a new domain, a move to https, a new CMS or a new URL structure. For why migrations lose traffic and how to plan one, read the website migration guide first.

Quick answer

• Before: export every URL (sitemap, Search Console, analytics, backlinks), build and test the redirect map, benchmark rankings, traffic and key pages, freeze content, lower the DNS TTL.
• Launch day: new site and 301s live in the same deploy; staging noindex removed; canonicals, hreflang and sitemap on the new URLs; sitemap submitted; Change of Address for a domain move.
• After: run the old URL list through the migration redirect validator or the bulk URL checker and expect one 301 to a 200 on every row; watch Search Console weekly for 8 weeks; keep the redirects for at least a year.
• The three classic failures: staging noindex left on, redirect chains, and a redirect map that sends everything to the home page.

Which parts of the checklist you need

The risk depends on whether URLs change. A host move keeps every address; a domain change replaces all of them.

A host move needs only steps 5, 7, 8, 9 and 14. A redesign on the same URLs needs the benchmark and staging checks; website redesign SEO covers the rest. Moves with their own traps have their own guides: changing domain name, moving to https and the WordPress site migration checklist.

Before the move

1. Inventory every URL. Export the sitemap, the Search Console Pages report (indexed and not indexed), the landing pages of the last 12 months from analytics, and the top pages by links from your backlink tool. Merge and de-duplicate into one sheet: it is both the redirect map's left column and the after-launch test list.

2. Build the redirect map. One row per old URL with its new URL; redirect mapping for a site migration covers collecting, matching and testing it. The rules:

• Every old URL gets a target with the same intent: the same product, article or category. No equivalent: the closest parent, or a deliberate 410.
• The target is the final form of the new URL (scheme, host, trailing slash), so it lands in one hop.
• No catch-all to the home page: Google treats those like soft 404s.

3. Benchmark. For the top 50 pages, record rankings for their main queries, sessions from search and a getReport link each (the report URL is kept for 12 months, so it is your before picture). Save the origin's 40-week field data from the Core Web Vitals history tool.

4. Freeze content. From the inventory export until launch, no new URLs on the old site; anything published in that window will not be in the map.

5. Test on staging. With the new site at a staging address set to noindex, run the SEO audit on four key pages: the home page, a product or post, a category and a deep page. Expect exactly one failing SEO finding, robots-meta-noindex, and fix everything else now. The report only reaches public addresses: staging on localhost, a private network or behind HTTP basic authentication cannot be fetched, so give staging an obscure public hostname plus noindex, or run the report in the first minutes after launch.

6. Test the redirect map on staging. Load the rules on staging and run the old paths against it. If staging is public, paste the old paths and expected targets into the migration redirect validator, which gives each pair one verdict: correct, wrong target, not redirected or gone, chain, temporary, or a broken or noindex target.

7. Lower the DNS TTL. A week before a domain or host move, set the TTL of the records that will change to 300 seconds, so the switch propagates in minutes.

Launch day

8. Switch and redirect at the same moment. The new site goes live and the old addresses start answering 301 in the same deploy. Hours of 404s on old URLs are hours Google may crawl.

9. Run the report on the four key pages. These findings are the migration classics:

The staging noindex rides along with the database or the theme into production. The check reads both the meta tag and the X-Robots-Tag header. In WordPress, also confirm Settings → Reading → "Discourage search engines" is unticked (the WordPress Doctor's wp-discourage-search finding).

After a domain move, canonicals are the tags most often left on the old host, because the CMS stored absolute URLs. The companion canonical-self-or-valid finding checks where the tag points and what that URL answers.

Two hops (http → https, then old host → new host) is the default result of two separate rules; redirect chains shows how to make it one.

10. Point every signal at the new URLs. Canonical tags, hreflang, the XML sitemap, og:url, structured data @id and url values, and internal links. In WordPress, run a serialisation-aware search-and-replace of the old host (wp search-replace or Better Search Replace, after a backup).

11. Tell Google. Submit the new sitemap in Search Console. For a domain move, use Change of Address on the old property; it applies only to domain changes, not https or path changes, which Google picks up from the redirects. Keep the old property: its reports show the old URLs draining.

12. Move the measurement. Analytics tag, consent banner, tag manager container and conversion pixels on the new site, with the new hostname in their settings.

After the move

13. Check every old URL. The hour after launch, paste the redirect map into the migration redirect validator, or the plain inventory into the bulk URL checker (up to 1,000 per run). Every row should be one permanent redirect (301 or 308) to a page that answers 200.

Filter to "Needs a look" and work through chains, 4xx, temporary redirects and noindex rows.

14. Crawl the new site. Any crawler: it should find only new URLs, no links to the old host, no 404s and no stray noindex.

15. Watch weekly for 8 weeks. Search Console: "Page with redirect" rising on the old property, "Indexed" rising on the new one, "Not found (404)" and "Excluded by noindex tag" flat. Analytics: search sessions against the benchmark. Core Web Vitals history: the new origin against the old once four to six weeks of field data exist. Google's site move documentation says a medium-sized site can take a few weeks for most pages to move in its index, and larger sites longer.

16. Update the links you control. Google Business Profile, social profiles, directories, email signatures, ad campaigns and partner sites.

17. Keep the redirects. At least a year, as Google's guidance for site moves with URL changes says, and in practice for as long as the old URLs get visits or links.

The printable checklist

Print this page (the site header and footer are left out of the printout) or copy the table into your project tracker.

Platform notes

• WordPress. The database stores absolute URLs in content, options and serialised theme settings, so a domain change needs wp search-replace old.example new.example --all-tables or Better Search Replace. Set the new address under Settings → General first. The Redirection plugin's CSV import loads a redirect map in one step.
• Shopify. Shopify handles https and the primary domain itself; your part is the redirect map under Content → Menus → View URL redirects (CSV import). Its URLs follow a fixed pattern (/products/, /collections/), so a move onto Shopify always changes paths.

Common mistakes

• Staging noindex in production. The most expensive migration mistake, found by one report on the home page. Run it in the first ten minutes after launch.
• Redirecting to the home page. Fast to set up, useless to Google, confusing to visitors. Every old URL gets its own target or a 410.
• Two-hop redirects by design. http → https at the CDN, old host → new host at the origin. Combine them into one rule.
• Canonicals on the old host. The new pages tell Google to index old URLs that redirect back to them. Search-and-replace the database and check one page in the report.
• Removing the old Search Console property. It is the only place that shows the old URLs draining. For checks that apply to any launch, see the pre-launch website checklist.

Questions people ask

What should an SEO migration checklist include?

It should cover three phases. Before launch: a full URL inventory, a tested redirect map, a benchmark of rankings and traffic, and staging checks. On launch day: redirects live with the new site, the staging noindex removed, canonicals and sitemaps on new URLs, and Search Console updated. After launch: every old URL checked, weekly monitoring for about 8 weeks, and redirects kept for a year or more.

What should I check after a website migration?

Check every old URL first: each should answer one 301 to its new equivalent, which answers 200. Then run a report on your key templates for noindex, canonicals, robots.txt and the sitemap, crawl the new site for links to the old host, and watch Search Console's Pages report and search traffic weekly against your benchmark for about two months.

Do I need the full checklist for a host move with the same URLs?

No. When every URL stays the same, there is no redirect map and nothing to tell Google. You still need the staging report, a lowered DNS TTL, a check that the new server is not slower or set to noindex, and a crawl after the switch. Watch server errors and response times in Search Console's Crawl stats for the first weeks.