Replatform without losing your rankings

When we need to be involved, and why earlier is cheaper

At the sitemap stage, before design. That is not a preference, it is where the decisions that determine visibility get made.

The URL structure, which pages survive, which get merged and which get dropped are all set during planning. Once design and build are underway those decisions are expensive to revisit, and redirect mapping bolted on in launch week is where most visibility is lost. By then the mapping is being reverse-engineered under deadline pressure by someone who did not plan it.

If you are already mid-build, we can still help and the work is more constrained. If you have already launched and traffic has dropped, that is recovery rather than migration, and the first job is diagnosis: usually missing redirects, sometimes a staging site left indexable, occasionally a robots directive that shipped to production.

Before launch

A complete URL inventory first, and complete is the operative word. Your live sitemap, Search Console coverage data, server logs and analytics all hold URLs the others do not. A firm with fifteen years of history has campaign landing pages, old team profiles and superseded location pages that still hold links and still receive traffic.

Then a one-to-one redirect map. Every old URL points to the closest equivalent, not to the homepage. Bulk-redirecting to the homepage is treated as a soft 404 and throws away the authority you were trying to preserve, and it is the single most common shortcut taken under deadline.

Then a staging crawl against a sign-off checklist: metadata parity, schema parity, internal linking parity, canonical correctness, and no robots directives or noindex tags that would ship. Staging must not be publicly indexable, which sounds obvious and happens regularly.

Launch day and the week after

Launch early in the week and not before a holiday, so that if something is wrong there are people available to fix it. Friday launches are how a problem gets six weeks to compound.

On the day: verify redirects are firing with the right status codes rather than assuming the mapping deployed, submit the new sitemap, confirm robots.txt is what you intended, and check the analytics and enquiry tracking still fire, because a migration that preserves rankings and breaks enquiry attribution has still cost you.

Then daily monitoring for the first week on indexation, crawl errors and rankings for your top terms, with a rollback plan agreed in advance so the decision does not have to be made under pressure.

The first ninety days

Expect some fluctuation. A well-executed migration typically shows a modest dip while Google reprocesses, then recovery. What matters is distinguishing normal fluctuation from a genuine problem, which is why the pre-launch baseline exists.

At thirty days: indexation coverage against the old site, redirect errors, ranking movement on priority terms. At sixty: whether recovery is tracking or whether specific page types are lagging, which usually points at a mapping gap. At ninety: a fair assessment against the baseline, plus the pages that did not recover and why.

We do not guarantee that visibility will be unchanged, because no one can. What we commit to is a complete mapping, a documented pre-launch checklist, and monitoring close enough that a problem is found in days rather than at the next quarterly review.

What actually goes wrong, in order of frequency

Missing redirects, by a wide margin, usually for older pages nobody remembered existed. Then bulk redirects to the homepage instead of one-to-one mapping. Then a staging site left indexable, competing with the live one. Then noindex tags or a blocking robots.txt shipping to production. Then internal links still pointing at old URLs, creating redirect chains that leak authority. Then metadata not carried across, so pages that ranked lose their titles. Then enquiry tracking broken, so the firm cannot tell what the migration cost.

All seven are preventable with a checklist. None of them are exotic. They happen because a migration has a launch date and the SEO work is the part that can be compressed.