Site Migration SEO: The Complete Checklist for 2026

A site migration is any significant change to a website's URL structure, domain, protocol, CMS, or hosting that requires redirects and risks disrupting search engine indexing. Done poorly, a migration can eliminate years of accumulated search ranking in days. Done correctly, it preserves or improves rankings while modernising the site.

This is the complete site migration SEO checklist.

What counts as a site migration (SEO-wise)?

Any of the following triggers migration-level SEO work:

• Domain change — moving from old-domain.com to new-domain.com
• Protocol migration — moving from HTTP to HTTPS (if not already done)
• Subdomain changes — moving from www.example.com to example.com or vice versa
• URL restructuring — changing path patterns (e.g., /blog/post-title → /articles/post-title)
• CMS migration — moving from WordPress to Webflow, Shopify to Magento, etc. — often changes URL patterns
• Domain consolidation — merging multiple sites into one (blog.example.com and example.com merged)
• HTTP to HTTPS migration — still common for older sites; straightforward but requires redirect verification

The SEO risk in all cases is the same: indexed URLs that change without correct 301 redirects lose their link equity, rankings, and organic traffic, potentially permanently.

Phase 1: Pre-migration audit (before touching anything)

Crawl the current site. Use the DeepSEOAnalysis audit or a dedicated crawler to document: all current URLs, their HTTP status codes, canonical tags, internal links, meta titles/descriptions, and structured data. This is the baseline you'll compare against post-migration.

Export GSC data. In Google Search Console, export:

• Performance report: all queries with impressions > 0 (90-day date range)
• URL coverage report: all indexed URLs
• Internal Links report: most-linked internal pages
• Core Web Vitals: baseline CWV scores per page group

This data becomes the comparison baseline for verifying no traffic was lost post-migration.

Build the URL redirect map. For every URL on the current site, map it to its new URL on the migrated site. This is the most labour-intensive part of a migration. For pattern-based URL changes (all /blog/ → /articles/), a rule-based redirect handles the bulk. For non-pattern changes (individual pages with different slugs), individual 301s are needed.

Priority tiers for the redirect map:

1. Top-traffic pages (top 20% by clicks from GSC)
2. Top-linked pages (top 20% by inbound links)
3. Top-converting pages (check analytics)
4. All other crawled pages

At minimum, all pages in tiers 1–3 must have explicit 301 redirects. Tier 4 can use pattern-based redirects.

Preserve canonical tags. The canonical tag on each new URL should self-reference (point to the new URL), not to the old URL. Update canonical tags as part of the migration, not afterwards.

Phase 2: Migration execution

Implement 301 redirects, not 302s. A 301 (permanent redirect) transfers link equity from the old URL to the new URL. A 302 (temporary redirect) does not transfer link equity — Google keeps the old URL indexed. All migration redirects must be 301s.

Avoid redirect chains. If the old site already has some redirects (A → B), and the migration creates B → C, the result is a chain (A → B → C). Googlebot follows redirect chains but link equity is diluted at each hop. Flatten chains to direct A → C redirects where possible.

HTTPS migration specifics:

• HTTP → HTTPS redirect at the server level (nginx/Apache), not just in the CMS
• All internal links must update to HTTPS — HTTP links that redirect to HTTPS still work but are inefficient
• Update canonical tags to HTTPS URLs
• Update the XML sitemap to HTTPS URLs
• Submit the HTTPS property in GSC (separate property from HTTP)

Update the XML sitemap. The sitemap should contain new URLs only — not the old URLs that now redirect. Remove old URLs and ensure the lastmod values are current. Submit the new sitemap in GSC immediately after migration.

Update robots.txt. The new domain's robots.txt should allow crawling of all new URLs. If any paths changed, update Disallow rules accordingly.

Internal links. Update all internal links on the new site to point directly to the new URLs, not via redirects. A site where all internal navigation goes through 301 redirects is technically correct but sub-optimal — Googlebot follows redirects, but direct internal links are faster and more efficient.

Structured data. Update all URLs in JSON-LD blocks (particularly "url", "@id", and canonical-related fields) to the new URLs.

Phase 3: Post-migration verification

Crawl the new site immediately. Within 24 hours of launch: crawl the new site to verify that all expected URLs are reachable (200 status), all redirect destinations are correct (301s go to the right new URLs), canonical tags on new pages self-reference, and no pages are accidentally noindex.

Verify redirects. Spot-check every tier-1 and tier-2 URL: the old URL should return HTTP 301, and following the redirect should land on the correct new URL with a 200 status.

Submit to GSC. If the domain changed, add the new domain as a GSC property and submit the new sitemap. Use the Change of Address tool (GSC → Settings → Change of Address) to inform Google of a domain migration — this accelerates the transition from old to new domain in the index.

Monitor for traffic drops. Compare weekly traffic (same day/week year-on-year if seasonal) in the first 4 weeks post-migration. A drop in the first week is expected and normal as Google re-crawls and re-indexes. A sustained drop after 3–4 weeks indicates a migration issue.

Check for index coverage errors. In GSC Coverage report: "Submitted URL not found (404)" errors on URLs from the old sitemap indicate missing redirects. "Redirect error" indicates broken redirect chains or invalid 301 configurations.

Common migration mistakes

Implementing 302 instead of 301 redirects. Google doesn't transfer link equity through 302s — the old URL stays indexed indefinitely and the new URL doesn't benefit from the old page's link authority.

Forgetting to update the sitemap. A sitemap still containing old URLs causes GSC to report them as 404s after the migration.

Canonicals still pointing to old domain. New pages with <link rel="canonical" href="https://old-domain.com/page/"> tell Google the old URL is authoritative — self-defeating after a domain migration.

Launching without monitoring. The post-migration monitoring window (first 4 weeks) is when most migration problems surface. Set up GSC alerts and compare weekly organic traffic before leaving this phase.

Run the DeepSEOAnalysis free audit pre-migration for a baseline and post-migration to verify redirects, canonicals, sitemap integrity, and Core Web Vitals are all correct on the new site.

---

Frequently asked questions

How long does SEO recovery take after a site migration?

For a well-executed migration with correct 301 redirects, sitemap submission, and GSC Change of Address (for domain migrations): most of the rankings recover within 4–8 weeks as Google re-crawls and re-indexes the new URLs. For simpler migrations (URL restructuring on the same domain), recovery is typically faster — 2–4 weeks. Poorly executed migrations (missing redirects, wrong canonical tags) can take 3–6 months to recover from, and some link equity may be permanently lost.

Should I use a soft launch or hard launch for a migration?

For most migrations, a hard launch (all URLs going live simultaneously with all redirects in place) is preferable to a gradual/staged rollout. A staged migration where old and new URLs coexist for a period creates duplicate content problems and complicates the redirect map. The exception: very large sites (100,000+ pages) where QA-ing all redirects before launch is impractical — a staged migration by content section is sometimes necessary, with each section completing a full old-to-new transition before the next section is migrated.

Do 301 redirects lose any PageRank?

Historically, Google suggested that 301 redirects lose a small amount of PageRank (John Mueller's 2016 clarification suggested the loss is minimal and comparable to any internal link). For practical purposes: the loss from a single-hop 301 redirect is negligible. The loss from a redirect chain (A → B → C) is more significant. The greatest risk is missing 301 redirects entirely — pages that return 404 without a redirect lose all their accumulated link equity permanently.

What is the difference between a site migration and a redesign?

A redesign that doesn't change URLs is not a migration from an SEO perspective — URLs, canonicals, and redirects remain unchanged. A migration involves changing URLs (even on the same domain). The SEO risk is the URL change, not the visual redesign. Many redesigns that change the URL structure are inadvertent migrations — the team changes the CMS or path patterns without realising the SEO implications. Always check whether a redesign changes any existing URLs before assuming it's SEO-safe.