A migration is any change to how your site is structured, accessed, or delivered. A replatform. A domain change. A redesign. A URL rewrite. Done well, it preserves the rankings you've earned. Done badly, it erases them in days. Everything you need to plan for the first version, or recover from the second, sits below.
The same four failure modes show up on almost every audit. Different stacks, different brands, same broken patterns underneath.
Every old URL that ranks needs a one-to-one 301 redirect to its new equivalent. Blanket redirects to the homepage destroy topical relevance. 302s tell Google the old URL is coming back.
→ See the redirect playbookMenus, footers, and in-content links keep pointing at old URLs after launch. Crawl budget bleeds, equity dilutes, and search engines see a site at war with itself about which paths are canonical.
→ See the master checklistNew sitemaps surface URLs that canonical back to old ones. Old sitemaps don't get retired. Search engines pick the wrong page to index, or skip indexation entirely on the URLs that matter most.
→ See the master checklistA heavier theme, bloated apps, or un-optimised images quietly slip LCP into the red after launch. Rankings drift over weeks without anyone connecting the trend to the technical decay underneath.
→ Read the recovery guideThree questions. Honest answer in under a minute. Use it before you start, to know what you're walking into.
The same six pre-launch checks come up on every migration, regardless of platform or scale. Work through them in order. Your progress saves automatically, and the full breakdown of each item, plus the launch-day and post-launch tracks, lives in the master checklist.
Most migrations that lose rankings skip two or three of these. None of them are hard. All of them are easy to forget under launch pressure.
Read the Full Checklist →Two deep-dive guides covering the platform-specific quirks that generic migration advice misses.
URL strategy, redirect mapping, metadata preservation, canonical behaviour, Markets and international, and the Shopify-specific gotchas a generic guide misses.
Plugin pitfalls, permalink changes, host moves, HTTP to HTTPS, page-builder quirks that hardcode URLs into post meta, and the redirect strategy that holds it together.
Every engagement follows the same five stages. Audit first, deploy last, monitor longest.
Crawl the current site, baseline rankings and traffic, identify the URLs and templates that carry the most equity, and map the technical dependencies that must survive the move.
Build the redirect map, define the canonical strategy, document metadata parity, and set the validation criteria for go-live. Decisions made now are cheaper than fixes after launch.
Crawl the staging build, validate redirects, confirm canonicals, check indexation directives, and verify that template-level signals match the plan.
Validate the live site inside the first four hours: redirects firing, robots.txt clean, staging noindex stripped, sitemap submitted, key templates verified.
Track Search Console coverage, organic traffic, and rankings against the pre-launch baseline through the first 8 to 12 weeks. Catch and fix regressions before they compound.
Most post-launch drops trace back to four layers: redirects, coverage, internal links, and content. Work them in that order.
Three guides covering planning, redirect strategy, and recovery.
The platform-agnostic master checklist. Pre-migration audit, build phase, launch day, and the first 30 to 90 days of monitoring.
Read guide → 02How to plan, map, and execute the redirect strategy that decides whether your organic traffic survives a move.
Read guide → 03The diagnostic and recovery playbook for when traffic has already fallen. What's normal, what's broken, what to fix first.
Read guide →The questions teams usually ask before a replatform, a domain change, or a redesign.
Before development is finalised. Migration SEO has the highest leverage when it shapes the URL strategy, redirect plan, and preservation rules before any code is shipped. Bringing SEO in for "the redirects at the end" is the most common reason migrations lose rankings.
Replatform plus domain change plus redesign, all in one launch. Each layer multiplies the failure surface and slows recovery. If you have to combine them, treat each as its own track with its own checklist, and phase the changes where possible.
For a well-executed migration, expect 2 to 12 weeks of volatility followed by stabilisation. Small sites with preserved URLs recover within 4 to 6 weeks. Large sites with structural changes can take 6 to 16 weeks. Botched migrations can take 12 to 18 months, and some never fully recover.
Every valuable URL that changes should have a 301 redirect to its closest equivalent. Thin or low-value URLs with no traffic, no rankings, and no backlinks can be retired with a 410 (Gone) response. The decision should be deliberate per URL, not blanket logic that sends everything to the homepage.
You can, but combining changes multiplies SEO risk. Where possible, keep information architecture, copy, and key on-page elements stable through a replatform, then refine the design after performance stabilises. When the timeline forces a combined launch, treat each change as a separate track.
Three signals over the first 30 to 90 days: indexed page count stable or growing against the pre-launch baseline; organic sessions on top landing pages within plus or minus 10 to 15 percent of baseline within four weeks; and Search Console coverage report free of 404 spikes on legacy URLs.
Structured data is bound to templates, so a theme rebuild or platform switch almost always disturbs it. Product, FAQ, Article, and BreadcrumbList schemas commonly disappear when templates are re-built without explicit parity checks, and broken implementations frequently survive the migration as warnings in Search Console. Treat schema as its own QA track: audit what's live before the move, document the JSON-LD per template, and validate parity after launch. For deeper structured-data tooling, including a free gap analyzer and platform-specific guides, see the Schema Markup hub.
Work the diagnostic in order: redirects on top pages first, then Search Console coverage, then internal links, then content and canonicals. Most post-launch traffic drops trace back to one of those four layers. The Traffic Drop After Migration guide walks through the full playbook.
Book a focused migration risk review. You'll leave with priority failure points, validation checkpoints, and a clearer pre-launch action plan.