Skip to content

Website Migration Without Losing Search Traffic

How to migrate a B2B website without losing search traffic: URL inventory, redirect mapping, content parity, launch checks and monitoring.

Two floating translucent platforms, one dim and one bright, joined by glowing blue bridges of light carrying small cubes from the old to the new

The short answer

To migrate a site without losing search traffic, inventory every URL that earns visits or links, map each one to its closest new page with a permanent redirect, keep or improve the content and metadata on pages that perform, and test the redirects before launch. After launch, submit the new sitemap, watch for errors and fix broken redirects quickly. Most traffic losses come from missing redirects and content cut without a plan.

Key takeaways

  • Inventory every URL that has traffic, links or rankings before you redesign anything.
  • Map old URLs to their closest new equivalents one to one, never all to the homepage.
  • Keep the substance of pages that perform, even when the design changes.
  • Monitor errors and rankings for several weeks after launch and fix fast.

A redesign or platform change is often the moment a firm loses search visibility it spent years earning. The new site looks better, but pages disappear, URLs change without redirects, and content that ranked is trimmed to fit a new layout. Traffic drops, and it can take months to recover.

Most of that loss is avoidable. Accumentum plans migrations as part of our web experiences work, and the steps below are the ones that protect visibility.

Inventory everything first

Before the new site map is final, build a complete list of current URLs. Pull them from several sources, because each one misses something.

  • A crawl of the live site
  • Your current XML sitemap
  • Pages that received visits in your analytics over the past year
  • Pages that other sites link to
  • Pages that appear in search results for your important terms
  • Files such as PDFs that people link to directly

Mark each URL with its traffic, links and purpose. This becomes the migration sheet. Pages with no traffic, no links and no purpose can be retired. Everything else needs a destination.

Map redirects one to one

For each URL that matters, choose the closest page on the new site and set a permanent redirect. The goal is that a person or a search engine following an old link lands on a page that serves the same need.

  • Map old service pages to new service pages, not to a general services page.
  • Map old articles to their new URLs, even if the article was edited.
  • Avoid sending everything to the homepage. Search engines tend to treat that like a missing page.
  • Avoid chains, where one redirect points to another. Point old URLs straight to the final destination.
  • Keep redirects in place long term. Old links in emails, documents and other sites keep working for years.

Protect what performs

Design teams often shorten content during a redesign. That is fine for weak pages but risky for pages that rank. For your top pages, keep the substance: the topics covered, the questions answered and the headings that match how people search. Improve them if you can, but do not cut what made them useful.

Carry over titles, descriptions, headings, image alt text and structured data. Check that internal links on the new site point directly to new URLs, not through redirects.

A migration checklist

  1. Full URL inventory. Combine crawl, sitemap, analytics, links and search data.
  2. Migration sheet. Each old URL, its value, its new destination and its status.
  3. Redirect rules. Permanent, one to one, no chains, tested in a staging environment.
  4. Content parity. Top pages keep or improve their substance and headings.
  5. Metadata. Titles, descriptions, canonicals and structured data carried over and checked.
  6. Internal links. Updated to point to final new URLs.
  7. Staging protection. The test site is blocked from indexing, and that block is removed at launch.
  8. Launch day. Submit the new sitemap, test a sample of redirects live and check robots rules.
  9. Monitoring. Watch crawl errors, top page rankings and traffic for several weeks.

The launch day mistakes

Two problems cause a large share of failed migrations. The first is launching with the staging block still in place, which tells search engines not to index the new site. The second is redirect rules that work on staging but not on the live domain because of protocol or trailing slash differences. Test both on the live site within the first hour.

Changing domains or structure

Some migrations change more than the design. A firm may move to a new domain after a rebrand, merge two sites after an acquisition or reorganize URLs to match a new offer structure. Each of these raises the risk.

  • New domain. Redirect every old URL to its equivalent on the new domain, keep the old domain registered and redirecting indefinitely, and update profiles and listings you control so they point to the new site.
  • Merging sites. Decide which pages survive, which merge and which retire. Merged pages should combine the useful substance of both, not keep only the shorter one.
  • New URL structure. Keep URLs short and stable. Avoid putting dates or internal codes in them, so you do not need another migration later.

Avoid changing everything at once if you can. Moving domain, platform, design and content in one launch makes it hard to know which change caused a problem. If timing forces a combined launch, keep the migration sheet especially detailed.

Who should be involved

Migrations go wrong when they are treated as a design or development task alone. Bring in the person responsible for search visibility from the start, not the week before launch. Involve content owners so they can confirm which pages matter to buyers. Include whoever manages analytics so tracking moves with the site. Agree on a launch day plan with named people for redirects, sitemap submission, robots rules and monitoring, and schedule the launch for a time when that team is available for the following days.

Where to start this month

If a migration is on the calendar, start the URL inventory now, even before design begins. Export every indexed page, your top landing pages from analytics and the pages other sites link to most. Mark each one as keep, merge or retire, and name an owner for the decision. This work takes longer than people expect, and doing it early means redirects and content choices are settled before the launch week, when there is never enough time. It also shows the design team which pages carry real search value and deserve care.

After launch

Some movement in rankings is normal while search engines process the change. Watch for patterns rather than single days. If a group of pages drops and stays down, check their redirects, content and indexing status. Keep the migration sheet as a living document, and log every fix so you can explain what happened later.

Our technical SEO guide covers the foundations your new site should have. If you are planning a rebuild, request a Digital Growth Assessment before the design is locked.

Frequently asked questions

Why do sites lose traffic after a redesign?

Most losses come from URLs that change without redirects, content that ranked being cut or merged without a plan, and technical mistakes at launch such as leaving a staging block in place.

Should old pages redirect to the homepage?

No. Redirect each old URL to the closest equivalent new page. Sending many URLs to the homepage tends to be treated like missing pages and frustrates visitors.

How long should redirects stay in place?

Keep them long term. Old links live on in emails, documents, bookmarks and other websites, and removing redirects breaks those paths.

How long does it take to see if a migration worked?

Some ranking movement is normal in the first weeks. Monitor errors and top pages for several weeks and look for sustained patterns rather than daily swings.

Related reading and services

Want a second pair of eyes?

Tell us what you are working on. We reply personally to every inquiry.