Website Migration Checklist

A phase-by-phase website migration checklist — pre-migration benchmarking, URL mapping and 301 redirects, staging QA, launch day, and the post-launch monitoring window.

First published: Jul 2, 2026 · Last updated: Jul 15, 2026 · Advanced
demand #2 in Site Migrations#114 in Technical SEO#151 on the site
AIAuthored byAI v2
1 evidence signal on this page

This is the actionable, tick-box companion to the migrations hub — the same job, run as phases you can hand to a dev team: (1) pre-migration benchmark — full crawl of the old site as a baseline, a three-source URL inventory (sitemaps + server logs + analytics, not sitemaps alone), and snapshots of rankings, traffic, and indexed-page count; (2) map every old URL 1:1 to its closest new URL with a server-side 301/308, never bulk-to-homepage, no chains beyond 3–5 hops; (3) keep staging private with authentication or network access control, then crawl it with authorized tooling and diff canonicals, hreflang, schema, robots directives, internal links, and analytics/GTM tags against the baseline; (4) launch — remove staging-only controls, activate redirects, resubmit the current sitemap with new canonical URLs only, optionally submit a separate temporary old-URL sitemap for monitoring, and submit Change of Address for qualifying domain or subdomain moves; (5) post-launch, crawl the full old-URL list to confirm every redirect resolves with no chains or orphaned 404s; (6) monitor GSC coverage, performance, and rankings for 4–8 weeks. Keep redirects for at least 1 year for Google.

TL;DR — Run the migration as six phases, not as a migration-type taxonomy (the types live in the migrations hubA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once.). (1) Benchmark: full crawl of the old site as a baseline, a three-source URL inventory — sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. + server logsLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened. + analytics, never sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. alone — and snapshots of rankings, traffic, and indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.-page count. (2) Map + redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't.: 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 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., then removal of every staging-only control at launch; diff canonicals, hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others., schema, meta robotsThe robots meta tag is an HTML element in a page's head — <meta name=\"robots\" content=\"noindex\"> — that tells search engines how to index and serve that page. It's crawl-then-obey: a page blocked in robots.txt is never fetched, so the tag is never seen., and internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. against the baseline; check analytics/GTM tag parity. (4) Launch: activate redirects, regenerate and resubmit the current sitemap with new canonical URLsHow search engines pick one canonical URL among duplicates and consolidate signals onto it. only, optionally submit a separate temporary old-URL sitemap for monitoring, submit Change of Address for whole-domain moves only, use IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it. + 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: 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: 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 reportThe Google Search Console report (renamed from \"Index Coverage\" in 2022) that shows which URLs Google has indexed, which it hasn't, and why. It splits your known URLs into Indexed and Not indexed, grouping the not-indexed ones by reason.) 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 PageRankPageRank is Google's original recursive link-graph algorithm: a page's score depends on the scores of the pages linking to it, and in the published model each page's score is split across its outbound links (the simplified version: links are weighted votes). Google says it's evolved since launch but still part of its core ranking systems..
  • 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 hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others. 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 redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. guide.

TIP Build and review the migration map

To compare old and new inventories, surface uncertain matches, and export reviewed rules, use the Redirect Map Builder Free

  1. Upload the complete old and new URL inventories before launch, not a sample after the move.
  2. Review low-confidence, unmatched, many-to-one, and irrelevant suggestions manually; choose 404 or 410 when no equivalent exists.
  3. Export the approved map, test it on staging, and crawl every old URL again after deployment.

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 crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. access. Do not describe robots.txt plus noindex as redundant indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. 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 tagsA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. — “These should be the same.” Confirm they point at the new URLs, not at staging hostnames.
  • Structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. parity — the same schema present on the new pages as the old.
  • Internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. — “Things like breadcrumbsBreadcrumbs are a secondary navigation trail (Home > Category > Page) that shows where a page sits in a site's hierarchy. They create internal links that pass PageRank, and when marked up with BreadcrumbList structured data they can drive the path Google shows in desktop search results., 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 sitemapAn XML sitemap is a UTF-8 file listing the canonical URLs on your site (with optional lastmod) so search engines can discover and prioritize them. It's a discovery and diagnostic aid, not a guarantee of indexing — and Google ignores its priority and changefreq tags. in Google Search Console and Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. 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→HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' 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 toolA setting in Google Search Console that tells Google you've moved your whole site to a new domain or subdomain. It's a supporting signal for a domain migration — the 301 redirects do the real work of transferring rankings. page for when to use it. You must own qualifying old and new Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. 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 toolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version.. 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 GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’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-crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. 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 geoGenerative Engine Optimization — visibility inside AI answer engines.-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 reportThe Google Search Console report where you submit sitemaps and watch how Google processes them — type, last read date, status, and how many URLs were discovered. It confirms Google read your list; it doesn't prove anything got indexed. — 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 rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. 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.

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 linkingLinks between pages on the same site., 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.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.