The website rebuild that cost us half our enquiries

The old site was embarrassing. Sixty-odd pages accumulated over nine years, three different fonts, a blog nobody had touched since a rebrand, service pages written by whoever had a spare afternoon. Every time we sent the link to someone we apologised for it first.

The new one was twelve pages, fast, properly designed, and we were proud of it. It went live on a Thursday. By the following spring we were doing less than half the enquiry volume we had been doing the previous year, and for most of that time we genuinely believed the market had gone quiet.

The bit that broke

Nobody had thought about the sixty pages we deleted.

Some of them were rubbish. But some of them were the reason people found us at all: a five-year-old page answering an oddly specific question in our sector, a location page, a handful of blog posts that had picked up links from trade sites. Those pages had accumulated authority slowly and invisibly, and they were doing the work that the shiny homepage got credit for.

When the new site launched, those URLs stopped existing. Worse, the developer had been thorough in a way that made it harder to spot: rather than leaving them broken, everything old was redirected to the new homepage. That feels tidy and is close to the worst option available. A search engine reading a mass redirect of unrelated pages to a single homepage treats it much like a page not found, so we got no benefit from the redirects and lost the signal that the content had moved anywhere in particular.

Deleting a page that ranks is deleting a salesperson. It does not feel like it, because the page never sent you an invoice.

There were three smaller failures on top. The phone number in the new header was part of an image, so it was not selectable on a phone. The enquiry form posted to an email address that had belonged to someone who left. And the analytics tag from the old site was never reinstalled, which is why the whole thing was invisible for so long.

Why nobody noticed for eight weeks

This is the part I would want another owner to take from it. A small business does not have enough enquiries for a decline to be obvious. We were running somewhere around forty enquiries a month before the launch. When that fell, it fell unevenly, and every individual month had a story: August is always slow, that big client took up all our time, the trade show was late this year.

It took a quiet Tuesday and an idle search for one of our own services, on which we had always ranked, to find that we were not there at all. Then somebody tried to submit the contact form and it vanished.

The honest reckoning, using illustrative but representative numbers: forty enquiries a month down to eighteen, converting at roughly one in four, at an average job value of about £1,400. That is five or six jobs a month, somewhere around £7,000 to £8,000 of revenue, against a rebuild that cost £6,000. The site paid for itself in damage inside a month.

What we actually did to fix it

Recovery was slower than the damage, which is the usual asymmetry.

First, we rebuilt the list of what had existed. The old sitemap file was gone, but Search Console still held historical data, the server logs had a year of requests, and the Wayback Machine had crawled the old site often enough to reconstruct most of the structure. Between those three we got back to a list of URLs and a rough idea of which had been receiving traffic.

Then we mapped them one by one. Each old URL either went to the closest genuinely equivalent new page with a 301 redirect, or, where nothing equivalent existed and the page had been earning traffic, we restored the page. About fifteen pages came back from the dead, lightly rewritten. That was the bulk of the recovery.

We reverified Search Console on the new site, submitted a fresh sitemap, and put analytics back. We fixed the form and tested it by submitting from an outside email account, which is a five-minute job we should have done on day one. And then we waited, because nothing about this is fast. Rankings came back over months, not weeks, and a few never fully did.

The checklist we use now

Before the build: crawl the existing site and export every URL, with its traffic if you have it. Decide page by page whether it is being kept, merged or removed, and write the mapping down in a spreadsheet before a single new page is designed. Note which pages currently bring in traffic and treat those as fixed points the new design has to accommodate, not as content to be tidied away.

At launch: every old URL gets a 301 to its closest equivalent, one to one. Never bulk-redirect a site to its homepage. Where a page is genuinely being kept, keep its heading and page title close to what they were, because rewriting everything at the same moment as changing every URL makes the cause of any drop impossible to isolate.

Keep the analytics property and the Search Console verification live through the switch, and confirm they are recording on the new site the same day. Test every form and phone link from a device that is not yours, from an account that is not yours. Keep the old site accessible somewhere for a fortnight so you can check what a page used to say.

After launch: look at Search Console coverage and query data weekly for two months. You are looking for a rise in not-found errors and for queries you used to appear on going missing. Both show up long before the enquiry count makes it obvious.

The part that was really our fault

Underneath the technical failures was an ownership problem. The domain was registered in the agency's account. The analytics property was theirs. The hosting was theirs. When we wanted to look at what had happened, we had to ask the people who had done it, which is a bad position to negotiate from and a worse one to investigate from.

We now hold the registrar account, the DNS, the hosting account and the analytics and Search Console properties in our own name, and grant agencies access to them. That single change would not have prevented any of this, but it would have cut the diagnosis from four months to about a week. It is the same lesson as the software we couldn't get our data out of, arriving from a different direction.

The wider point is that a website is not a brochure, it is a channel, and a channel has a measurable output. We had never measured ours, so when it stopped working we had nothing to compare against and no alarm to trigger. If you do not know roughly how many enquiries the site produces in a normal month, you will not notice the month it stops. How to set a marketing budget with no baseline is the piece to read before you commission anything, and Google Business Profile: what actually moves local enquiries is where a lot of small firms should be spending attention before they spend it on a redesign at all.

The site we have now is the one from the rebuild, plus fifteen resurrected pages that the designer would have hated. It is not as clean. It works considerably better.

Common questions

Will redesigning my website hurt my Google rankings?

A redesign that keeps the same URLs and the same content is usually low risk. The damage comes from what typically accompanies a redesign: pages deleted, URLs restructured, headings and page titles rewritten, and content consolidated. Each of those individually is survivable and all of them at once is how sites lose visibility. The safest approach is to treat structure and design as separate projects. Redesign the look first while holding the URLs and content stable, confirm nothing has moved, and only then consolidate or rewrite pages, so that if traffic drops you know which change caused it.

What is a 301 redirect and do I need one for every page?

A 301 is a permanent redirect telling browsers and search engines that a page has moved to a new address, passing most of its accumulated value to the destination. You need one for every old URL that will no longer exist, pointed at the closest genuinely equivalent new page. The common and damaging shortcut is redirecting everything to the homepage, which search engines treat much like a missing page because the destination does not answer what the old page answered. If no equivalent page exists and the old page was earning traffic, the better answer is usually to rebuild that page rather than redirect it somewhere approximate.

How long does it take to recover rankings after a bad site migration?

Expect months rather than weeks, and expect partial rather than complete recovery. Once correct redirects are in place and any genuinely valuable deleted pages have been restored, search engines need to recrawl the site and reassess it, which is gradual. Pages that were restored close to their original content and address tend to come back fastest. Pages that were merged into something broader often do not fully return, because the thing that ranked no longer exists in the same form. The practical implication is that prevention is worth far more than remediation here, because the recovery is slow and incomplete.

Who should own my domain and analytics, me or my web agency?

You should, without exception. The domain registrar account, the DNS, the hosting account, the analytics property and the Search Console property should all be in accounts you control, with the agency granted access as a user. This costs nothing at setup and is awkward to unwind later. The reason is not distrust so much as continuity: when something breaks, or a relationship ends, or you simply want a second opinion, needing permission from the party whose work you are questioning turns a one-week diagnosis into a months-long one. Ask for this before the project starts.