Moving a Website Without Losing Search Traffic

Traffic is lost in the URLs, not the design

When a business moves to a new website and its search traffic falls off a cliff, the usual suspect is the new design. It is almost never the design. It is that every page search engines knew about now answers with a 404, or with a redirect to the homepage, and the rankings those pages had earned go with them.

Search engines rank URLs, not businesses. A page that has ranked for "wedding card printers in Nagercoil" for three years has a history attached to that exact address. Change the address without telling anybody, and from the search engine's point of view the old page has vanished and a new, unknown page has appeared. It may eventually rank again. It starts from nothing.

This applies to more moves than people expect:

• A redesign that changes the URL structure, for example /services.php?id=4 becoming /services/printing/.
• A platform move, such as WordPress to a static site, or a page builder to a custom build.
• A domain change, including a rebrand or a move from a .in to a .com.
• Switching between www and the bare domain, or from HTTP to HTTPS.

Each one is survivable. What decides it is a spreadsheet most projects skip.

The cheapest option is not moving the URL

Before mapping redirects, ask the question that removes most of them: does this URL actually need to change?

A new design does not require new addresses. If the old site had /about-us/ and the new one wants /about/, that is a cosmetic change with a real cost and almost no benefit. Keeping URLs that already rank is the single most effective migration decision you can make, and it is free.

We follow this on our own site. When the BitsSolved blog moved from hand-written HTML pages to Markdown files and a generator, the two posts that were already indexed kept exactly the URLs they had. The generator derives each address from the filename precisely so that those addresses cannot drift. Whatever else changed underneath, a search engine requesting the old URL got the same article back with a 200.

Change a URL when the old one is genuinely wrong: it contains a session ID, a year that dates the page, or a structure you cannot maintain. Not because the new framework prefers a different pattern.

Build the redirect map before launch day

For everything that does have to move, you need a map: one row per old URL, with the new URL beside it. It is tedious, and it is the whole job.

All of this assumes you can still get at the old site, its DNS and its registrar account. If you cannot, because whoever built it holds them, sort that out first: getting your website back from a previous developer is the order to do it in, and the redirect map can wait until you have the domain.

Collect the old URLs from more than one source, because no single source has all of them:

1. The old sitemap. Check it with the sitemap checker before the old site goes away, and save a copy.
2. Search Console. The Pages and Performance reports show the URLs Google has indexed and the ones that actually earn clicks.
3. Your analytics. Landing pages over the last year, sorted by traffic.
4. Backlinks. Pages that other sites link to carry value even if they get little traffic.

Then map each old URL to the most relevant new page. Not the nearest category, not the homepage: the page a visitor following the old link would expect to land on.

The rows that do not map cleanly are the important ones. Sort the list by traffic and spend your attention at the top.

301, 302 and 410: say what you mean

HTTP status codes are how your server tells a crawler what happened to a URL, and in a migration three of them do almost all the work. If you need to look one up, the HTTP status code reference explains each in plain terms.

The difference between 301 and 302 matters more than it looks. Google's documentation on redirects and Google Search says a permanent redirect is used as a signal that the target should be the canonical URL, and a temporary redirect is not. A migration done with 302s keeps telling Google the old URLs are the real ones, and it is an easy mistake to make: Apache's own Redirect directive, for example, issues a temporary 302 unless you ask for a permanent one.

Do redirects on the server. A meta refresh or a JavaScript redirect works for a visitor, but Google's guidance is to use them only when server-side redirects are not possible.

Do not redirect everything to the homepage

The tempting shortcut for unmapped URLs is a catch-all that sends them to the homepage. It feels tidy, and it is the wrong answer.

Google is explicit about it. Its help article on 404 errors says that redirecting users to another page, such as the homepage, instead of returning a 404 can be problematic, and that such pages are called soft 404s.

For content that is genuinely gone, let the URL say so. A 404 is fine. A 410 is more precise, because it says the removal was deliberate. Be honest about what the difference buys you: Google states that it currently treats 410 the same as 404. The value of a 410 is that it documents intent, in your server configuration and for anyone reading a crawl report, rather than any ranking effect.

That is the approach this site took with what was left of an earlier WordPress install. Paths like the default /blog/hello-world/, the date archives, and the category, tag, author and feed URLs return 410 Gone, by four pattern rules in the server configuration. Nothing there was worth redirecting, so nothing pretends to be.

Keep chains short and redirects long

Two rules for the redirects themselves.

One hop, not a chain. If the site has moved before, old redirects may point at URLs that now redirect again. Google's crawlers follow up to ten hops, but every hop adds a round trip for the visitor and another place for the chain to break. Point every old URL straight at its final destination, and run the important ones through the redirect checker to see the full chain hop by hop.

Keep them for a long time. Google's site move guidance says to keep redirects for as long as possible, and generally at least a year. In practice, keep them indefinitely. A redirect rule costs nothing to leave in place, and backlinks from other sites do not update themselves.

Sitemaps, robots.txt and Search Console

With the redirects in place, tell search engines what changed rather than waiting for them to discover it.

• Publish a sitemap of the new URLs only. No redirected or removed URLs in it. Google suggests submitting the old sitemap as well for a while, so it can see the old URLs redirect, and removing it once the move has settled.
• Do not block the old URLs in robots.txt. It sounds sensible and it breaks the migration, because a crawler that is not allowed to request the old URL never sees its redirect. Check the live file with the robots.txt checker, and look especially for a staging Disallow: / that came across with the new build.
• Use the Change of Address tool only for a domain move. It exists for moving from one domain or subdomain to another. Google says it is not needed for HTTP to HTTPS, for switching between www and the bare domain, or for path changes within the same domain.

What to watch after launch

Rankings will move for a while. Google says that for a medium-sized site it can take a few weeks or more before the new URLs replace the old ones in results. That is normal. What is not normal is a fall that keeps going.

For the first few weeks, check:

1. The Pages report in Search Console. Watch for a rise in "Not found (404)" and "Soft 404" against the new site.
2. The top twenty old URLs, by hand. Request each one and confirm it returns a single 301 to the right page. The HTTP header checker shows the exact status and Location header the server sends.
3. Your server's 404 log. Real visitors and real crawlers will find the URLs your map missed. Add redirects for the ones with a sensible destination.
4. Organic landing pages in analytics. Compare them to the same period before the move, page by page rather than as one total.

Most migration damage is visible within a fortnight, and almost all of it is fixable by adding rows to the map.

The takeaway

A website move costs rankings when URLs disappear without explanation. Keep the addresses that already rank, map every other one to its closest real equivalent, use permanent redirects on the server, let genuinely removed pages return 404 or 410, and watch the reports for a month.

If the site already ranks well locally, our guide to local business website design covers the structure worth keeping through a rebuild.

If the move is part of a wider decision about whether to spend on search at all, is SEO worth it for a small business is the free test to run before you commission anything.

If you are planning a rebuild and want the migration handled as part of it, that is web application development with SEO built into the plan. If the move already happened and traffic fell, start with website fixes and maintenance: the old URLs can usually still be recovered.