A twenty-year-old website, rebuilt in 18 days without losing anything

Most owners of an old website know it “needs a rebuild”. Most also put it off, and for a good reason: a rebuild is the easiest way to lose what the site has earned over the years. Addresses change, pages vanish, search traffic drops, and the new site looks better while doing worse.

We just finished one. A directory and review website, live for more than twenty years, with many years of articles and reviews on WordPress. From kickoff to the new site live on its own domain took 18 days, and every old address answered as mapped on launch day. Speed was not the point. It was possible because of the order the work was done in, and that order is what you can copy.

Audit first, from the site’s own data

Before anyone talked about design, we audited the old site from its own data: its Search Console export, a full crawl, Google’s inspection of a sample of addresses, and the sites linking to it. A few things came out that no redesign brief would have mentioned:

• Google had dropped the main review pages in one step, months earlier.
• Most of the pages that earned clicks were missing from the sitemap the site gave Google.
• Google had never seen a large share of the addresses we checked.
• A large share of the sites linking to it were spam.
• Nothing tied the traffic to what the site earns.

The audit kept verified findings apart from hypotheses, and listed what we did not know. A new design would have fixed none of this on its own. Knowing it first meant the rebuild could fix it on purpose. We wrote about the same logic in six questions to answer before you buy a website: the site’s own data tells you what you actually have.

The owner’s plan is the spec

The owner then wrote his own plan for the new site, in twenty sections. Our rule was simple: we follow his plan section by section. Where our data disagreed with it, we wrote the difference down as an open question and left his plan standing. The plan was agreed before anyone built anything.

That rule saves days. Nobody argues mid-build about what the site should be, and every disagreement has a place to go. At launch, 20 of 20 sections were built, with a checklist showing the state of each one.

Size the site from search demand, not old traffic

An old site’s traffic measures how it was run, not what is possible. So the structure of the new site was sized from market search demand: 13,252 searches sorted into the pages the owner’s plan names.

Then a second, slower pass: 1,005 searches sorted one by one, each with an action and a reason. Merge into a page that already serves the same purpose, hold, drop, make a new page, make a tool. 61 new pages came out of it. Most rows merged into existing pages. The ones held were searches that need facts we could not source or keep current. Before launch, 60 near-duplicate addresses were merged into the page serving the same purpose, and their searches moved with them.

Every old address mapped, and checked on every build

Every old address was classified: keep, forward or remove. A script checked a running copy of the new site against that map on every build, so a broken forward showed up the day it was made, not a month after launch. Old sitemaps and feeds forward to the new ones, and images keep their old addresses.

The go-live was rehearsed with the live switch on (search engines allowed, sitemap named, preview-only tools removed) before the real switch, with a written plan to roll back. More on this step in redesign without losing what ranks.

Write only what can be sourced

Fast writing is where rebuilds usually get careless. Ours had one rule: never invent a fact, a figure or a memory. Every fact about a listed company comes from that company’s own pages, with the source and the date checked. Pages that need facts we could not source were held, not guessed. Lines that read as personal experiences nobody had were cut in review.

The pages are written in the owner’s voice, from a profile built on his own writing samples, and a voice check runs on every page written or edited. The page sources live as plain text files in the site’s repository, so his team can edit them.

Check everything, at two widths, three times

• Every page viewed at phone and desktop width: no overflow, no broken images, no browser errors.
• Lighthouse 100 for accessibility, best practices and SEO on the homepage and a review page.
• Three reviews: a cleanup review by four reviewers, a correctness review that found and fixed 10 bugs, and a security review with nothing exploitable.
• The listing request form, where a company asks to be listed, tested end to end: 63 of 63 checks passed.

When a critical security advisory for the site’s framework came out mid-build, the site was moved off the affected version and live the same day.

Launch is the start of the job

A new site starts going stale the day it launches. A website is never finished, so this one has an AI agent on duty, with an engineer setting the rules and checking the work. It follows a written routine: changes at listed companies that touch a reader’s money go into the page that day, with the source; news posts are refused by the build without a source; guides are refreshed from a list of pages due for review; links and security are checked every week. We described that kind of routine in keeping your website working every week.

Before you start your own rebuild, ask

• What does the old site’s own data say is broken today, and which of those findings are verified?
• Whose plan is the spec, and where do disagreements get written down?
• How was the new structure sized: from old traffic, or from what people search for?
• Is every old address mapped, and is the map checked automatically on every build?
• Where does each fact on the new pages come from, and what happens when it can’t be sourced?
• Has the launch been rehearsed, and what is the written way back?
• Who keeps the site current after launch, and how will you see what they did?

A team that can answer these before it starts can move fast without being reckless.