The Website Migration Checklist

A migration is where a site quietly loses its Google traffic. It's almost never something advanced. It's a redirect nobody wrote, a page title that didn't carry across, or one box left ticked.

Work through this before, during and after the move. Your ticks save in this browser so you can come back to it, and it prints cleanly if your developer wants it on paper.

Site: ______________________________ Launch date: ________________ Owner: ________________

1. Before you build (7 items)
2. Before launch (15 items)
3. Launch day (11 items)
4. The first week (6 items)
5. The months after (4 items)

Stage 1 of 5

Before you build: save a dated baseline

Write down what the site looks like today, with the date on it. If traffic moves after launch, this is what tells you whether the move caused it.

• Export your top pages by clicks from Search Console.Performance, then the Pages tab. Take the last 3 months and the same months a year ago, so a seasonal dip doesn't fool you later. These are the pages you can't afford to lose.
• Export your top search queries too.What each important page shows up for, and roughly where. It's how you'll know after launch whether a page still shows for the same searches.
• Record traffic and enquiries from GA4.Organic sessions, and the enquiries or sales they bring in, by landing page. Rankings matter because of what they bring in, so measure that too.
• Crawl every URL on the current site.Every address with its status code, title, meta description and canonical. Screaming Frog is free up to 500 URLs; bigger sites need a full crawl. Add the URLs from your XML sitemap and Search Console that the crawl missed, plus PDFs and images that get traffic. A URL nobody listed is a URL nobody redirects.
• List the pages other sites link to.Search Console's Links report shows your top linked pages. Those links point at specific old addresses, so those pages need a redirect most of all, even if they get little traffic.
• Save it all in one dated folder, with the planned launch date.If traffic falls later, this is what stops the drop being blamed on an algorithm update for three months while nobody fixes it.
• Launch outside your busiest trading period.Google has to reprocess every changed URL after a move, and rankings can move while it does. Don't let that land on the quarter that pays the bills.

Stage 2 of 5

Before launch: map, protect and test

This is where most of the work is, and where most of the damage is done or avoided. Fix problems here, not three months after launch.

• Keep every URL that doesn't need to change.The safest redirect is the one you never need. Only change an address when there's a real reason to.
• Build a redirect map: every changed URL to its closest new match.One row per old URL in a spreadsheet, ready for your developer, saying whether it stays, moves or is retired. Every link you've ever earned points at the old addresses, and without a redirect it points at nothing.
• Make every redirect a 301, straight to the final page in one hop.A 301 tells Google the move is permanent and passes the old page's signals to the new one. Don't chain redirects (old to older to new): map each old URL straight to where it ends up.
• Never send everything to the homepage.Google can treat a redirect to an unrelated page, like the homepage, as a soft 404, and the value of the old page is lost. It looks tidy and quietly throws your links away.
• Give every page with no new home a decision.Rebuild it if it earns clicks or links, redirect it to the closest real match (a parent category or a successor page), or let it 404 on purpose if it's genuinely dead. Start with the pages worth the most.
• Carry over titles, meta descriptions and headings on your top pages.New templates get built from scratch, and these get rewritten or dropped without anyone deciding to. Compare old and new side by side.
• Keep the content on pages that already rank.Whatever makes a page rank is in there somewhere, and you can't always see it. Add to a page that ranks. Don't replace it because it looks old or doesn't match the new brand.
• Update internal links to the new URLs.Menus, footers and links inside your content should go straight to the new address, not through a redirect. Check no important page has lost every link pointing to it.
• Point canonical tags at the new URLs.A canonical still pointing at the old address tells Google the old one is the real page.
• Carry over your structured data.Product, organisation, breadcrumb and other schema often doesn't make it into new templates. Check it's there and matches what's on the page.
• Selling in more than one country or language? Update hreflang.Hreflang tags that point at old addresses stop working. Treat it as its own job, not a row in the redirect map.
• Set up analytics and conversion tracking on the new site.GA4, ad tags and enquiry or sale tracking, tested before launch. If tracking breaks on launch day, you can't tell a real drop from a broken tag.
• Check Google and AI crawlers can read the new site.If the content only appears after JavaScript runs, as with many React or vibe-coded builds, AI crawlers that don't run JavaScript get a blank page, and Google can miss content when rendering fails. Ask your developer for server-side rendering or plain HTML, and treat a blank page as a launch blocker. Test a staging page with Can AI See Your Page?
• Crawl the staging site before launch.Check every template, not just the homepage: broken links, unexpected noindex tags, canonicals pointing the wrong way and missing content. Fix what it finds before launch day.
• Keep the staging site out of Google while it's being built.Password-protect it or block it from indexing, so a half-finished copy never gets indexed. Then plan who removes that block on launch day.

Stage 3 of 5

Launch day: unblock, redirect, submit

Most of this takes minutes. Skipping it is how a site goes invisible and nobody notices for days.

• On WordPress, untick “Discourage search engines from indexing this site”.It's under Settings, then Reading. This is the box that cost Harry about 50,000 visits. On another platform, find its equivalent setting and check it's off.
• Remove any leftover staging noindex.Check your key pages for a noindex tag or header left over from staging. Run them through the Noindex Checker.
• Check robots.txt on the live site, line by line.Make sure it isn't still blocking the whole site from staging (Disallow: /). Don't block the old URLs either: Google has to crawl them to see the redirects. Test it with the Robots.txt Tester.
• Turn the redirects on and test them.Every changed URL should land on the right new page, in one hop, with a 200 status. URLs that didn't change should still return a 200 themselves, and pages you retired on purpose a 404 or 410. Include the awkward ones: query strings, trailing slashes, uppercase letters and paginated pages. Use the Redirect Checker, and re-check any failure by hand before you believe it.
• Check the old URLs redirect, and aren't still loading as pages.If the old addresses still load, you have two copies of the site competing with each other.
• Submit the new XML sitemap in Search Console.List only live, indexable pages on the new site that return a 200, not redirects or old addresses.
• Changed domain? Use Change of Address in Search Console.Verify the new domain in Search Console, then use the Change of Address tool in the old property's settings. It tells Google the whole site has moved, and it needs the 301s to be live first.
• Crawl the live site.The same crawl as staging, now on the real thing, to catch anything that changed on the way live.
• Spot-check your top pages by hand.Open the top pages from your baseline. Right content, right title, canonical pointing at itself, the page loads and the forms work.
• Make a test enquiry or test order.Check it shows up in GA4's Realtime report and wherever your leads or sales are recorded.
• Update the links you control elsewhere.Google Business Profile, social profiles, ads, email signatures and your main directory listings should point at the new addresses.

Stage 4 of 5

The first week: check every day

Don't wait a few days to look. Harry's 50,000 visits went in the days between launch and his first check.

• Check Search Console and GA4 every day, starting on launch day.A problem you find on day one costs you a day. Found in month three, it's cost you a quarter and it's much harder to trace.
• Watch the Pages report in Search Console.It shows which pages are indexed and why others aren't. Look for “Excluded by ‘noindex’ tag”, “Blocked by robots.txt” and new “Not found (404)” pages.
• Fix unexpected 404s straight away.A 404 on a page you meant to keep or move is a missing row in your redirect map. Add the redirect now, while the page's value is still there to pass on. Pages you retired on purpose can stay 404.
• Check Crawl stats for errors.Search Console, Settings, then Crawl stats shows what Google gets back when it visits. Server errors or 404s climbing on the new site mean stop and investigate.
• Run your top pages through URL Inspection.It shows whether Google has picked up the new page and which canonical it chose. Test live URL, then View tested page, shows whether Google can see your content.
• Compare traffic and enquiries with the same days before launch.Some movement in the first fortnight is normal while Google reprocesses the site. A fall that keeps going isn't.

Stage 5 of 5

The months after: dated check-ins against your baseline

Put these in your calendar on launch day, with the dates written down, not “watch it for a few weeks”.

Your launch date Add it and each check-in below shows its date. It saves in this browser with your ticks.

• 2 weeks after launch: compare with the baseline. Clicks and impressions for your top pages, how many pages are indexed, and any new 404s. Look for important pages that have dropped out entirely.
• 1 month after launch: compare again, and crawl the new site. A steady decline past four weeks, or replacement pages missing from the index, is a problem, not noise. Bigger sites take longer to settle, and on a domain move the old site's pages dropping out is expected while the new ones appear. The crawl catches broken links and redirect chains that crept in.
• 3 months after launch: the full comparison. Top pages, queries, traffic and enquiries against the baseline you saved, and against the same months last year. This answers “did the move cost us anything?”, and tells you which pages to fix first.
• Keep the redirects in place, and keep the old domain.Don't remove them in a later clean-up: keep them for at least a year, and for as long as anything still links to an old address. On a domain move, keep the old domain registered and its hosting or redirect service running, or every redirect switches off with it.