Pre-migration baseline
Every indexed URL with its traffic, rankings and links, recorded before anything changes. Without this, nobody can prove what was lost or when.
Why migrations lose traffic
Migrations lose traffic for a small number of repeated reasons: URLs change without correct redirects, redirects chain or point somewhere generic, content is dropped in the redesign, and internal linking is rebuilt differently. Each is avoidable, and each is far cheaper to prevent than to recover.
The single most common failure is redirecting large parts of a site to the homepage or to a category page. It is fast, it looks tidy, and it discards the accumulated authority of every URL treated that way. A one-to-one map to the closest equivalent page is more work and is the difference between a migration and a reset.
The second is content quietly disappearing. Redesigns simplify, and a page that was carrying long-tail traffic gets consolidated because nobody checked what it earned. That decision is entirely reasonable if made deliberately with the data in front of you, and expensive when made in a design review.
Timing determines almost everything about the outcome. Involved before launch, this is a mapping and verification exercise with a predictable result. Called in after a bad launch, it becomes forensic work under pressure, and some of the loss will be permanent because competitors have already taken the positions.
Recovery is possible and it is not free. How fast depends almost entirely on documentation: where the previous URL structure can still be reconstructed, most of the loss can be reversed within weeks. Where nobody kept a record of what existed before, recovery is slower, partial, and sometimes not possible at all.
What the engagement covers
The engagement covers a pre-migration baseline and a full URL inventory, a one-to-one redirect map, staging verification before you launch, launch-day monitoring, and then post-launch tracking against that baseline until performance has demonstrably recovered or exceeded where it originally started.
One-to-one redirect map
Each old URL mapped to its closest equivalent, not to a category or the homepage. The mapping is the deliverable that decides the outcome.
Content parity check
What existed before and does not exist after, with the traffic each page was earning, so consolidation decisions are made deliberately rather than discovered later.
Staging verification
Redirects, canonicals, markup and rendering checked on staging while fixing them is still cheap and nobody is watching a traffic graph fall.
Launch-day monitoring
Live checks through the switch, so a redirect loop or a stray noindex is caught within hours rather than at the next reporting cycle.
Post-launch tracking
Performance tracked against the baseline until recovery is demonstrated, with anything unrecovered named specifically rather than absorbed into an average.
How the engagement runs
The engagement spans the launch itself: record a complete baseline, build a one-to-one redirect map, verify everything on staging, monitor through the switch, then track recovery against that baseline until performance is demonstrably restored or better than it was before.
- 01
Baseline everything first
Every indexed URL with traffic, rankings and inbound links. This is the record that later settles every argument about what changed and when it changed.
→ A complete pre-migration baseline
- 02
Map URLs one to one
Each old URL to its closest equivalent. Where no equivalent exists, that is a content decision to make deliberately rather than a redirect to the homepage.
→ A reviewed one-to-one redirect map
- 03
Verify on staging
Redirects, canonicals, markup, rendering and robots directives checked before launch, when fixing them costs an afternoon rather than a quarter.
→ A signed-off staging verification
- 04
Monitor the switch
Live checks through launch and the following days. Most catastrophic migration failures are visible within hours to somebody who is actually watching.
→ Launch-day monitoring and issue log
- 05
Track recovery
Performance against the baseline until recovery is demonstrated. Anything that has not recovered is named specifically rather than averaged into a reassuring total.
→ Recovery tracking against baseline
The cost of being involved early versus late
Migration is the one engagement where timing changes the nature of the work rather than only its cost. Before launch it is a mapping exercise with a predictable outcome. After a bad launch it is forensic recovery under pressure, and some losses will be permanent.
| Involved before launch | Called in after | |
|---|---|---|
| Nature of the work | Mapping and verification | Forensic reconstruction under pressure |
| Baseline available | Yes — recorded deliberately | Reconstructed from whatever survives |
| Typical outcome | Performance held or improved | Partial recovery, some losses permanent |
| Timescale | Weeks, planned | Months, reactive |
| Content decisions | Made deliberately with data | Discovered after the traffic has gone |
| Competitor effect | None | Positions taken while you were down |
Signals you need this now
You need this when a replatform, redesign or domain change is planned, when a migration has already happened and traffic fell, or when nobody on the project has been made responsible for what happens to organic performance through the switch.
- A replatform, redesign or domain change is planned
- You migrated recently and traffic fell
- Nobody on the project owns organic performance through launch
- The redirect plan sends large sections to the homepage
- URLs are changing and no baseline has been recorded
- Content is being consolidated without checking what it earns
- You are merging two sites after an acquisition
What clients see
Migrations planned with this work in place typically hold performance and frequently improve, because the exercise surfaces problems that predate the migration. Recoveries after a bad launch vary considerably, and how completely the old site was documented is usually the deciding factor.
Where this fits
Related SEO services
Common in these sectors
The adjacent disciplines
Deciding between options
Questions about site migration SEO
Each answer is written to stand alone in 40 to 60 words — the shape an AI Overview or Perplexity citation lifts. Ships with FAQPage schema.
When should we involve you in a migration?
As early as the URL structure is being decided. Before launch this is a mapping exercise with a predictable outcome; afterwards it becomes forensic recovery under pressure, and some losses are permanent because competitors take the positions while you are down.
We already migrated and traffic dropped. Can it be recovered?
Usually a substantial part of it, and how completely depends on whether the old site is still documented. Our fastest recorded recovery was fourteen days on a well-documented site. Where nothing was recorded beforehand, it is slower and less complete.
Can we redirect old URLs to the homepage?
You can, and it is the most common way migrations lose traffic. Bulk redirects to the homepage or a category discard the accumulated authority of every URL treated that way. A one-to-one map to the closest equivalent is the difference between a migration and a reset.
How long does organic performance take to stabilise?
Typically four to eight weeks for a well-executed migration, longer for large sites. Some fluctuation in the first fortnight is normal and expected. What is not normal is a sustained decline, which usually indicates a mapping or indexing problem worth investigating immediately.
What if some old pages have no equivalent?
That is a content decision rather than a redirect one. Either the page is recreated, its content is merged into an equivalent that then absorbs the redirect, or it is retired deliberately with the traffic loss accepted. All three are fine; discovering it later is not.
Do we need this for a redesign that keeps the same URLs?
A lighter version, yes. URLs staying the same removes the largest risk, but redesigns still drop content, change internal linking and alter rendering. A content parity check and staging verification catch most of what goes wrong in that scenario.
Find out whether this is your constraint.
Thirty minutes with a senior strategist. We pull your live visibility while we talk and tell you plainly whether a site migration SEO is what you need — or whether your problem sits somewhere else.