SEO Migration Checklist: Before, During and After Launch

An SEO migration checklist keeps a site move from costing the search visibility it has earned. If you'd rather have it planned and signed off for you, see my SEO migration services. It applies to domain changes, replatforming, URL restructures, HTTPS moves, merging sites and moving into an international folder structure. Every one of these changes the addresses Google has indexed, and every one can go wrong in the same predictable ways.

Most migrations that lose traffic are not unlucky. They skip steps. This site migration checklist is organised by phase so you can hand each part to the right owner and know what "done" looks like before you move on.

What counts as a migration, and how risky is yours?

Not every migration carries the same risk. Knowing which type you are running tells you where to focus.

The last row is the one I push back on most. When a redesign, a new CMS, new URLs and a content cut all launch together, and traffic drops, nobody can tell which change caused it. If you can split a large change into stages, do.

Google's own site move with URL changes guide is the primary reference. The checklist below is how I turn it into a working plan.

Phase 1: Before launch

This phase takes the longest and determines most of the outcome. Start it weeks before the launch date, not days: planning typically runs 2–6 weeks before launch, depending on the size of the site.

Build a complete URL inventory

A crawl is not enough on its own. Combine:

• A full crawl of the current site in Screaming Frog
• Pages with impressions or clicks from Google Search Console (export via the API if the interface caps rows)
• Landing pages from GA4 for at least the last 12 months
• URLs with backlinks from Ahrefs, SEMrush or Majestic
• Every URL in the current XML sitemaps
• PDFs, images and other files that earn traffic or links

De-duplicate the list, then tag each URL with its traffic, conversions and backlinks so you know which pages matter most.

Build the redirect map

Every old URL that has value gets a destination. The rules I use:

1. Map one-to-one to the closest equivalent page, not the homepage or a category.
2. Use 301 (permanent) redirects.
3. One hop only. If old URL A already redirects to B, point A and B straight to the new URL.
4. Pages being deliberately removed with no equivalent can return 404 or 410; do not force them into irrelevant redirects.
5. Keep the map in a spreadsheet with columns for old URL, new URL, status and tested result, so it doubles as your test script.

Record benchmarks

Before anything changes, capture the baseline by page template (homepage, category, product, article, location page):

• Organic clicks, impressions and average position from Search Console
• Organic sessions and conversions from GA4
• Rankings for a tracked set of priority keywords
• Indexed page counts and Core Web Vitals
• Crawl stats and response codes

Plan the launch, and the way back

Every migration I run has a full backup and an agreed rollback plan, whatever its size. Settle these before launch, not on the day:

• Take a full backup of the current site: files, database, server configuration and existing redirect rules, and confirm it can actually be restored.
• Agree the rollback trigger. Write down what would make you roll back (for example, redirects failing at scale or key pages not loading) and who makes that call. Deciding this in advance stops a bad launch turning into a long argument.
• Choose a quiet launch date. Pick a low-traffic period, never your peak season, when the people who can fix problems are available.
• Consider moving in phases. For a very large site, moving one section or one market at a time limits the damage if something breaks and makes the cause easier to find.

Check the new site in staging

• Content parity: titles, meta descriptions, headings, body copy and internal links carry over, or are deliberately improved
• Canonicals point to new URLs, not old ones or staging
• Structured data validates
• Hreflang references new URLs and still has return links (see my notes on hreflang pitfalls)
• A helpful custom 404 page is in place: it returns a real 404 status, explains that the page has moved and links to search and the main sections, so visitors who hit a missed URL don't leave
• Staging is protected by password or authentication, and you know exactly which noindex or robots.txt rules must be removed at launch

Check tracking and consent

Redesigns often break analytics tags and consent banners. When that happens, traffic looks lower than it really is, and the team starts fixing SEO problems that don't exist. Treat these as launch blockers:

• The GA4 tag is installed on every template, not just the homepage
• Consent banner settings are unchanged: the same categories, defaults and behaviour as on the old site
• Key events (forms, purchases, calls, sign-ups) fire on the new templates
• Search Console is verified for the new property, so you have data from the first day

Phase 2: Launch day

Launch day is a checklist, not a celebration. Launch on the quiet date you chose, keep the backup and rollback plan to hand, and make sure the developer who can fix redirects is available all day.

1. Deploy redirects and test the full redirect map by crawling the list of old URLs. Every row should return one 301 to the expected destination, which returns 200. For spot checks of up to 10 URLs at a time, my free redirect checker shows every hop.
2. Remove staging blocks: check robots.txt, meta robots and X-Robots-Tag headers on live templates.
3. Confirm canonicals and hreflang on a sample of each template.
4. Verify the new property in Search Console if the domain or protocol changed, and submit the new XML sitemap. Validate it first with the XML sitemap checker.
5. For a domain change, use Search Console's Change of Address tool. If Bing matters in your markets, use the Site Move feature in Bing Webmaster Tools too; Bing does not pick up Google's Change of Address.
6. Update the internal links that matter most (navigation, footer, key templates) so they point directly to new URLs rather than through redirects.
7. Confirm analytics is recording sessions and conversions on the new site, and that key events and the consent banner behave as they did in staging.
8. Update external profiles you control: addresses and URLs in Google Business Profile and Bing Places, social profiles and key directory listings.
9. Ask the owners of your top linking sites to update their links to the new URLs. Where links were built by a previous vendor or agency, you'll usually need to contact them, because they may have the relationships or access. Otherwise, focus on earning new links once the old URLs redirect correctly.
10. Paid campaigns can keep running on the old site up to the migration date. On the new site, restart them or update their destination URLs only after the landing pages and tracking have been validated and are working as expected.

Phase 3: After launch, at 2, 4 and 12 weeks

Some ranking fluctuation after a migration is normal while Google recrawls and processes the redirects. The monitoring plan exists to separate normal fluctuation from real problems early.

First two weeks (check daily, then every few days):

• Search Console coverage and page indexing reports for spikes in errors, "not found" or "excluded" pages
• Server logs or crawl stats to confirm Googlebot is crawling new URLs
• 404 reports: any old URL with traffic or links that was missed goes into the redirect map
• Conversions in GA4 by template, compared with the benchmark

Four weeks:

• Compare clicks and impressions by template with the pre-launch baseline
• Check that new URLs, not old ones, are showing in search results for priority terms
• Re-crawl the site for redirect chains, broken internal links and canonical errors introduced after launch

Twelve weeks:

• Full comparison against benchmarks, adjusted for seasonality
• Decide which remaining issues need content or technical work rather than more waiting
• Document what went wrong and update your migration SOP for next time (my SEO SOP templates include a pre-launch QA procedure you can adapt)

Keep redirects in place for at least a year, as Google recommends. In practice I advise keeping them indefinitely for any URL with backlinks. For a domain change, that means keeping the old domain registered and its server answering every old URL with a 301 for the same period. Change of Address depends on those redirects staying in place.

AI search after the move

Google is not the only system that needs to find the new site. AI answers are covered as standard in my SEO work, and a migration can quietly undo the first of the three pillars I work to, Read: can AI crawlers fetch and read your pages? I add four checks:

• Robots.txt still allows AI crawlers. New platforms often ship with their own default robots.txt. Compare the old and new files line by line, so the AI crawlers you allowed before (such as OAI-SearchBot, GPTBot, ClaudeBot and PerplexityBot) are still allowed.
• llms.txt and ai.txt have moved. I add both files by default: there is no proof they help visibility, but there's no harm in having them. Move them to the new root and update the URLs inside them. My llms.txt guide explains what the files do and don't do.
• Content is still server-rendered. Many AI crawlers don't run JavaScript. If the new templates load body copy in the browser, check the page source, not just what you see on screen.
• Brand prompts re-checked after four weeks. Re-run the prompts you track about your brand, several times each, logged out and set to your buyer's location, and check that assistants describe you with the new URLs and current facts. My guide to measuring AI search visibility covers how to set this up.

Why migrations fail: common causes and how to prevent them

When I review a migration that lost traffic, the cause is almost always on this list.

What nobody can promise about website migration SEO

Honest limit: no one can guarantee a migration with zero movement in rankings. Google needs time to recrawl and reprocess a site, and a domain change in particular can take a while to settle. What a careful process does is remove the avoidable losses and give you the data to fix anything else quickly.

If you are planning a replatforming, a domain change or a move into an international structure, I lead migration planning and QA as part of my international and enterprise SEO consulting. For a smaller site, a pre-migration audit using my SEO audit checklist is often enough to catch the major risks before launch. You can read more about how I work across technical and strategic SEO on the main SEO consulting page.

Copy-ready SEO migration checklist

Copy this table into a spreadsheet or Google Sheets, assign an owner to each row and track status as you go.