Start a conversationReplatforming is the largest controllable SEO risk an enterprise takes, and it arrives with a fixed launch date. The work belongs before the launch: redirect mapping, parity testing on staging, hreflang and canonical carry-over, and agreed rollback criteria. Then thirty days of log monitoring.
Overview
Site migration SEO is the discipline of preserving organic visibility through a change to a site’s platform, domain, URL structure, templates or content model. The triggering events are familiar: a replatforming from Magento to Shopify Plus or SFCC, a move to a headless Next.js front end, a domain consolidation after an acquisition, a shift from ccTLDs to subfolders, or a redesign that quietly rewrites every URL. The common factor is that search engines must re-discover, re-crawl and re-attribute an entire site in a compressed window.
Unlike most SEO work, migrations are scheduled events with a hard date and an asymmetric risk profile: done properly the outcome is that nothing happens, done badly it removes a third of organic revenue in a week. Almost all of the work is therefore pre-launch (redirect mapping, parity testing against staging, and agreed criteria for rolling back) followed by intensive log and index monitoring once traffic is live.
Who it's for
Every indexed URL needs a 301 to its closest equivalent, not a bulk rule pointing at the homepage or a category. The map is built from a crawl of the live site, historical Search Console URLs, log files and backlink data, because pages no longer linked internally still carry authority. Chained and looped redirects are the usual failure, and they are avoidable.
Before launch the new build is crawled on staging and compared with production field by field: titles, headings, canonical tags, robots directives, structured data, internal links and rendered content. Parity testing is where you discover that the new template dropped its schema, or that the staging environment is noindexed and that directive is about to ship.
Multi-market sites carry signals that break quietly. hreflang clusters must be rebuilt against the new URLs with reciprocal tags and a valid x-default; canonical logic has to survive the new templates; and a change from ccTLDs to subfolders, or the reverse, resets geotargeting. These are checked before launch rather than diagnosed after it.
The first thirty days decide the outcome. Server logs show whether Googlebot is finding the new URLs and how quickly the old ones are retired; Search Console shows indexing and coverage moving; rankings lag both. Rollback criteria (what level of loss, measured how, by when, triggers reverting) are agreed before launch, while the decision is still rational.
What's included
A baseline of what currently earns traffic, which URLs carry links, and where the new build already threatens to lose either of them.
A URL-level map built from crawl, log and Search Console data, then tested against staging for chains, loops, 404s and parameter edge cases.
Field-by-field comparison of titles, canonicals, robots directives, schema, internal links and rendered content between the old site and the new build.
Presence through the release, then log, index and ranking monitoring at 30, 60 and 90 days against the rollback criteria agreed in advance.
Not sure which of these you actually need?
Request a discovery callProcess
1
Baseline crawl, log analysis and a map of every URL that earns traffic or links.
2
Redirect map built and tested, staging parity checked field by field, defects logged and retested.
3
On call through the release: redirect verification, robots and sitemap checks, live crawl within hours.
4
Log, index and revenue monitoring against the baseline, with fixes shipped as issues surface.
Related case study · Confidential, B2B SaaS platform
FAQ
Yes, and it is the most common way this starts. The work is forensic: compare the old URL inventory against what now exists, find the redirects that chain, loop or resolve to 404s, and check what changed in canonicals, robots and rendering. Most losses are recoverable.
Eight to twelve weeks before launch on an enterprise migration, and before the URL structure is finalized. The most expensive migration decision, how URLs are formed, is usually made early by people who were not thinking about search, and reversing it after launch costs far more.
No. A well-run migration typically dips for two to six weeks and recovers; a badly run one does not recover at all. What I can do is remove the avoidable failures (broken redirect maps, lost hreflang, noindexed templates, etc.) which is where nearly every catastrophic loss comes from.
Usually not. Rule-based redirects cover the tidy majority and miss exactly the URLs that matter: old campaign pages with links, discontinued products, paginated and faceted URLs, and anything the CMS renamed years ago. The test is whether the map was built from log files or from the sitemap.
Related resources
Migrations · 5 min
Migrations · 6 min
Technical SEO · 4 min
Technical SEO · 6 min
Technical SEO · 6 min
Send me your launch date and the platform you are moving from and to. I reply personally within 48 hours.
