Redesign Your Website Without Losing Search Traffic

The first few weeks after a website relaunch are usually rough to look at in the analytics: organic traffic drops, form submissions slow down, and search queries that used to bring in customers stop bringing in anyone at all. The cause is rarely the new design — it's that nothing bridges the old site's URLs to the new ones.

Google only has one way to carry a page's accumulated ranking, its inbound links, and its click history over to a new address: a permanent, server-side redirect. Skip that step, or do it halfway, and even a flawless redesign starts back near zero in search.

Why the loss is about addresses, not design

Every indexed page has its own URL, and Google spends years attaching weight to that exact address — inbound links, click history, content stability. When a relaunch changes the URL structure (say, /services/design becomes /our-work/design), that accumulated weight does not follow automatically. As long as the server keeps answering "page not found," Google gradually drops the old address from its index — and the weight attached to it goes with it.

There is one way around this: explicitly map every old URL to its new equivalent before launch. That list is a redirect map, and it belongs at the start of the project, not something bolted on after the design is finished.

Before the move: building the redirect map

1. Pull a complete list of the old URLs

Gather it from three sources: the old site's sitemap, server logs (which addresses actually received traffic), and Google Analytics' most-visited-pages report. Don't stop at the navigation menu — a lot of old blog posts and product pages never appear there but still pull in search traffic.

2. Match each URL to a specific new one

Pointing every old URL at the homepage is the most common mistake teams make. Google does not treat that as a genuine redirect, because there is no topical relationship between the old page and the new target. Each URL should map to the closest matching new page; when there is no exact equivalent, the nearest category page is the next best choice.

3. Use a permanent redirect, and never chain them

Google's own documentation is direct about this: use permanent 301 or 308 redirects wherever possible — a temporary (302) redirect sends the wrong signal when the address is changing for good. The same documentation also warns against pointing one redirect at another, i.e. chaining them: every extra hop both slows the visitor down and makes the page harder for a crawler to follow.

Launch day: the release checklist

Once the map is ready, launch day itself comes down to a handful of small steps that have an outsized effect on the outcome:

• Remove any noindex tag or blocking rule left over from robots.txt on staging — that block exists to keep an unfinished site out of search, and it is the most common thing left in place after launch.
• Confirm every new page carries its own self-referencing canonical tag.
• Submit the new sitemap immediately; only remove the old one once Google has picked up the new addresses.
• Walk the redirect map line by line by hand — one typo in an automated rule can turn an entire section into "page not found."
• Test every redirect by opening the old URL directly and confirming it lands on the right new address with a 301 or 308 response — do this before publishing, not after.

The detail everyone forgets: the site's own internal links

The redirect map usually gets built with external links and search rankings in mind, but a site's own internal links matter just as much. The main menu, the footer, a "related posts" block, and cross-links between old blog posts can all still point at the old addresses. Every click then lands on a redirect first and the real page second, which both slows the visitor down and forces the crawler to take an extra hop to reach the page. The fix is straightforward: update internal links to the new address directly, rather than leaning on the redirect to carry the click.

This is easy to miss specifically when the platform changes (moving off a page builder into custom development), because finding hundreds of internal links on the old platform by hand takes time — and it's exactly where the "small" details end up making the biggest difference.

After the move: what to watch, and for how long

Submit a change of address request in Google Search Console — the tool built specifically for announcing a domain move. From there, watch the Coverage and Performance reports: they show which old URLs are still indexed and which have already been replaced by the new ones.

The transition doesn't happen overnight. Google describes a transition period of a few weeks for a small-to-medium site — traffic swings during that window are normal, not a sign of a permanent drop. And don't pull the redirects too early: the same documentation recommends keeping them in place for at least a year, because old links and browser bookmarks take that long to catch up with the new address. To confirm the new site's speed hasn't slipped after the move, our free SEO and speed audit tool is a quick way to check.

A new site does not inherit the trust the old one spent years earning — the only way to carry it over is a properly built redirect map.

When it's worth bringing in help

For a corporate site with a few dozen pages, you can realistically build this map yourself in a spreadsheet. But when the platform changes (moving off a page builder into custom development), when an online store has hundreds of product pages, or when the old site's URL structure was never documented anywhere, doing it by hand sharply raises the odds of a mistake — and every skipped row is a lost page.

For example, when an online store moves off a page builder (Tilda, WordPress) onto custom development, product URLs usually change format entirely — /product-id-123 becomes something like /catalog/category/name. Matching a hundred and fifty product pages by hand can take a few days; skipping the step costs months of lost traffic instead.

In those cases, it costs less to hand the technical transition to a development team that plans it before launch than to fix it afterward.