Site Migration SEO Checklist for 2026: Domain and Replatform

A safe SEO migration comes down to five things: a saved baseline, a one-to-one redirect map, a tested staging site, a controlled launch day and 90 days of monitoring. Google's own documentation says to change only one thing at a time, keep redirects for at least a year and submit Change of Address for every verified variant of the old domain. This checklist, current as of 14 October 2026, turns that into a runbook you can paste into a project plan.

Key Takeaways

• Take a baseline before touching anything: Search Console, analytics, a full crawl and a redirect map.
• Map every old URL to its closest new equivalent. Do not redirect everything to the homepage.
• Use server-side 301 or 308 redirects, avoid chains, and keep them for at least a year (Google's guidance).
• Remove staging blocks on launch day, and name a person responsible for checking robots.txt and noindex.
• Hosting-only moves and URL-changing moves follow different Google guides; know which you are doing.
• Expect a temporary wobble, but set escalation triggers in advance rather than guessing at "normal".
• If the old domain lingers afterwards, use the diagnostic guide.

First, name your migration type

Google separates site moves with URL changes (domain, HTTPS, path changes) from site moves without URL changes (hosting, CDN). They need different checklists.

Google's guidance says the Change of Address tool is only for domain or subdomain changes, not HTTPS moves, www to non-www on the same domain, or path moves. Move small and medium sites all at once; larger sites can move in sections, and avoid combining domain, CMS and layout changes.

Phase 1: Baseline (2-4 weeks before)

Trade checklists agree on the core of this. FocusReactive suggests 12 months of Search Console and analytics data, and Centric DXB about 16 months of Search Console data plus dated ranking and backlink snapshots. I use the longer window for seasonal sites.

• [ ] Export Search Console performance by page and query (12-16 months).
• [ ] Export analytics organic sessions and conversions by section.
• [ ] Crawl the full live site: URL, status, title, H1, canonical, hreflang, schema.
• [ ] Identify the top 50 pages by traffic and the top 50 by referring domains.
• [ ] Snapshot Core Web Vitals for key templates.
• [ ] Record legacy parameters and filtered URLs.
• [ ] Save robots.txt, sitemaps and the current redirect rules.
• [ ] Note Bing Webmaster Tools data if you use it.

Phase 2: Redirect map (the part people rush)

Every old URL needs a destination or a retirement decision. Google says to map each old URL to its new counterpart and use server-side permanent redirects; its redirect documentation treats 301 and 308 as permanent and 302, 303 and 307 as temporary, and says JavaScript redirects may never be seen if rendering fails. Avoid chains (ideally no more than three hops, fewer than five at most) and not send many old URLs to one unrelated page.

A redirect-map template

The columns are mine; use whatever your team will actually maintain. The key is that "Tested?" is checked against real staging URLs, not just the spreadsheet.

A redirect map is a living document; test it on real URLs, not only the sheet.

Phase 3: Staging and pre-launch checks

• [ ] Block crawling and indexing of staging, and write down how that is reversed. Google notes robots.txt is not a mechanism for keeping a page out of Google, so use noindex or password protection for staging.
• [ ] Confirm canonicals on staging point to the final production domain, not the staging host. Google's canonicalization documentation calls a canonical tag a hint, not a rule, so keep redirects, sitemaps and internal links consistent with it.
• [ ] Test 100% of top-50 redirects and a sample of the rest.
• [ ] Check titles, descriptions, H1s and schema match baseline in the rendered HTML.
• [ ] Validate structured data per template.
• [ ] Confirm hreflang pairs are reciprocal if you run multiple languages.
• [ ] Verify XML sitemap lists only final, canonical, 200-status URLs.
• [ ] Render key pages without JavaScript to see what non-rendering crawlers get. FocusReactive claims major AI crawlers do not render client-side JavaScript; it does not attribute the testing, so treat it as a claim and run your own test.
• [ ] Verify analytics and tag manager events on staging.
• [ ] For hosting moves, lower DNS TTL to a conservative value a week ahead, as Google's no-URL-change guide advises.

Phase 4: Launch-day runbook

Assign a named person to each item.

1. Remove staging noindex tags and robots.txt blocks. Verify robots.txt allows crawling.
2. Switch redirects or DNS.
3. Spot-check 30 URLs across templates for status code, final URL and canonical.
4. Submit the new sitemap in Search Console. For domain changes, keep old sitemaps temporarily (per Centric DXB).
5. Submit Change of Address for every verified variant of the old domain (domain moves only). Per Google's Change of Address help page, you must own both domain-level properties, the effects last 180 days, and you should keep redirects at least that long and consider keeping the old domain registered for a year.
6. Check that analytics records organic sessions.
7. Check that the server is not blocking Googlebot through firewall or DoS protection, as Google's hosting guide warns.
8. Run a full crawl of the live site and compare it with the baseline.
9. Note the exact launch time in your change log.

Phase 5: Monitor for 90 days

Google says a move is complete only after Googlebot has visited every old and new URL at least once, and small to medium sites may take a few weeks or more. Its hosting guide says to expect a temporary dip in crawl rate after launch.

I deliberately do not quote a "normal dip" percentage. The trade guides I read disagree with each other (and sometimes within a single page), and none are Google's. Define your own tolerance with stakeholders before launch and write it down.

For Googlebot behaviour, use log file analysis to confirm that it requests new URLs and follows redirects.

Launch day works best when every item has a named owner and a verification step.

Common mistakes and why they hurt

• No redirect map, or everything to the homepage. Centric DXB notes this passes almost no value and gets treated as a soft 404; Google's guidance also warns against it.
• 302 for a permanent move. Use 301 or 308 where possible.
• Staging blocks left on. The most preventable disaster.
• Changing everything at once. Domain, CMS, URLs and design in one release makes diagnosis nearly impossible.
• Cutting content that earns links. Review pages with backlinks before retiring them.
• Ignoring non-Google systems. Bing Webmaster Tools and AI crawlers see your changes too.
• Treating launch as the finish line. The work is the 90 days after.

When to refresh rather than migrate

Not every pain point needs a new platform. A content refresh or audit may fix more with less risk. If you must migrate, treat it as a project with owners, dates and rollback criteria.

Rollback criteria

Agree before launch what would trigger a rollback: widespread 5xx errors, a robots or noindex mistake you cannot fix within hours, or a redirect failure on top pages. Keep the old environment available until server logs show no more traffic to the old host, as Google's hosting guide advises.

FAQ

How long should I keep 301 redirects after a migration?

Google's site move documentation says to keep redirects for as long as possible, generally at least one year, and to consider keeping them indefinitely from a user's perspective.

Do I need the Change of Address tool for a replatform?

Not if the domain stays the same. Google says to use it only for domain or subdomain changes, not for HTTPS moves, www and non-www changes on the same domain, or path moves within a domain.

Should I migrate domain, CMS and design at the same time?

Avoid it. Google recommends changing one thing at a time, such as domain, CMS or layout, because combined changes make problems hard to diagnose.

How long does it take Google to process a move?

Google says small and medium sites may take a few weeks or more for most pages, larger sites longer, and a move is complete only after Googlebot has visited every old and new URL. Some cases take far longer, as discussed in my diagnostic guide.

What is the most common launch-day failure?

Leaving staging noindex tags or robots.txt blocks live, according to Centric DXB, which lists it among its main pitfalls. Assign a named person to verify it on launch day.

Should I redirect old URLs to the homepage?

No. Google advises against sending many old URLs to one unrelated page. Map each URL to its closest equivalent, and use 404 or 410 for pages that have no equivalent.

What should I benchmark before migrating?

Search Console performance by page and query, analytics organic sessions and conversions, a full crawl with titles, canonicals and schema, backlinks and Core Web Vitals for key templates. Save dated copies.

How do I check AI crawlers can see my new site?

Render key pages with JavaScript disabled and inspect the raw HTML. Server-side rendering for important content is a safe default, but verify with your own tests rather than relying on unattributed claims.

Should I submit sitemaps for the old and new domain?

Yes, submit the new sitemap and, for domain moves, consider keeping old sitemaps temporarily. Google may not read them promptly, so redirects and internal links matter more.

What if traffic falls after migration?

Compare against your baseline, check redirects, canonicals, sitemaps and indexing, and escalate if the trend keeps falling past your agreed trigger. See my diagnostic guide for the step-by-step order.

Work with me

I'm Younus Fardeen, an organic growth and AEO marketer with 4+ years of marketing experience across edtech and startups. If you are planning a migration or want a second pair of eyes on a redirect map, see my work and reach me through the contact form at https://younusfardeen.in.