How to redesign a website without losing your rankings

Your site is six or eight years old and it looks it. You have been putting the replacement off, and not because of the money. It is because that tired old site sits at position three for the phrase that brings you most of your work, the person who built it stopped answering emails in 2021, and nobody can tell you which parts of it are load-bearing. Every redesign quote arrives with the same unspoken question attached: what happens to the phone?

Here is the answer. Redesigns lose rankings for three reasons and almost no others. URLs change and nobody maps them. The copy that earned the rankings gets tidied away to suit the new layout. The new site is slower than the old one. Keep the addresses, keep the words, ship nothing heavier, and a redesign is a non-event: clicks down 5 to 20 per cent for two to four weeks while Google recrawls, then back to where you were.

A badly handled one can shed 40 per cent or more and never fully get it back. The arithmetic is worth doing with your own numbers. Say search brings you 25 enquiries a month, you win a third of them, and an average job is £900. That is about £7,200 of work a month, so a 40 per cent drop costs you roughly £2,900 a month, or about £34,000 over a year, on a redesign that cost a few thousand.

None of this is Google disliking your new design. It has no opinion on your hero section. It re-evaluates the pages that changed, and if what changed is the thing it was ranking you for, the ranking leaves with it.

The three things that actually cause the loss

1. The URLs move and nobody maps them

The big one, and it is nearly always a platform change. WordPress serves /services/mot-brighton/. The new Webflow build serves /mot-brighton. Ninety pages become ninety 404s the hour the DNS flips.

Trailing slashes count as different addresses. So does casing. So do the old query-string URLs like /?p=142 that still have links pointing at them from a directory listing somebody built in 2015. Image files count too, which is why sites that rebuild their media library quietly lose whatever image search was sending them.

2. The content gets tidied

The quiet one, and designers cause it with the best intentions. A 1,400-word servicing page that answered "how much is an interim service", "how long does it take" and "do you use manufacturer parts" gets cut to 180 words and a beautiful photograph, because the new layout breathes better with less text.

It ranked for the sentences that were deleted. The site got better looking and the page stopped earning. Nobody notices for six weeks, by which point the design is signed off and the invoice is paid.

3. The new site is slower than the old one

A hand-built page with a 0.9-second largest contentful paint can come back as a page-builder version carrying a 2.4 MB hero video, at four seconds and up. Speed is a weak ranking factor on its own, so this rarely moves positions much. It costs you enquiries immediately, which is worse. There is more detail in why website speed costs you customers.

Before: write down what you already have

You cannot tell whether a redesign hurt you if you never recorded where you started. This is an afternoon's work. It is the difference between diagnosing a problem in an hour and arguing about it for a month.

Crawl the old site first. Screaming Frog is free up to 500 URLs, which covers most small business sites. Export every URL with its status code, title, H1, meta description, canonical and word count, then put the CSV somewhere you will still find it in a year. Take a copy of the actual HTML too, wget --mirror does it in one command, because that is the only reliable way to answer "what did that page say before?" once the old site is gone.

Do the Search Console export before launch, not after. It only keeps 16 months, and the day you badly want that data is the day the useful months have rolled off the end of it. For your twenty best pages, run each through Save Page Now at the Internet Archive as well. It takes ten minutes and gives you a dated public copy that nobody can overwrite.

The one sheet the whole redesign should be built around

Put every URL that has earned a click in the past 12 months, a form fill, a phone call, or an external link into a single list. On a 60 to 120-page business site that comes to 30 to 50 rows, and 10 to 15 of those rows carry something like 80 per cent of the value.

Sort it by value and you have a specification instead of an opinion. These are the pages the new site must still serve, at the same addresses, saying the same things. Watch the linked pages even when their traffic is nil. A 2017 blog post with three links from local news sites can be doing more for the whole domain than your homepage.

During the build: what has to survive

Keep the URLs identical

Free, invisible, and worth more than everything else on this list put together. Same paths, same trailing slashes, same casing. Resist tidying /services/mot-brighton/ into /mot because it looks neater on the sitemap diagram. Nobody types your URLs. Google has been reading them for eight years.

Where they must change, build a 1:1 map

Two columns: old URL, new URL. Every old URL gets exactly one destination, served as a 301. Three rules decide whether it works.

• Point each old URL at its closest equivalent page, never at the homepage. A mass redirect to the homepage gets treated as a soft 404 and the signals go nowhere.
• No chains. If /a already redirected to /b back in 2022 and /b now becomes /c, edit the old rule so /a goes straight to /c. Chains add latency and they snap the day somebody prunes the rules file.
• Test them rather than assuming. curl -I on a sample should show one 301 and one Location header. Not a 302, and not two hops.

Say a garden studio's ninety-thumbnail gallery becomes fourteen individual project pages. Every old gallery URL has to land on the specific garden it was showing, not on the new index. That mapping is about an hour of the build, and it is what lets the new pages inherit the old traffic instead of starting from zero.

Where a page has no equivalent because you genuinely stopped offering that service, send it to the nearest relevant page. If nothing is relevant, let it 404 honestly. A clean 404 is better than dropping somebody somewhere confusing.

Keep the words that earned the rankings

The copy is the asset. A page that ranks because it answers nine questions in 1,200 words answers two of them in the 400-word version, and loses seven rankings doing it. If a page really is bloated, rewrite it to answer the same questions in fewer words. Losing the questions is the failure. Losing the word count is fine.

Leave titles and H1 patterns alone unless there is a reason

"MOT Brighton | a Brighton garage" sitting at position three is not a design problem. Swapping it for "Servicing" because it balances the navigation is trading visibility for tidiness. If you do want to test better titles, do it a month after launch, a few pages at a time, so you can still tell what caused what.

Carry the schema over and rebuild the internal links

Structured data is easy to lose because it is invisible. LocalBusiness, Product, Review, BreadcrumbList and FAQ markup all need porting to the new templates, and the Rich Results Test tells you in a minute whether it survived the move.

Internal links need the same attention. New sites tend to ship with a tidy five-item nav and no links at all inside the body copy, which flattens a structure that took years to build. If old pages linked to each other in context, put those links back in context.

Launch day, in order

1. Load /robots.txt on the live domain and confirm the staging Disallow: / has gone. Check the file the server returns, not the CMS toggle that claims to control it.
2. View source on the live HTML and search for noindex. Check the response headers for X-Robots-Tag too, which is the one people miss.
3. Remove staging basic auth and any IP allowlist left over from the build.
4. Purge the CDN and page cache. Half of the "the new site isn't showing" panics on launch day are Cloudflare still serving yesterday.
5. Spot-check 20 to 30 redirects, weighted towards your highest-value URLs. One hop, status 301, correct destination.
6. Regenerate the XML sitemap with the new URLs and submit it in Search Console.
7. Verify analytics with a real visit. GA4 real-time should show you, and a genuine form send should fire the conversion event. Check call tracking if you use it.
8. Send a test enquiry from an outside email address and confirm it lands in the inbox. A thank-you page proves nothing about deliverability.
9. Confirm canonical tags point at the live HTTPS domain. Staging canonicals leaking into production is common and expensive.
10. Pick one canonical host, www or bare, and 301 the other. Same for HTTP to HTTPS.
11. If the domain itself changed, submit the Change of Address in Search Console and keep the old domain and its redirects live indefinitely, not for a token twelve months.

After launch: normal dips and abnormal ones

A normal dip looks like clicks down 5 to 20 per cent for two to four weeks, impressions wobbling, average position drifting a place or two, and most of it recovered by week six. Google has to recrawl and reprocess every page that changed. A 60-page site can be through that in days. A few thousand pages takes weeks.

An abnormal dip is a different shape, not just a bigger number. Down 40 per cent or more inside a fortnight. Still meaningfully down at week eight. Indexed page count falling week on week in the Pages report. "Crawled, currently not indexed" climbing. Or one valuable page losing its position while everything around it holds, which nearly always means that specific page changed.

Check in this order. Search Console Pages report for noindex and redirect errors. Then re-crawl the new site and diff it against your old crawl to find URLs that quietly disappeared. Then test the redirects for the exact pages that dropped, because server rules mishandle trailing slashes constantly. Then compare title, H1 and word count against your archive. Look at Core Web Vitals last, because it is rarely the answer. Why a site is not showing up on Google walks the same diagnostic tree for sites that never ranked to begin with.

Do not panic-edit in week one. Rewrite your titles the day traffic dips and you destroy your ability to tell what caused what. Set review points at day 14, day 30 and day 90.

Redesign in place, or one big launch

Redesigning in place means keeping the site live and replacing it in sections: homepage this fortnight, service pages next, blog last. The URLs never move, problems surface while they are still small, and you can stop halfway if something is wrong. It is the right call when the site earns real organic traffic and the platform is staying put. It is also slower, and perhaps 10 to 20 per cent more expensive, because you are working around a live site.

A big-bang launch is unavoidable when the platform changes or the structure itself is the problem. All the risk lands on one day, so the redirect map and the checklist above stop being paperwork and become the actual job. Build the map before the design is signed off, not the night before launch. Mine gets written at the sitemap stage, which is why the process settles structure before anything visual happens.

Now the unprofitable part. Baselines, a redirect map and proper launch checks on a 60-page site are four to eight hours of work, call it £300 to £700 at ordinary freelance rates. If organic search brings you thirty enquiries a year, that is a rounding error against what you are protecting. If your site gets 40 organic visits a month and none of them convert, you have no rankings to lose and the whole ceremony is money that should go into the copy and the build instead. Sketch a rough redirect map in an hour and get on with it.

That is the honest shape of the discipline: the care scales with what you have to lose. If you want a second opinion on a redesign already in progress, or a rebuild that treats your existing rankings as a constraint from day one, the services page explains how I work. Otherwise send me the URL and I will tell you which of the three failure modes you are closest to.