Redesigning a website without losing your SEO

There is a specific kind of silence that follows a website redesign. Traffic does not crash — it just stops growing. The enquiry form still works. Nothing is visibly broken. And four months later someone finally asks why it used to bring in three calls a week and now brings one.

The rankings did not disappear. They were replaced. By pages that were never submitted, at URLs nobody redirected, with metadata nobody checked.

Here is how to do a redesign without that happening.

Step one: audit before you touch anything

Before opening a design file, export the complete picture of what currently exists:

• Every indexable URL, with its current status code
• Current title and meta description for each
• Which URLs have inbound links, and how many
• Which URLs actually generate traffic and leads
• The current keyword footprint — what the site is ranking for

Google Search Console and your analytics both export this. So does a crawler. Do not skip this step, because it is the only moment where you know for certain what you have.

The output is a simple list of pages, and each one gets one of three labels: keep, improve, or retire.

Step two: decide the URL structure before you design

This is the decision that matters most, and it is the one teams make too late.

A URL should change only when there is a reason. Renaming /services/plumbing to /plumbing-services because it reads better on a slide deck is not a reason. It is a reason to lose a ranking.

When you do need to change a URL — a real restructure, a service renamed, a location consolidated — decide it before the design phase and hold it. Every late URL change means another round of mapping and another set of redirects to verify.

One useful default: keep the URL structure exactly as it is unless the current structure is genuinely broken or actively harmful. A redesign should change how the site looks and works, not where it lives.

Step three: map every redirect

This is the single highest-value technical task in a redesign, and the one most often faked.

Build a redirect map in a spreadsheet before the build starts. One row per old URL, one row per new URL, one row for the reason.

Then, at launch:

• Every old URL that still has a page gets a 301 permanent redirect to its new equivalent.
• Every old URL without a new page gets a 301 to the closest relevant new page — never to the homepage. Redirecting forty dead pages to the homepage is how you end up with a site Google distrusts.
• Nothing gets left returning a 404, a soft 404, or a redirect loop.

Test the whole map after launch, not a sample. Automated crawlers will find loops and chains; manual spot checks will not.

Step four: preserve the metadata that works

For every URL you are keeping, check whether its current title and description are earning clicks. If they are, keep them. A redesign is not a licence to rewrite everything — it is often a licence to fix what is broken and leave the rest alone.

If a page is genuinely changing topic, write new metadata. If it is changing only in layout, keep the old metadata and let the content catch up gradually.

Step five: keep the technical foundation sound

The things that quietly break during a redesign, in rough order of how often I see them:

• Titles and headings rendered client-side. If your framework renders headings after JavaScript loads, some crawlers will not see them. Render them in the HTML.
• The old URL structure still running underneath. A site that serves /old-path with a canonical tag pointing to /new-path is fine. A site that serves both with no canonical is a mess.
• Images without alt text. Every image needs descriptive alt text. It is an accessibility requirement and a relevance signal at the same time.
• Structured data dropped in the rebuild. If the old site had LocalBusiness or Article schema and the new one does not, you have deleted a ranking signal for no reason.
• A sitemap that was never regenerated. Regenerate it, and make sure every canonical URL is in it.
• No robots.txt. Point it at the live sitemap.

Step six: the launch-day checklist

Do all of this on the same day, in this order:

1. Put the new site live.
2. Submit the new sitemap in Google Search Console.
3. Check that every redirected URL returns a 301 and lands on the right page.
4. Crawl the whole site for 404s, redirect chains and loops.
5. Verify the analytics tracking is firing — a redesign that breaks tracking is a redesign that cannot be measured for four months.
6. Verify Search Console has no new "page not indexed" errors.
7. Check the top twenty landing pages from the old site. Confirm each one is live, indexed and has the right title.
8. Submit the sitemap to Bing as well.
9. Watch Search Console for two weeks before changing anything else.

That last point matters. The temptation after launch is to start "improving" based on three days of data. Wait a fortnight. Search takes time to re-crawl and re-evaluate, and the data you act on before then is noise.

The two mistakes that cost the most

Rebuilding the site on a different platform mid-redesign. Changing the design and the technology at the same time means that when something breaks, you have two suspects and no way to isolate it. Change one thing. Redesign first, migrate later if you must.

Redesigning during a seasonal trough, or worse, during your busiest month. The post-launch dip in organic traffic is normal, whatever the redesign. If you launch in November, you will see the dip and panic in January. If you launch in February, you will see the dip and panic in March. Launch when the consequence of a dip is smallest.

How long the recovery takes

For a well-executed redesign with a complete redirect map and preserved metadata: two to four weeks for re-indexing, six to twelve weeks for rankings to recover and then exceed where they were.

For a redesign done without an audit or redirect map: three to six months, if it recovers at all.

That is the real cost comparison. The redesign itself might be $3,000 to $6,000. The difference between a managed migration and an unmanaged one is usually one week of careful preparation — and it is the single highest-return week available in a web project.

We run the pre-launch audit as part of every website project, because the alternative is handing a client a site that quietly went backwards. Our web design service page describes the build and the launch process, and redesigning an existing site is covered in the same package. If you want a second opinion on a site you already have, book a 30-minute chat.