Migrating a site without losing rankings: our redirect checklist

Moving a site from one platform to another, WordPress to a headless build, for instance, without changing the domain, still carries real SEO risk if the URL structure shifts even slightly. A trailing slash added or removed, a category prefix changed, can be enough to break the link between old rankings and the new page if redirects aren't handled deliberately.

This risk gets underestimated precisely because the domain itself isn't changing, which feels like the low-risk part of a migration to most non-technical stakeholders. In practice, URL structure carries just as much of a site's accumulated ranking signal as the domain does, and treating it as an afterthought is one of the more common, avoidable causes of a post-migration traffic drop.

We pull the full list of indexed URLs from Search Console and crawl the live site independently to cross-check, before any migration work begins. This becomes the master checklist every new URL gets mapped against, and it catches pages that might not be obvious from the current site's navigation but are still actively ranking and receiving traffic.

Cross-checking both sources matters because either one alone can miss real pages: Search Console's index can lag behind recent changes, and a live crawl can miss pages that rank well but are no longer linked from anywhere visible on the current site. Combining both gives a genuinely complete picture of what actually needs to survive the migration intact.

Preserving the exact same URL structure on the new platform, where the platform allows it, eliminates the need for redirects entirely for those pages, which is always the safest option. Where structure has to change, every single old URL gets an explicit 301 to its new equivalent, not a pattern-based catch-all redirect that might not map every specific page correctly.

Pattern-based redirects are tempting because they're faster to set up, a single rule instead of thousands of individual entries, but they're also where subtle mapping errors hide, a pattern that correctly handles ninety-five percent of URLs while silently sending the remaining five percent somewhere wrong. We only use pattern-based redirects after verifying, page by page on a sample large enough to be meaningful, that the pattern actually produces the correct destination every time.

A URL that's already been redirected once, from an earlier migration or a past URL structure change, sometimes ends up redirected again during a new migration, creating a chain of two or three redirects instead of one direct hop. Each additional hop in the chain adds latency and, in some cases, dilutes the ranking signal passed through to the final destination.

We check for existing redirect chains as part of the pre-migration audit specifically so a new migration can collapse them into a single direct redirect rather than adding yet another link onto an already-long chain. It's a small detail that's easy to overlook in the middle of a larger migration but meaningfully affects both crawl efficiency and user experience for anyone landing on an old bookmarked link.

Ranking impact from a migration doesn't always show up immediately. We keep an elevated monitoring cadence on rankings and crawl errors for a full sixty days after any migration, since Google needs time to fully re-crawl and re-evaluate the new URLs, and issues sometimes surface weeks in rather than on day one.

This extended window is what catches the slower-moving problems a launch-week check alone would miss entirely, a page that redirected correctly but is being crawled less frequently than before, or a ranking that holds steady for the first two weeks and then drifts as Google's own re-evaluation catches up with the change. Sixty days of elevated attention is what turns a migration from a one-time event into something we can actually confirm succeeded.

Every migration plan we run includes a documented rollback path, agreed and tested before launch day, even for migrations the team is confident will go smoothly. Confidence going in isn't the same as certainty, and a rollback plan that exists only as a vague verbal understanding tends to fall apart under the actual pressure of a launch-day problem, exactly when it matters most.

We've needed the rollback plan only a small handful of times across many migrations, but every one of those times it turned a potentially serious, extended ranking problem into a contained, quickly reversed incident instead. The plan's value isn't in how often it gets used, it's in the fact that it exists and has actually been tested before anyone needs it under pressure.

We run the full redirect map against a staging environment before it ever touches the live site, checking a representative sample of URLs across every content type and template the site uses, not just the homepage and a handful of obvious pages. Errors caught in staging cost nothing beyond the time to fix them. The same errors caught after a live migration cost real ranking and traffic while they go unnoticed.

A client who's read about migrations going badly for other businesses often arrives anxious about the process, and we address that directly rather than downplaying the risk to sound reassuring. Walking through the actual checklist, the URL export, the redirect mapping, the staging test, the tested rollback plan, the sixty-day monitoring window, tends to calm that anxiety far more effectively than a vague promise that everything will be fine, since it shows the risk is being managed deliberately rather than simply hoped away.

We also share, honestly, the specific things a checklist like this can't fully eliminate, algorithmic volatility unrelated to the migration itself, for instance, that can coincide with a launch window purely by chance. Naming that limitation upfront, rather than implicitly promising a risk-free outcome, is what keeps client trust intact even in the rare case where some ranking movement happens that the migration itself didn't actually cause.