Do you actually need a new website? Five signs the platform is the problem

By the time a website rebuild reaches a budget conversation, the decision has usually already been made. Enquiries have been flat for three quarters. Sales say the leads are poor. Someone on the board has looked at a competitor's site. The brief that lands with an agency isn't "help us work out what's wrong", it's "we need a new website by the autumn".

Sometimes that's the right call. Often it's an expensive way of avoiding a harder question, because a rebuild is one of the few marketing investments that can absorb six months, a large budget and most of your team's attention while changing nothing about why the site wasn't working.

The site being dated is not evidence that the platform is the problem.

The useful question is narrower than "should we rebuild?"

A new website makes commercial sense when the platform is the thing preventing improvement. It rarely makes sense when the platform is merely the place where a different problem is visible.

So the question worth answering before any budget is approved is this: if you could change anything on your current site tomorrow, without a rebuild, would performance improve?

If you can name three specific changes and the only thing stopping you is the platform, you have a platform problem. If you can't name them, a rebuild will simply reproduce your current thinking in a nicer typeface.

Four problems that all present as "we need a new website"

A proposition problem

A visitor arrives, reads the homepage and still can't tell whether you solve their problem. The words are fine. They're just about you rather than about them, and they'd apply equally to four of your competitors.

This one is worth ruling out first, because it's the cheapest to test and the most likely to be inherited by a new site. If nobody internally agrees on why customers choose you, a rebuild will formalise that disagreement across forty pages instead of resolving it.

A structure problem

The content exists. People can't find it, or they find it in an order that makes no sense to them. This tends to show up as high traffic to a small number of pages, healthy search visibility, and almost no movement towards anything commercial.

Navigation built around how the business is organised, rather than how buyers think, is one of the most common causes of an apparently underperforming site. Categories that mirror your internal structure, product names only insiders use, and menus that require the visitor to already know what they need are versions of the same problem.

A journey problem

The site works until the point where somebody tries to act. Forms with eleven fields. A demo request that promises nothing about what happens next. Pricing conversations only available by phone. Three different calls to action competing on the same page.

These are usually concentrated in a handful of pages and steps, which is exactly why a full rebuild is such a blunt response.

A measurement problem

Nobody can say where visitors give up, which pages produce enquiries that turn into revenue, or whether last quarter's dip was traffic quality or conversion. In that situation, the rebuild isn't a solution to a diagnosed problem. It's a way of doing something while the diagnosis is unavailable.

Solve this one before you spend, or you'll have no way of knowing whether the new site was worth it.

Five signs the platform genuinely is the problem

1. Every meaningful change needs a developer

The clearest test isn't how the site looks. It's how long it takes to change.

If publishing a new page takes three weeks, if a campaign landing page requires a development ticket, if the marketing team has quietly stopped asking because asking is exhausting, the platform is costing you every improvement you're not making.

And this isn't an unusual frustration. Research for the 2025 State of the Website report found 60% of marketers struggled to keep up with the volume of website projects they were responsible for. The report identified website tools requiring technical skills as one of the two main barriers to marketers having the autonomy they needed, alongside ineffective cross-functional collaboration. 96% also said their marketing teams could collaborate better with the engineers and developers responsible for their sites.

That dependency has a cost which doesn't appear neatly in analytics. Teams stop testing, stop iterating, and start treating the website as a fixed asset rather than something that should get better every month.

Count the changes your team wanted to make last quarter and didn't. If the list is long and the reason is always technical, that's a platform constraint.

2. The site can't tell you what happens after the form

A website that captures enquiries but can't pass useful information to the system where sales works will always look like it's underperforming, because nobody can prove otherwise. Marketing reports form fills. Sales reports poor quality. Neither has the evidence to settle it.

When the platform can't integrate properly with your CRM, you lose more than reporting. You lose lead scoring, routing, campaign attribution and any ability to distinguish a page that generates enquiries from a page that generates customers.

This is where the platform decision and the commercial decision meet.

FutureGroup's work with Community, a business-to-business social platform, is a useful example of the difference. The existing Webflow site had unclear journeys, slower than ideal load times and no meaningful connection to the marketing tools the team already owned.

The rebuild wasn't cosmetic. It was a custom content management theme with a reusable component library, roughly thirty pages of rewritten copy, and tight integration with HubSpot so that attribution and lead scoring worked end to end. The point of the new build was to make the site measurable and maintainable, not just better looking.

3. The performance problems live in the build, not the pages

Slow sites lose enquiries. That much is well established. What matters for this decision is whether the slowness is fixable.

One of the more useful studies here looked specifically at B2B lead-generation sites rather than ecommerce. Portent analysed more than 100 million page views across 20 B2B and B2C websites, including 14 B2B lead-generation sites. In its B2B data, a site loading in one second had a conversion rate three times higher than one loading in five seconds, and five times higher than one taking ten seconds.

Deloitte found the effect of comparatively small performance improvements too. Its research across mobile sites in Europe and the US found that improving mobile speed by just 0.1 seconds was associated with an 8.4% increase in retail conversion and 10.1% increase in travel conversion, while bounce rates on lead-generation information pages improved by 8.3%.

The point isn't that shaving 100 milliseconds off every B2B website will produce the same commercial result. It's that performance is sufficiently connected to commercial behaviour to deserve diagnosis rather than assumption.

Oversized images, unnecessary tracking scripts and bloated third-party embeds are page-level problems, and page-level problems have page-level fixes. A platform where the theme itself loads badly, where the hosting can't cope, or where every attempted fix is undone by the next content update is a different matter.

Google's current Core Web Vitals provide a useful shared reference point. A good user experience means Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) of 200 milliseconds or less, and Cumulative Layout Shift (CLS) of 0.1 or less, measured at the 75th percentile of page loads across mobile and desktop.

And if somebody in the meeting is still talking about First Input Delay, the measurement has moved on. Interaction to Next Paint replaced FID as a Core Web Vital in 2024. Unlike FID, which measured only the delay on the first interaction, INP assesses responsiveness across interactions throughout the page visit.

Get a technical audit that separates page-level issues from platform-level ones, and insist it tells you what could be fixed on the current platform. A failed Core Web Vital tells you there is a performance problem. It does not, by itself, tell you that you need a new website.

4. You're running several sites that should be one

Acquisitions, sub-brands, campaign microsites and a legacy product site nobody owns. Each was reasonable at the time. Together they create a fragmented experience where the same visitor gets three different versions of who you are, and your team maintains four content management systems to keep it that way.

This is a genuine platform problem, because no amount of improvement to any one site resolves it. It usually needs a single scalable platform with shared components, proper multilingual support where relevant, and clear ownership.

The commercial question here isn't simply what consolidation costs. It's what fragmentation is already costing: duplicated content, duplicated development, inconsistent measurement, slower publishing and several different customer experiences being maintained at once.

5. You're on a version with no future

Unsupported software. A plugin doing something critical that stopped being maintained in 2021. A theme so heavily customised that upgrading breaks it. A platform that can't support the languages, regions or volume you now operate at.

Here the trigger is risk and capability, not performance.

The question isn't whether the current site converts. It's whether it can be safely maintained and whether it can support what you're about to ask of it. Scale and language requirements in particular tend to expose platform limits that no redesign would touch.

Why rebuilds so often fail to move the numbers

Three patterns account for most disappointing website projects.

The first is that the rebuild inherits every unresolved decision. If the business couldn't articulate its proposition before, the new site will contain a longer version of the same vagueness.

The second is that a rebuild is a single large bet, launched all at once, which makes it almost impossible to learn from. The numbers move and you won't know which of the four hundred changes did it.

The third is timing. A rebuild typically means months in which nothing on the current site improves, because everything is being saved for launch. That's a long time to stop optimising something that still has customers on it.

None of this argues against rebuilding. It argues for knowing what you're buying.

Questions worth answering before you approve the budget

Ask these in a room with marketing, sales and whoever owns the technology.

What result needs to change, in numbers? Enquiries, qualified pipeline, average deal size, self-service revenue, cost to serve. "A more modern site" isn't an outcome.

Where do people actually stop? If you can't answer this from your analytics, that's your first project, not the website.

What did we want to change last quarter and couldn't? The reasons matter more than the list.

Do sales trust the leads the site produces? If not, is that quality, routing, timing or information?

Has anyone tested the proposition on someone who doesn't work here? Five conversations with real buyers usually tells you whether the problem is words or wiring.

Which pages carry the commercial load? Most business-to-business sites depend on a small number of pages. Rebuilding two hundred to fix six is poor economics.

Is the traffic right? A site converting poorly on badly matched paid search traffic is not a website problem.

What would we do differently this time, specifically? If the answer is mostly aesthetic, the budget belongs elsewhere for now.

If the platform isn't the constraint, fix in this order

Start with measurement, because everything after it depends on knowing what's true.

Then proposition and messaging on the pages that carry commercial weight.

Then the journeys where people are already trying to act, which is usually forms, demo requests, pricing information and the moment somebody wants to talk to a person.

Then structure and navigation, tested against how buyers group things rather than how you do.

That sequence is unglamorous and it can often be delivered on the platform you already have, at a fraction of a rebuild's cost, with the useful side effect that you learn what works before committing to a new build.

When a rebuild is the right call

A rebuild earns its budget when the platform blocks change, when it can't connect to the systems that run your commercial process, when the estate has fragmented beyond repair, or when you've outgrown what the technology can support.

It also earns it when the underlying problem is structural rather than technical, and the structure can't be untangled page by page.

Netacea's website contained genuinely valuable product information, but its structure and messaging made it hard for prospective enterprise buyers to see why a complex cyber security product mattered to them, and there were no clear routes from discovery to conversion.

The rebuild worked because it was treated as a narrative and structure project that happened to require a new build: buyer insight shaping the architecture, a stronger explanation of the problem being solved, simplified journeys, and search considerations built in from the start rather than retrofitted.

That's the distinction worth holding on to. The projects that repay the investment are the ones where the team can explain what the new site will let them do that the old one wouldn't.

The test to apply before you commit

If the honest answer to "what would we change tomorrow if we could?" is a list, you have a plan and you may not need a rebuild to start on it.

If the honest answer is "we're not sure, that's why we want to start again", you're about to spend a lot of money to find out.

The website is rarely the whole problem, and it's rarely blameless either. Working out which parts are which is the actual project.

If you're weighing up a rebuild and you want a clearer view of where the real constraint sits before committing to a build, this is the kind of question FutureGroup's web design and build team works through with clients before anyone talks about platforms.