Measure before you touch anything
Export the list of pages that get visits, the pages that get search impressions, and the pages that other sites link to. Those three lists define what you are not allowed to break.
Most small sites have a handful of pages doing nearly all the work, and they are rarely the ones the owner expects. Finding out before the rebuild is far cheaper than discovering afterward.
Our page on auditing a site covers how to assemble that picture, and our page on the performance report covers where the search half of it comes from.
Keep the addresses where you can
Every address that changes is a risk. Links from other sites point at the old one, a search engine or an answer engine has to relearn the new one, and anything you miss becomes a dead page.
Keeping the same addresses removes the whole problem. Where a new structure genuinely improves the site, map every old address to its closest new one before anything goes live.
Then redirect properly, one hop, permanent. Our page on redirects covers the difference between the two kinds and why chains cost you.
What to carry and what to regenerate
Carry anything that performs. A page with links and visits has earned its position, and replacing it with a fresh version discards the evidence that it works in exchange for nothing.
Regenerate what was always thin. The service page nobody finished, the empty section, the pages that exist as placeholders. Those are where generation genuinely adds something.
And rewrite what is wrong. Old prices, old coverage, credentials that lapsed. A rebuild is the moment those get fixed, because nobody will go looking for them later.
The rebuild sequence
This order protects what works first and improves second. Reversing it is how rebuilds lose visibility, and the loss usually shows up weeks later when it is expensive to diagnose.
- Export visits, impressions and inbound links
- List every existing address
- Decide the new structure on paper first
- Map old addresses to new ones, with nothing unmapped
- Carry the pages that perform, rewriting only what is wrong
- Generate the pages that were always missing
- Redirect, publish, then check every old address resolves
After it goes live
Check that every old address resolves to something sensible. A sample is not enough on a rebuild, because the missed ones cluster in the parts of the site nobody thought about.
Submit the new sitemap and watch coverage. Our page on the coverage report covers what to look for, and the first two weeks are when problems surface.
Expect a dip. Some movement after a rebuild is normal even when everything was done correctly, and the mistake is reacting to week one by changing things again.
What rebuilds usually get wrong
Changing addresses for tidiness. A cleaner address is worth very little and costs every link pointing at the old one. Keep the address unless the change fixes a real problem.
Dropping pages quietly. A page nobody remembers may still be the one another site links to, which is why the export comes before the decisions rather than after them.
And regenerating the pages that were working. Those pages are evidence of what your audience responds to, and a rebuild is the worst possible moment to discard that.
Doing it gradually instead
A rebuild does not have to be a single event. Improving the worst pages one at a time carries almost no risk and produces most of the benefit, which suits a site that is already performing.
The case for doing it all at once is structural. Where the whole shape of the site is wrong, fixing it page by page never converges and the mess persists.
Our page on rebuilding a site covers the wider decision, including how to tell which of the two situations you are actually in.