Website and platform migrations that keep their search visibility
Most post-migration traffic loss is not bad luck. It is a predictable set of decisions — URL mapping, redirect architecture and cutover sequencing — each of which has a right answer that is easier to choose before launch than after.
Migration loss is usually a design decision, not an accident
A migration replaces every URL a site has, and with them every accumulated signal attached to those URLs. The loss that follows is normally attributable to a specific set of causes: a URL mapping that was never completed, redirects that were temporary when they needed to be permanent, signals split across two live versions, or a cutover that made the change unmeasurable. Each is avoidable, and none is detected by testing the new site.
- A replatform or redesign after which organic traffic fell and never recovered
- URLs that changed shape, with redirects added afterwards from a sitemap comparison
- Two versions of the site both reachable and both indexed
- Redirect chains and loops left over from an earlier platform
- Traffic that recovered partially and then plateaued below its previous level
- No record of what the old URLs were, so the mapping cannot now be checked
The people who usually bring us this problem
CTO / VP Engineering
A migration is scoped or underway and the search consequences need to be engineering requirements with acceptance criteria, not a post-launch checklist.
Head of SEO / SEO Director
You have been asked to sign off a migration and need the mapping and redirect work treated as a deliverable it is possible to verify.
Head of Digital / Marketing
Organic acquisition is material to the business and a migration has been proposed. You need the risk stated in terms of what would actually be lost and how it would be prevented.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
Redirects added after launch recover less than redirects planned before
Signals pass through a redirect, but not instantly and not perfectly. A mapping built from the old URL inventory before cutover preserves equity that a mapping reconstructed from a traffic report afterwards cannot.
Temporary redirects do not pass signals at all
A 302 left in place after a migration tells a search engine the move is temporary, and it behaves accordingly. This is one of the most common and most easily prevented causes of permanent loss.
Running both versions splits what either would have had
If the old and new sites are both live and both indexable, the accumulated signal is divided rather than transferred. Cutover is a sequencing problem with a correct order.
An unmeasured migration cannot be corrected
Without a captured baseline and a post-launch comparison, a decline is visible only as a trend nobody can attribute. That makes the difference between diagnosing and guessing.
Capabilities
Each of these is work we carry out, not an area we advise on.
Pre-migration crawl and URL inventory
A complete record of the URLs that exist before anything changes. Every later step depends on it, and it cannot be reconstructed accurately once the old site is gone.
URL mapping and redirect architecture
Every old URL mapped to its closest equivalent, one hop, with permanent redirects. Where a genuine equivalent does not exist, that is identified explicitly instead of being pointed at the homepage.
Indexation continuity
Keeping the new URLs crawlable and the canonicals consistent through the change, and closing the old URLs to crawling once they redirect so the two versions do not compete.
Content and template parity checking
Verifying that the pages that carried the most search value before the migration exist afterwards with equivalent content, metadata and structure — not merely that the new site looks correct.
Cutover sequencing
The order of DNS, redirects, robots directives and sitemap submission, chosen so the change is measurable and no step is discoverable by a crawler before it should be.
Post-migration verification
Comparison against the pre-migration baseline by URL class, with a stated expected recovery window. Migration recovery is not immediate, and knowing what normal looks like is what distinguishes a slow recovery from a real loss.
Platform migration engineering
Forum and community platforms, CMS changes and stack replacements where content, users, URLs and internal link structures all have to be preserved through the move.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Inventory the old site before touching the new one
A full crawl producing the definitive URL list, with traffic and link data attached where available. This is the single step that everything else depends on, and it is the one that is skipped when the timeline is tight.
Map by intent, not by string similarity
An old URL should point at the new page that serves the same purpose, which is not always the one with the nearest name. Similar-looking URLs are checked, because a plausible automatic mapping is how traffic ends up redirected to the wrong place.
Permanent, single-hop, everywhere
301s rather than 302s, no chains, and old URLs closed to crawling. This is mechanical, unglamorous, and where a large share of migration outcomes is decided.
Sequence the cutover so it can be measured
The order of operations is written down in advance, including how the staging environment is kept out of the index and how the change is confirmed live. A migration that cannot be pinned to a date cannot be measured against one.
Capture the baseline and compare against it
Per-class figures are recorded before the migration, with a stated recovery window. This is what allows a dip to be identified as expected or as a fault, and it is why the baseline is taken before the change rather than after.
Keep the mapping as an artefact
The redirect map is retained rather than discarded once live, so that later questions about a specific URL can be answered from a record instead of from memory.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Planning
- Pre-migration crawl and full URL inventory
- URL-to-URL mapping with unmatched URLs identified
- Redirect specification: status, direction, single hop
- Cutover sequence with owners and verification steps
- Pre-migration baseline per URL class
Execution
- Redirect rule implementation and validation
- Canonical and hreflang consistency across the change
- Robots and sitemap handling for old and new URLs
- Staging indexation control
Verification
- Post-launch mapping audit, checking every rule resolves
- Indexation and crawl comparison against baseline
- Recovery monitoring with a stated expected window
- Redirect-chain and loop monitoring
Architecture and technology
URL and redirect layer
- Redirect rule source, versioned rather than hand-edited in a console
- Mapping coverage: mapped, intentionally unmatched, unknown
- Canonical resolution across old and new paths
- Old-URL crawl closure once redirecting
Continuity concerns
- Internal link structure updated to the new URL space
- Sitemap reflecting the new estate only
- Structured data carried across where it existed
- Analytics continuity so pre- and post-migration periods are comparable
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
Discovery and indexation problems that are not migrations
See Crawl and Indexation for the log-driven diagnosis of what a search engine is doing on a site that has not moved.
A migration where content is client-rendered
See JavaScript SEO. A rendering change made during a migration can produce a second, independent cause of loss.
Frequently asked
Do you have a migration case study?
Our reviews include a forum upgrade and migration and a move to different infrastructure. We can also walk through the migration approach, risk controls and verification plan relevant to your platform.
How much traffic should we expect to lose?
Done properly, a well-planned migration can settle back to its previous level within weeks to a few months, with the dip concentrated at cutover. But we will not give you a number in advance, because the honest answer depends on how much of the site's value is URL-dependent, how many URLs genuinely have no equivalent, and how much of your traffic arrives on URLs that change shape. Anyone quoting a fixed percentage without those facts is quoting an average.
Can we run the old and new sites in parallel?
For a short transition period with the old URLs redirecting and closed to crawling, yes. What must not happen is both versions live, indexable and serving the same content, because that divides the signal rather than transferring it. Parallel running is a cutover technique, not a permanent arrangement.
Do you migrate the platform as well, or only handle the SEO side?
Both, and the two are better done by the same people. The URL and redirect decisions depend on what the new platform can express, and the platform configuration depends on what the mapping requires. Splitting them between a migration vendor and an SEO consultant is how redirects get specified correctly and implemented approximately.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.