Websites do not need another redesign. They need an owner.

The pattern nobody names

Every agency owner I have spoken to recognises this sequence, though almost none of them have a name for it. A company rebuilds its site. For about four months it is genuinely good. Then a product launches and a page goes up quickly because the launch date was fixed and the page was not. Then someone changes pricing and three pages disagree about what a seat costs. Then a campaign needs a landing page, and it gets built from whichever template was closest to hand, by someone who will not be there in a year. Eighteen months later the site is worse than the one it replaced, and somebody proposes a redesign.

The instinct is to treat this as a design problem. It is not. The design was fine. In most cases the design is still fine on the day it gets thrown away. What failed was that nobody was responsible for the site as a running thing between the day it launched and the day it was declared broken.

I want to be careful here, because this can read as an argument against redesigns, and it is not. Sites do need rebuilding. Positioning changes, the company grows into a different shape, the visual language genuinely dates. Those are real reasons. What I am arguing is that almost none of the redesigns I have been asked to quote for were driven by those reasons. They were driven by eighteen months of small unattended decisions arriving all at once, and a redesign being the only line item anyone knew how to approve.

A redesign is the most expensive way to find out that nobody owned the site.

Why this is a business problem before it is a design problem

The cost of the redesign is the visible number. It is not the interesting one. The interesting number is what the site was costing while it was quietly wrong.

A pricing page that contradicts the pricing in the product costs you a support conversation on every deal that reads it carefully. A page that describes a feature by its old name costs you every search that used the new one. A dead link in the middle of a buying path costs you whoever hit it and did not email to complain, which is nearly all of them. None of these show up as a line item. They show up as a sales team that is slightly slower than it should be, and a founder who cannot work out why.

That is the part that makes this a founder problem rather than a marketing one. The failure is not visible in the place where the money is counted. It is spread across a hundred small interactions that each look like normal friction. By the time it accumulates into something visible, the only remedy anyone can articulate is starting over.

• The site was wrong, and nobody whose job it was noticed
• The people who noticed did not have permission to change it
• The people with permission did not know it was wrong
• Everyone assumed someone else was watching

How sites actually decay

Decay is not one thing. If you treat it as one thing you will apply one remedy, and it will only work on a quarter of the problem. In six years of looking after other people's sites I have found four distinguishable modes, each with a different cause and a different fix.

The table below is the version I now draw on a call, usually in the first fifteen minutes, because it is faster than asking someone to describe what is wrong with their website. People recognise their own site in one of these rows almost immediately.

Drift is the one that costs you deals

Drift is when two pages that should agree do not. It is the most common and the most expensive, because it is the one a buyer is most likely to catch at the worst moment.

Pricing is where it shows first, and it is almost never a mistake in the ordinary sense. Someone updated the plan limits on the pricing page, correctly, because that was the ticket. Nobody updated the comparison table on the competitor page, or the FAQ, or the sentence in the middle of the enterprise page that mentions seat counts in passing. Each of those was written by a different person for a different reason at a different time, and none of them was wrong when it was written.

The fix is not vigilance. Vigilance does not survive a quarter. The fix is knowing which pages are allowed to state a given fact, and having exactly one of them be the source. If four pages mention pricing, three of them should be pointing at the fourth rather than restating it. That is a content architecture decision, and it is the kind of decision that only gets made if somebody owns the site rather than owning tickets about the site.

Accretion is the one nobody wants to fix

Accretion is what you get when adding a page is easy and removing one is politically difficult. Every campaign adds a landing page. No campaign removes one, because removing one means telling somebody their work is over.

The result is a site where six pages address roughly the same audience with roughly the same argument, and the person about to send a link to a prospect has to guess. Usually they pick the one they remember, which is the oldest one, which is the one with the worst copy.

Removing pages is a real decision with real risk, and I would not have anyone do it casually. Some of those pages have inbound links, some rank, and some are being used by people you do not know about. But there is a difference between deleting a page and deciding which page is canonical. The second one is cheap, reversible, and fixes most of the harm. Pick the one that should exist, point the others at it, and stop the guessing.

Rot and silence are the ones you cannot see

Rot is straightforward and boring. Something was renamed or moved, and the references did not follow. Most teams catch it eventually, because eventually someone clicks the link. The problem is that eventually is measured in months, and the people who hit it in the meantime mostly did not tell you.

Silence is different and much harder, because there is nothing to look at. It is the page that should exist and does not. Your sales team answers a question every week. Your support inbox has the same thread forty times. None of that is connected to the site, so the question keeps getting answered one person at a time, and the page that would answer it for everyone never gets written.

Silence is the one I care most about, because it is the only decay mode where the remedy makes the site better rather than merely correct. Drift, accretion and rot are all about restoring a site to the state it was supposed to be in. Silence is about the site learning something it did not know at launch. That is the difference between maintenance and operations, and it is most of the argument for treating the site as a system that runs rather than a project that ended.

A site that cannot hear anything can only be redesigned. It can never be improved.

The four mistakes that produce this every time

None of these are stupid mistakes. Every one of them is a reasonable decision made by a competent person with incomplete information, which is exactly why they keep happening.

The first is scoping the build and not the year after it. Almost every website project I have quoted on has a detailed scope for the twelve weeks of the build and nothing at all for the eighteen months that follow. The budget is shaped the same way. Whatever is left over after launch becomes an ad hoc arrangement, and ad hoc arrangements are the first thing to go when a quarter gets tight.

The second is treating the CMS as the handover. Giving someone a well structured CMS is not the same as giving them the ability to keep the site correct. It tells them where to type. It does not tell them which pages are allowed to disagree with each other, or which facts have a single source.

The third is measuring output instead of state. A monthly report of tasks completed tells you the agency was busy. It does not tell you whether the site is currently right. Those are different questions and only one of them is the client's.

The fourth is assuming the person who noticed can act. In most companies the person most likely to spot that a page is wrong is in sales or support, and is the person least able to change it. If there is no route from noticing to changing, noticing is worthless, and after a few attempts people stop bothering.

What owning a site actually means

Ownership is one of those words that sounds like it means something and usually does not. Everybody agrees somebody should own the site. In practice this resolves to a marketing team that owns the roadmap, an agency that owns the build, a developer who owns the deploy, and nobody at all who owns whether the thing is currently correct.

The version that works is narrower and less impressive sounding. One named person can answer the question: which page on this site is currently wrong, and what are we doing about it. Not a team, not a function, a person. If the answer to that question requires a meeting, nobody owns the site.

The second half is that this person needs a record. Not a report, a record. A report says what was done in a month. A record says what changed on which URL, what it was meant to achieve, and whether it did. The difference matters because the report is written for the person paying and the record is written for the person who inherits the site in two years.

The handover is where most of this is decided

Almost every case of severe decay I have looked at traces back to a handover that did not contain enough. The site was built well, delivered on time, and given to a team who received a set of files and a login. Six months later nobody could remember which decisions were deliberate.

This is the checklist I now argue for at the end of a build. It is short on purpose. Long handover documents do not get read, and a document nobody reads is worse than no document, because it lets everyone believe the handover happened.

What good looks like when you are in it

A site that is being operated properly does not look dramatic. That is the thing people find hardest to sell internally. There is no launch, no reveal, no before and after slide. It looks like a site that is quietly still correct.

Concretely: pricing agrees with itself in every place it appears. The three questions your sales team answers most often have pages, and those pages get updated when the answer changes. There is one canonical page per audience, and campaign pages point at it rather than competing with it. When a product gets renamed, someone runs the rename through the site as a task rather than discovering it later. And somebody can tell you, without checking, which two pages they are currently unhappy with.

The last one is the real test. In a site with an owner, there is always a short list of known problems, because someone is looking. In a site without one, the list is empty right up until it is enormous.

How to evaluate whether you have this

You do not need an audit to find out. Four questions, answered honestly, will tell you more than most audits do, and they take about ten minutes.

If you can answer all four, you have an operations practice whether or not you call it one. If you cannot answer the first, the rest do not matter much, because there is nobody to act on the answers.

• Who is the one person who would know if a page were wrong today?
• Where is the record of what changed on the site in the last quarter, and what each change was meant to do?
• Which page is canonical for your main audience, and can the sales team name it without looking?
• What is the route by which a question asked three times in sales calls becomes a page on the site?

Where this connects to what we are building

We spent six years delivering Webflow sites for SaaS teams, startups and agencies, a good share of it white labelled behind other agencies. We shipped the site, the site was good, and then we watched a reasonable proportion of those sites decay in exactly the ways above. That is an uncomfortable thing to notice about your own work.

Creogen is the thing we are building because of it. It is a website intelligence and operations platform, which is a heavy phrase for a simple idea: tie every finding to a URL and a change, record what the change was meant to do, and check afterwards whether it did. Creobot is the other half, the conversation engine that gives the site somewhere to hear from, so the silence mode has an input.

Both are in private development and I would rather say that plainly than imply otherwise. Nothing in this article depends on either of them existing. The four decay modes and the handover checklist are just what six years of looking after other people's sites taught us, and they work with a spreadsheet.

The argument, condensed

If your site is due a redesign, ask what happened in the last eighteen months rather than what the new one should look like. If the answer is that it drifted, accreted, rotted and stayed silent, a new design will buy you four good months and put you back here.

The redesign is not wrong. It is just far more expensive than the thing that would have prevented it, and it does not prevent the next one. What prevents the next one is somebody whose job it is to know which page is currently wrong.