Rebuilds: deciding what is worth keeping

Before anything gets drawn, you need a list of every URL the site serves. Not the CMS navigation, and not the sitemap, which is usually fiction. Crawl it, then read the server logs for the URLs nothing links to any more. That is where the unmaintained form endpoint turns up, and the ad landing page still taking spend. Then join it to everything else pointing at it.

• Sessions, conversions and search impressions per URL, last 12 months
• Every inbound link worth keeping, and where it lands today
• Every integration touching the site: forms, payments, CRM, webhooks, feeds

The earning set is usually small. A home page, 2 or 3 service pages, whatever carries pricing, a few posts that have quietly ranked for years. The pages that pull sessions and the pages that close work are rarely the same, which is how a traffic ranking keeps the blog archive and skips the pricing page. Budget follows what the pages do.

The fix depends on where the time goes. Open the network panel and read one number: how long the server takes to send the first byte of the HTML document. Over 1 second and the problem sits behind the site. Templates render uncached, the query count grows with the page, a plugin does work on every request.

If the first byte arrives in 200ms and the page still shows nothing for 6 seconds, the problem sits in front of the site. Render-blocking stylesheets, a webfont with no font-display, a 2MB hero image, third-party tags nobody audits. That is not a structural fault, it is a removal job, and plenty of sites need that more than a rebuild.

The structural question has nothing to do with speed. Count the files somebody has to open to add a page type that does not exist yet. If a new case study means touching 5 templates, a plugin setting and a hard-coded menu, the structure is the problem and image compression goes nowhere near it. A site can pass every audit a tool can run and still be one nobody can add to.

URLs are the part of a website other people hold copies of. Every inbound link, bookmark, email footer, search result and printed card points at a string. Change the strings for style and you have broken all of it, and bought a redirect map you now maintain forever.

Keeping /services/roof-repair and rebuilding what renders at it costs nothing. A 301 carries ranking signals across, so nothing collapses when a URL genuinely has to move, but every move is a hop and hops accumulate. Let the inbound link list decide: rename freely when nothing points at a URL and nothing has landed on it in 12 months, and leave it alone when a directory listing, a supplier's site and years of email signatures still land there. Rename when the address is wrong, not when it is old.

What people call keeping the content usually means keeping the CMS, and those are different things. The content is the words, the images and the structure holding them, a shape you could describe over the phone. The CMS is storage plus an editing interface, and usually the thing making the mess.

Export before any decision gets made. If the body of every page is a wall of page-builder shortcodes, the content is not in a content model, it is in a rendering format, and the migration is a text-extraction job nobody costed.

The words are the likeliest thing thrown out for sounding dated. The odd, over-specific sentence on the pricing page is usually there because the same question arrived 100 times. It was paid for in sales calls and support tickets, and it does not come back from a brand deck. Rewrite what is wrong. Leave what is merely old.

The template layer and the plugin stack go without ceremony, and the argument is not age. Open view-source and attribute every script tag and inline block on one page to a decision somebody can still explain. Whatever you cannot attribute is the case for losing the tower, normally most of the list.

Redirects get budgeted for pages and forgotten for everything else. Other sites link straight to your PDFs, a press article hotlinks an image, an aggregator has polled a feed URL for years. Those break the same way.

The next category is everything in the CMS admin nobody files as content. Form definitions and the endpoints they post to. Transactional email templates. The redirect table several people have added to over the years, now aimed at new URLs and building chains. A chain of 3 hops is 3 sequential round trips before the first byte of the real page arrives, which on mobile is most of what a visitor calls slow.

Then the integrations, which fail silently and late. A payment webhook posts to a hard-coded path. A CRM sits behind a form endpoint that moved. An ops script scrapes a page that no longer carries its table.

None of this has to be found live, but each category needs its own pass, and the URL pass needs to know where the redirect map lives. Edge or CDN config, host rules and application routes are 3 different places, and only the last exists on a staging site. A sweep at a staging hostname exercises staging's own routing, not the rules that will run at the live origin, so a column of 200s from staging is a false pass.

Resolve the production hostname to the new origin yourself, with a hosts-file entry or a Host header, then request the whole audit list that way and read the status codes in one column. A 200 where a 301 was intended, a 301 landing on a 404, a chain 4 hops deep: one pass finds all of it.

The other 2 passes are shorter. Fire a test event at each webhook against the new host. Submit every form once and look for the record at the other end. Send yourself one of each transactional email. Run all 3 the week before launch and there is nothing left to find the morning after.