Site migration without losing traffic needs a map

Aug 29
3 min read

Updated: 2 days ago

Introduction

A business rebuilds its website. The new one is better designed, faster and easier to update. Traffic falls by half in the fortnight after launch and takes eight months to recover, if it recovers at all.

Almost every case of this has the same cause: the old addresses were not mapped to new ones. Pages that had accumulated years of links and rankings were replaced by error pages, and everything they had earned was discarded. The prevention is a spreadsheet made before launch, not a diagnosis made after it.

1. Site migration without losing traffic rests on the redirect map

The single most important artefact.

A list of every existing address and the new address it should point to. Produced before launch, it turns the risky part of a migration into a mechanical one; produced afterwards, it is an archaeological exercise.

2. Build a complete list of existing addresses first

Several sources, combined.

Crawl the current site, export the pages from analytics, take the addresses from your search console and add the sitemap. Any single source misses pages, and the ones it misses are frequently the old ones with the most links.

3. Map every address to the closest equivalent

The rule that keeps value.

Each old address should point at the new page covering the same thing. Where nothing equivalent exists, choose the nearest relevant page rather than defaulting everything to the home page, which loses most of the benefit.

4. Know which pages you cannot afford to lose

Prioritise within the map.

Identify the pages with the most traffic, the most inbound links and the most revenue. Those deserve individual attention and individual checking, while the long tail can be handled by pattern rules.

5. Preserve the content, not only the addresses

A frequently forgotten half.

A redirect to a page with a fraction of the original content still loses rankings. If the old page ranked because it answered something thoroughly, the new one needs to answer it at least as well.

6. Test the redirects before launch

Where staging earns its cost.

Run the full list against the staging environment and confirm each one arrives at the intended page in a single hop. Finding forty errors the day before is inconvenient; finding them a week after is expensive.

7. Check the technical settings on the new site

The recurring launch disaster.

Staging environments block crawling, and that block goes live with everything else. Verify the robots file, the no-index tags, the canonical tags and the sitemap within the first hour.

8. Update internal links rather than relying on redirects

Otherwise every path has a hop in it.

Menus, in-content links and footers should point at the new addresses directly. Leaving them to be redirected works, slowly, and builds the chains that cause problems at the next migration.

9. Watch the data closely for a month

Recovery is normal; decline is not.

Some fluctuation in the first weeks is expected. Watch the index coverage report, error logs and search performance daily at first, because most problems are visible within days and are far cheaper to fix while the site is still fresh in everyone's mind.

Keep the old site accessible somewhere until you are confident. Being able to look at what a page used to contain, when something ranked well before and does not now, saves a great deal of guessing and occasionally recovers the page outright.

Conclusion

Treat the redirect map as the deliverable that determines whether the migration succeeds.

Assemble the address list from a crawl, analytics, search console and sitemap together, map each old address to its closest equivalent rather than to the home page, identify the pages you cannot afford to lose and check them individually, preserve the content and not merely the addresses, test every redirect against staging before launch, verify robots files and no-index tags within the first hour of going live, update internal links directly instead of relying on redirects, monitor the data daily for a month, and keep the old site available for reference.