Website Migration Checklist

TL;DR — A migration is any big change to your site — a new domain, a switch to HTTPS, a new platform, a folder reshuffle, a redesign. This is the step-by-step list to run so you don’t lose your rankings. Before you touch anything, write down where you stand today (crawl the site, note your traffic and rankings). Then map every old page to its new home and send it there with a 301 redirect. Test it all on a staging site that Google can’t see, launch, resubmit your sitemap, and then watch your traffic closely after launch. A temporary dip can occur while search engines process the move; if it never recovers, something broke.

Evidence for this claim For URL changes, Google recommends mapping old URLs to relevant new destinations and using permanent server-side redirects. Scope: Google site-move guidance; avoid irrelevant bulk redirects. Confidence: high · Verified: 2026-07-14 Google Search Central: Site moves with URL changes Evidence for this claim Google recommends keeping redirects in place for at least one year after a site move. Scope: Google site-move processing; users and other systems may justify keeping them longer. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move best practices

What this checklist is (and what it isn’t)

This is the do-this-in-order version of a site migration. If you want the background — the seven kinds of migration, why redirects carry rankings, how risky each type is — that lives in the full site migrations guide. This page is the tick-box companion you can literally hand to a project manager or a developer and run down during the move.

The whole thing breaks into six phases: benchmark before you touch anything, map your URLs, test on staging, launch, verify, then monitor. Here’s the plain-English version of each.

1. Before you change anything: write down where you stand

You can’t tell whether a migration went well if you don’t know where you started. So before launch:

• Crawl your whole site and save the results. This is your “before” picture — every URL, title, and status code.
• Note your traffic, your rankings, and how many pages Google has indexed. Export these from Google Search Console and your analytics so you have a baseline.
• List every URL you’ll need to redirect. Don’t just use your sitemap — also pull URLs from your server logs and analytics, because those catch old pages that still get traffic but aren’t in the sitemap.

2. Map old URLs to new ones, then redirect

Make a spreadsheet: old URL in one column, its new home in the next. Every old page gets pointed at the closest matching new page with a 301 redirect (a permanent one). Two rules that trip people up:

• Don’t dump everything on the homepage. If a page doesn’t have an obvious new equivalent, send it to the closest relevant page, not the home page.
• Don’t chain redirects. Old URL → new URL, one hop. Not old → middle → new.

3. Test on a staging site Google can’t see

Build the new site somewhere private first. Protect it with authentication or a network allowlist, authorize your QA crawler, and compare it against your “before” picture — are the titles, canonical tags, and internal links all correct?

The single most-forgotten step comes next: when you launch, prove every staging-only control is absent from production. That includes access controls, robots rules, noindex, and staging-host canonicals wherever they were used.

4. Launch day

• Turn on all the redirects.
• Remove every staging-only control and verify the public response is crawlable.
• Regenerate your current sitemap with new canonical URLs only and submit it in Search Console. If an old-URL sitemap would help you monitor the move, keep it separate and temporary, then remove it when it is no longer useful.
• If you moved to a whole new domain, submit Google’s Change of Address tool. (You don’t need it for an HTTPS switch or a folder reshuffle on the same domain.)

5. Right after launch: check the redirects actually work

Crawl your full list of old URLs and confirm each one lands on the right new page — no dead ends, no error pages, no chains. Fix the broken ones, starting with your most important pages first.

6. Then watch for a month or two

Keep an eye on Search Console for the next 4–8 weeks: is the new sitemap getting indexed? Are rankings and traffic recovering? A temporary wobble is expected. Keep your redirects live for a long time — at least a year.

Want the sourced, phase-by-phase version with Google’s and Bing’s exact guidance, the common mistakes, and the monitoring numbers? Switch to the Advanced tab.

TL;DR — Run the migration as six phases, not as a migration-type taxonomy (the types live in the migrations hub). (1) Benchmark: full crawl of the old site as a baseline, a three-source URL inventory — sitemaps + server logs + analytics, never sitemaps alone — and snapshots of rankings, traffic, and indexed-page count. (2) Map + redirect: every old URL to its closest new URL 1:1 with a server-side 301/308, never bulk-to-homepage, chains kept low (≤3, fewer than 5), non-HTML assets included. (3) Staging QA: private access with authorized crawling, then removal of every staging-only control at launch; diff canonicals, hreflang, schema, meta robots, and internal links against the baseline; check analytics/GTM tag parity. (4) Launch: activate redirects, regenerate and resubmit the current sitemap with new canonical URLs only, optionally submit a separate temporary old-URL sitemap for monitoring, submit Change of Address for whole-domain moves only, use IndexNow + bulk URL submission for Bing (the Site Move Tool is retired). (5) Verify: crawl the full old-URL list to confirm every redirect resolves — no chains, no orphaned 404s. (6) Monitor: GSC coverage/performance + rankings for 4–8 weeks; Bing recommends daily log monitoring for 3 months. Keep redirects at least 1 year (Google), 1–2 years (Bing).

Evidence for this claim For URL changes, Google recommends mapping old URLs to relevant new destinations and using permanent server-side redirects. Scope: Google site-move guidance; avoid irrelevant bulk redirects. Confidence: high · Verified: 2026-07-14 Google Search Central: Site moves with URL changes Evidence for this claim Google recommends keeping redirects in place for at least one year after a site move. Scope: Google site-move processing; users and other systems may justify keeping them longer. Confidence: high · Verified: 2026-07-14 Google Search Central: Site move best practices

How to use this checklist

The migrations hub owns classification, principles, risk, migration-type decisions, and recovery diagnosis. This checklist owns the executable tasks, assigned owners, phase gates, and acceptance criteria. Before work begins, assign an owner to every phase and record the evidence required to pass its gate. I’ve anchored it to phases (before / staging / launch / after) rather than to migration type, because on the day of an actual move you’re working through time, not through a taxonomy. Where a step is type-specific — Change of Address for domain moves, DNS TTL for host-only moves — I’ll flag it.

Phase 1 — Pre-migration benchmarking

You cannot diagnose a migration you didn’t measure first.

Full crawl of the old site. As I put it in my own migration guide: “Crawl your website. You’ll use this as a baseline to check for changes later on.” Save every URL, title, meta tag, canonical, and status code. This baseline is what you’ll diff staging and the live site against.

Three-source URL inventory — not the sitemap alone. This is the step most competitor checklists get wrong. Google’s own site-move guidance says to build the master old-URL list from sitemaps, server logs, and analytics — three sources, because logs and analytics surface URLs the sitemap never had. A sitemap-only inventory misses orphaned-but-still-trafficked pages, and those are exactly the pages whose lost redirects you’ll notice months later. Include non-HTML assets too: images, videos, PDFs, JS and CSS files.

Benchmark rankings, traffic, and indexed-page count. Export from GSC (Performance

• the Pages/Index Coverage report) and your analytics. You want three numbers on record before launch: where you rank, how much traffic you get, and how many pages are indexed. Everything post-launch is measured against these.

Export the backlink profile. Pull your most-linked pages — this becomes your priority-redirect list. The pages with the most external link equity are the ones a broken redirect hurts the most, so they get QA’d first. A practical technique from my guide: “Create a set of test pages such as those from the Top Pages report in Site Explorer.” You don’t manually QA every URL on a large site — you sample from the top-traffic and top-linked pages.

Back up, and have a rollback. “Make a backup of your site, just in case you need to go back to it,” and “You should always have a way to get back to the original state, even if you only plan to use it in extreme situations.”

Phase 2 — URL mapping and redirect strategy

Map every old URL to a specific new URL, 1:1. This is the heart of the migration. John Mueller: “I think the most important part is really to track the individual URLs, so that you have a clear map of what previously was and what it should be in the future. And based on that… to make sure that you have all of the redirects set up properly.”

The redirect rules, concretely:

• Server-side permanent redirects (301 or 308). This is Google’s stated preference, and permanent redirects don’t cost you PageRank.
• Map to the closest relevant equivalent — never bulk-to-homepage. Google is explicit: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page.” If a page has no equivalent and shouldn’t exist anymore, return a proper 404 or 410 rather than redirecting it somewhere irrelevant.
• Keep chains short. Google: “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” A migration is where chains breed — an old redirect from a previous move plus the new one already makes two hops.
• Self-referencing canonical on each new URL. Google: “Each new URL should have a self-referencing rel=“canonical” link tag.”
• Update hreflang annotations for multilingual sites so they point at the new URLs.
• Include non-HTML assets in the mapping — images, videos, JS, CSS.

For sites too large to move at once, decide up front: small and medium sites move all at once; very large sites move in sections. The mechanics of chains, hops, and 301 vs 302 are in the redirects guide.

Phase 3 — Staging and pre-launch QA

Keep staging private at the access layer. Google’s migration guidance says to restrict access to a staging or development site. Prefer authentication, an IP/VPN allowlist, or another access control, then give your authorized QA crawler access. Do not describe robots.txt plus noindex as redundant indexing protection: Google must crawl a URL to see its noindex, so a robots disallow prevents that tag from being read. If a public staging environment temporarily uses either control, record the exact mechanism and add a release check that proves it is absent on the production hostname. See Google’s robots meta documentation and site-move checklist.

Crawl staging and diff it against the baseline. “If you have a dev or staging site, you should crawl this to make sure everything’s okay before pushing.” You’re checking parity on the elements that carry ranking signals. My own on-page parity list is: Canonicals, Hreflang, Schema, Meta robots — plus:

• Canonical tags — “These should be the same.” Confirm they point at the new URLs, not at staging hostnames.
• Structured data parity — the same schema present on the new pages as the old.
• Internal links — “Things like breadcrumbs, related posts, footer links, or even the main navigation may have changed.” Update internal links to point directly at the new URLs — don’t rely on the redirect to do it for you (more on why below).
• Meta robots and hreflang carried over correctly.

Analytics and tag parity. Confirm your analytics and GTM container fire correctly on the new templates before launch, not after — a migration is the easiest place in the world to lose your measurement and not notice for a week.

Sample, don’t boil the ocean. For a large site, QA the test pages you pulled in Phase 1 (top pages by traffic and by links) rather than trying to eyeball every URL.

Phase 4 — Launch day

• Activate all redirects.
• Remove and inventory every staging-only control. Verify authentication or allowlists, any temporary robots or noindex rule, and staging-host canonicals are all absent from production. This is the first check if the new site is inaccessible or not getting indexed.
• Verify canonicals reference the new URLs, not staging.
• Regenerate and submit the current production XML sitemap in Google Search Console and Bing Webmaster Tools with new canonical URLs only. If an old-URL sitemap would provide useful redirect-discovery or monitoring evidence, submit it as a separate, clearly temporary sitemap; never mix the old and new inventories, and remove the old-URL sitemap when it no longer provides useful evidence. See Google’s site-move guidance.
• Submit Change of Address — for whole-domain moves only. Google’s tool is for moving “from one domain or subdomain to another.” It is explicitly not for HTTP→HTTPS moves, in-domain URL restructures, or www/non-www changes. It’s an extra signal, not a substitute for the redirects — the 301s do the real work. (Note the two different “180 days” figures Google mentions: you can cancel a Change of Address request for 180 days after filing, and separately the general redirect- maintenance floor is “at least 180 days.”) See the site’s own Change of Address tool page for when to use it. You must own qualifying old and new Search Console properties with no path scope: a Domain property qualifies, and a root URL-prefix property can qualify, but a path-scoped URL-prefix property cannot. See Google’s eligibility requirements.
• Bing: use IndexNow + bulk URL submission — not the Site Move Tool. The old Bing “Site Move Tool” no longer exists in the current Bing Webmaster Tools console, even though Bing’s own 2020 migration post still references it. Submit your migrated URLs via IndexNow and Bing’s bulk URL submission (up to 10,000 URLs/day) and spot-check with the URL Inspection tool. Most competitor checklists still list the retired tool — don’t be one of them.
• Server capacity. Google crawls the new site harder than usual right after a move: “Ensure that your new site has sufficient capacity to handle the increased traffic from Google.” For host-only moves, lower your DNS TTL to a low value (e.g. a few hours) at least a week ahead, and check that your firewall / DoS protection “does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.”

Phase 5 — Post-launch verification (first 48 hours to 2 weeks)

Crawl the full old-URL list against the live site. Confirm every old URL redirects to the correct new URL — no chains, no dead ends, no orphaned 404s. This is where the Phase 1 inventory pays off: you’re re-crawling that exact list.

Prioritize the fixes by link equity. A tool-based technique from my guide: in a backlinks report (Ahrefs’ “Best by links”), “filter for 404s to see pages with links that are now broken.” Fix the redirects on your most-linked pages first — that’s where a broken redirect costs the most.

Spot-check with URL Inspection. Use GSC’s URL Inspection tool to confirm Google sees the redirect and the chosen canonical on a sample of URLs; bulk-test the rest with your crawler.

Carry over your GSC settings. Post-migration this bundle is easy to forget: “This can include things like transferring your disavow file, setting geo-targeting, URL parameter settings, and uploading sitemaps.” Verify all variants — www, non-www, http, https — as separate properties in Search Console, not just one. On Bing, disavow files should be handled on both the old and new domains.

Phase 6 — The monitoring window (weeks 2–8+)

A migration isn’t done at launch; it’s done when the new URLs have settled in the index and traffic has stabilized. What to watch, and for how long:

• GSC Sitemaps report — if you submitted a separate old-URL sitemap, expect the crossover. “Initially, the sitemap containing the new URLs would have zero pages indexed, while the sitemap of the old URLs would have many pages indexed.” The new sitemap’s indexed count climbs from zero while the old one’s declines. This is the normal, expected pattern — not a failure signal. Knowing this in advance is what stops a mid-migration false alarm.
• GSC Index Coverage / Pages report for crawl errors, and the Performance report for new-URL impressions and clicks appearing.
• Rankings snapshots — weekly for the first couple of weeks, then bi-weekly.
• Server logs for Googlebot activity on the new host. For host-only moves, “It’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days.”

What “normal” looks like. Google: “Expect temporary fluctuation in site ranking during the move” and “Expect to see traffic drop on the old site and rise on the new site.” A “medium-sized website can take a few weeks for most pages to move” in the index; larger sites take longer. A wobble that recovers is the move working; a drop that never recovers means something broke — usually a redirect, a canonical, or a crawl block.

The monitoring numbers, sourced. Google’s guidance is “a few weeks” and longer for big sites. Bing is more specific and more conservative: “Log files are critical… and must be monitored on a daily basis once the actual website migration has been initiated for a period of at least three months.” A practical synthesis: daily GSC/log checks for the first 2 weeks, weekly through weeks 3–8, and a formal check-in at the 3-month mark for large migrations.

Keep the redirects. Google: “Keep the redirects for as long as possible, generally at least 1 year.” Bing goes further: “the redirects on the old domain need to remain live for at least 1 to 2 years, preferably longer.” Use the more conservative number — and remember redirects also serve real users with bookmarks and old links, so there’s rarely a reason to rush their removal. Decommission the old host only after logged traffic to it reaches zero — not on a fixed calendar date.

Why the internal-links step is non-negotiable

One item above deserves its own note because skipping it is so common. Mueller: “The other thing I would watch out for is all of the internal linking, so that you really make sure that all of the internal signals that you have as well that they’re forwarded to whatever new URLs.” And the specific failure mode: “what I’ve sometimes seen with these kind of restructurings is that you redirect the URLs, you move them over but you forget to set the rel canonical, you forget to set the links in the navigation, or in the footer somewhere.” The consequence isn’t a ranking crash — it’s slower consolidation: “It’s not so much that it would stop ranking but it’s more that we would just keep the old URLs for much longer than we actually need to.” Redirects alone work; they just work slower than redirects plus updated internal links.

AI summary

A condensed take on the Advanced version:

• Run it as six phases, not by migration type. The types/risk levels live in the site migrations hub; this is the ordered task list.
• Phase 1 — Benchmark. Full crawl of the old site as a baseline; a three-source URL inventory — sitemaps + server logs + analytics (never sitemaps alone, which miss orphaned-but-trafficked pages); snapshots of rankings, traffic, and indexed-page count; export top-linked pages as the priority-redirect list; back up + rollback plan.
• Phase 2 — Map + redirect. Every old URL → closest new URL, 1:1, with a server-side 301/308. Never bulk-redirect to the homepage; return 404/410 for genuinely dead pages. Keep chains low (≤3, fewer than 5). Self-referencing canonical on each new URL; carry over hreflang; include non-HTML assets.
• Phase 3 — Staging QA. Restrict staging with authentication or network access control, authorize the QA crawler, and remove staging-only controls at launch. Diff canonicals, hreflang, schema, meta robots, and internal links against the baseline; confirm analytics/GTM parity.
• Phase 4 — Launch. Activate redirects; remove staging blocks; regenerate and resubmit the current sitemap with new canonical URLs only; optionally submit a separate temporary old-URL sitemap for monitoring; submit Change of Address for whole-domain moves only (not HTTPS/in-domain/www changes); for Bing use IndexNow + bulk URL submission — the Site Move Tool is retired; ensure server capacity (lower DNS TTL a week ahead for host-only moves).
• Phase 5 — Verify. Crawl the full old-URL list — every redirect resolves, no chains, no orphaned 404s. Fix by link equity first (“Best by links, filter 404s”). Spot-check with URL Inspection; carry over GSC settings (disavow, geo-targeting, parameters); verify all variants (www/non-www/http/https) as separate properties.
• Phase 6 — Monitor. If you submitted a separate old-URL sitemap, expect the GSC Sitemaps crossover (new climbs from zero, old declines) — that’s normal. Watch coverage, performance, and rankings for 4–8 weeks; Bing recommends daily log monitoring for 3 months. Fluctuation that recovers is the move working; a drop that sticks means something broke.
• Keep redirects at least 1 year (Google) to 1–2 years (Bing); decommission the old host only once logged traffic reaches zero.
• Don’t rely on redirects alone — update internal links to the new URLs, or Google keeps the old URLs around longer than necessary (Mueller).

Official documentation

Primary-source documentation from the search engines.

Google

• Site move with URL changes — the master checklist: prepare, URL mapping, redirects, launch, and monitoring phases.
• Site move without URL changes (hosting/server) — DNS TTL, temporary hostnames, firewall/DoS cautions, and crawl-rate expectations for host-only moves.
• Redirects and Google Search — permanent vs. temporary redirects and signal strength.
• Change of Address tool — when to use it (and when not to), prerequisites, and the 180-day guidance.
• Consolidate duplicate URLs — canonical selection and the HTTPS-as-canonical preference.

Bing / Microsoft

• Website Migration with Bing — Bing’s 8-phase framework, redirect-retention and log-monitoring numbers. (Note: this 2020 post still references the retired Site Move Tool — see the Advanced tab.)
• IndexNow — Getting Started — the current way to notify Bing of migrated/redirected URLs at scale.
• Bing URL Inspection tool — spot-checking migrated URLs in Bing.

Quotes from the source

On-the-record statements from Google and Bing. Each Google-docs link is a deep link that jumps to the quoted passage.

Google — URL mapping and redirects

• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page.” — Google Search Central docs. Jump to quote
• “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” Jump to quote
• “Keep the redirects for as long as possible, generally at least 1 year.” Jump to quote

Google — what to expect during and after the move

• “Expect temporary fluctuation in site ranking during the move.” Jump to quote
• “a medium-sized website can take a few weeks for most pages to move.” Jump to quote
• “Initially, the sitemap containing the new URLs would have zero pages indexed, while the sitemap of the old URLs would have many pages indexed.” — Google Search Central docs (the expected Sitemaps-report crossover pattern when a separate old-URL sitemap is submitted). Read the source

Google — host-only moves

• “Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” — Google Search Central docs, on firewall / DoS protection. Jump to quote
• “It’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days.” Jump to quote

John Mueller, Google — Office Hours (via Search Engine Journal)

• “I think the most important part is really to track the individual URLs, so that you have a clear map of what previously was and what it should be in the future. And based on that, on the one hand to make sure that you have all of the redirects set up properly.” Read the coverage
• “The other thing I would watch out for is all of the internal linking, so that you really make sure that all of the internal signals that you have as well that they’re forwarded to whatever new URLs.” Read the coverage
• “Because what sometimes happens or what I’ve sometimes seen with these kind of restructurings is that you redirect the URLs, you move them over but you forget to set the rel canonical, you forget to set the links in the navigation, or in the footer somewhere.” Read the coverage
• “It’s not so much that it would stop ranking but it’s more that we would just keep the old URLs for much longer than we actually need to.” Read the coverage

Bing / Microsoft

• “Keep in mind that the redirects on the old domain need to remain live for at least 1 to 2 years, preferably longer.” — Bing Webmaster Blog, Website Migration with Bing.
• “Log files are critical… and must be monitored on a daily basis once the actual website migration has been initiated for a period of at least three months.” — Bing Webmaster Blog, Website Migration with Bing.

The website migration checklist

Work top to bottom. Don’t skip Phase 1 — everything after it is measured against it.

Phase 1 — Pre-migration benchmarking

• Full crawl of the old site saved as a baseline (URLs, titles, canonicals, status codes).
• Three-source URL inventory: sitemaps + server logs + analytics (not sitemaps alone).
• Non-HTML assets included in the inventory (images, videos, PDFs, JS, CSS).
• Benchmarks recorded: rankings, traffic, and indexed-page count (GSC + analytics).
• Backlink profile / top pages exported as the priority-redirect list.
• Backup taken and a rollback path confirmed.

Phase 2 — URL mapping and redirect strategy

• Every old URL mapped 1:1 to its closest new URL in a spreadsheet.
• Redirects are server-side 301/308 (permanent).
• No bulk-to-homepage; genuinely dead pages return 404/410, not a redirect.
• No redirect chains beyond ~3 hops (fewer than 5).
• Each new URL has a self-referencing canonical.
• Hreflang updated to new URLs (multilingual sites).

Phase 3 — Staging and pre-launch QA

• Staging protected with authentication or network access control; QA access documented.
• Staging crawled and diffed against the baseline.
• Parity confirmed: canonicals, hreflang, schema, meta robots, internal links.
• Internal links point directly at new URLs (not relying on the redirect).
• Analytics / GTM tags fire correctly on the new templates.

Phase 4 — Launch day

• All redirects activated.
• Production verified free of all staging-only controls and staging canonicals.
• Canonicals reference new URLs, not staging.
• Current production XML sitemap regenerated with new canonical URLs only and resubmitted in GSC and Bing Webmaster Tools.
• If useful, a separate temporary old-URL sitemap submitted for redirect discovery or monitoring, with an owner and removal condition.
• Change of Address submitted — whole-domain moves only (not HTTPS/in-domain/www).
• Bing: IndexNow + bulk URL submission (the Site Move Tool is retired).
• Server capacity confirmed; for host-only moves, DNS TTL lowered a week ahead and firewall/DoS not blocking Googlebot.

Phase 5 — Post-launch verification (first 48 hours–2 weeks)

• Full old-URL list re-crawled — every redirect resolves, no chains, no orphaned 404s.
• Broken redirects fixed by link equity first (“Best by links, filter 404s”).
• Sample spot-checked with URL Inspection.
• GSC settings carried over: disavow file, geo-targeting, URL parameters, sitemaps.
• All variants verified as separate GSC properties (www, non-www, http, https).

Phase 6 — Monitoring window (weeks 2–8+)

• If using a separate old-URL sitemap, its GSC Sitemaps crossover understood as normal (new climbs from zero, old declines) and its removal condition reviewed.
• GSC Coverage + Performance monitored for crawl errors and new-URL impressions.
• Rankings snapshotted weekly, then bi-weekly.
• Server logs checked for Googlebot on the new host (Bing: daily for 3 months).
• Redirects kept at least 1 year (Google) / 1–2 years (Bing).
• Old host decommissioned only after logged traffic hits zero (not a fixed date).

Migration cheat sheet

The six phases at a glance

Redirect rules

Change of Address — use it or skip it

Fast facts

• Three sources, not one, for the URL inventory — sitemaps + logs + analytics.
• Prove staging-only controls are absent from every production template at launch.
• Bing Site Move Tool is gone — use IndexNow + bulk URL submission (10,000/day).
• GSC Sitemaps crossover is relevant when a separate temporary old-URL sitemap is submitted; remove that sitemap when it no longer provides useful evidence.
• Decommission the old host only after logged traffic reaches zero, not on a date.

Tools for the redirect-map phases

• Redirect Chain Mapper — trace every hop, status, and host/path change when staged or live rules stack unexpectedly. Its cleanup rules help turn old → intermediate → new into a direct old → new redirect.
• Redirect Checker — fast verification for a single URL or small batch during launch. It cannot replace the Phase 5 crawl of the complete old-URL inventory.
• A full-site crawler — creates the Phase 1 baseline, crawls staging, tests every old URL after launch, and compares canonicals, directives, metadata, links, and status.
• Google Search Console URL Inspection and Sitemaps — spot-check Google’s reported redirect/canonical state and, when an optional old-URL sitemap is used, monitor the old-to-new sitemap crossover after launch.

Post-launch migration proof

Complete redirect-map test

• Test to run: Crawl the full old-URL inventory against production, then inspect any unexpected paths with the Redirect Chain Mapper.
• Expected result: Each moved URL reaches its approved equivalent through one server-side 301 or 308; intentionally retired URLs return their planned 404 or 410.
• Failure interpretation: A chain, loop, irrelevant target, or orphaned 404 means a rule or mapping did not ship as approved—not that redirects inherently lose value.
• Monitoring window: Run immediately after launch and after every redirect-rule fix; repeat during the first two weeks while crawlers are processing the map.
• Rollback trigger: A systemic rule sends a protected or high-link-equity section to wrong destinations or makes it unreachable and cannot be corrected safely in place.

New-URL canonical and indexability test

• Test to run: Crawl new URLs for 200 status, meta/X-Robots directives, and canonicals; spot-check representative pages in Google Search Console URL Inspection.
• Expected result: New pages are crawlable and indexable, declare the intended new canonical, and eventually show that same Google-selected canonical after recrawl.
• Failure interpretation: A staging noindex, blocked host, old/staging canonical, or conflicting internal signal prevents clean consolidation onto the new URL.
• Monitoring window: On-page signals are immediate; Google’s index and canonical crossover can take weeks for a medium site and longer for a large one.
• Rollback trigger: A site-wide crawl/indexability or canonical template defect affects the protected set and cannot be hot-fixed promptly.

Internal-link and sitemap test

• Test to run: Crawl rendered internal links and validate submitted sitemap URLs against the approved new canonical set.
• Expected result: Internal links resolve directly to new URLs, and new sitemaps list only successful canonical destinations—not old redirected URLs. Any old-URL sitemap is separate, temporary, and tied to a removal condition.
• Failure interpretation: Old internal links, mixed old/new sitemap inventories, or an old-URL sitemap retained after it stops providing useful evidence keep old URLs in circulation or obscure consolidation even when redirects work.
• Monitoring window: Verify immediately in production and again when Search Console processes the submitted sitemap.
• Rollback trigger: Navigation or sitemap generation points a broad section to old, staging, or broken URLs and cannot be corrected without reverting the release.

Test yourself: Website Migration Checklist

Five quick questions on running a migration by the numbers. Pick an answer for each, then check.

Resources worth your time

My related writing

• A Website Migration Takes More Than A Checklist To Be Successful (Ahrefs blog, updated Jan 2025) — the full migration guide behind this checklist: baselines, staging, parity, rollback, and the common mistakes.
• Redirects for SEO (Ahrefs blog) — 301 vs 302, chains, hops, and how long to keep redirects.
• Canonicalization (Ahrefs blog) — confirming Google’s chosen canonical post-migration via URL Inspection.
• Site Migrations — the hub: the 7 migration types, risk levels, and the universal process this checklist executes.
• Change of Address tool — when to use it (whole-domain moves) and when to skip it.

Official

• Google — Site move with URL changes and without URL changes.
• Google — Change of Address tool.
• Bing — Website Migration with Bing and IndexNow.

From around the industry

• Google’s Mueller On Keys To A Successful Site Migration (Search Engine Journal) — the source for the four Mueller quotes in this article.
• Website migration checklist: 11 steps for success (Search Engine Land) — a widely-referenced checklist-format walkthrough.
• The Complete Website Migration Checklist (Semrush) — a competing checklist reference; cross-check its tool recommendations against the Bing note above.
• r/TechSEO — the community for debugging redirect maps, crawl diffs, and post-launch coverage drops.

Changelog