Website Migration SEO Checklist: How to Relaunch Without Losing Your Rankings

Why Website Migrations Are High-Risk SEO Events

A website migration — whether a domain change, platform switch, HTTPS upgrade, URL restructure, or visual redesign — is one of the highest-risk events in the SEO calendar. Done correctly, a migration is transparent to search engines: rankings hold, traffic continues, and the new implementation benefits from all the authority accumulated by the previous site. Done incorrectly, a migration can erase years of SEO equity within days and take months to fully recover from.

The most dangerous migrations are the ones that appear to succeed in the first week. Rankings hold for several weeks because Google has cached the old pages and the redirects have not yet been fully evaluated. Then, as Googlebot recrawls at scale and processes the new URL structure, the problems surface — often in a single weekend of ranking drops that can be traced back to implementation decisions made during the migration.

This 40-point checklist covers every phase: pre-launch technical preparation, launch-day execution, and the post-launch monitoring that catches problems before they compound.

Pre-Launch: Technical Preparation (Weeks Before)

1. Crawl the existing site with Screaming Frog or Sitebulb to generate a complete list of all indexed URLs, their current meta data, canonical tags, internal links, and inbound link targets. This is your baseline inventory.

2. Export current rankings for all keywords via Ahrefs or SEMrush and download current Search Console performance data. You need before-migration benchmarks to evaluate post-migration performance accurately.

3. Build a URL mapping document mapping every old URL to its new equivalent. If the URL structure is not changing, document this explicitly. If it is changing, every old URL must have a 1:1 destination mapping — not just a redirect to the homepage or a category page.

4. Identify your top-value URLs — those with the most backlinks, highest traffic, and best rankings. These need extra scrutiny in the migration plan. A single broken redirect on your highest-link-equity page can cost weeks of recovery time.

5. Test redirect implementation on a staging environment before touching production. Verify that every old URL returns a 301 (not 302, not 200, not 404) to the correct destination. Test redirect chains — old URL A should redirect directly to new URL C, not through a chain of intermediate redirects.

6. Prepare updated XML sitemaps with new URLs and trailing slashes consistent with the new URL structure. Do not submit the old sitemap after the migration.

7. Update canonical tags on the new site to point to the new URLs. A canonical tag pointing to an old URL after migration tells Google the old URL is still the authoritative version.

8. Verify hreflang implementation if the site serves multiple languages or regions. Hreflang tags must reference the new URLs after migration.

Pre-Launch: Content and On-Page Preparation

9. Carry over all existing meta titles and descriptions to the new URL structure. Do not use migration as an opportunity to change title tags at scale — this introduces two variables simultaneously and makes diagnosing post-migration issues much harder.

10. Verify internal links update to new URLs and do not point to old URLs that will become redirects. Internal links through redirects add crawl overhead and reduce crawl efficiency.

11. Check that all noindex tags are intentional and that the new site does not noindex pages that should be indexed. A CMS migration often resets noindex settings to their platform defaults.

12. Update Google Business Profile and other local directory listings if the domain is changing. GBP website field, schema markup URLs, and any citations containing your domain need updating.

Launch Day

13. Verify redirects are live by spot-checking 20–30 URLs from your top-value list immediately after launch. Confirm 301 status codes, confirm destination URLs, confirm no redirect chains.

14. Submit new XML sitemap to Google Search Console immediately after launch. Remove old sitemaps if the domain or URL structure changed.

15. Verify robots.txt is not blocking new URLs — a common migration error where staging-environment robots.txt (which typically disallows all crawling) is deployed to production.

16. Request indexing for your top 20 URLs through the URL Inspection tool in Search Console. This accelerates recrawling of your highest-priority pages.

17. Monitor Search Console for crawl errors in real time for the first 48 hours. Any 404s or redirect errors on important URLs need same-day resolution.

18. Monitor Core Web Vitals scores on the new implementation — a platform change can introduce performance regressions that immediately affect rankings.

Post-Launch: Monitoring and Recovery

19–25: Week 1 monitoring: Check Search Console daily for new crawl errors; monitor ranking changes for top 50 commercial terms; check organic traffic in GA4 compared to pre-migration baseline (adjusted for day-of-week effects); verify index coverage is not declining; confirm redirected URLs are being discovered and processed; check that the new sitemap is being crawled; verify that Google is indexing new URLs (not just caching old ones through redirects).

26–32: Week 2–4 monitoring: Assess whether referring domains are pointing to old URLs (update outreach to notify major link sources of new URLs); check for soft 404s in Search Console; confirm organic traffic recovery trend; verify that old URLs are being removed from index and replaced by new URLs; assess any ranking anomalies against specific URL redirects in the mapping document.

33–40: Month 2–3 monitoring: Full traffic recovery assessment against baseline; referring domain update status; final redirect chain audit to remove any that accumulated during migration; assessment of Core Web Vitals on new platform; schema markup validation on new URLs; final canonical tag audit across the new site structure.

For technical SEO support on upcoming migrations, see our technical SEO service.