When should SEO be brought into a migration?

At the replatform or redesign decision — ideally eight weeks before launch. Bring it in after the new site is built and you are paying for discovery of problems that were cheap to prevent and are now expensive to fix.

Can you guarantee traffic will not drop?

No, and anyone who does is selling. What the process controls is the avoidable loss: redirect errors, indexation mistakes and template regressions, which are where the big recoverable drops come from. Unavoidable flux is monitored and reconciled against the benchmark.

Do you work with our development agency?

Yes — most of the work is coordination with the dev team doing the build. Redirect implementation, staging access and release timing all live with them; the checklist tells everyone exactly what “done” means.

[09]Technical

Website Migration SEO

Protect organic traffic through replatforms, redesigns and restructures with migration SEO done properly.

Most organic traffic losses during migrations are not accidents. They happen because SEO was brought in after the rebuild was scoped, the URLs were decided and the launch date was locked. A migration handled properly is unremarkable — traffic dips, then recovers. One handled as an afterthought can take a business years to recover from.

Written by Rahul Sengupta, independent SEO & AI-search consultant in Melbourne.

About the author

Why migrations destroy organic traffic

Search engines don't see your redesign. They see URLs, content, internal links and page structure. Change any of those carelessly and you change what the site is understood to be. Common consequences include lost rankings, lost link equity, orphaned content and analytics that no longer line up with history — meaning you can't even measure the damage cleanly.

The phases that matter

Pre-launch audit — a full inventory of what exists now: URLs, rankings, backlinks, indexation, content performance. This is the baseline everything else is measured against, and the insurance policy if things go wrong.
URL mapping and redirects — every old URL mapped to its new destination, one-to-one, with permanent redirects. No shortcuts, no "homepage catch-alls".
Staging review — the new site tested before launch: redirects live, metadata carried over, internal links intact, canonicals correct, noindex removed.
Post-launch monitoring — crawl the new site, watch indexation and traffic against the baseline, and fix problems in the first days when they're cheap to fix.

[S1]Phases

The four phases, with timings

Most migration damage happens in two windows: just before launch and just after. The phase structure exists to control both.

Pre-launch audit
Launch minus 6–8 weeks
The old site fully mapped: URLs, authority, rankings and revenue per page.
Every URL gets a destination decision. Redirects are written and tested against staging before anything ships.
Staging review
Launch minus 2–3 weeks
The new site reviewed on staging before it can hurt you.
Indexation controls, template parity, structured data, performance and the redirect map — verified where fixes are still cheap.
Launch window
Launch week
The redirect map goes live and is crawled immediately.
Live monitoring of crawl behaviour, indexation and error rates. Decisions in hours, not in the week-four retrospective.
Post-launch validation
Launch plus 2–6 weeks
Traffic, rankings and revenue reconciled against the pre-launch baseline.
Weekly check-ins while the picture stabilises, then a written close-out: what held, what moved, and the recovery plan for anything that did not.

Timeline expectations

A proper migration programme for an enterprise site takes months, not weeks — the mapping and staging work alone is significant. If your agency has promised a launch in six weeks and nobody has mentioned redirects yet, that's the moment to call someone in.

[S2]Coverage

The migration checklist

Ninety checks across three windows. The same list runs on a ten-page site or a two-million-URL platform move.

Pre-launch: mapping and benchmarks36
- URL inventory
- redirect map
- authority map
- revenue baseline
Launch window: controls and monitoring28
- redirects live
- indexation controls
- error monitoring
- rollback plan
Post-launch: validation and recovery26
- traffic reconciliation
- crawl verification
- GSC reconciliation

What this looks like

I typically join before the rebuild is scoped, not after. We agree what must be preserved, I review the plan and staging environment, and I stay through the weeks after launch. My role is to make sure search visibility is treated as a launch requirement alongside design and functionality — not as a problem to investigate afterwards. If a migration is already underway and something looks wrong, there's still usually time to limit the damage, but earlier is always cheaper.

[S3]Deliverables

What the engagement produces

Full URL map with a destination decision per URL
Redirect map, tested against staging before launch
Pre-launch benchmark: rankings, traffic and revenue per section
Staging sign-off report with launch/no-launch recommendation
Launch-week monitoring with same-day issue response
Post-launch reconciliation report against the benchmark

The single most common failure is skipping the staging review. If the new site is only ever reviewed after it goes live, the audit starts after the damage does.

← All services

[Q]Questions