Patch a website while changes are still cheap and safe, and rebuild when the cost of every change keeps climbing, the foundations can no longer be secured or measured, or the site no longer fits the business. The deciding factor is not age or looks. It is whether the extra effort each change costs now exceeds what removing the underlying problem would cost.
What technical debt means for a website
Martin Fowler explains that software accumulates what he calls cruft: poor internal quality that makes systems harder to change. Ward Cunningham coined the “technical debt” metaphor to treat that cruft like a financial debt. In Fowler’s explanation, the interest is the extra effort each new feature costs because of the cruft, and the principal is the cost of removing it.
His worked example is useful. A feature that takes four days in a clean codebase takes six days with cruft, so the two-day difference is the interest. Cleaning up costs five days, which only pays off if similar features follow. He also notes that interest is only charged when you work in a messy area, so stable code that is rarely touched can often be left alone, while frequently changed code deserves low tolerance for cruft.
For a business website, translate that into plain terms. The debt is whatever makes routine work slow, risky or impossible: a fragile theme, plugins nobody maintains, content locked into layouts, tangled styling, undocumented hosting.
Signs of debt you can observe
You do not need to read code to spot it. Watch for these patterns:
- Simple edits take days. Changing a heading or adding a page needs a developer and still breaks something.
- Fear of updating. Nobody dares update the platform or plugins because the last update broke the site.
- Performance that will not improve. Fixes help briefly, then regress. See Core Web Vitals thresholds from web.dev for a measurable yardstick: good is an LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, at the 75th percentile.
- Knowledge held by one person. If the only person who understands the build leaves, the site is at risk.
- Duplicate content structures. The same information is maintained in several places and drifts apart.
- Tracking and forms you cannot trust. Analytics are unreliable and enquiries sometimes vanish.
- Security concerns. Components are end of life or cannot be patched.
Fix or rebuild: a decision test
Work through these questions with whoever maintains the site.
- What does a typical change cost now, compared with what it should? This is Fowler’s interest. A gap that is large and growing points toward rebuilding the worst areas.
- Is the debt in code you change often? If the problem sits in areas you rarely touch, leave it. If it sits in your core templates, it is costing you continually.
- Can the foundation be secured and maintained? If critical components cannot be updated, patching is borrowing time.
- Does the structure match the business? If the site was built for a company that no longer exists, you are fixing the wrong thing.
- Can you migrate content cleanly? If content is portable, a rebuild is far less risky.
- What does a fix cost compared with a rebuild over a realistic horizon? Compare total effort, not the first invoice.
| Situation | Usually better |
|---|---|
| Isolated problems in rarely changed pages | Patch |
| Slow, but cause is a few heavy assets or scripts | Patch |
| Every change is slow and risky across the core templates | Rebuild the core |
| Platform cannot be updated or secured | Rebuild or migrate |
| Business model, audience or brand has changed | Rebuild around the new reality |
| Content is clean but design is dated | Redesign, which is a different question |
Redesign and rebuild are not the same decision. A redesign changes how the site looks and flows. A rebuild changes what it is built on. You can do either without the other. Our guides to redesigning without losing SEO and choosing a web development partner cover the planning side.
Partial rebuilds
Between patching and a full rebuild sits the incremental route: replace the worst component first. You might move the blog to a cleaner setup, rebuild the main templates, or retire a plugin that causes most problems. This follows Fowler’s advice to pay down principal gradually, mainly in code you change often. The trade-off is that running two systems adds its own complexity, so set an end date.
Protecting search traffic in a rebuild
A rebuild is where visibility is most often lost, usually through changed URLs. Google’s site move guidance is specific about what to do when URLs change:
- Use server-side permanent redirects (301 or 308) from each old URL to its new one, and send each old URL directly to its final destination rather than chaining redirects.
- Do not send many old URLs to an unrelated page such as the new home page.
- Build a map of old URLs from sitemaps, server logs, analytics, your CMS and the Search Console links report, including images, videos, CSS and JavaScript files, then use it to update internal links and create a sitemap of new URLs.
- Monitor sitemap indexing, coverage reports, search queries, server logs and analytics. Rankings may fluctuate during the move.
- Keep redirects for at least one year, though keeping them indefinitely is also reasonable.
Our article on URL structure and redirects explains the mechanics for non-specialists.
Avoiding the same debt again
A rebuild without new habits recreates the problem. Agree on:
- A named owner for the site and its documentation.
- A maintenance schedule for updates, backups and security checks.
- Rules for adding plugins, scripts and embeds.
- A performance budget so weight cannot creep back.
- A short written record of why key decisions were made.
Honest limits
Rebuilding costs money and carries risk, and a rebuilt site can pick up new debt quickly if it is rushed. There is no formula that gives the answer in advance, only a method for comparing effort. Treat Fowler’s numbers as an illustration of the idea, not as a benchmark for your site.
Where Radiance Impact fits
Radiance Impact’s Technology division works on business websites and redesigns, and provides maintenance and care. If you are unsure whether to patch or rebuild, contact us or read about the Technology division.
Sources
- Technical Debt, Martin Fowler
- Site moves with URL changes, Google Search Central
- Web Vitals, web.dev (Google)
