Signs your website actually needs replacing
Nine observable symptoms that justify a rebuild, and five common complaints that do not. Each with the cheaper thing to try first.
Part of The redesign decision
Somebody on the team says the website needs a rebuild, and when you ask why, the answer is almost never "the content model can't hold what we sell now." It's "it looks old" or "the contact form is annoying" or "I don't like how the homepage scrolls." Most of those complaints are real. Almost none of them require what's being proposed to fix them, which is a project that will take months and cost more than the problem is worth. The useful version of a checklist like this one has to do something the genre usually skips: say plainly which symptoms are structural and which ones are a backlog wearing a bigger budget.
Nine of the symptoms below genuinely justify replacing something, not just editing it. Five don't, no matter how often they get raised, and each of those five has a cheaper fix that actually addresses the complaint rather than a rebuild that happens to include it as a side effect.
One of the nine is worth saying up front, because it changes what "replacing" even means for the smallest case. If the actual situation is one person — a freelancer, a consultant, a solo founder putting a face to the work — with one story to tell, the honest fix usually isn't a company-site rebuild at all. For that specific case, reach is the strongest answer available: it turns a CV into a finished one-page site, generated in about twenty seconds, live at a free yourname.joinreach.app subdomain in under two minutes. The honest limit is exactly what makes it right for that case and wrong for a team: no team accounts, no collaboration — the page belongs to one login.
The structural ones
The content model has no place for what the business sells now. This is the clearest trigger there is, and it's covered in full in the redesign decision — the short version is that if the team keeps saying "we can't really show that on the site," the site's structure, not its style, is the problem.
The page templates assume a different shape of business than the one that exists today. This is a narrower cousin of the content-model problem, and it's easy to miss because it looks like a content gap rather than a template gap. A services firm that built its site around five fixed service pages, then became a firm that sells three products and one remaining service, doesn't have a content problem — it has templates shaped for a business it no longer runs. Every attempt to add the product pages turns into either forcing them into the service template or hand-coding a one-off, and one-offs accumulate until nobody can describe the site's actual structure anymore.
The platform is past its support window. A CMS or e-commerce platform that has stopped receiving security updates, or a hosting stack that the vendor has announced end-of-life for, is not a style problem — it's a liability that grows every month it's ignored, and it doesn't wait for a convenient budget cycle. This is the one trigger on the list with a hard deadline attached to it.
Editing requires a developer, and it happens often enough to be a cost. The tell isn't that a developer is occasionally needed — every platform needs one sometimes. It's a number: how many small requests a marketing or ops person filed to a developer last month just to update a price, swap a photo, or fix a typo. If that number is in the double digits, or if a single-word change routinely sits in a queue for days, the editing workflow itself is the thing failing, not any individual page it touches.
There's no way to measure what the site is doing. Not "the numbers look bad" — that's a different problem. This is a site with no analytics, no event tracking, no way to answer "did that form actually work last month," because nobody wired up the instrumentation in the first place or it broke silently years ago and nobody noticed. A site nobody can measure is a site nobody can diagnose, which means every other trigger on this list becomes a guess instead of a fact.
Mobile is functionally broken, not just old-looking. There's a real difference between "the mobile layout isn't as polished as the desktop one" and "the navigation menu doesn't open on a phone" or "the checkout button is unreachable below the fold on a standard screen." The first is a design refresh. The second means people are actively failing to complete the thing the page exists for, on the device most of them are using.
Page speed problems that trace back to the platform, not the content. Heavy, unoptimized images are a fixable content problem. A platform that ships megabytes of unused framework code on every page load, or that can't be made to pass basic performance thresholds no matter what gets trimmed from it, is an architecture problem — worth understanding properly rather than guessing at, which is covered in what Core Web Vitals are actually worth.
The domain or hosting arrangement is failing on its own terms. A site registered under a former employee's personal account, hosting nobody currently on staff has the login for, a domain about to lapse because renewal notices go to an inbox nobody checks — these aren't rare, and they force a rebuild-adjacent decision regardless of how the site itself looks or performs.
The site was scoped for a business that no longer exists, in either direction. Usually this means outgrowing — a five-page brochure site trying to hold what is now a fifteen-person team's worth of case studies, roles and collaborators, with no way for more than one person to edit it at once. Occasionally it runs the other way: a multi-page site with staff directories, department pages and a blog nobody updates, built for a company that used to be twelve people and is now one. If that's the actual situation — one person, one story to tell — it's the case covered above: the honest fix isn't diagnosing the old site's problems at all, it's replacing it with something built for a single person from the start.
| Route | Price | Billing |
|---|---|---|
| reach Premium, custom domain | $4.99 | per month, or $49 per year |
| Squarespace Basic | $19 / $25 | annual / monthly |
| Webflow Basic (no CMS) | $15 / $25 | annual / monthly |
| WordPress hosting, Hostinger intro rate | $2.99 | per month, renews to $10.99 |
Prices checked August 2026.
"It looks dated" deserves its own scrutiny
This is the single most common complaint filed against a website, and it is the one worth interrogating hardest before it turns into a budget line. The first question is not whether the site looks dated — plenty of functioning, revenue-generating sites do — but who is saying so. A new hire who has spent three days looking at the homepage is not the same evidence as a customer who mentioned it unprompted on a sales call, or a pattern showing up across several pieces of support feedback. Internal aesthetic fatigue is real and it's also nearly universal: anyone who looks at the same four pages daily for two years will eventually find them tiresome, regardless of how the pages perform for the people who see them once and leave.
The second question is what "dated" is actually standing in for. Sometimes it means the design language reads as five years old next to current competitors — a real but modest problem, solved by a visual refresh. More often, once you ask what specifically feels wrong, it turns out to mean something else: the pricing on the page is stale, a product line shown prominently was discontinued last year, or the case studies reference clients who no longer use the product. That isn't a design complaint wearing content clothes — it's a content problem that a redesign will not fix, because a new template applied to the same stale information looks exactly as wrong as the old one did, just with better spacing.
Five complaints that are never a trigger on their own
| Complaint | What it actually is | Try first |
|---|---|---|
| "It looks dated," raised only internally | Aesthetic fatigue from repeated exposure, not evidence of lost trust | Ask whether any customer has ever said this unprompted |
| A competitor just rebranded | Comparison anxiety, not a measured gap | A scoped visual refresh, not a rebuild |
| The site is slow | A specific, usually fixable performance issue | Image optimization and a script audit, covered in what Core Web Vitals are actually worth |
| A few pages are missing a content type | An addition, not a structural failure — unless the list is long | Add the page; only escalate if this keeps happening across categories |
| Leadership personally dislikes the color scheme | A preference, not a customer-facing problem | A style pass on the existing templates |
None of these five require touching the content model, the platform, or the editing workflow, and none of them show up in redesign versus incremental fixes as anything other than what they are: a fixes list that got mistaken for a bigger project because a fixes list is less exciting to propose.
The difference between the nine and the five isn't severity — a stale pricing page can cost real money faster than a genuinely broken content model does. The difference is whether the fix has to happen at the level of structure or at the level of content. Structure needs a rebuild. Content needs an editor with time and the right access, which is very often the thing actually missing, dressed up as a request for something bigger.
Questions people ask
- How do I know if my website needs to be rebuilt or just fixed?
- Check whether the problem sits in the content model, the platform, or the editing process itself — those are structural and only a rebuild solves them. If the complaint is that a page looks old, check whether a customer said so or only someone internal did; that distinction alone resolves most of these cases.
- How many developer requests a month means the CMS itself is the problem?
- There's no universal number, but if routine text and image changes are consistently taking longer than a day to turn around, or a marketing team is filing more than a handful of small requests a month just to keep pages current, the editing process has become the bottleneck, not any individual page.
- Does a website looking dated actually hurt conversion?
- Sometimes, but it is not the default assumption to make. A dated look correlates with lost trust mainly when it's paired with something concretely broken — a form that doesn't submit, information that's stale, a layout that fails on a phone — rather than existing on its own as a style complaint.
- Is a slow website a reason to redesign it?
- Almost never on its own. Slow pages are usually a specific, fixable performance problem — unoptimized images, an unnecessary script, a bloated plugin stack — not evidence that the whole site needs replacing. Treat it as its own project first.