Website migration SEO: a checklist to keep rankings and traffic

A website migration is any change that alters where your pages live or how search engines reach them: a new domain, platform, URL structure, host or a move to HTTPS. Done carefully, with website migration SEO in the plan, most sites see a short wobble in rankings and then settle. Done carelessly, a migration can wipe out years of search traffic in a week.

This guide is for small-business owners and in-house marketers moving a site, for example from WordPress to Shopify or Wix, to a rebranded domain, or to a new agency-built site. You will be able to judge how risky your move is, build a redirect map, run launch day from a checklist, use Google's Change of Address tool correctly and tell normal turbulence from a real problem. The rules come from Google's and Bing's documentation, checked in October 2026. The risk ratings, templates and thresholds are our own method, labelled as such.

What a website migration is, and why rankings drop

For SEO, a website migration is a change to a site's URLs, domain, platform or hosting that makes search engines recrawl it and re-associate everything they know with the new version. Rankings drop when that re-association breaks: old URLs return errors, signals split between two versions, or crawlers are kept out.

Some movement is expected. Google's site moves and migrations guide says rankings fluctuate while Google recrawls and reindexes a moved site, and that for a medium-sized website it can take a few weeks or more before the new URLs gradually replace the old ones. A loss that keeps growing is different, and it almost always comes from one of five causes:

1. Missing or wrong redirects, so old URLs return 404s and their links and history don't carry over.
2. Temporary redirects on a permanent move. A 302 tells Google the old URL may come back.
3. Staging blocks carried into production, such as Disallow: / in robots.txt or a sitewide noindex tag.
4. Content losses, when new templates drop titles, headings, copy, structured data or internal links.
5. Too many changes at once, so nobody can tell which one caused a drop.

Types of migration and their risk level

A migration's risk depends on how many signals change at once. Moving to HTTPS on the same domain is low risk; a new domain combined with a redesign and new URLs is the riskiest move a small business is likely to make.

Method: we rated each type by counting how many of five things change (URLs, domain, templates and content, internal links, server) and noted whether Google offers a dedicated tool. The ratings are our assessment, not Google's.

Decision: one launch or two?

• If your site is small or medium and URLs map cleanly, move everything at once. Google recommends this for small and medium sites because it helps its systems detect the move and update the index faster.
• If you are changing domain, URLs and design together, consider two launches: the domain first with identical paths, the redesign a few months later. Each step is easier to diagnose, at the cost of two rounds of turbulence.
• If your site is large, Google suggests moving one section first to test the effect on traffic and indexing, then the rest.
• If your busiest season starts within about six weeks, wait (our rule of thumb). A dip during peak demand costs the most.
• If Google is rolling out a core update, launch afterwards if you can, or you won't be able to tell the two effects apart. Our core update recovery guide explains the difference.

The migration plan: who does what, and when

A migration plan is a dated checklist with one named owner per task. As a rule of thumb, a small site can run it in six to eight weeks; only the volume of URLs changes with size. Write a name against every row, even if one person holds several roles.

Build the URL inventory from several sources

No single source lists every URL that matters. Combine a crawl of the live site, your XML sitemaps, Search Console's Performance report exported by page, analytics landing pages, and the pages other sites link to (Google's guide suggests saving a list of sites linking to your old URLs). Add PDFs and any URLs printed on brochures or QR codes, because print can't be updated.

For a small site, the free Website SEO Audit crawls up to 50 pages the way a search engine does, reading your sitemap and robots.txt. Save its health score and issues as your "before" snapshot. Larger sites need a desktop crawler.

Benchmarks to save before anything changes

Benchmarks are how you tell, three weeks after launch, whether a dip is normal. Export Search Console clicks and impressions by page and query, analytics sessions and conversions by landing page, positions for your 20 to 50 most valuable queries, and page-speed results for your main templates (our website speed checks post covers which numbers to record). List existing problems with the technical SEO audit checklist so they aren't blamed on the move later.

Build the redirect map (template included)

A redirect map is a spreadsheet that pairs each old URL that matters with the single new URL that best replaces it, plus the status code to use. Finish and test it before launch day, not during it.

Example (hypothetical): a garden-supplies shop in Leeds is moving to a new e-commerce platform and domain, and its product URLs follow a new pattern. Its map starts like this:

Copy the columns into a spreadsheet and add two of your own: each old URL's clicks over 12 months and its number of linking domains. Sort by those to set priority, and test the high-priority rows one by one.

How to choose each destination: a decision flow

1. If an exact equivalent exists, 301 to it, even if the wording changed.
2. If the content was merged, 301 to the page that now covers it.
3. If a product was discontinued and a close replacement exists, 301 to it or its category, but only if a visitor would find what they wanted there.
4. If there is no useful equivalent, let the URL return 404 or 410. Google's documentation on HTTP status codes says every 4xx code except 429 signals that the content doesn't exist, and indexed URLs are removed.
5. If the move is temporary, such as maintenance, use a 302 or 307.

Don't send hundreds of old URLs to the homepage to "keep link value". Google's site move guide warns that redirecting many old URLs to one unrelated page, such as the homepage, can confuse users and may be treated as a soft 404, in other words as an error.

Use pattern rules for predictable changes (every /blog/ slug kept on the new domain) and one-to-one rows for important pages. Make sure the one-to-one rows take priority and that no pattern sends a URL to another redirect.

Redirect rules that keep rankings

Use server-side permanent redirects (301 or 308), send each old URL straight to its final destination in one hop, and keep the redirects for at least a year. These three rules come from Google's documentation and prevent most migration losses.

Permanent versus temporary redirects

Google's redirects documentation says permanent redirects (301, 308, an instant meta refresh or a JavaScript location change) tell Google the target should become canonical. Temporary redirects (302, 303, 307 or a delayed meta refresh) are followed but don't carry that signal. Google recommends server-side redirects, and JavaScript ones only when nothing else is possible.

Google's canonicalisation documentation lists redirects and rel="canonical" as strong signals and sitemap inclusion as a weak one. Make all three agree: old URL redirects to new, the new page's canonical points to itself, and the sitemap lists only new URLs.

Keep chains to one hop

A redirect chain is a series of hops, such as HTTP to HTTPS to www to the new path. Google's site move guide advises redirecting straight to the final destination or, failing that, keeping chains ideally to no more than 3 hops and fewer than 5, because each hop adds delay. Googlebot can follow up to 10 hops, but that is a limit, not a target. Update redirects left over from past redesigns so they point at the new final URL too.

Test URLs with the free Redirect Checker, which lists every hop with its status code and tests the http, https, www and non-www versions. You want a single 301 or 308 ending in a 200. Two or more hops, a 302 on a permanent move, or a final 404 means the rule needs fixing.

How long to keep redirects

Google's site move guide says to keep redirects as long as possible, generally at least one year, so signals such as links from other sites can move to the new URLs. If you use the Change of Address tool, Google's Change of Address help page sets a minimum of 180 days, longer if old URLs still get search traffic. After that, Google no longer recognises a relationship between the two sites.

Our advice: never remove redirects for URLs with backlinks, print references or visits, and keep renewing the old domain. If it lapses and someone else registers it, every link to it points at their site.

What Google and Bing say: our comparison

Google and Bing agree on permanent redirects kept for a long time and on submitting a sitemap of the new URLs. They differ on duration, on the tools each offers for a domain move, and on how recently their guidance was updated.

Method: in October 2026 we read Google's site move guide, Change of Address help and documentation changelog, plus Bing's 2020 migration post and its content removal help, and recorded what each says on the same five points.

What this shows: following Bing's 2020 migration post on duration (one to two years at least) satisfies both engines. Google's guidance is fresher: its documentation changelog records that on 17 June 2026 the site move guide began saying to use Change of Address for all subdomain variants, including www and non-www, during domain migrations. Bing offers a faster nudge than Google: its content removal help says to submit deleted, moved or updated URLs through IndexNow so Bing and Copilot refresh results sooner.

Staging checks before you go live

Staging is the private copy of the new site where you test before launch. Check it for the four things behind most launch-day disasters: crawl blocks, noindex tags, canonicals pointing to the wrong host, and internal links to old URLs.

Plan how staging blocks come off

Password protection keeps people and crawlers out of staging more reliably than robots.txt, which only asks crawlers to stay away and is the file most often copied to production by mistake. Google's guide to changing your hosting says to remove temporary robots.txt disallow rules and noindex tags before the switch. Put that on the launch list with a name against it.

Write the production robots.txt as its own file

Carry across the deliberate rules from your old robots.txt, including AI crawler rules, and update the sitemap line. If you allowed OpenAI's search crawler before, allow it again: OpenAI's crawler documentation says sites that opt out of OAI-SearchBot won't appear in ChatGPT search answers, and changes take about 24 hours to apply. Our guide to blocking AI crawlers explains which bots to allow.

Paste the new file into the free Robots.txt Tester and test key paths for Googlebot, Bingbot and OAI-SearchBot. It shows whether each may fetch a path and which line decides. A "blocked" result on a page you want found stops the launch.

Check noindex, canonicals and on-page parity

Crawl staging and list every page with a noindex meta tag or X-Robots-Tag header. Every canonical should point to the final production URL on HTTPS, never the staging host or old domain; hreflang tags need the same check. Then compare your 20 to 50 most valuable pages old against new: title, meta description, H1, copy, alt text, structured data and internal links. The on-page SEO checklist lists what to compare, the schema markup guide covers structured data that themes often drop, and the Google SERP Preview shows whether rewritten titles will be cut off.

Internal links, server and firewall

Internal links should point straight at new URLs. Google's site move guide says redirects slow visitors down and asks you to update your own links. Replace the old domain in menus, footers, copy and image paths, then crawl again.

Google's hosting guide also says to check that firewalls and denial-of-service protection don't block Googlebot. Since 15 September 2026 this matters more: Cloudflare's Block settings now cover mixed-use crawlers, including Googlebot, Bingbot and Applebot. To opt out of AI training on Cloudflare, choose Disallow AI Training rather than Block. Plan for load too: Google says it crawls a newly moved site more heavily than usual.

Launch day, step by step

Launch day is switching things on in the right order and testing each one straight away. Pick a quiet weekday morning when your developer is free all day, never a Friday evening.

For domain or hosting changes, Google's hosting guide suggests lowering the DNS TTL to a low value, such as a few hours, at least a week before the move. Then, on the day:

1. Save a final crawl of the old site as your last record of every URL and title.
2. Go live and lift every staging block: password, robots.txt disallow, noindex tags and headers.
3. Switch on the redirects or point DNS at the new host, in the order your developer rehearsed.
4. Test the top 50 to 100 mapped URLs within the first hour. Each should give one 301 ending in a 200. Spot-check with the Redirect Checker, then run the whole map through a crawler in list mode.
5. Open the live robots.txt on the new domain. If a block slipped through, fix it and use Request a recrawl in Search Console's robots.txt report; Google's guide to updating robots.txt says crawlers otherwise refresh their cached copy every 24 hours.
6. Inspect key pages with the URL Inspection tool in the new Search Console property, which Google's hosting guide recommends to confirm Googlebot can reach the new setup.
7. Submit the new XML sitemap in Search Console and Bing Webmaster Tools.
8. For domain moves, submit the Change of Address for every verified variant of the old domain. Bing's 2020 post named a Site Move tool, but its help page is no longer live, so for Bing also submit the moved URLs through IndexNow if your platform supports it.
9. Check analytics in real time and complete one test enquiry or purchase.
10. Run the Website SEO Audit on the live site, compare it with your "before" snapshot, and note the launch time in your benchmark sheet.

Change of Address tool, sitemaps and listing updates

The Change of Address tool in Search Console tells Google that a whole domain or subdomain has moved. Use it only for domain-level moves, only after redirects are live, and keep those redirects for at least 180 days.

The Change of Address rules

From Google's help page and site move guide (checked October 2026):

• Own both old and new properties in Search Console, under the same Google account.
• Domain level only: you can't move a folder such as /shop/, and it isn't for HTTP to HTTPS or www to non-www changes.
• Subdomains don't move automatically. Submit for every variant of the old domain, including www, non-www and unused ones, and verify each.
• The old homepage must 301 to the new homepage; Google recommends 301s for canonical pages too.
• After moving A to B, you can't immediately move B to C. To cancel, remove the 301s as well.

Sitemaps during the move

Google's site move guide recommends submitting a sitemap of the new URLs once the move starts. Warnings that old-sitemap URLs redirect are normal and can be ignored. In the Sitemaps report, the new sitemap starts at zero indexed pages and should climb while the old one falls, one of the clearest progress signals you have.

Listings and profiles that link to you

Update these in the first week, busiest first: your Google Business Profile website and booking links (the Google Business Profile guide shows where each lives); Bing Places, Apple Maps, directories and review sites; social profiles and YouTube descriptions; Google Ads final URLs and shopping feeds; booking and payment tools; the url and sameAs values in your Organization structured data; and email signatures. Keep the redirects anyway, because old copies and print keep sending visits for years.

The first 30 days: normal versus alarming signals

In the first month, spot real problems fast without panicking at normal turbulence. Check daily in week one, twice weekly to day 30, then weekly to day 90, always against your benchmarks.

Method: the "normal" column reflects what Google's documentation says to expect; the "alarming" thresholds are our rules of thumb for small sites.

Two normal signals worry people most, and Google has addressed both. Its redirects documentation notes that after a domain change Google may still occasionally show old URLs even when the new ones are indexed. And in its July 2023 office hours, Google told a site owner still seeing about a million "pages with redirect" a year after a migration that this can be perfectly normal: old URLs stay in its systems for a long time and drop out gradually.

The Crawl Stats report is your early warning for server trouble. A higher share of 301 responses is normal during a move; what to look for are the redirect errors, such as loops or too many redirects, that Google's help page lists among the bad responses. Its status code documentation adds that 5xx and 429 errors slow crawling, and URLs that keep returning them for days can drop out of the index.

Days 31 to 90, and when to roll back

By around day 60 to 90, most small sites should be near their benchmark for pages whose content didn't change. Merged or rewritten pages may settle at a different level, which is a content question, not a migration fault. After that, fold the checks into your monthly SEO report and set a month-12 reminder so nobody removes redirects or lets the old domain lapse.

• If robots.txt or noindex blocks the new site, fix it in place within the hour; rolling back would start a second move.
• If redirects are broken sitewide, fix the rules. It is a configuration problem.
• If the new site is down or very slow and can't be fixed within a day, roll back if the old site is intact, reversing the redirects.
• If traffic is down but every check passes, wait four to eight weeks before drawing conclusions.

Keeping AI citations and backlinks on the right URLs

AI answers draw on the same indexes as search, so a migration that breaks indexing also costs citations in AI Overviews, AI Mode and ChatGPT search. Keep redirects permanent, keep AI search crawlers allowed, and update the links you control.

Google's AI features follow the index

Google's AI features documentation says a page must be indexed and eligible to show with a snippet to appear in AI Overviews or AI Mode, with no extra technical requirements. A new URL that isn't indexed can't be cited, and an old one returning 404 drops out. Watch the new property's AI impressions with the Search Console AI performance report.

AI crawlers keep requesting old URLs

In Vercel's December 2024 analysis of its network, 34.82% of ChatGPT's crawler fetches hit 404 pages and another 14.36% followed redirects; Claude's crawler hit 404s on 34.16% of fetches, against 8.22% for Googlebot. Vercel found that, apart from robots.txt, many of these requests were for outdated files, and suggested the crawlers need better URL selection. Either way, these crawlers keep asking for old URLs, so a missing redirect is a dead end for AI systems as well as people.

Move your best backlinks, then check AI answers

Google's site move guide also suggests updating high-volume external links. Sort your saved list of linking sites by visits and relevance, and email the top 10 to 20 with the exact old and new URL. Two to four weeks after launch, ask ChatGPT, Perplexity, Gemini and AI Mode a few questions about your business. Note any answer linking your old domain or a dead URL and confirm it redirects; where facts are outdated, fix your own pages and listings first. Our guide to getting cited in AI search covers the wider method.

If you would like a second pair of eyes on your redirect map or launch plan, our technical SEO service covers migrations, and you can contact us to talk it through.