LinkGuard cover — Site migration SEO checklist: 37 items for surviving a 2026 domain move

You are 14 days from cutover. The new domain is half-built. The redirect map is a spreadsheet with 12 thousand rows of "decide this later." The CEO wants a launch-day press release. Your dev lead wants to bundle the CMS swap, the redesign, the new pricing pages, and the domain change into one release because "we're already touching everything." The last time your company migrated was 2019, the consultant who ran it has left, and the only checklist anyone can find is the 2017 HTTP-to-HTTPS one Aleyda Solís published when www-versus-non-www was still a debate.

This checklist is for that 14-day window. It is not a beginner's guide. It assumes you know what a 301 is and you have read enough migration content to know that "1:1 redirect mapping" is the spine. It focuses on the four 2026 shifts that now belong on every serious migration checklist and that older guides do not cover: (1) migration as a quality-reassessment trigger — Google now uses a domain change to re-evaluate the entire site, and pre-existing junk content that was tolerated on the old domain can collapse rankings on the new one; (2) AI-surface persistence — ChatGPT, Claude, Perplexity, and Google AI Mode have memory of your old domain in training data, and there is no Change of Address form for an LLM; (3) the early-launch pattern — Mueller's "launch new domain 7-14 days BEFORE the redirects" guidance from 2023 is now operator default in 2026; (4) edge-CDN-routed migrations — Cloudflare Workers, Fastly, and Vercel edge are now a normal cutover pattern that older DNS-based migration guides do not address.

Three numbers anchor what's at stake.

1. The average site that runs a domain migration takes 523 days — about 17 months — to return to its pre-migration organic-traffic level. 17% of the migrations in the study never recovered to baseline after 1,000 days. The fastest recoveries clocked at 19-33 days. Source: Search Engine Journal's recovery study of 892 domain migrations, updated 2024. The 17% never-recover rate is down from 42% in the 2023 version of the same study — operator practice has improved — but the permanent-loss tail is still meaningfully larger than most stakeholders are told before they sign off on the migration. Your work over the next 14 days is the difference between landing in the 33-day cohort and landing in the 17%. Migrations are also the highest-visibility piece of SEO work most leads will ever own — the number that lands in the executive readout 90 days later is the number that defines you for the next two years.

2. A workable expectation, even for a well-run migration, is 30-40% organic traffic loss for three to six months before you are back to baseline. Source: Joost de Valk, Yoast founder, "The missing guide to SEO domain migrations" (SMX Munich 2025, updated 2026). This is not a prediction of failure — it is the realistic baseline that even careful execution produces. If you are promising the CEO no traffic loss, you are setting up a credibility-loss event you cannot win. Set the expectation early: the cleanest migration in the world dips, then recovers, on a timeline measured in months.

3. In June 2025, John Mueller publicly diagnosed a domain migration (javatpoint.com → tpointtech.com) where rankings collapsed not because of redirect issues but because the new domain inherited the old domain's content. Mueller's diagnostic of that case: migrating to a new domain forced Google to re-evaluate the entire site, and that is when the pre-existing low-quality content became the issue. His own verbatim observation while looking at the collapsed site: "One of the things I noticed is that there's a lot of totally unrelated content on the site." Source: Search Engine Journal, June 10 2025. This is the freshest piece of consensus in the 2026 migration playbook and the most commonly-missed step: a content cull is now mandatory BEFORE the move, not after. If your old site is carrying off-topic content, abandoned campaigns, or thin pages that Google has been tolerating for years, the migration is when that tolerance ends.

If you have run one of these before, you already know the feeling of the second Monday after cutover: the dashboard is red, the CEO wants a one-line explanation, and the redirect map you signed off on has a question mark next to a URL you cannot find in any export. The work below is meant to leave you with no question marks on day eight.

This checklist has 37 items across 7 categories: pre-migration planning & baseline, URL & redirect map, indexability & canonicals on the new domain, day-zero launch verification, backlinks + brand entity + AI-surface continuity, post-migration monitoring across the first 12 months, and anti-patterns being sold as migration best practice in 2026 that do not survive scrutiny. Tier filter, browser-saved progress, no account required.

Quick answers (the 4 questions you searched for)

How long does a site migration take to recover? The average domain migration takes 523 days to return to pre-migration organic traffic, per Search Engine Journal's recovery study of 892 migrations. The fastest recoveries clock at 19-33 days; 17% never recover after 1,000 days. A workable expectation for a clean migration is 30-40% traffic loss for three to six months before you are back to baseline (Joost de Valk, 2026).

Is Google Search Console's Change of Address tool worth filing? Yes, where it applies — it opens a 180-day window during which Google forwards signals and favors the new property. But COA does NOT replace 301 redirects, and it does not work for HTTPS migrations, www/non-www changes, or URL path changes within the same domain. File it as confetti on top of a clean redirect map; do not file it expecting it to fix a broken move.

How long should I keep migration redirects live? At least 12 months (Gary Illyes, Google) — ideally indefinitely if practical. Keep both domains registered. The old domain's robots.txt must NOT block crawling during this window; Google needs to crawl the old URLs to follow the 301s and consolidate signal on the new domain. The "block the old site so it doesn't compete" pattern is a 2018 mistake that still ships in 2026 guides.

Can I bundle a CMS swap, domain change, redesign, and content overhaul into one release? No — even Joost de Valk, the strongest public voice arguing this can work, caveats that most teams fail it. Shopify's 2026 migration checklist Step 3 is literally "Isolate the migration strategy." Mueller and Illyes both recommend separating concerns. When traffic drops in week 2, bundled migrations are an attribution nightmare: you cannot tell which dimension broke.

Vocabulary

If you have read our technical SEO pre-launch checklist and indexation troubleshooting checklist you have most of these. New terms in italics.

301 / 308: the two HTTP redirect codes Google honours as permanent. 301 is the classic; 308 preserves the request method (POST stays POST). Either works for SEO; pick one and stick with it across the migration.
Change of Address (COA): Google Search Console tool that signals a domain move to Google for a 180-day signal-transfer window. Does NOT replace 301s; works only for true domain or top-level-subdomain changes; does NOT work for HTTPS, www/non-www, path changes, or same-URL-different-host moves.
hostAge: leaked Google Content Warehouse API attribute that quietly down-ranks brand-new hostnames until they accumulate real-world trust. A domain change resets this calendar on the new hostname even when 301s carry PageRank.
sameAs: schema.org property listing a brand's other canonical URLs (LinkedIn, Crunchbase, Wikidata, X). On a migration, every sameAs reference to the old domain on third-party profiles must be updated.
AI-surface persistence: the lag during which AI engines (ChatGPT, Claude, Perplexity, Gemini, Google AI Mode) keep returning your OLD domain as the citation source because their training data predates your move. There is no "Change of Address" for an LLM.
Early-launch pattern: launching the new domain (crawlable, indexable, but with no inbound redirects yet) 7-14 days BEFORE the cutover that flips the 301s. Mueller's 2023 guidance, now operator default.
Big-bang vs phased cutover: big-bang = all redirects flip at the same instant. Phased = sections migrate over weeks. 2026 default for sites ≤ 100k URLs: big-bang with early-launch pre-stage. Phased for enterprise multi-domain consolidations only.
Edge-routed migration: keeping DNS pointed at the CDN edge (Cloudflare Workers, Fastly, Vercel) and using an edge function to route between old and new origins. Cutover becomes a config flag, not a DNS-propagation event. Gives instant rollback; adds an extra hop and edge-side failure modes.
Soft 404: a page that returns HTTP 200 but is functionally a not-found page (empty content, "page not found" body, or a homepage redirect that has no real match). Google treats these as 404 anyway and trust in your URL→status mapping drops.
Migration as quality-reassessment trigger: Mueller's June 2025 framing — Google uses a domain move as an opportunity to re-score the entire site for content quality. Off-topic / thin / abandoned content that was tolerated on the old domain can collapse rankings on the new one.
Substantially-similar redirect: Mueller's standing test for a "good" 301 — the destination URL must serve substantially the same content topic as the source. A 301 to an unrelated page is treated as a soft 404.

What success looks like

+90 days post-cutover: organic traffic is back to 90-95% of baseline. GSC shows your old URLs steadily de-indexed and the new URLs taking their slot. The "Pages with redirects" report is trending toward zero. The +90-day post-mortem is on the calendar with the migration DRI as owner and a 1-page lessons-learned doc that updates your internal runbook. Two MORE Mondays after cutover have passed without a paging incident, and the third one will too. The next migration on your career — the one nobody will brief you on for another two years — will be 60% faster because you wrote down what you learned.

What you do NOT do: promise the CEO same-day traffic recovery. The cleanest migration in the world dips, then recovers, on a timeline measured in months. Give the executive team the 523-day study before you sign off, so they know the difference between a good migration and an average one is a year and a half. You set the expectation early, then beat it. Beating an expectation you set is a career-defining moment; missing one you didn't set is a career-defining incident.

Related reading: migrations are where redirect chains pile up — see redirect chains explained: what they are, why they hurt SEO, and how to fix them.

0 / 37 · 0%

Critical Important Nice to have

Show only undone

Per Joost de Valk: 'Migrations that go badly went badly in Phase 2.' This is 90% of the work. Lock these before the dev team merges anything.

Critical Single Directly-Responsible-Individual named in writing — not a committee Every recovered post-mortem of a migration disaster traces back to fractured ownership: SEO assumed dev did the redirects; dev assumed SEO did the canonicals; PM assumed both. One person owns the migration end-to-end, signs off on the redirect map, and has authority to delay launch. Without this, the launch-day Slack channel becomes a finger-pointing surface and bugs ship.
How to do this
Name a single DRI for the migration in writing. Their job is not to do every task — their job is to own the outcome.
The DRI's authority must include:
Veto over the launch date if the redirect map is not verified.
Final sign-off on the URL strategy (slug conventions, trailing-slash, www/non-www).
Coordination across SEO, dev, content, PR, and paid-media — paid campaigns that point at old URLs must be in the redirect-priority list.
The +90-day post-mortem.
Put their name + accountability in a 1-page migration charter shared with all stakeholders. If you cannot get this signed before kickoff, the migration is already in trouble.
Critical Migration scope frozen in writing — name what's changing and what's NOT The single most expensive 2026 mistake is bundling. CMS swap + domain change + redesign + content overhaul + new URL structure, all in one release, is a category-A attribution nightmare when traffic drops in week 2 — you cannot tell which dimension broke. Shopify's 2026 checklist Step 3 is literally 'Isolate the migration strategy.' Mueller and Illyes both recommend separating concerns where possible.
How to do this
Write a 1-page scope doc listing each dimension that is and is not changing:
Domain (acme.com → acme.ai? same? subdomain → folder?)
CMS / platform (WordPress → Webflow? same?)
URL structure (/blog/post-slug → /posts/{id}? same?)
Page design / templates (full redesign? minor tweaks? same?)
Content (rewrites? cull? same?)
Metadata (titles / descriptions / schema — preserved verbatim? regenerated?)
For high-stakes sites, change ONE dimension at a time across separate releases. If business pressure forces bundling, document it explicitly and plan for the attribution-nightmare risk in your monitoring runbook. Joost de Valk: most teams who bundle, fail. The Guardian's multi-CMS consolidation worked; almost no one's does.
Critical Pre-migration content cull executed — remove junk BEFORE the move, not after Mueller's June 2025 javatpoint → tpointtech diagnosis: migration triggers a full quality re-evaluation of the new domain. If the old domain carried off-topic content, abandoned campaigns, AI-generated cruft, or expired-product pages that Google had been tolerating for years, the new domain inherits all of it under a fresh lens. The honest test: run `site:olddomain.com sexy` or `site:olddomain.com top 10` or other off-brand queries and look at what surfaces.
How to do this
Two weeks before the migration:
Run site-search audits with off-brand queries (porn-keywords, gambling, off-topic listicles, hacked-site detritus) to find content that exists but doesn't belong.
Run a Screaming Frog crawl + sort by inlinks ascending and impressions ascending (GSC data) — the orphans + zero-impression pages are candidates.
For each junk page: either delete (return 410 Gone) or `noindex` it on the OLD domain before the migration, so the signal of removal predates the move.
Do NOT just plan to skip junk pages from the redirect map and let them 404 on the new domain — Google reads them as inherited problems even then.
Don't be conservative here. The migration is your one chance to escape years of accumulated cruft.
Critical Decide big-bang vs phased + early-launch lead time — calendared, not 'TBD' 2026 operator default for sites ≤100k URLs: big-bang cutover with the new domain crawlable 7-14 days before the 301s flip. Mueller's 2023 early-launch guidance is now consensus. For sites >100k URLs with high-revenue critical paths, big-bang still wins for the SEO half (atomic redirect map) but phasing the feature rollout is acceptable. Illyes-style phasing applies to multi-domain consolidations (acme.com + foo.com → bar.com), not to single-domain CMS swaps.
How to do this
Lock the answer in the project plan:
Big-bang day: pick Tuesday or Wednesday morning. Never Friday afternoon. Never the week of a major holiday. Never during an actively-rolling-out Google core update window (check Search Status Dashboard).
Early-launch lead time: the new domain goes live, crawlable, indexable, with the new sitemap submitted, between 7 and 14 days BEFORE the redirect cutover. This gives Google time to discover and index the new URLs so the 301 signals find ready targets.
DNS TTL prep: reduce TTL on the cutover hostname to 300s about 48 hours before launch — wait the full duration of the OLD TTL for that change to propagate.
If business pressure pushes for a Friday or holiday launch: push back. The cost of needing to fix something at 4pm Friday with no on-call is higher than the cost of moving the date by 4 days.
Critical Complete crawl + export of the OLD site captured as the redirect-map source-of-truth Without a complete inventory of every old URL (every title, H1, canonical, status code, inbound link source) you cannot build a 1:1 redirect map. You cannot detect orphans. You cannot diff the post-launch crawl. Every recovered migration disaster traces back to a missing entry in the inventory — the URL nobody knew existed that drove 4% of organic traffic.
How to do this
Run a full crawl of the old site at least 14 days before cutover. This is a crawler job — there is no monitor-tool substitute. Tools that own this workflow:
Sitebulb — its Migration Audit is the named industry artifact for exactly this step; auto-generates the inventory + flags drift.
Screaming Frog — free tier handles 500 URLs; licensed unlimited; CSV plumbing is excellent.
Botify or Lumar (formerly DeepCrawl) — enterprise default for sites >500k URLs.
Export to CSV with at minimum these columns:
URL (full absolute), Status code, Canonical (raw HTML), Title, H1, Meta description, Inbound internal links (count + source URLs), Current redirect destination (if URL is itself a redirect), noindex / X-Robots-Tag values.
Augment with GSC export: top 500-1000 URLs by clicks (last 90 days), which is the link-equity priority list. This becomes the redirect-map source-of-truth. Re-crawl 24h before launch to catch last-minute changes.
Important Baseline metrics frozen in writing, including AI-surface snapshot If you don't snapshot baselines, you can't measure recovery. The traditional baseline is GA4 sessions, top keyword rankings, top landing pages, backlink count, Core Web Vitals — all still mandatory. The new 2026 piece is the AI-surface snapshot: capture how ChatGPT, Claude, Perplexity, and Google AI Mode answer 5-20 priority queries about your brand and category, with screenshots. Without this, you cannot tell whether month-3 'no AI citations' means the migration broke them or means they were never there.
How to do this
Lock these in a dated, shared document, 7 days pre-cutover:
GA4: 90-day organic sessions, top 200 landing pages by sessions, top 50 conversion events.
GSC: top 500 keyword positions (export Performance → Queries), top 500 landing pages (Performance → Pages).
Backlinks: top 100 referring domains (Ahrefs / Moz / Semrush), with anchor text.
Core Web Vitals: CrUX field data per page-type.
AI-surface snapshot: for each of 5-20 priority queries, screenshot the response from ChatGPT (search-enabled), Claude, Perplexity, Google AI Mode, and Google AI Overview. Note which engines cite you, which cite competitors.
Save with the date. Re-capture at +30, +60, +90 days post-cutover. You can't recover what you can't measure.
Important Paid-media + email URLs updated the morning of cutover — every campaign destination points at the NEW URL Every paid campaign (Google Ads, Meta, LinkedIn, X), every transactional email template, every email-signature URL, and every social-bio URL still pointing at the OLD domain hits the 301 on launch day. That costs you conversion rate (Safari and Brave strip referer through 301s), wastes paid-media budget on the redirect hop, and breaks email-deliverability heuristics that flag freshly-redirecting links as suspicious. This is the DRI's first launch-day checklist item but nobody writes it down.
How to do this
The morning of cutover (before the 301s flip):
Google Ads, Meta Ads, LinkedIn Ads: bulk-edit destination URLs across all active campaigns → new domain. Most platforms have a CSV bulk-update; use it.
Transactional email templates: order confirmations, password-reset, invite emails — every URL in every template.
Email signatures: company-wide signature management (e.g. Exclaimer) update; ping the team to refresh local clients.
Social profile bios: X, LinkedIn, Instagram, TikTok, YouTube About — every link in every bio.
Affiliate / partner links: if you run an affiliate program, push the new URL into the affiliate dashboard same morning.
Spot-check one URL from each surface post-cutover with curl -sI — first response line should be 200 (direct hit), not 301 (still pointing at old).

The most error-rich workstream and the one that decides what fraction of your historical link equity reaches the new URLs. Kelly-Anne Crean: 'In one rescue, every URL gained a trailing slash. Only the top 50 pages had correct redirects. Thousands of other URLs redirected to the homepage.' That is the failure mode this category prevents.

Critical One-to-one mapping for EVERY old URL — closest-equivalent or 410, never blanket-to-homepage Mueller's standing guidance: redirecting orphan URLs to the homepage is treated as a soft 404 and destroys signal. Kelly-Anne Crean's March 2026 SEL piece names the failure mode concretely: thousands of URLs to homepage = catastrophic equity loss. The default 'wildcard the long tail' shortcut is the single biggest reason migrations land in the 17% never-recover tail per the SEJ 892-domain study.
How to do this
For every old URL in your inventory:
If a closest-equivalent page exists on the new site → map 1:1 (301 to that URL).
If no equivalent exists but the topic is preserved (e.g. old product category collapsed into a parent) → 301 to the nearest topical parent.
If no equivalent and no parent → return 410 Gone (preferred; tells Google the page is intentionally removed) or 404 Not Found (acceptable).
Never redirect orphans to the homepage. Mueller is explicit about this; Google treats it as a soft 404 and the redirect carries no signal.
For relaunches with >1000 URLs: use LLM-assisted matching (Rapid301, SEOMigrator, or a custom Claude/GPT prompt) for the fuzzy mid-tier. Joost de Valk's 2026 guide: 'LLMs are now effective enough to take meaningful work off your plate during a migration.' But human-verify the top 200 by clicks before launch.
Critical All redirects are server-side 301 or 308 — no 302, no meta-refresh, no JS redirects 302 is 'temporary' and Google treats it differently — signal transfer is slower and less reliable. Meta-refresh and JS-based redirects work but require Google to render the page first; AI crawlers do not execute JS and will not follow them at all. Use 301 (permanent) or 308 (permanent, method-preserving) — both pass full PageRank, both signal a permanent move. The '301 loses 15% PageRank' zombie myth is from a 2013 Matt Cutts phrasing Illyes has corrected multiple times since 2016.
How to do this
Server-level implementation:
Nginx: rewrite ^/old-url$ /new-url permanent; (sends 301).
Apache .htaccess: Redirect 301 /old-url /new-url or RewriteRule ^old-url$ /new-url [R=301,L].
CDN edge (Cloudflare Workers, Fastly VCL, Vercel edge): return new Response(null, { status: 301, headers: { Location: '/new-url' }}).
Bulk verify after deploy: curl -sI -L https://yoursite.com/old-url — the first response line should be HTTP/1.1 301 Moved Permanently, the final follow should be 200 OK on the intended destination.
Push back hard on devs who want to justify NOT setting up redirects 'because they leak PageRank anyway.' That is wrong since 2016. Illyes: 30x redirects pass full PageRank.
Important No redirect chains longer than 1 hop on critical paths; chains accumulate across migrations Mueller's recommendation: keep chains ≤5 hops, ideally 1. Each hop adds latency, consumes crawl budget linearly, and loses signal at the margin. Chains accumulate when older migrations were not consolidated — a URL from 2018 might 301 to 2020 → 301 to 2023 → 301 to 2026 today. Compress every chain to a direct 301 from the original source URL to the current final destination.
How to do this
Audit (Screaming Frog → Reports → Redirects):
Crawl every URL in your sitemap PLUS the old-URL inventory from plan-05.
Filter for status 301/302 → identify chains (URL A → B → C → D).
For each chain, update the original 301 rule to point directly at the final destination (A → D, one hop).
Internal links on the NEW site must point at the FINAL URL, not at a URL that 301s. Update the source HTML; don't rely on the redirect every request.
Long chains aren't a publish blocker for most sites but they're a slow tax. The migration window is the cheapest time to clean up historical chains from previous moves.
Critical Old domain's robots.txt is NOT Disallow: / after launch — Google needs to crawl to see the 301s Legacy migration guides recommended 'block the old site so it doesn't compete with the new one.' This kills the redirect signal. Google must crawl the old URLs to follow the 301s and consolidate signal on the new domain. Joost de Valk's 2026 guide names this explicitly: empty (or leave unrestrictive) the old domain's robots.txt at cutover. The 301 IS the 'don't compete' signal; blocking the crawl prevents the consolidation you wanted.
How to do this
Within the first 5 minutes of cutover, check the OLD domain:
curl -s https://old-domain.com/robots.txt — confirm there is no Disallow: / directive for User-agent: * or User-agent: Googlebot.
If the old robots.txt was previously restricted, replace with a minimal allow-all + sitemap reference:
User-agent: * Allow: / Sitemap: https://old-domain.com/sitemap.xml
(the OLD sitemap is still useful for 30-90 days so Google discovers and processes the redirects).
Keep this state for at least 12 months post-cutover — ideally for the full lifetime of your redirect rules. The 'block the old site' pattern is a 2018 mistake that still shows up in 2026 migration guides; the 301 is the consolidation signal, blocking the crawl prevents the consolidation you wanted.
Check your robots.txt free
Important Redirects retained for at least 1 year — both domains registered indefinitely Gary Illyes's standing recommendation: keep migration redirects live for at least 12 months so signals fully migrate. After that they stick with the destination. His stronger user-experience guidance: keep them indefinitely if practical. Joost de Valk, 2026: keep both domains registered indefinitely — 'search engines aren't the only systems with a memory of your old domain anymore' (AI training data, ancient bookmarks, deep-linked emails).
How to do this
Operationally:
Domain registration: renew the OLD domain auto-renew for at least 5 years. Annual renewal cost is trivial; lapsed-domain risk is catastrophic (domain squatter buys it, every old link in your equity graph becomes a vote for them).
301 rules: keep all redirect rules in production config for at least 12 months. After 12 months, audit which old URLs still receive traffic / Googlebot hits; prune rules with zero traffic for 6+ months if your dev team wants the config trimmed.
SSL on old domain: keep the SSL cert renewed for the old domain. Browsers warning on HTTPS errors is the second-worst possible outcome of a forgotten renewal.
DNS for old domain: keep pointing at the same server / CDN so the 301 rules continue to serve.
If procurement / finance ask why you're paying $10/year for a domain you don't use: it's the cheapest insurance policy in your stack.
Important Internal links on the NEW site point to FINAL URLs — no internal links into redirects Every internal link that points at an old URL that 301s is one extra hop the user (and Googlebot) has to follow. Crawl budget tax. Latency tax. On a fresh site cold-starting from `hostAge`, every signal optimization matters. The 301s handle external referrers you can't update; internal links you control should point directly at the final destination.
How to do this
Search the new-site source for any links containing the old domain:
# grep all template / content files grep -r 'old-domain.com' app/templates/ app/static/ content/ 2>/dev/null # crawl the deployed new site, filter for internal links screaming-frog --headless --crawl https://new-domain.com --filter 'href contains old-domain.com'
Replace every match with the new-domain equivalent.
Also audit for internal links to URLs that 301 within the new domain:
Crawl the new site.
Filter Internal Links → Status Code 301.
For each: update the source link to point at the redirect destination directly.
This is the cheapest internal-SEO win available during the cutover window. Skip it and every page on your site pays the hop tax forever.

Highest blast-radius bucket on launch day. One missed noindex or Disallow: / and the new domain ranks for nothing. One canonical pointing back at the old domain and the new domain de-indexes itself.

Critical NEW domain robots.txt does NOT contain Disallow: / and does not block /assets/, /static/, /css/, /js/ Same launch-day disaster as a greenfield site: staging robots.txt with Disallow: / survives into production and de-indexes the entire new domain. Plus Googlebot needs CSS and JS to render the page, compute Core Web Vitals, and decide content visibility. Blocking /assets/ or /wp-content/ silently degrades rendering across the new site.
How to do this
Within 5 minutes of cutover:
curl -s https://new-domain.com/robots.txt
Confirm no Disallow: / under User-agent: * or User-agent: Googlebot.
Confirm no Disallow: /assets/, /static/, /css/, /js/, /wp-content/.
Run GSC → URL Inspection → Test live URL → View tested page → Screenshot. If the rendered screenshot looks like a 1995-unstyled page, CSS is being blocked.
Cross-link our pre-launch checklist for the full indexability staging-leak prevention pattern (idx-01 through idx-08) — same rules apply on the new domain.
Check your robots.txt free
Critical Self-referencing canonical on every indexable new-domain page — points at NEW URL, not OLD Most common copy-the-template-from-staging mistake: canonicals on the new domain still point back at the old domain because the staging template was duplicated and nobody updated the canonical generation logic. Google honours the canonical signal; if it says 'this page is canonical on the OLD domain', Google de-indexes the new domain version. Self-canonicals on the new domain must reference the NEW URL.
How to do this
Audit after launch:
Crawl new domain with Screaming Frog → Canonicals tab.
For every indexable URL, the canonical MUST: (a) be present in raw HTML (not JS-injected), (b) be absolute, (c) start with https://new-domain.com/, (d) match the page URL itself (self-referencing).
Spot-check 20 priority pages with curl -s https://new-domain.com/page | grep canonical.
Any canonical pointing at the OLD domain on the NEW domain is a launch-day blocker. Fix the template + redeploy; do not 'just submit URL Inspection requests' to paper over it.
Validate this canonical free
Critical No site-wide noindex on new domain — meta tag, X-Robots-Tag header, OR CMS plugin defaults Three independent surfaces can carry noindex on the new domain: HTML meta tag, HTTP X-Robots-Tag header (set by CDN/edge/server config), and per-CMS plugin defaults. Any one shipped from staging silently de-indexes. Google honours the strictest signal — so the directive only has to leak in one place to cost you the entire migration.
How to do this
Three checks, within 1 hour of launch:
Meta tag: view-source any indexable page on new domain; search for noindex. Should be absent (except on intentionally-noindex'd surfaces like cart, account, search-results).
HTTP header: curl -sI https://new-domain.com/ | grep -i x-robots-tag — should return nothing or no noindex value.
GSC verification: URL Inspection on 5 random indexable URLs — 'Indexing allowed: yes'.
WordPress site? Check Settings → Reading → 'Discourage search engines from indexing this site' — must be UNCHECKED on production. This is the most common WP-specific noindex leak in 2026 migration disasters.
Run the on-page audit free
Critical Sitemap on NEW domain submitted in NEW GSC property — keep OLD sitemap submitted for 30-90 days The new domain's sitemap (with new URLs) goes in the new GSC property. But also keep the OLD domain's sitemap submitted in the OLD GSC property for 30-90 days — when Google crawls the old URLs from the old sitemap and hits the 301, signal-transfer happens faster than waiting for organic re-discovery. Drop the old sitemap submission only after you stop seeing old URLs in 'Pages with redirects' report.
How to do this
On launch day, in NEW GSC property:
Domain property added + DNS-verified for the new domain (covers all subdomains + protocols).
Submit the NEW sitemap-index URL at https://new-domain.com/sitemap.xml or /sitemap-index.xml.
Verify sitemap parses + has no 4xx/5xx URLs (Screaming Frog → Mode → List → paste sitemap URL).
In OLD GSC property, keep submitted:
The OLD sitemap with the old URLs that now 301 — accelerates Google's discovery of the redirects.
Re-submit on cutover day to trigger re-crawl.
Drop the submission after 90 days OR after 'Pages with redirects' count falls below ~10% of the original old-URL count, whichever comes first.
Important AI-crawler robots.txt policy decided and applied per bot on the new domain Same per-bot decisions as pre-launch (cross-link our robots.txt AI-crawler checklist). Migration is a natural moment to re-evaluate: do you want GPTBot crawling the new domain for training? OAI-SearchBot for ChatGPT Search citations? ClaudeBot for Anthropic training? Default to allowing search-flavored bots, decide separately on training bots based on content type.
How to do this
On the new domain's robots.txt, decide and document ALLOW or DISALLOW for each:
GPTBot (OpenAI training), OAI-SearchBot (ChatGPT Search), ChatGPT-User (live fetch)
ClaudeBot (Anthropic training), Claude-User (live fetch), Claude-SearchBot (search indexing)
PerplexityBot, Google-Extended (Gemini training), CCBot (Common Crawl)
Document the policy in a top-of-file comment so future devs don't undo it.
Full per-bot reasoning + 2026 defaults in our robots.txt AI-crawler checklist. If you blanket-blocked AI on the OLD domain — reconsider. Late-2025 directional research found publishers who blanket-blocked AI experienced ~23.1% total traffic decline without reliable citation reduction [weak provenance, directional].
Check your robots.txt free
Critical Staging hostnames de-indexed in Google BEFORE the new domain launches The second-most-common launch-day disaster after the staging Disallow: / leftover: the staging hostname (e.g. new.staging.acme.com, preview-*.vercel.app, *.netlify.app preview deployments) is already in Google's index when you launch the new domain. Google has two competing canonical URLs for the same content and may pick the staging one. Your new-domain SERP slot is silently eaten by the staging URL.
How to do this
One week before cutover:
Audit Google's index for staging surfaces: site:staging.yourdomain.com, site:vercel.app inurl:yourproduct, site:netlify.app inurl:yourproduct. Any results = staging is indexed.
If indexed: GSC → Removals → New request → Temporarily remove URL (or whole prefix). Remove takes effect within hours; lasts ~6 months.
Permanent fix: HTTP-auth-protect the staging hostname (per idx-04 pattern) AND add server-side X-Robots-Tag: noindex, nofollow header for the staging hostname.
Add Disallow: / on the staging robots.txt as backup (advisory only — auth is the real defence).
This MUST be done before the new domain goes live and indexable. If staging gets into the index first, you spend the first 30 days post-cutover fighting your own preview environment for SERP slots.
Important Third-party script allowlist audit — every script with a domain whitelist works against the NEW host Analytics, GTM, consent-management platforms (Cookiebot, OneTrust), A/B testing (Optimizely, VWO), chat widgets (Intercom, Drift), heatmap tools (Hotjar, FullStory), error tracking (Sentry), customer-support widgets (Zendesk, HelpScout) — most have a domain-allowlist in their config tied to the OLD hostname. On launch day they silently stop accepting events from the NEW hostname, and you lose data right when you need it most.
How to do this
One week pre-cutover, audit every third-party script the site loads:
Crawl the homepage + 5 priority pages with Chrome DevTools → Network → filter type:script. List every external host loaded.
For each script vendor, find the config dashboard → look for 'Allowed domains', 'Site URL', 'Authorized domains', or equivalent field.
Add the NEW domain alongside the OLD (do not replace — keep both during the transition window so cross-domain tracking continues to work).
Common offenders to check first:
GA4 + GTM: Property → Data Streams → add new domain stream OR update existing stream URL.
Cookiebot / OneTrust: Domain list → add new hostname.
Optimizely / VWO: Project domain settings.
Stripe: Dashboard → Payment methods → Apple Pay → Domain registration.
Auth providers (Auth0, Clerk, Cognito): callback URL allowlist + CORS origins.
Most are 2-minute fixes. Skipped, they cost you a week of analytics + a broken checkout.

The launch-day runbook. If cutover happens at 10am Tuesday, you have until 5pm to find and fix anything visible to crawl. Print this category; tick it off live during cutover.

Critical DNS pointing correctly; HTTPS valid on new domain; no mixed-content warnings If DNS is wrong, nothing else matters. If HTTPS is broken, Chrome marks the site 'Not Secure' on day one and the launch press release lands on a warning page. Mixed-content warnings (HTTP assets loaded inside an HTTPS page) trip the same flag. All three are 5-minute checks; all three are catastrophic if missed.
How to do this
Within 5 minutes of cutover:
DNS: dig new-domain.com +short from at least 2 networks; also check global propagation via whatsmydns.net. All resolvers should return the intended IP/CDN endpoint.
HTTPS: curl -vI https://new-domain.com/ — first line HTTP/1.1 200 OK; certificate covers both apex + www; auto-renewal configured.
HTTP → HTTPS 301: curl -sI http://new-domain.com/ must return 301 with Location: https://....
Mixed content: open the new homepage in Chrome → DevTools → Security tab. Should be 'This page is secure (valid HTTPS).' Any 'Mixed content' warning = a hardcoded http:// URL in HTML/CSS/JS; fix it before press goes out.
Critical Spot-check 20 redirects from the map — each lands on a 200 with no chain The redirect map can have 10,000 rows verified in staging and still ship broken because the production CDN config differs from staging in one rewrite rule. Spot-check 20 real redirects in the first hour: 10 high-traffic, 5 random mid-tier, 5 edge cases (URL with query string, URL with fragment, URL with trailing slash difference). If any of the 20 are wrong, the full map probably has the same pattern of issues — escalate and pause.
How to do this
One-liner per URL:
curl -ILso /dev/null -w "%{http_code} %{redirect_url} %{url_effective}\n" https://old-domain.com/old-url
Expected output: 301 https://new-domain.com/new-url https://new-domain.com/new-url (the final URL has 200, not another 301).
What to check on each:
First line is 301 (or 308), NOT 302 or 200.
Final destination is 200, NOT 404 or another 301.
Chain length is 1 hop, not 2+.
Final URL is what your map said it should be.
If 1 of 20 is wrong: investigate, fix, move on. If 5+ of 20 are wrong: PAUSE the launch comms, escalate, your map has a systemic issue.
Critical Live-crawl the NEW domain and diff against the staging crawl — same titles, H1s, canonicals, no surprise 4xx/5xx Staging and production differ in subtle ways — different environment variables, different CDN config, different feature flags, different content version. A live crawl in the first hour catches the divergences before Google does. Diff against the staging crawl: same URL count, same titles, same H1s, same canonicals, no new 404s or 5xx errors.
How to do this
Within 30 minutes of cutover, run a crawl-vs-crawl diff. Sitebulb's Compare report is purpose-built for this and is faster than the manual CSV-diff approach; Screaming Frog requires two crawl exports + a side-by-side spreadsheet diff (Excel/Beyond Compare/Python).
Crawl the new live domain. Configure to crawl all URLs reachable from the homepage + sitemap.
Export to CSV: URL, status code, title, H1, canonical.
Diff against the staging crawl (same export from staging done 24h pre-cutover).
What the diff should show: zero differences in URL count, titles, H1s, canonicals. Status-code differences should be expected (e.g. URLs that legitimately moved). Any unexpected 404 / 5xx / title change / canonical mismatch is a launch-day bug.
Common surprises: feature-flagged content visible in staging but not prod; CDN auth-protecting paths intended to be public; localized URLs missing because the i18n config didn't deploy.
Critical GA4 receiving events from new domain + GSC ownership verified + sitemap submitted Breaking analytics on launch day means losing the first week of post-migration data — the most valuable window for spotting issues. GSC ownership not verified means you can't request URL inspection, can't see manual actions, can't submit the sitemap, can't file Change of Address. Both are 15-minute checks; both are catastrophic if missed.
How to do this
Within 1 hour of cutover:
GA4: open new domain with GA Debugger extension; navigate 3-5 pages; GA4 → Configure → DebugView should show events in seconds. If empty, the GA4 tag didn't deploy or your container is misconfigured.
GSC ownership: confirm the NEW GSC Domain property is verified (DNS TXT record live). If not, add it now — verification takes minutes after DNS propagates.
Sitemap submission: GSC → Sitemaps → Add the new sitemap URL. Confirm it's accepted (status = Success).
URL Inspection on the homepage: should return 'URL is on Google' within 24-48h; on day zero it may still say 'URL is not on Google' (normal — Google hasn't recrawled yet).
Nice File GSC Change of Address — if the move legitimately qualifies The COA tool is a 5-minute insurance signal. Google opens a 180-day window during which it forwards signals from old → new and explicitly favors the new property. The tool does NOT replace 301s — broken redirects break the move regardless — but the 180-day favoritism is a real, modest tailwind. Only works for true domain or top-level-subdomain changes; does not work for HTTPS / www-non-www / path changes. Disavow files do NOT auto-transfer via COA either — port them separately, see off-04.
How to do this
Qualifies for COA:
Domain change (acme.com → acme.ai)
Top-level subdomain change (acme.com → www.acme.com if not already same)
Domain → path-on-another-domain (acme.com → otherdomain.com/acme)
Does NOT qualify:
HTTP → HTTPS migration
www → non-www or vice versa (treated as same site)
URL path/structure change without hostname change
Same hostname, different server
If qualifies: in OLD GSC property (must be verified) → Settings → Change of Address → select the destination property (must be ALSO verified in same Google account) → submit. Google opens the 180-day window automatically.
Don't WAIT for COA validation to launch. Don't expect it to do anything if your 301s are broken. It's confetti on top of a clean redirect map.
Critical CDN cache purged on cutover; cache-key includes the host so prod and old don't poison each other If your CDN still has the OLD-domain build cached when DNS flips to point at the new origin, real users hit the stale OLD response for the cache lifetime (often hours). And if the cache-key doesn't include the host, requests for old-domain and new-domain URLs collide in the same cache entry — Googlebot pulls whichever version was cached last. Both failure modes are silent until rankings drop. Same pattern as our pre-launch checklist fou-06; on migrations the blast radius is bigger because the wrong-cached response is a completely different site.
How to do this
15 minutes BEFORE DNS cutover, on BOTH the new-domain CDN and (if same edge) the old-domain CDN:
Purge the cache for both hostnames. Cloudflare: Caching → Configuration → Purge Everything. Fastly: fastly purge --all. Vercel/Netlify: usually automatic on deploy, verify in dashboard.
Verify cache-key includes the host. Cloudflare: Caching → Cache Rules → confirm no rule strips host. Custom edge workers: request.url.host must participate in the cache-key hash.
After cutover: curl -I https://new-domain.com/ twice. Second response should be a fresh cf-cache-status: HIT on the NEW response, not on a stale OLD one. Verify last-modified/etag matches your NEW build.
For migrations that move BOTH origin AND CDN: also verify TLS cert renewal on new origin, edge config matches origin-host-header expectations, and no edge-level robots.txt drift between origins. See our pre-launch checklist for the full CDN-cutover pattern.

The off-site half of the migration. 301s carry signal automatically; outreach + entity work + AI-surface monitoring accelerate the catch-up. Joost de Valk: 'There is no Change of Address form for a model that finished training a year before your move.'

Critical Top 50-200 referring domains identified — outreach sent asking them to update the URL Mueller's specific migration recommendation: 'try to find larger websites linking to your previous domain and request they update those links.' Existing linkers already linked to you — getting them to update is the cheapest, highest-success link operation you'll ever run, and it eliminates the friction of the 301 hop. The top 50-200 referrers hold the bulk of your link equity; the long tail can stay on 301s.
How to do this
One week pre-cutover, build and qualify the outreach list with Ahrefs / Moz / Semrush:
Export top 200 referring domains by Domain Rating / Authority.
Qualify before pitching: keep only linkers whose page (a) is still indexed in Google, (b) has been modified in the last 24 months, (c) isn't a syndicated copy/scrape. Round-up and resource-page links convert 2-3× higher than the average — segment them and prioritise.
For each: find the author's CURRENT contact via LinkedIn + Hunter pattern-match. Fall back to the section editor. Never to a generic editorial@ inbox.
Draft a 4-sentence outreach template — name the linking page, the anchor, the new URL, and the reason for the reader: latency from the 301 hop, plus Safari/Brave referer-stripping that breaks the linking page's outbound analytics.
Send the week of cutover, after the new URL is live and indexable.
Realistic numbers: 25-40% reply rate on personal outreach to small/mid sites for migration-update specifically (the link already exists; ask is trivial). 5-15% reply rate on large publications; reply rate ≠ fix rate — on large pubs expect 2-5% actually-updated even with a 15% reply. Plan capacity accordingly.
Critical Brand entity records on Wikidata, Wikipedia, Crunchbase, LinkedIn updated to new domain These third-party entity records feed Google's Knowledge Graph and AI training data. Every reference to the OLD domain on a high-authority third-party profile is a signal that confuses LLMs and crawlers about which hostname is your real entity home. Update on cutover day — these are the levers that accelerate AI-surface catch-up over the next 6-12 months.
How to do this
Update on cutover day, in priority order:
Wikidata Q-item (if you have one) — update the official website property + add a redirected to or also known as claim for the old domain.
Wikipedia page (if you have one) — edit the infobox URL + add a sentence in the article body noting the move with citation.
Crunchbase — edit the company profile → Website field → new URL.
LinkedIn Company Page — Settings → Company website → new URL.
Social profiles — X/Twitter bio, Instagram bio, GitHub org, YouTube About: all point at new domain.
G2 / Capterra / Product Hunt / TrustPilot (SaaS-specific) — update the company URL on each.
Your Organization schema on the new domain's homepage should now point at all of these in sameAs — confirm the sameAs cluster matches reality.
Nice AI-surface baseline (from plan-06) re-checked at +30 and +90 days AI engines have memory of your old domain that 301s can't update. Their catch-up timeline depends on training-data refresh cycles (3-12 months) plus live-fetch behavior (immediate for ChatGPT-User / Claude-User / PerplexityBot, lagged for training). Without a dated baseline + re-checks, you can't tell whether the migration is being absorbed by AI surfaces or you've been replaced in their training data by a competitor who hasn't moved.
How to do this
Re-capture the AI-surface baseline (5-20 priority queries) at +30, +60, +90 days:
Same queries as captured in plan-06.
Same engines: ChatGPT with search enabled, Claude, Perplexity, Google AI Mode (enable at labs.google.com), Google AI Overview.
Same browser conditions: incognito, logged out, screenshot the response.
Track per-engine: does the response cite OLD domain, NEW domain, or competitor? Same query at each checkpoint.
Expected pattern at +30d: live-fetch engines (ChatGPT-User, Claude-User, Perplexity) start citing new domain within days if they were citing old. Training-based responses (ChatGPT default mode, Claude default mode without search) take 3-12 months to catch up.
If at +90d the AI surfaces still cite old domain heavily: your brand entity updates (off-02) didn't fully take. Re-audit Wikidata / Wikipedia / Crunchbase / LinkedIn.
Important Disavow file (if any) ported to NEW domain GSC property — does not auto-transfer via Change of Address Disavow files are property-specific in GSC. The Change of Address tool transfers many signals but the disavow file is not one of them. If your OLD domain had a disavow file submitted (e.g. cleaning up a prior aged-domain purchase or a negative-SEO incident), the NEW domain starts with no disavow until you re-submit it. Forgotten disavow = old penalty signals re-emerging.
How to do this
If your old GSC property had a disavow file:
Download the existing file: OLD GSC → Disavow tool → Download disavow file.
Re-upload the file as-is to the NEW GSC property: Disavow tool → Upload. (Disavow operates at the spamming domain's root — a spammy domain is spammy regardless of which of your hostnames it points at, so don't 'clean up' entries that linked to the old domain.)
If you don't have a disavow file from the old domain: skip this. Per Mueller, most sites don't need one — see our disavow file checklist for when one is warranted.
Don't disavow the OLD domain itself or any URL on it. The 301 is the consolidation signal; disavowing your old domain would be self-defeating.

The part most teams under-budget because the migration team rotates off after launch day. The +90-day post-mortem is the difference between learning from a botched migration and repeating it next time.

Critical Daily monitoring runbook for first 14 days — GSC, GA4, top 500 rankings, 4xx/5xx alerts Per the SEJ 892-domain study, the fastest recoveries (19-33 days) all share daily monitoring + same-day fixes in the first 14 days. The slowest (>1000 days, never recover) all share 'we'll check it in a month.' Catching a 5% indexation drop in week 1 and fixing the canonical bug takes a day; catching it in week 6 and untangling 6 weeks of cascading damage takes months.
How to do this
Daily checks, 14 days:
GSC Pages report: indexed count vs day-1 baseline. Acceptable: -10% in week 1, recovering by week 2. Alarm: -25%+ at any point.
GSC Crawl-errors: any new 4xx/5xx on previously-200 URLs → investigate same day.
GSC Manual Actions: should be 'No issues detected.' If anything appears: page founder immediately.
GA4: organic sessions vs day-1 baseline. Acceptable: -30% in week 1 (matches de Valk's 30-40% baseline).
Top 500 rankings: weekly delta against baseline. Watch for queries that lost more than median.
Alert threshold: 20%+ sustained traffic decline over 48h triggers a paging incident. Sudden spike in 404s triggers a redirect-map re-audit.
Important Weekly checks weeks 3-12 — referring domains, hreflang errors, Core Web Vitals on new domain Weeks 3-12 are when slower-moving issues surface: referring domains stop updating to the new URL (some sites rebuild and break the link), hreflang gets misconfigured on the new domain, Core Web Vitals data accumulates and reveals regression. Weekly cadence catches these without overwhelming the runbook.
How to do this
Weekly, weeks 3-12:
Referring domains: track new-domain referring-domain count (Ahrefs / Moz / Semrush). Should grow as outreach lands. If flat for 3+ weeks, outreach didn't take.
hreflang report (multilingual sites only): GSC → Search results → International Targeting (legacy) → hreflang. Any errors → fix immediately; hreflang misconfiguration is common after a CMS swap.
Core Web Vitals: GSC → Core Web Vitals → check 'Good URLs' count is growing. Field data starts populating ~28 days post-launch.
Old URLs in Google's index: site:old-domain.com — count should drop steadily as Google processes the 301s. Plateaus = redirects not being followed (investigate).
Image rankings: spot-check image-search rankings on Google Images for 5-10 priority images. Glenn Gabe's pattern: image rankings can collapse within 24h of bad image-URL migration; weekly check catches this.
Important Monthly checks months 4-12 — full re-crawl diffed against launch-day, orphan + drift detection Months 4-12 are when content drift accumulates: CMS auto-generates titles for pages where authors didn't override (per the B2B-migration example: 60% of pages ended up with auto-generated titles, organic CTR dropped 22%); orphan pages appear as the team adds content without internal links; templated metadata regresses. Monthly full re-crawl + diff catches this before it becomes baseline.
How to do this
Monthly, months 4-12:
Full new-domain crawl with Sitebulb (Compare report for built-in diff) or Screaming Frog (manual CSV diff). Export same columns as launch-day baseline.
Diff against the launch-day crawl: URL count change (new URLs added, old URLs orphaned); title / H1 / meta drift (CMS auto-generation regression — check after every CMS upgrade); canonical drift; new noindex appearances.
Orphan check: filter for URLs with 0 inbound internal links. Either internal-link them or remove (410).
301 chain check: any new redirect chains accumulating from internal team edits → compress.
Backlink-target check: top 100 referring pages from last month — confirm the linking page is still indexed and the link still resolves.
Important +90 day post-mortem scheduled BEFORE launch — calendared, not 'we'll do it eventually' Most migration teams disband after launch + 30 days. The +90 post-mortem (when full recovery picture is visible) is when the lessons-learned go into the internal runbook. Without a calendar invite and a doc owner, it doesn't happen — and the next migration repeats the same mistakes 3 years later.
How to do this
Pre-cutover, schedule:
Calendar invite for the +90-day post-mortem (with the migration DRI + dev lead + content lead + founder).
1-page template in a shared doc: what worked, what didn't, what surprised us, what we'd do differently next time.
Update the internal migration runbook with the lessons.
Specifically capture: redirect-map gaps (URLs we missed); indexability bugs (noindex / robots.txt / canonical issues we shipped); content-cull misses (junk that we should have removed pre-cutover); AI-surface catch-up rate per engine; recovery-time data point (vs the 523-day study baseline).
If you skip this: the next migration starts from the same blank slate. If you do it: every subsequent migration is faster + cleaner. The 30-minute post-mortem compounds across years.

Four things vendor blogs, agency proposals, and dev-team shortcuts still sell as migration best practice that do not survive scrutiny against 2025-2026 evidence. If you've planned around any of these, you're not behind — you're early enough to fix the plan.

Nice Don't treat the GSC Change of Address tool as a substitute for 301 redirects Google's own documentation: COA is a complementary signal, not a replacement. It cannot be used for HTTPS migrations, www/non-www changes, or path changes. The 180-day signal-transfer window only opens if your 301s are also correct. Filing COA without proper 301s is filing paperwork on a broken move; the COA does nothing on its own.
How to do this
What COA does: opens a 180-day window during which Google forwards signals from old → new property and explicitly favors the new one in ranking decisions.
What COA does NOT do:
Replace 301 redirects (signal transfer requires the actual HTTP redirect).
Work for HTTPS migrations (it's a same-property change in Google's eyes).
Work for www/non-www changes.
Work for URL path changes within the same domain.
Work indefinitely (180 days, then no special handling).
Per Topify guide: 'a common misconception is that either redirects or the Change of Address Tool alone are sufficient. In reality, they serve different but complementary roles.' File it where applicable; treat it as confetti, not the cake.
Critical Don't bundle CMS swap + domain change + redesign + content overhaul in one release Even Joost de Valk — strongest public voice arguing that bundling can work when executed perfectly — caveats that 'most teams fail this approach.' Shopify's 2026 checklist Step 3 is literally 'Isolate the migration strategy. Avoid multiple simultaneous changes.' Mueller and Illyes both recommend separating concerns. The reason: when traffic drops in week 2 you have no attribution — was it the CMS swap, the URL change, the redesign, or the content overhaul? You cannot recover what you can't diagnose.
How to do this
For high-stakes sites, change ONE dimension at a time across separate releases:
Release 1: CMS swap, same domain, same URLs, same content, same design.
Release 2 (4-6 weeks later, after rankings stabilize): URL structure change, with 1:1 redirects.
Release 3: content overhaul / redesign.
Release 4: domain change (the actual hostname move).
For low-stakes / pre-PMF sites: bundle if you must, but document the decision and plan for an attribution-nightmare risk in your monitoring runbook.
The Guardian's multi-CMS consolidation is the exception that proves the rule — large org, dedicated team, multi-year prep. For everyone else: don't bundle.
Important Don't believe '301 redirects lose 15% of PageRank' — it's a 2013 myth Google has corrected since 2016 Gary Illyes has confirmed multiple times since 2016 that 30x redirects pass full PageRank. The '15% loss' number came from a 2013 Matt Cutts comment and a 2016 Moz case study that Google's current guidance has actively superseded. This zombie myth still shows up in dev-team conversations and 'fast migration' guides recommending skipping low-traffic redirects 'to save server load.' If the page had any link equity or traffic in the last 12 months, it gets a 301.
How to do this
The truth: 301 and 308 redirects pass full PageRank signal. No 'tax' applies. The friction of redirects (extra latency, occasional crawl-budget cost) does have a small real-world effect; PageRank loss does not.
Use this to push back on devs who want to skip redirects to 'save config bloat':
Every URL with non-zero traffic in the last 12 months → 301.
Every URL with non-zero referring domains → 301.
Every URL with non-zero impressions in GSC (last 90 days) → 301.
Orphan URLs (zero traffic + zero referrers + zero impressions for 12 months) → can return 410 Gone instead of 301.
Source: Search Engine Land, Illyes's clearest statement: 'There is no PageRank dilution when using 301, 302, or 30x redirects anymore.'

About the Author

Andrei

SEO and digital marketing professional with 13+ years of experience. Started as a website administrator in 2011, transitioned to SEO, and achieved top-3 rankings for competitive keywords. Co-founded a consulting firm specializing in marketing audits for companies in Ukraine and internationally. Built LinkGuard to solve the problem he experienced firsthand: most SEO teams purchase links but never monitor their survival. Based in Kyiv, Ukraine.

Site migration SEO checklist: 37 items for surviving a 2026 domain move

Andrei