Content Migration SEO: How to Replatform Without Losing Your Rankings

Every replatforming project starts with the same promise — "SEO will be handled" — and a shocking number end with the same chart: organic traffic falling off a cliff the week the new site goes live, then flatlining for months while everyone argues about whose fault it was. The traffic didn't vanish because the new platform is worse. It vanished because the migration broke the three things Google was using to understand the old site: the URLs, the signals attached to those URLs, and the structured data describing what lives at them. A migration that preserves all three keeps its rankings. A migration that improvises any of them starts over from zero — and starting over takes months, not weeks.

The uncomfortable truth is that migration SEO is not a task you do after the move. It's a constraint you design the move around.

The URL map is the migration

Before a single page moves, every URL on the old site needs a documented destination on the new one. Not "the important pages" — every URL Google has ever indexed, which is always a longer list than anyone expects. The full inventory comes from four sources cross-referenced against each other: a complete crawl of the live site, the XML sitemap, the pages Google Search Console reports as indexed, and the landing pages receiving organic traffic in analytics. The last two matter most, because they catch the URLs your crawl misses — old blog posts with backlinks, product pages that got shared years ago, parameter URLs that somehow accumulated authority.

Each old URL gets one of three verdicts:

Maps to an equivalent page on the new platform — the normal case for products, categories, and content that survives the move.
Maps to the closest relevant parent — the discontinued product redirects to its category, the merged article redirects to the piece that absorbed it. Never to the homepage; bulk homepage redirects are treated as soft 404s and pass nothing.
Deliberately dies — thin pages, expired promotions, junk parameters. These return a clean 404 or 410 on purpose, documented so nobody panics when they drop out of the index.

Platforms disagree about URL structure in ways that multiply this work. WooCommerce puts category paths in product URLs; BigCommerce doesn't by default. Trailing slashes, uppercase handling, pagination formats — every difference between platforms is a set of URLs that will silently break unless the map accounts for it. This is why our team builds the map from the crawl data, line by line, before anyone touches the new platform's settings.

301s, not 302s, and never in chains

Every mapped URL gets a 301 redirect — the permanent kind that tells Google to transfer the old page's accumulated authority to the new address. A 302 says "temporary," and while Google claims to eventually treat long-lived 302s as permanent, "eventually" is measured in months of ranking limbo you don't need to gamble on. Platform defaults are not on your side here: several redirect apps and server configurations issue 302s unless explicitly told otherwise, so every redirect gets verified by checking the actual HTTP status code, not the plugin's settings screen.

The second killer is the redirect chain. Old URL redirects to an intermediate URL from a previous migration, which redirects to the new URL — and each hop leaks authority and slows the crawl. Sites that have migrated before almost always carry legacy redirects, and the new map has to be flattened against them: every old URL should reach its final destination in exactly one hop. We test this on the full URL list after go-live, because a chain that looks fine in a spreadsheet has a way of appearing in production when two redirect systems stack.

What has to survive besides the URL

A redirect preserves the address. It does nothing for what was on the page. The migration checklist that separates clean moves from slow-motion disasters:

Meta titles and descriptions carried over field by field — not regenerated from the new platform's default template, which is how a catalog of hand-written titles becomes "Product Name | Store Name" overnight. If the old metadata was a mess anyway, migration is the right moment for a proper meta overhaul — but as a deliberate rewrite, not an accidental reset.
Structured data rebuilt on the new templates. Schema doesn't migrate; it's generated by the theme, and the new theme generates its own — often less complete than what you had. Product schema with full offers, breadcrumbs, and organization markup needs to be verified on the new platform's rendered pages before launch, which is a template-level job, not a page-level one.
Internal links updated to final URLs. Body content copied from the old site carries old URLs in every link. They'll technically work through the redirects, but you've just built thousands of internal redirect hops on day one. The link targets get rewritten to the new structure.
Image URLs and alt text. New platform, new media paths — and image search traffic dies quietly when nobody redirects the old image URLs or carries the alt attributes across.

Staging to production, in the right order

The go-live sequence matters as much as the preparation. The staging site stays behind authentication or a noindex until launch day — a staging site that leaks into the index creates a duplicate-content mess you'll be untangling for weeks. At cutover: the redirects go live at the same moment as the new site, never "next sprint"; the noindex comes off and gets verified on the rendered production pages, because a forgotten staging noindex on a live template is the single most catastrophic migration error there is; the new XML sitemap is submitted immediately, and the old sitemap stays available temporarily so Google can crawl the old URLs and discover the redirects.

Then the monitoring phase, which is where migrations are actually won: GSC's URL Inspection tool on the top fifty pages to confirm Google sees the redirects and indexes the new URLs, the Page Indexing report watched daily for spikes in 404s or "Redirect error" entries, and rankings tracked against the pre-migration baseline. Expect a dip of a few weeks even on a clean migration — Google has to recrawl and reconcile everything — but a clean migration recovers to baseline within four to eight weeks. A dirty one never does, because lost signals don't come back on their own.

Our team runs the full migration process — inventory, URL map, redirect implementation, metadata and schema carry-over, and post-launch monitoring — so the replatform ships with its rankings attached. The new site should be a better version of what Google already trusts, not a stranger wearing its domain.