The site migration checklist: move your website without losing traffic

A site migration is any change big enough to affect how search engines find and understand your website: a new domain, a new platform, a redesign that changes URLs, or a move to HTTPS. This checklist covers everything to do before, during and after launch so the move keeps the search visibility your site has already earned.

I’ve planned migrations for ecommerce stores, clinics and publishers, including headless Shopify builds and full redesigns. The pattern is always the same. Sites rarely lose traffic because a migration is inherently risky. They lose it because something small was missed: a sitemap that didn’t get built, a page nobody knew was popular, a redirect that pointed at an error.

[Table of contents]

What counts as a site migration

A site migration is any change to a website’s URLs, domain, platform, structure or hosting that could change how Google crawls, indexes and ranks it. Some are obvious, like moving to a new domain. Others, like a redesign on the same platform, are easy to underestimate because the address stays the same.

Google’s documentation splits these into moves with URL changes and moves without them. The guide to site moves with URL changes covers most of this checklist. Changing your web hosting covers the rarer case where only the infrastructure changes.

How migrations have changed

Migrations used to be mostly about domains and redirects. Today they’re more often platform and template changes, where the risks sit in how the new site renders content, generates sitemaps and handles duplicate URLs, not just whether old addresses redirect.

A decade or more ago, a typical migration meant moving a site to a new domain or reorganising folders on a server. The job was largely a redirect spreadsheet. The big wave of HTTPS moves followed, and those were relatively forgiving because the rest of each URL stayed the same.

Now most businesses run on platforms like Shopify, WordPress or Magento, and a migration usually means moving between them or rebuilding templates. Platforms impose their own URL formats, so paths change even when the domain doesn’t. Headless builds, where the front end is separate from the content system, add a new category of risk: things a standard theme does automatically, like generating a sitemap or putting text in the HTML, only exist if someone specifies them.

Why sites lose traffic after a migration

Sites lose traffic after a migration mainly because old URLs don’t redirect to the right new pages, valuable pages are dropped or changed, the new site blocks crawling or indexing, or content and internal links are weaker than before. Some short-term fluctuation is normal. A lasting drop usually points to one of these faults.

Google is clear that some movement is expected. Its site move guide says you should “expect temporary fluctuation in site ranking during the move”, and that for small to medium sites it can take a few weeks for most pages to move, with larger sites taking longer.

Lasting losses have more specific causes. These are the ones I see most often:

• Missing or wrong redirects. Old URLs return errors, redirect to the homepage, or redirect to a page that doesn’t match.
• Pages nobody knew mattered. A page outside the main structure, an old blog post with strong links, or a PDF that still gets searched.
• Crawling or indexing blocked. A robots.txt block or noindex tag from the staging site carried into launch.
• Content thinned out. New templates with less text, fewer headings or missing FAQs.
• Internal links broken. Menus and in-content links pointing at old URLs, sending both visitors and Google through redirects or to errors.
• Metadata lost. Titles and descriptions reset to platform defaults.
• Duplicate URLs. Old and new versions of a page both resolving, splitting signals between them.

Two real examples show how small these can be. When I audited the Evewell fertility clinic’s site before its redesign, one page sitting outside the main /support/ section brought in 5,145 clicks a year, the ninth-highest on the site, and would have been lost if it had been tidied into the new structure without a redirect. After Kwiat’s move to a headless Shopify build, the new site’s /sitemap.xml returned a 404 error, so Google had no sitemap to find the new URLs from. Both were caught. Neither was complicated. Why sites lose traffic after a migration goes further into diagnosis.

Before you start: decisions to make

Before any technical work, decide what’s changing and why, when you’ll launch, whether you’ll move everything at once, and who owns each part of the migration. These decisions shape the whole checklist, and changing them mid-project is where many problems begin.

• [ ] Write down exactly what’s changing: domain, platform, URLs, templates, content, hosting.
• [ ] Choose a launch date away from your busiest season. A shop shouldn’t migrate in November. A clinic shouldn’t launch before a major campaign.
• [ ] Decide whether to move all at once or in sections. Google recommends moving all URLs at once for small and medium sites. For large sites, it suggests moving a section first where that’s technically possible, to test the effect.
• [ ] Agree who does what: who builds, who writes redirects, who checks them and who signs off launch.
• [ ] Avoid changing everything at once where you can. A new domain, new platform and new content in a single launch makes any drop much harder to diagnose.
• [ ] Record where you’re starting from. Export 12 to 16 months of Search Console data and analytics before anything changes.

Stage 1: inventory everything

Build a complete list of every URL on the current site that earns traffic, links, enquiries or sales, drawn from several sources rather than one. This inventory is the foundation of the redirect map, and any page missing from it is at risk of being lost at launch.

No single source finds every page. Google’s site move guide suggests using sitemaps, server logs or analytics, the links reports in Search Console and your content management system. In practice, combine:

• [ ] A full crawl of the current site
• [ ] Search Console pages with clicks or impressions over the last 12 months or more
• [ ] Analytics landing pages with organic, referral or campaign traffic
• [ ] Backlink data, so pages with external links are protected
• [ ] XML sitemaps, current and old
• [ ] The CMS export of every page, post, product and category
• [ ] Anything outside the CMS: PDFs, landing pages built elsewhere, subdomains

For each URL, record its traffic, links and conversions, so you know which ones matter most. On large stores, search intelligence data also shows which pages are earning paid and organic visibility for valuable searches.

Stage 2: map every URL to its new home

Create a redirect map: a spreadsheet listing every old URL alongside the most relevant new URL it should redirect to. Each redirect should point to the closest equivalent page, not the homepage, so visitors and search engines land on content that matches what they came for.

• [ ] Map one to one wherever an equivalent page exists.
• [ ] Where pages are merged, redirect each old URL to the page that now covers its content.
• [ ] Where a page is genuinely removed with no replacement, decide whether a redirect to a close parent page helps the visitor, or whether it should return a 404 or 410.
• [ ] Never redirect everything to the homepage. Google’s site move guide warns against redirecting many old URLs to one irrelevant page such as the homepage, which can confuse users and might be treated as a soft 404 error.
• [ ] Check the new site keeps the high-value URLs identical where possible. The best redirect is one you don’t need.
• [ ] Handle platform-specific URLs: Magento’s .html endings and layered navigation, Shopify’s /products/ and /collections/ formats, WordPress date-based permalinks.
• [ ] Check the map for chains and loops, so each old URL goes straight to its final destination.

On Evewell’s redesign, the redirect map covered 207 URLs, and it was referenced in every brief so every old address had a confirmed destination before the build started. It also caught an existing fault: an old IVF landing page already redirected to a URL that returned a 404.

Stage 3: build the new site properly

Make sure the new site carries across everything search engines use to understand the old one: content, titles, descriptions, headings, internal links, structured data, canonical tags and hreflang. Then check it renders properly and that nothing important depends on JavaScript alone.

• [ ] Content: priority pages keep their depth, headings and FAQs, or improve on them.
• [ ] Titles and meta descriptions carried across or rewritten, not reset to platform defaults.
• [ ] Self-referencing canonical tags on every new page. Google’s guide says each new URL should have one.
• [ ] Internal links updated to the new URLs directly, not left to pass through redirects.
• [ ] Structured data for products, articles, organisation and breadcrumbs, validated.
• [ ] Hreflang updated to the new URLs on multilingual or multinational sites.
• [ ] XML sitemap generated with only live, indexable, canonical URLs.
• [ ] Rendering: content, links and headings appear in the HTML, or render reliably. Some AI crawlers don’t run JavaScript the way Google does.
• [ ] Page speed and Core Web Vitals checked on key templates.
• [ ] Analytics and conversion tracking installed and tested.
• [ ] Images keep their alt text, and important image URLs are redirected.

Headless builds need extra care here. On Kwiat’s Shopify Hydrogen build, products lived in Shopify and editorial content in Sanity, so the sitemap had to be specified to pull from both: a sitemap index pointing to separate product, collection and editorial sitemaps, each listing only live, indexable URLs. The same build served education articles whose text sat inside a script payload rather than the initial HTML, which Google can render but some other crawlers can’t. SEO-ready site builds covers how to specify this before a build begins.

Stage 4: test before launch

Test the new site on a staging environment before launch: crawl it, check redirects against the map, confirm important pages are indexable, and compare it with the old site. Keep staging blocked from search engines, and make a clear note to remove that block at launch.

• [ ] Keep staging private with password protection, which is more reliable than robots.txt alone.
• [ ] Crawl the staging site and compare page counts, titles, headings, canonicals and word counts with the old site.
• [ ] Test the redirect map against staging, or in a test file, checking every old URL returns a single permanent redirect to the right page.
• [ ] Check robots.txt for the live site is ready, and blocks only what it should.
• [ ] Confirm no noindex tags will go live on pages you want indexed.
• [ ] Test forms, checkout and tracking end to end.
• [ ] Check mobile layout on priority templates.
• [ ] Verify the new site in Search Console before launch, including any new domain or subdomain.

Google also recommends a temporary hostname for testing a hosting move, such as beta.example.com, so you can confirm Googlebot can reach the new infrastructure.

Stage 5: launch day

On launch day, put the redirects live, remove any staging blocks, submit the new sitemap and check the most important pages by hand. Launch early in the week, when the people who built the site are available to fix anything that breaks.

• [ ] Redirects live, as server-side permanent redirects.
• [ ] Staging blocks removed: robots.txt disallow rules, noindex tags and password protection.
• [ ] Spot-check the top 50 to 100 URLs from the inventory: each redirects once, to the right page, which returns a 200 status.
• [ ] Submit the new XML sitemap in Search Console.
• [ ] Keep the old sitemap available for a short time if it helps Google find the redirects, then remove it.
• [ ] Use the Change of Address tool in Search Console if the domain or subdomain changed.
• [ ] Update external profiles: Google Business Profile, social profiles, Google Ads final URLs, email templates and any directories you control.
• [ ] Check analytics is recording visits and conversions.

Which redirect to use

Google’s redirects documentation says server-side redirects are preferred, and explains the difference between permanent and temporary redirects.

When to use the Change of Address tool

Google’s Change of Address tool is for moving between domains or subdomains, including www and non-www. Use it after the redirects are live. Google’s site move guide says to submit it for all verified variants of the old domain, including subdomains and www and non-www versions.

Don’t use it for an HTTP to HTTPS move, or for moving pages within the same domain. For those, redirects and an updated sitemap are enough.

Stage 6: after launch

After launch, check crawl errors, indexing and redirects in Search Console daily for the first week and weekly after that, compare clicks and impressions with the same period before the move, and fix problems as soon as they appear. Keep redirects in place for at least a year.

First week:

• [ ] Search Console Page indexing report: watch for rising “Not found (404)”, “Page with redirect” on new URLs, or “Excluded by noindex tag”.
• [ ] Crawl the old URL list to confirm every redirect still works.
• [ ] Check server logs or crawl stats for errors, if you have access.
• [ ] Check the priority pages in live search results: titles, descriptions and the URL shown.

First three months:

• [ ] Compare clicks and impressions week by week with the same weeks before the move, for the whole site and for priority pages.
• [ ] Look for old and new URLs both ranking. It means redirects or canonicals aren’t doing their job.
• [ ] Watch the Sitemaps report to see how many new URLs are indexed.
• [ ] Re-check backlinks to high-value old URLs and ask key referring sites to update links where possible.
• [ ] Check conversions, not just traffic. A migration that keeps visits but breaks a checkout isn’t a success.

Long term:

• [ ] Keep redirects for at least a year, and ideally for good. Google’s site move guide says to keep them “for as long as possible, generally at least 1 year”. Its Change of Address help page gives a minimum of 180 days, and longer if old URLs still get traffic from Google Search. Old links from other sites don’t expire, so I’d leave redirects in place permanently wherever the platform allows.
• [ ] Keep the old domain registered after a domain move, so nobody else can take it.

On Kwiat’s site, later checks after the move found old category URLs still returning pages rather than redirecting, relying on canonical tags instead, with old and new URLs both ranking for many searches. Google’s canonicalisation documentation describes redirects as a strong signal and canonical tags as a strong signal too, but redirects are the clearer instruction when an old page has genuinely been replaced.

Recovering from a migration that’s already lost traffic

If traffic has already dropped, compare the old URL inventory against what’s live now. Find old URLs that return errors, redirect to the wrong place or have lost content, then fix those in order of the traffic they used to earn. Most recoveries come from putting back what was lost.

1. Find the drop in Search Console. Compare the months before and after launch by page, not just site-wide, to see exactly which pages lost clicks.
2. Rebuild the old URL list from Search Console, analytics, old sitemaps and archived crawls.
3. Crawl the old URLs and record where each goes now.
4. Fix redirects for pages returning errors or pointing at irrelevant pages.
5. Compare content on pages that redirect correctly but still lost traffic. Missing text, headings or FAQs are common.
6. Check indexing and rendering of the new templates.
7. Track recovery weekly against the pre-launch baseline.

The migration traffic recovery service follows this process for sites that have already moved.

Platform notes

Every platform has its own URL formats and its own way of handling sitemaps, redirects and duplicate pages, so the same checklist catches different problems on each. These are the platform-specific risks I check first on Shopify, headless, Magento and WordPress migrations.

Platform-specific guidance is on the Magento to Shopify, Shopify migrations and WordPress migrations pages.

What’s likely to change

My expectation is that migrations will be judged less on redirects alone and more on whether the new site is as easy for AI systems to read as the old one. That’s a forecast based on current direction, not a certainty.

Here’s what I’d expect over the next few years:

• Rendering matters to more crawlers. Google renders JavaScript, but AI crawlers vary. A new build that hides content behind scripts may stay visible in Google while becoming harder for other systems to use.
• Headless and composable builds keep growing, so specifying the SEO basics before a build becomes a standard part of the brief rather than an afterthought.
• AI answers change what “lost traffic” means. Some informational clicks are already going to AI Overviews regardless of a migration. Comparing a migration’s effect needs care to separate the two, by looking at impressions and positions, not just clicks.

I’ll update this checklist when Google’s guidance changes.

What I learned

The migrations that go smoothly aren’t the ones with the cleverest technical set-up. They’re the ones where everything was written down: every URL mapped, every search basic specified for the developer, and every change checked after launch rather than assumed.

The sitemap on Kwiat’s headless build only exists because it was specified in detail, built to that specification and then checked live. The page on Evewell’s site with 5,145 clicks a year was protected because the inventory found it, not because anyone remembered it. In both cases the work was checking, not guessing.

If you’re planning a move, this is where I’d start:

1. Export at least 12 months of Search Console data today, before anything changes.
2. Build the URL inventory from several sources and sort it by clicks.
3. Make sure your top 100 URLs either stay the same or have a confirmed redirect.
4. Run your most important pages through the free SEO checker before and after launch to compare titles, canonicals and structured data.

If you’d like a second pair of eyes on a migration plan, a free assessment is a good place to start, and the site migrations service covers planning, launch and recovery. The Evewell and Kwiat case studies show the process on real projects.

FAQ

Sources

1. Site moves and migrations, Google Search Central, accessed 15 September 2026. Supports: expected ranking fluctuation, a few weeks for small to medium sites, moving all at once versus in sections, finding URLs, self-referencing canonicals, updating internal links and hreflang, removing staging blocks, avoiding irrelevant homepage redirects that might be treated as soft 404s, Change of Address for all domain variants, keeping redirects generally at least 1 year.
2. Redirects and Google Search, Google Search Central, accessed 15 September 2026. Supports: server-side redirects preferred, permanent and temporary redirect types, JavaScript redirects as a last resort.
3. Change of Address tool, Search Console Help, accessed 15 September 2026. Supports: when to use and not use the tool, maintaining redirects for at least 180 days.
4. Changing your web hosting and SEO, Google Search Central, accessed 15 September 2026. Supports: temporary hostnames for testing a hosting move, removing temporary crawl blocks.
5. How to specify a canonical, Google Search Central, accessed 15 September 2026. Supports: redirects and rel=”canonical” as strong signals, sitemaps as a weak signal.
6. The Evewell, pre-migration SEO audit and redirect map, Search Console data. Supports: the 207-URL redirect map, the page with 5,145 clicks a year and the broken IVF redirect.
7. Kwiat, post-migration technical audit and sitemap specification, 2026. Supports: the 404 sitemap, the multi-source sitemap specification, client-rendered education pages and old category URLs still resolving.