The SEO Migration Playbook: How to Replatform Without Losing the Rankings You Already Earned

Every replatform project has a marketing line item and an SEO line item, and the SEO line item is almost always smaller than it should be. That is backwards. A redesign, a CMS switch, or a domain move can erase years of earned authority in a single deploy, and most teams only find out after traffic has already cratered. If your migration plan does not have SEO as a workstream with its own owner, timeline, and sign-off gate, you are planning a traffic loss event and calling it a launch.

This is not a checklist problem. Teams that lose rankings during a migration almost always had a checklist. The problem is that the checklist got treated as a QA formality instead of the thing standing between the business and months of lost pipeline.

The Redirect Map Is the Whole Project

Missing or incorrect redirects cause more post-migration ranking loss than every other technical issue combined. Every URL that has ever earned a backlink, ranked for a query, or accumulated organic authority needs a single, deliberate destination on the new site. Not a category page. Not the homepage. The specific new URL that covers the same search intent.

Two mistakes show up on nearly every migration post-mortem, and both are avoidable.

The first is the incomplete map. Teams redirect the top fifty pages by traffic and assume the long tail does not matter. It does. A blog with three years of posts might have four hundred URLs generating a trickle of traffic each, and collectively that trickle is a third of total organic sessions. When those return a 404 on launch day, that traffic does not degrade. It stops.

The second is the homepage dump. When a team cannot be bothered to map a page, the redirect defaults to the homepage. Google does not treat this as a redirect. It treats it as a soft 404, and it will deindex the source URL within weeks, taking whatever authority that URL had with it. If you cannot find a genuine one-to-one match for a page, a redirect to the closest topical parent is still better than the homepage, but the honest fix is to do the mapping work before launch, not patch it after.

Metadata and Structured Data Do Not Survive a Platform Swap

Page titles, meta descriptions, canonical tags, schema markup, hreflang, and Open Graph data live in the old platform's templates, and none of it moves automatically to a new CMS or framework. Teams that treat content migration as a copy-paste job for body text routinely ship a new site with generic auto-generated titles and no structured data, then wonder why click-through rate drops even on pages that kept their ranking position.

Schema markup deserves particular attention right now. AI Overviews and chatbot answers increasingly pull from structured data rather than crawling raw page content, so a migration that quietly drops your Article, Product, or FAQ schema is not just an SEO regression. It is a citation-visibility regression in the surfaces that are taking an increasing share of search behavior. Audit and re-implement schema as its own line item, verified against the old site's markup field by field, not assumed to be handled because "the new CMS supports schema."

The Timeline Everyone Gets Wrong

Rankings do not drop the moment you flip the switch. They erode over the following three to four weeks, as Google finishes reprocessing the crawl, recalculating link equity, and re-indexing the new URL structure. This delay is exactly why so many migrations get blamed on the wrong cause. A team ships in week one, sees stable rankings in week two, declares victory, and reassigns the SEO lead to the next project. By week four, when the erosion actually shows up, nobody is watching for it and nobody remembers what changed.

Nearly 17 percent of the sites in that study never recovered to pre-migration levels at all. That is not a rounding error. That is a meaningful share of companies that replatformed for a better tech stack and paid for it with a permanently smaller organic funnel.

Build the Recovery Window Into the Project Plan, Not Around It

The fix is not more caution. It is treating the four weeks after launch as an active monitoring phase with a named owner, not a passive wait-and-see period. Pull Search Console and analytics data weekly for the first month, not monthly. Compare indexed page count, not just rankings, since a page that silently drops out of the index will not show up as a ranking loss until it is too late to react quickly. Keep the old site's redirect rules live and unchanged for at least ninety days; migrations that "clean up" redirects too early re-break URLs that were only just starting to pass equity through.

None of this requires new tooling or a bigger budget. It requires putting an SEO owner in the same room as the engineers making the platform decision, from kickoff through the first month of monitoring, instead of handing them a URL list the week before launch and hoping the crawler catches everything.

The actionable version: before you approve a replatform timeline, confirm three things exist: a complete one-to-one redirect map covering every indexed URL, a schema and metadata audit with field-level sign-off, and a thirty-day post-launch monitoring plan with a named owner. If any of the three is missing, the launch date is not real. It is a guess with a deadline attached.