Website Redesign: When It's Worth It and How Not to Lose Your SEO

There is a story that keeps repeating: a company rebuilds its website, feels proud of the result, and three weeks later notices organic traffic has halved. The new site is prettier, faster, more modern, and gets fewer people.

That does not happen because redesigns are dangerous. It happens because most redesigns treat SEO as something that "comes along with it". It does not. What exists on the old site is an accumulated asset, URLs Google already knows, links from other sites pointing at them, history. If you do not transfer that asset deliberately, it evaporates.

Five signs it is time

A redesign should not start with "it looks dated". It should start with a measurable problem. Five signs justify one:

1. The site does not work well on a phone. Not "has a mobile version", works. If most traffic comes from phones and the experience there is bad, everything else is secondary.
2. You cannot publish without help. When adding a page or changing a price becomes a developer ticket, the site turns into a marketing bottleneck and stops keeping pace with the business.
3. Performance is bad for structural reasons. If you have already optimised images, already cut scripts, and the metrics still refuse to move, the foundation is the problem. Worth measuring properly before concluding, as in Core Web Vitals explained.
4. The site describes a different business. Services you no longer offer, an audience that changed, old positioning. Here the problem is content and structure, not aesthetics.
5. The technology lost support. A version that no longer receives security fixes and cannot be updated without breaking. That is risk, not taste.

If none of those five apply and the complaint is purely visual, consider restyling the presentation layer instead of rebuilding everything. It is cheaper, faster, and it does not put SEO at risk. If what is missing is a routine, the problem may be a different one, covered in website maintenance.

Audit before touching anything

This is the stage that separates a redesign from an accident. Before any layout work, you need to know exactly what the current site has and what it is worth.

Gather six things:

• The full URL list. Crawl the whole site and export every URL, with status, title, description and main heading. Include what is not in the menu: old pages, campaign landing pages, PDFs.
• Traffic per URL. From Analytics, twelve months. This shows which pages actually work.
• Search Console queries and pages. Impressions, clicks and position per page, also twelve months. This is where you find the page nobody remembered that brings in half the organic traffic.
• External links. Which sites point at you, and at which specific URLs. Every one of those URLs becomes untouchable in the plan.
• Conversions per page. High traffic with no conversion is worth less than moderate traffic that generates enquiries.
• The current technical state. Sitemap, robots, canonicals, structured data. It serves as the baseline for comparison later. The technical SEO checklist covers what to look at.

Save all of it in a dated file, before touching the site. If something goes wrong later, that file is the only way to know what existed.

The 301 redirect map

This is the step almost everyone skips, and it is the one that causes the drop.

When a URL stops existing and nothing points to the new path, three things disappear together: the position it held, the value of the external links pointing at it, and the visitor who clicked an old result. Redirection preserves all three.

301 and 302 are not interchangeable. A 301 is a permanent redirect: it tells the search engine the address changed for good, that it should replace the old URL with the new one in the index, and transfer the accumulated signals to the destination. A 302 is temporary: it says the original URL is still the right one and should stay indexed. Using 302 in a redesign is asking Google to keep indexing a URL that will never exist again.

On what happens to a redirected URL's authority: Google treats a 301 as consolidation. The old URL's signals are attributed to the new one, and current documentation does not describe a loss of value caused by the redirect itself. What causes loss are the mistakes around it:

• Redirecting everything to the home page. The most common error. When the destination has no content relationship with the source, the search engine may treat it as a soft 404 and simply discard the signals. Always redirect to the closest equivalent.
• Chains. A leads to B, which leads to C, which leads to D. Every hop adds latency and a chance of breaking. Rework the map so each source points straight at the final destination.
• Loops. A points to B and B points to A. That route becomes unreachable.
• Keeping redirects for a month. Rule of thumb: keep them for at least a year. External links and bookmarks live far longer than the search index.

The map itself is a spreadsheet with two columns: old URL and new URL. One row per URL from the audit. No exceptions, no "nobody visits that one". If a page genuinely has no successor, the deliberate choice is to return 410, signalling permanent removal, and that should be the exception, not the rule.

Preserving the URLs that already rank

The best redirect strategy is not needing one. If a URL brings traffic and conversions, the default decision is to keep the address exactly as it is, even if the new URL scheme is prettier.

URL aesthetics are not worth the risk. Swapping /services/web-design for /what-we-do/websites buys no search benefit and costs a redirect you will carry forever.

Beyond the address, three things have to survive the change on any page that already ranks:

1. The substantive content. If a page ranks, it answers something. A redesign that cuts eighty per cent of the text in the name of minimalism removes exactly what made the page findable.
2. The terms that already work. Rewriting is fine; replacing the entire vocabulary with "more modern" synonyms is not.
3. The heading hierarchy and internal structure. Including the links from other pages on the site that point at it.

One specific technical caution: if the new site is built on a JavaScript framework, make sure the content arrives rendered in the HTML. A technically beautiful redesign that serves an empty page to the crawler loses everything at once, the mechanism is explained in why a React site does not show up on Google.

What to migrate, rewrite and retire

Use the audit data to sort every URL into one of three piles.

Two situations deserve attention. If you have several old pages competing on the same topic, consolidating into one strong page and redirecting the others into it is usually a gain, the content adds up instead of splitting. And if a page has external links but irrelevant content, it is a candidate for a rewrite at the same address, never for deletion.

Launch checklist

On switch day, in order:

1. Block indexing on staging, and confirm the block was not copied to production. Going live with a global noindex is the classic launch accident.
2. Load the redirect map and test a large sample, every high-traffic URL, one by one, confirming a 301 status and the correct destination.
3. Confirm valid HTTPS and redirects from HTTP to HTTPS, and from www to non-www or the reverse, always onto a single canonical version.
4. Check canonicals point at their own final URL and never at the old domain.
5. Generate and submit the new sitemap in Search Console. Keep the old sitemap reachable for a few weeks: it helps the crawler find the old URLs and process the redirects.
6. Verify Analytics and tags are installed on the new site, and that consent is still being respected.
7. Test every form for real, from a phone, with an external email address.
8. Run a full crawl of the new site looking for 404s, redirect chains, internal links still pointing at old URLs, and orphan pages.
9. Check unique titles and descriptions on migrated pages, and valid structured data.
10. Keep a complete copy of the old site, files and database, before switching anything off.

The next four weeks: what to monitor

After launch, fluctuation is normal. Panic does not help, and neither does not looking.

Week 1. Check Search Console every day. Focus on crawl errors and not-found pages. Every 404 that shows up is a missing line in the map, fix it immediately. Look at server logs too, if you have access: they show what the crawler is actually requesting.

Week 2. Track index coverage. You want to see new URLs entering and old ones moving into the redirected state. Impressions tend to wobble here, which is expected while the index reorganises.

Week 3. Compare position per query against the audit baseline. Look for a pattern: if everything dipped a little, reindexing is in progress. If only a few specific pages fell hard, investigate those pages, it is almost always a wrong redirect, cut content, or a canonical pointing at the wrong place.

Week 4. Compare organic traffic and conversions with the same period last year, not with last month, so seasonality is discounted. If the picture is still worse and you have ruled out the technical causes, the problem is probably removed content, and the fix is to put the content back, not to wait.

A realistic reference point: a well-executed migration usually goes through a few weeks of fluctuation before settling. A badly executed one does not recover on its own with time, it gets worse, because the index keeps consolidating the wrong state.

If you are planning a redesign and want to replace the site without giving up what already ranks, see our portfolio and talk to ALB Seven.