Five Signs Your Website Needs a Rebuild, Not a Refresh

Five Signs Your Website Needs a Rebuild, Not a Refresh

The useful question is not whether your website looks dated. It is whether the problem lives in the presentation layer or underneath it, because those are different projects with an order of magnitude between them. A refresh changes what the site looks like. A rebuild changes how it works. Choosing the first when you needed the second is the most common way a website budget gets spent twice.

Five signals reliably separate the two. If none of them apply, you probably need a designer. If two or more apply, restyling the site will not fix what is actually wrong with it.

1. It fails Core Web Vitals, and the fixes keep not sticking

Google publishes three thresholds, and they are specific: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or below. INP is the one worth paying attention to, because it became a stable Core Web Vital in 2024, replacing First Input Delay, and it measures something much harder to fake - how long the page takes to respond to a real interaction, not just how quickly it accepts one.

Any site can be made to pass once. The signal is whether it stays passing. If image compression and a caching plugin move the numbers and they drift back within a few months, the cause is structural - too much third-party JavaScript, a page built from a dozen plugin queries, or a template that renders and then rearranges itself. Those are rebuild problems wearing a performance costume.

2. Publishing anything requires a developer

This is the sign most businesses do not recognise as a technical problem, because it presents as a scheduling problem. Marketing wants a landing page and it takes three weeks. A product launch needs a new section and it becomes a project.

A content model that cannot express the things your business actually publishes is a design failure at the data layer, and no amount of visual work fixes it. The tell is the workarounds - pages assembled by pasting HTML into a text field, a blog post being used as a product page, or a spreadsheet that is the real source of truth because the CMS could not hold it.

When we rebuilt One Playground's site it scored 100 out of 100 on Lighthouse best practices with a 45-second content publish pipeline. The publish pipeline is the part that changed how the business operated day to day.

3. Mobile is a compromise rather than the default

Mobile is now the majority of web traffic by a clear margin, which means a mobile experience that is a scaled-down version of the desktop one is the wrong way round for most sites.

Responsive layout is not the test - almost everything is responsive now. The test is whether the mobile experience was designed or merely accommodated. Navigation that hides the important things behind a menu because there was no room, forms that were laid out for a mouse, tables that scroll sideways, tap targets sized for a cursor. Those are decisions made desktop-first and then squeezed, and they are visible in the analytics as a mobile conversion rate well below desktop on the same traffic.

4. Nobody can safely change it

Ask what happens if you need to change something significant. If the answer involves finding the one person who understands the theme, or a warning that touching the checkout might affect the newsletter signup, the site has become an unmaintained dependency rather than an asset.

This is the sign with the highest cost and the lowest visibility, because a site nobody can change safely is a site that stops changing. It does not fail. It just quietly stops keeping up, and the decline is attributed to the market rather than to the platform.

Accumulated plugin dependencies are the usual mechanism. Each one was a reasonable decision. Collectively they are a system nobody designed, where the interactions are unknown and the upgrade path is a gamble.

5. The site cannot support what the business is now selling

Websites are built around a model of the business at a point in time. The business moves and the site does not. A services company that added a product, a retailer that added subscriptions, a single-location operator that became a franchise - each needs the site to express something the original structure had no concept of.

The symptom is a navigation that has grown by accretion, with categories that overlap and pages that exist because there was nowhere else to put them. That is not an information architecture problem you can solve with better labels. The structure is wrong because the model underneath it is wrong.

How to tell which project you actually need

There is a quick diagnostic. Write down the three things you most want the website to do differently in the next twelve months. For each one, ask whether it is a change to how something looks, or a change to what the system can represent.

If all three are appearance, you need a redesign and you should not let anyone sell you a rebuild. If two or more are about what the system can represent - a new content type, a new relationship between things, a new commerce model, a publishing workflow that does not exist - then a redesign will deliver a better-looking version of the same constraint, and you will be back inside two years.

The honest version of this conversation costs nothing and saves a great deal. When we rebuilt littlegren's online store, sales increased 300 percent year on year, and Schnuzzle saw a 200 percent return on investment within the launch period and expanded from Australia to the USA. Neither of those outcomes came from a better-looking site. They came from a site that could do something the previous one could not.

If you are trying to work out which side of that line you are on, talk to us - or start with our website design and development work to see what a rebuild involves.

Frequently asked questions

List the three things you most want the site to do differently over the next year, and for each one decide whether it is a change to how something looks or a change to what the system can represent. Appearance changes are a redesign. Anything requiring a new content type, a new relationship between things, a new commerce model or a publishing workflow that does not currently exist is a rebuild, and a redesign will not deliver it.

Intermittent passing usually means the fixes are cosmetic rather than structural. Any site can be tuned to pass once. If the numbers drift back within a few months of each optimisation round, the underlying cause is architectural - typically third-party scripts, a page assembled from many separate queries, or a template that renders then rearranges itself. That will keep recurring until the structure changes.

Yes, but it is a deliberate piece of work rather than a byproduct. Every URL that changes needs a permanent redirect to its replacement, resolving in a single hop, and the redirect map has to be built before launch rather than discovered afterwards from a 404 report. Rankings are lost in rebuilds through unmanaged URL changes far more often than through anything to do with content or design.

Working is not the same as serviceable. The question that matters is whether you can change it safely and quickly. A site nobody can modify without risk does not fail visibly - it simply stops changing, and the business stops using it as a lever. If a routine change requires the one person who understands the theme, the site is already a liability regardless of whether it is currently up.

The build is rarely the long part. The variable is how settled the content model is before development starts - what things the site needs to represent, how they relate, and who publishes them. Projects where that is resolved up front move quickly and predictably. Projects where it is deferred into the build spend the difference on rework, which is the same pattern that causes overruns in app projects.