Changing platforms without losing traffic

A week after launch, the new website is often better at everything you can demonstrate in a meeting: it’s faster, easier to update and reflects the new visual identity. Yet visits from Google may have fallen. The reason is usually the same: no one found out what the old website was actually doing well.

The migrations I’ve worked on have ranged from large, complex sites with hundreds of thousands of records to small websites. Size has determined how much work each move required, but whether visitors would follow has been a question every time. On a large site, it involves thousands of URLs; on a small one, perhaps a dozen pages. And if those are the pages generating enquiries, just as much is at stake.

When a website changes platforms, its pages move, and that’s where traffic can be lost. Google indexes and evaluates each page by its address (URL), and everything that contributes to its ranking — links from other websites, the search terms it answers and how visitors have used it — is tied to that address. If a page gets a new URL without a permanent redirect (a 301, which automatically sends visitors and search engines from the old address to the new one), that connection breaks and Google treats it as a new page. It then has to build its ranking from scratch.

That’s what makes this different from a normal update, where pages get a new look but keep their URLs. During a platform migration, every URL, link and signal needs to end up in the right place. Otherwise, the pages that brought in the most traffic start again from zero.

Google’s own guidance on website migrations says the same thing: redirect old URLs to new ones using permanent redirects, and keep them in place for as long as possible, generally at least a year.

We see the same four causes time and again.

1. The first is that no one has audited the old site. The specification describes the new website in detail but says nothing about the old one, so no one knows which pages bring in traffic, which have links from other websites or which forms generate enquiries — until traffic has already fallen.
2. URLs often change without anyone making a conscious decision. A new platform has its own rules for building URLs, so categories get renamed, folders disappear and extensions are added. Individually, the changes are small. Together, they can mean hundreds of pages get new URLs.
3. Redirects, which are meant to salvage what they can, are often left until last. They’re added the week before launch by someone who doesn’t know which pages matter, so many end up pointing to the homepage — something Google may treat as a missing page, known as a soft 404. Others form chains, where an old URL takes several hops before reaching its destination. This slows the site down and is something Google explicitly advises against.
4. Finally, settings from the staging environment can carry over. A site built at a staging URL is usually blocked from search engines, and that block needs to be removed at launch. If it’s forgotten, the site won’t appear in search results at all, however good it is.

A migration error often shows up in traffic within the first few days, but how long the impact lasts depends on the scale of the error and how quickly someone spots it. Sometimes the site recovers in a few weeks. Sometimes it takes months, and sometimes the rankings never return because a competitor has taken those positions in the meantime.

The cost rarely shows up in a technical report. It shows up as fewer enquiries, often only when the sales team starts wondering where they’ve gone.

If you haven’t measured it before the move, you can’t compare it afterwards. Start by recording where things stand today:

• Pages that receive visits from Google, with click counts for the past twelve months (from Search Console).
• Search terms and rankings for the pages that matter most.
• Pages with links from other websites.
• Forms, phone link clicks and other actions that generate business, and the pages where they happen.
• A complete crawl of all URLs, so no page is overlooked.

The result is a list of what must not be lost, and that list is the foundation for every step that follows.

URL structure belongs in the planning stage, not the build. Decide early which pages will keep their URLs and which will get new ones. The more URLs you keep, the fewer redirects you need and the less can go wrong. Don’t change URLs just because the new platform does so by default: most systems can be configured to keep the existing structure.

Every old URL that ranks or has links from other websites should point to the new page that answers the same question. The map should meet four requirements:

• Page to page. Not everything to the homepage.
• One hop. Straight from the old URL to the new one, with no intermediate steps.
• Permanent (301). Not temporary.
• Tested before launch on a copy of the site, against the entire map.

Pages that are removed entirely should redirect to the closest relevant page on the same topic. If there isn’t one, a clear 404 response (page not found) is better than a redirect to the wrong place.

It’s tempting to rewrite all the copy while changing platforms, but leave the pages that bring in traffic alone. Move them first with the same headings and content, then improve them once the migration has settled. That way, you’ll know what caused any change in traffic — something you can’t know if the platform and copy change on the same day.

What gets lost in a migration is often what visitors don’t see but search engines read:

• Page titles and meta descriptions.
• Headings and internal links.
• Image alt text.
• Canonical tags (which identify the preferred URL when the same content appears at several addresses).
• Language versions and hreflang (which identifies each language version), if the site is multilingual.
• Structured data.
• A sitemap with the new URLs, and a robots.txt file that allows search engines access.
• Tracking: Analytics, Tag Manager and conversions.

Run these checks on the day the site goes live, not the following week. Every day with an error costs you traffic:

1. Search engine blocks have been removed, both in robots.txt and in the platform settings.
2. The most important old URLs reach the right page in one hop.
3. The new sitemap has been submitted in Search Console.
4. The pages on the list from step 1 return a 200 response (page exists) and have the correct title.
5. Forms and tracking work, tested as a regular visitor rather than while logged in.

The first few weeks will reveal whether anything has gone wrong. Track clicks and impressions in Search Console day by day, compare them with an equivalent period before the move, and pay particular attention to the pages on the list from step 1.

Someone needs to own this monitoring and have the authority to get changes made. An error spotted on day four is a small problem. The same error discovered on day forty has had time to become expensive.

You can ask these questions during public procurement, before you’ve chosen a supplier:

1. How do you find out which pages bring in traffic today?
2. Who decides the URL structure, and when?
3. Will we receive the redirect map before launch so we can review it?
4. How do you test that it works?
5. What happens to page titles, headings and internal links?
6. Who monitors traffic after launch, and for how long?
7. What do you do if traffic falls?

An agency that gives specific answers to these seven questions has done this before. If it says instead that search engine optimisation comes at a later stage that’s a warning sign — and it’s also mistake 10 in ten mistakes we see in website procurement.

Yes, perhaps especially then. Leaving a platform that is outdated, insecure or expensive to maintain is often the right decision, but even the right decision can be implemented badly. We cover how to choose a new platform in the CMS guide. This article is about making the move without losing what you’ve already built.

Our guide Website procurement takes you through the whole process, from the brief and target audience to the specification. Download the guide

• Google Search Central: Site moves with URL changes
• Google Search Central: Redirects and Google Search