Website Migration SEO Checklist | ShazzSEO

Of all the things that can happen to a website, a migration is the one most likely to torch years of accumulated SEO equity in a single afternoon. Domain changes, CMS platform switches, HTTP to HTTPS moves, URL restructuring, and full redesigns all carry real risk because they force Google to re-evaluate signals (links, content relevance, crawl paths, and canonical relationships) that took months or years to build. A migration doesn’t create new authority; at best it preserves what already exists. Every technical mistake made during the process is a direct subtraction from that balance.

I’ve run migrations that lost under 5% of organic traffic and recovered within three weeks, and I’ve inherited cleanup jobs where a botched replatform wiped out 60% of organic sessions for six months because nobody built a redirect map before flipping the switch. The difference is never luck. It’s whether the team treated the migration as an SEO project with a development component, or a development project with SEO as an afterthought. This checklist walks through the process in the order it should actually happen, from pre-launch planning through post-launch monitoring, with the specific technical details that determine whether you keep your rankings or spend the next two quarters rebuilding them.

Types of Migrations and Their Relative Risk Levels

Not all migrations carry the same risk, and knowing where yours sits on the spectrum tells you how much time to budget and how paranoid to be about the redirect map.

• HTTP to HTTPS only (URLs otherwise unchanged) – Lowest risk. This is mostly a 301 redirect exercise plus updating internal links and canonical tags to the HTTPS versions. Traffic dips are usually minor and short-lived if executed cleanly.
• CMS or platform migration (e.g., WordPress to a headless setup, Magento to Shopify) with URLs kept identical – Moderate risk. The URLs don’t change, but templates, meta tag generation, internal linking modules, and structured data markup often do, and those get broken in the rebuild far more often than teams expect.
• Site redesign with URL restructuring – High risk. You’re changing both the front-end presentation and the URL paths, which means every internal link, every piece of content hierarchy, and every redirect target has to be rebuilt from scratch.
• Domain migration (moving to a new domain name, with or without a redesign) – Highest risk. You are asking Google to transfer link equity and trust signals from one root domain to another entirely, which is the single hardest signal to transfer cleanly, especially when combined with a redesign or CMS change at the same time.
• Consolidating multiple domains into one, or splitting one domain into several – Highest risk and hardest to plan, because redirect mapping isn’t 1:1 and you’re often merging or fragmenting topical authority that Google has to re-evaluate from scratch.

The mistake I see most often is bundling several of these into one launch: new domain, new CMS, and a full redesign, all going live the same day. Each variable you change simultaneously makes it harder to diagnose what caused a specific ranking or traffic drop afterward. Where the business allows it, stage the changes: move to HTTPS first, then migrate platforms with URLs unchanged, then restructure URLs, then change domains. Where you can’t stage it, at minimum document every variable that’s changing so your post-launch monitoring can isolate the cause of any anomaly.

Pre-Migration Planning: Crawl, Inventory, and Benchmark Everything

The single biggest predictor of a clean migration is how thorough the pre-launch audit was. You cannot protect what you haven’t measured.

Full site crawl and inventory

Run a full crawl of the live site with Screaming Frog, Sitebulb, or a comparable crawler: not just the pages in your CMS export, but everything a crawler can actually reach, including orphaned pages that only exist because of an old campaign link or a forgotten category. Cross-reference that crawl against:

• Google Search Console’s indexed URL list (Coverage/Pages report), since some indexed URLs won’t surface in a crawl if internal linking to them has already degraded
• Server log files, to find URLs Googlebot is actively crawling that aren’t in either the site crawl or GSC
• Your analytics platform, to identify which URLs actually receive organic sessions, these are non-negotiable priorities for the redirect map

Combine these into a single master URL list. On a site of any real size this routinely turns up 10-20% more URLs than the CMS admin panel shows, and those extra URLs are exactly the ones that get missed and turn into 404s after launch.

Benchmark before you touch anything

Take a full snapshot of current performance before development starts, not the week of launch. At minimum, record:

• Organic traffic by landing page (90 days minimum, ideally a full year for seasonality) from GA4
• Keyword rankings for your priority terms, tracked at the URL level, not just the domain level
• Full backlink export from Ahrefs, Semrush, or Majestic, sorted by the specific URL each link points to, this is what your redirect map has to preserve
• Current Core Web Vitals (LCP, INP, CLS) and page speed scores, so you can prove whether the new site actually improved or regressed technical performance
• Current indexed page count and crawl stats from Search Console

Without this baseline, you have no way to prove to a client or stakeholder whether a post-launch dip is normal fluctuation or a genuine problem, and no way to know which specific pages to prioritize fixing first.

Building a URL Redirect Map That Actually Holds Up

The redirect map is the single highest-leverage document in the entire migration. Missing or incorrect redirects are the most common cause of post-migration traffic loss, full stop.

• Map every old URL to its single closest topical equivalent on the new site, never default to redirecting everything to the homepage. A homepage catch-all for pages Google can’t match to relevant new content is treated as a soft 404 signal over time and forfeits the equity those pages built.
• Use 301s for permanent moves. Reserve 302s only for genuinely temporary situations (like an A/B test), because search engines are slower to pass full ranking signal through a redirect they interpret as temporary.
• Eliminate redirect chains. Old URL A should never redirect to old URL B which then redirects to new URL C. Every hop dilutes signal, slows crawling, and increases the odds Googlebot gives up before reaching the final destination. Point every entry in the map directly at its final URL.
• Watch for redirect loops introduced by trailing-slash inconsistencies, case sensitivity, or www/non-www mismatches, these are common when the redirect rules are written by hand instead of generated from the mapping spreadsheet.
• Prioritize by traffic and backlinks, not by gut feel. Every URL with organic sessions in the last 12 months, every URL with an external backlink, and every URL currently ranking on page 1 or 2 must have a mapped, tested redirect before launch.

Test the map in staging using a crawler pointed at the old URL list, confirming each one resolves in a single hop to a 200-status new URL. Keep the finished map as a live spreadsheet with columns for old URL, new URL, redirect type, priority tier, and a status column you update as each one is verified post-launch. That document becomes your recovery tool if anything goes wrong.

Preserving On-Page Elements During a Redesign

Redesigns are where good redirect work gets undone by a well-meaning content or design team who decides the new site needs “fresher” copy everywhere. Unless a page’s rankings were already poor, resist rewriting on-page elements wholesale during the same launch as a structural migration.

• Title tags and meta descriptions: carry these over verbatim from the old site unless a page is being deliberately re-optimized as a separate, tracked project. Changing titles at the same moment you’re changing URLs and templates removes your ability to isolate which change caused a ranking shift.
• Heading structure (H1/H2/H3): keep the existing heading hierarchy and the primary keyword phrasing within it. Redesigns frequently flatten headings into styled `div`s for visual reasons, which strips the semantic structure crawlers use to understand page topic and sections.
• Body content: migrate the existing copy as-is first, then iterate afterward. A redesign that also cuts word count, removes FAQ sections, or drops supporting content “for a cleaner look” is quietly removing the relevance signals that earned rankings in the first place.
• Internal linking structure: map the old internal link graph and rebuild it in the new site, don’t let a new nav or footer accidentally drop links to deep category or product pages that previously received the bulk of their crawl equity through internal links rather than external backlinks.
• Structured data: if the old site had schema markup (Article, Product, FAQ, Breadcrumb), verify the new templates output the same markup. This is one of the most commonly dropped elements in CMS migrations because schema is often hard-coded into old templates and never gets ported.

Technical Checklist for Launch Day

These are the items that, if missed, cause the most damage in the first 48 hours, often before you’ve even noticed anything is wrong.

• Deindex the staging environment. Before launch, confirm the staging/dev site was blocked via robots.txt disallow and a noindex meta tag, and that neither of those rules accidentally shipped to production. A noindex tag left over from staging is the single most common cause of a site vanishing from search results overnight after a migration.
• Robots.txt on production should allow crawling of all sections you want indexed and explicitly block any admin, search, or filtered-parameter paths you don’t. Diff the new robots.txt against the old one line by line, don’t assume it carried over correctly.
• XML sitemap should be regenerated to reflect the new URL structure only, submitted fresh in Search Console, and referenced correctly in robots.txt. Don’t leave the old sitemap live alongside the new one.
• Canonical tags on every template should self-reference the new, correct URL. A common bug after a CMS migration is canonical tags still pointing at the old domain or old URL pattern because a config value wasn’t updated.
• Hreflang tags, if you run international or multi-language versions, need to be re-verified for every locale, hreflang errors compound fast during a migration because a single wrong reference can break the return-tag relationship across an entire language cluster.
• SSL certificate should be valid on the new domain or subdomain with no mixed-content warnings, and HTTP URLs should 301 to HTTPS at the server level, not via a meta refresh or JavaScript redirect.
• 301 redirects from the finished redirect map should be implemented at the server or CDN level (not via plugin-based client-side redirects where avoidable), tested in staging, and spot-checked live within minutes of DNS propagating.

Google Search Console: Change of Address and Property Setup

If you’re moving to a new domain, verify the new domain as a property in Search Console before launch, then use the Change of Address tool under Settings once the redirects are live and confirmed working. This tells Google to prioritize crawling the new domain, transfer relevant signals, and prefer the new URLs as canonical going forward, with Google continuing to honor this signal for roughly 180 days.

A detail people miss: you need to submit a change of address request for every verified variant of the old domain (www and non-www, HTTP and HTTPS, and any subdomains that were separately verified) not just the primary property. Each variant needs to point at the correct corresponding new property. If you’re only changing URL structure or platform on the same domain (no domain change), you don’t use this tool at all; instead resubmit the new XML sitemap and monitor the URL Inspection tool to confirm Google is picking up the new URLs and dropping the old ones from the index over time.

Keep the old domain’s hosting, DNS, and redirects active for at least 180 days post-migration, longer if log files or GSC still show meaningful crawl activity or referral traffic hitting old URLs. Killing the old domain early is one of the fastest ways to convert a recoverable migration into a permanent loss.

Post-Migration Monitoring: What to Watch and When

The work isn’t done at launch: it shifts into daily monitoring for the first two to three weeks, then weekly for the following two months.

• Crawl errors: check the Search Console Pages report and Crawl Stats report daily for the first week. A spike in 404s or server errors almost always traces back to a gap in the redirect map.
• Index coverage: watch how quickly new URLs move from “Discovered” to “Indexed,” and track how quickly old URLs drop out of the index as “Page with redirect.” A large, growing bucket of old URLs stuck as “Crawled, not indexed” or excluded for other reasons often indicates thin or duplicate content on the new templates.
• Rankings and traffic: compare weekly, not daily, daily search data is noisy enough that a single bad day means nothing. Segment by landing page so you can see whether the drop is broad (a technical issue) or concentrated in a specific template or section (a content or internal-linking issue).
• Log file analysis: pull raw server logs and filter for Googlebot user agents to see exactly which URLs it’s requesting, how often, and what status codes it’s receiving. This is the most reliable way to catch a crawler stuck on old URLs or hitting redirect chains that your crawler-based tests didn’t surface.
• Backlink audit: re-check your top linked pages specifically to confirm each one redirects cleanly. A single high-value backlink pointing at a broken redirect is worth fixing immediately rather than waiting for a scheduled review.

A Realistic Recovery Timeline

Expect a temporary dip even on a clean migration: Google needs time to re-crawl, re-evaluate, and re-rank the new URLs. For a well-executed migration with a solid redirect map and unchanged content, most sites see traffic stabilize within 2 to 8 weeks. Google’s own guidance, echoed repeatedly by Search Advocate John Mueller, puts full ranking stabilization at roughly 4 to 12 weeks depending on site size and the scope of changes. Larger sites, domain changes combined with redesigns, and international sites with hreflang complexity sit at the longer end of that range; a same-domain HTTPS migration with no URL changes sits at the shorter end.

If you’re still seeing significant traffic loss (more than 20-30% sustained) past the 12-week mark, that’s no longer normal migration volatility: it’s a signal that something in the redirect map, content parity, or technical setup is genuinely broken and needs a fresh audit rather than more patience.

Common Mistakes That Cause Long-Term Traffic Loss

• Redirecting everything to the homepage instead of the closest topical match, which reads to Google as a mass soft-404 and forfeits the ranking value of every page redirected that way.
• Leaving a noindex tag or robots.txt disallow from staging live on production after launch, sometimes for weeks before anyone notices the traffic cliff.
• Rewriting titles, content, and URLs all at once, making it impossible to tell afterward which change caused a ranking shift.
• Shutting down the old domain or removing redirects too early, before Google has fully processed the transfer of signals, which can undo months of otherwise clean migration work.
• Ignoring internal links and leaving them pointed at old URLs that then route through redirects, wasting crawl budget and slowing the site’s own internal signal flow.
• Skipping the pre-migration benchmark, leaving no way to prove what changed, by how much, or where, so problems get diagnosed weeks later than they should.
• Treating the redirect map as a one-time task rather than a living document, so new content published between the audit and launch date never gets mapped at all.

Step-by-Step Launch Day Checklist

• Confirm the finished, tested redirect map is deployed and live (spot-check high-traffic and high-backlink URLs first)
• Verify staging noindex/robots.txt rules did not carry over to production
• Check production robots.txt allows the sections you want crawled and blocks the ones you don’t
• Submit the new XML sitemap in Search Console and confirm it validates with no errors
• Spot-check canonical tags across templates for correct self-referencing URLs
• Verify hreflang implementation if applicable, checking return tags across all locales
• Confirm SSL certificate is valid, HTTPS is enforced, and there is no mixed content
• Verify the new property is set up and verified in Search Console (and the old one still is, too)
• Submit the Change of Address tool request if migrating domains, covering every verified variant
• Crawl the live site immediately post-launch to catch broken internal links, missing redirects, and unexpected 404s
• Check Core Web Vitals and page speed on key templates to confirm no regression
• Set a daily monitoring cadence for crawl errors, index coverage, and rankings for the first two weeks
• Keep the old domain/hosting and redirects active for at least 180 days

A migration done right is invisible from the outside: users land on the right page, rankings hold, and traffic barely blips. That invisibility is the product of a redirect map built before a single line of new code shipped, on-page elements preserved rather than reinvented at the worst possible moment, and a monitoring plan that catches problems in days rather than months. None of it is complicated. It’s just easy to skip when a launch deadline is looming, and the sites that skip it are the ones still trying to claw back rankings a year later.

Related

Written by Shahzaib Ul Hassan, senior AI SEO consultant and founder of ShazzSEO. Ranking sites since 2009.

If the migration has already happened and the traffic has already gone, that is a different job from planning one. See site migration recovery.