Websites rarely fail outright. They get slower to change, more awkward to explain, and quietly more expensive to keep, until one day somebody asks for something simple and the answer is "that would be a project".
That moment is the signal, and it almost always arrives long after the site stopped being adequate. Here are the symptoms we see most, what each one actually indicates, and — the part most redesign articles skip — whether it justifies a rebuild or just a repair.
Symptoms of an editing problem
Routine changes need a developer
Adding a service, a team member, a location or a case study should be a form your marketing lead fills in, not a ticket. If it is a ticket, the site has no content model — the content exists as hand-built pages rather than as structured entries, so every addition is bespoke work.
This is the single most reliable indicator that a site has been outgrown, because it compounds. Every month you do not add content is a month of distribution you did not get.
Everyone is afraid to touch it
If your team edits around the layout rather than through it — pasting into the one text block nobody has broken yet, duplicating a page because changing the template is risky — you are paying for a CMS you cannot use. The fear is usually rational and based on something that genuinely broke.
The site has two of everything
Two contact pages, three versions of the services list, an old pricing page nobody has unpublished, a blog category with one post in it. Duplication is the fossil record of a site that cannot be edited cleanly: when changing something is hard, people add instead.
Symptoms of a technical problem
Mobile is an afterthought that everyone has stopped mentioning
Not "it does not fit" — that gets fixed. The version worth noticing is a site that technically reflows but is clearly a desktop layout that has been squeezed: a nav that needs two taps to reach anything, forms with inputs that trigger zoom, tables that scroll sideways into nothing. If most of your traffic is mobile and most of your testing is desktop, this has been true for a while.
Speed fixes stopped working
A plateau is diagnostic. If you have added a caching plugin, an image optimiser and a CDN and the field numbers barely moved, the remaining weight is structural — the markup the platform generates, the stylesheet it loads on every page, the JavaScript it needs to render a layout. No plugin removes that, because the plugin is downstream of it. We go into what that costs in detail in the real cost of a page builder.
Nobody can say what is indexed
Ask how many URLs the site has. If the answer is a shrug, or Search Console shows thousands more than anyone expected, you have duplicate URLs, stale parameters or orphaned pages. That is a crawl-efficiency problem now and a migration risk the day you move.
Accessibility is an unknown
If nobody has run a keyboard pass or a contrast check, assume it fails. WCAG 2.2 became a W3C Recommendation in October 2023 and is increasingly the standard cited in procurement requirements and complaints. The relevant question is not whether you are perfect; it is whether you know where you stand. An unknown here is a live risk, not a nice-to-have.
Symptoms of a business-mismatch problem
The site describes a company you no longer are
You have moved upmarket, dropped a service line, added a second location, or started selling to procurement rather than to owners — and the site still leads with the old pitch. This one has nothing to do with technology and everything to do with cost per lead. It is also the symptom clients notice last and prospects notice first.
Your sales team works around it
Watch what sales actually sends. If they attach a PDF instead of linking a page, keep a personal deck of screenshots, or say "ignore the website, let me show you", the site has stopped doing the job the sales process needs. That is a content and structure failure, and it is measurable: the pages they wish existed are the pages to build.
Repair or rebuild
Most of the list above is repairable, and a redesign sold on the back of a repairable problem is a waste of money. Our rough test, in the order we apply it:
- Is the content model wrong? Rebuild. You cannot bolt structure onto a site whose content exists only as page layouts, and everything else gets cheaper once the structure is right.
- Is the platform the bottleneck? Rebuild — but prove it first. Measure what the platform itself emits on a page with no content: baseline CSS, baseline JavaScript, baseline DOM node count. If the empty page is already heavy, no amount of tuning saves it.
- Is the positioning wrong but the structure fine? Repair. New copy, new hierarchy, maybe new templates on the same stack. This is dramatically cheaper and often the whole win.
- Is it slow, with sound structure? Repair. Fix the dominant cause, measure, repeat. That is speed optimization, not a redesign.
- Is it broken in a handful of specific ways? Repair, and do not let anyone tell you otherwise. A list of twelve defects is a maintenance sprint.
What a rebuild is really buying
Not a new look. A good rebuild buys three things: a content model that lets your team publish without asking anyone, a performance baseline that holds because it was a requirement rather than a cleanup, and a URL structure you will not have to break again. The visual refresh is the part everyone talks about and the part that ages fastest.
If you are weighing a rebuild against a cheaper route, the two comparisons worth reading are custom build versus template and WordPress versus Webflow. Our ranges for both repair and rebuild work are on the pricing page.