Every landing page you ship becomes somebody else's problem

How a campaign page is actually born

Somebody needs a page for a campaign that launches in nine days. There is no time to think about where it sits in the site, so it gets built from whichever page was closest in shape, with the copy swapped. It goes live, the campaign runs, and it works or it does not.

Then nothing happens to it, ever. The campaign ends. The person who made it moves on to the next one. The page stays, because deleting it feels risky and nobody owns the decision. Two years later it is still there, describing a product tier that no longer exists, and it is the third result when somebody searches your company name plus that use case.

Nothing about this is anybody's fault. Every individual decision was reasonable under the constraint that existed at the time. The problem is that the unit of work was a page, and a page is a thing that has to keep being true long after the reason for making it has gone.

The cost nobody prices

A landing page has two costs and only one of them appears in any plan.

The first is production, and it is small and getting smaller. Templates, components, and now generation have all pushed it down to the point where making a page is nearly free. This is genuinely good and it is the reason the second cost has become the whole problem.

The second is ownership. Every page you ship is something that has to be checked when pricing changes, updated when a product is renamed, considered when the positioning shifts, and decided about when somebody asks which page to send. That cost is small per page and it is permanent, and it accrues to a different person than the one who made the page.

Because production is priced and ownership is not, the rational behaviour for anyone working to a deadline is to add pages. Everyone does. The accumulated result is a site nobody can hold in their head.

There is a version of this I have watched play out repeatedly. A marketing team is measured on campaigns shipped. Nobody is measured on how many pages the site has. So the incentive points one way only, and the site grows in exactly the way you would predict from the incentives rather than from anyone's intentions.

Making a page is nearly free. Owning it is not, and the bill goes to somebody who was not in the room.

Why isolated pages decay faster

There is a specific mechanism here rather than a general tendency toward entropy.

A page that nothing else depends on has no forcing function. When you change your pricing, the pricing page gets updated, because it is obviously the pricing page. A campaign landing page that happens to mention pricing in its third section does not get updated, because nothing points at it and nobody remembers it exists.

System pages have forcing functions built in. If your integration pages are produced from a data source, renaming an integration updates all of them, because they were never separate things. If your pricing is stated in one place and referenced elsewhere, changing it changes every reference at once. The site stays consistent because consistency is structural rather than remembered.

The difference is not discipline. It is that in one case being wrong requires somebody to fail to notice, and in the other case being wrong requires the data to be wrong.

The tell is duplication

If you want to know whether your site is a collection of pages or a system, count how many pages say almost the same thing.

Almost every site I have looked at has a cluster: four or five pages aimed at broadly the same audience, making broadly the same argument, none of which is quite the canonical one. They were made at different times by different people for different campaigns, and each was reasonable in isolation.

The cost shows up in a specific and slightly embarrassing place. Somebody in sales is about to send a link and has to decide which one. Usually they send the one they remember, which is the oldest, which has the worst copy and the stalest pricing. The newest and best page is invisible to the people most likely to benefit from it.

That is the whole argument for a content system, expressed as one behaviour you can go and observe this week.

One-off thinking against system thinking

The difference is not tooling. Both columns below are achievable in the same CMS with the same team. What differs is which questions get asked before a page is made.

The right hand column looks slower and is, for the first few pages. It gets faster from about the fifth, and the gap widens with every page after that.

The moment the economics flip

There is a point where one-off page thinking stops being cheaper, and it arrives earlier than people expect.

For the first three or four pages of a kind, doing it as a one-off genuinely is faster. There is no model to design, no data source to set up, no argument about fields. Anyone who tells you to build the system first for three pages is optimising for elegance rather than for the business.

By about the fifth, the arithmetic changes. Now every change to the shared shape is five edits. Every product rename is five edits. Every person who wants to know which one is canonical asks a person rather than looking. And the fifth page was built by copying the fourth, which was built by copying the third, so a mistake in the second is now in all of them.

The tell that you have passed the point is that somebody has started maintaining a spreadsheet of which pages exist. That spreadsheet is a data model with no system attached to it, and it is a strong signal that the model should move into the site.

What a content system actually is

The phrase gets used to mean a template library, which is the least interesting part of it. Templates are how the pages get rendered. They are not what makes the thing a system.

Three decisions make it a system. First, which page types are allowed to exist, and what each one is for. Not which templates exist, which types: an integration page, a use case page, a comparison page, each with a stated purpose. Second, where each fact lives, so that pricing, plan names and product names have exactly one authoritative source and everything else references it. Third, who owns each type, and when instances of it get reviewed.

None of those is a technical decision, which is why buying a better CMS does not deliver a content system. The CMS makes it possible. The decisions make it real.

Where teams get this wrong

Building the template library and stopping. The components are lovely, the pages are still one-offs, and the duplication continues. Templates without page types just make it faster to produce the mess.

Treating the system as a constraint on marketing. If the only effect is that a campaign page now takes three days instead of one, the system will be routed around, and it deserves to be. A system that works makes the common case faster and the unusual case explicit.

Modelling everything as a collection. Not every page is an instance of a type. Your homepage is not, your about page is not, and the argument pages that carry your positioning usually are not. Forcing those into a data model makes them worse. The system is for pages that repeat.

Never deciding what gets removed. If the system defines what may exist but not what expires, you have a tidier version of the same accumulation. Every page type needs a review date and somebody who owns the decision.

What good looks like

The visible signal is that a person in sales can name the page to send for each of your main audiences, without checking, and is right.

Underneath that: pricing appears authoritatively in one place and by reference everywhere else, so a pricing change is one edit. Renaming a product updates every page that names it, because they all read it from the same field. There is a list of page types, it is short, and adding a new type is a deliberate conversation rather than something that happens by accident when somebody copies a page.

And there is a small amount of friction in exactly the right place. Making the fifteenth integration page is instant. Inventing a sixteenth page type requires somebody to say what it is for. That is the trade, and it is the right way round.

How to evaluate where you are

Five things you can check this week, mostly by asking people rather than by looking at the site.

The second one is the most diagnostic and the most uncomfortable, because the answer is usually a number nobody has said out loud.

• Ask two people in sales which page they send for your main use case. Do they agree?
• Count the pages that make substantially the same argument to the same audience.
• Change a plan name on paper and count how many pages would need editing.
• Ask who owns your integration pages. If the answer is a team, ask which person.
• Find a page that has not been touched in eighteen months and read it. Is it still true?

Who this is actually hard for

The technology has been available for years, so it is worth asking why most sites are still collections of pages. The obstacle is organisational and it is fairly specific.

A content system requires somebody to say no to a page. Not often, and not aggressively, but the system only holds if inventing a new page type requires a conversation. In most companies the person who could say no is not in the room when a campaign page gets made, and the person who is in the room has a deadline.

It also requires accepting a small amount of friction in exchange for a large amount of consistency, which is a trade that is easy to agree to in principle and hard to hold under pressure in a specific instance. The first time somebody needs a page in two days and the page type does not exist, the system either bends deliberately or gets routed around permanently.

The version that survives has an explicit escape hatch: an unstructured page is allowed, it is marked as temporary, and it carries a removal date. That way the exception is visible instead of quietly becoming the sixth duplicate.

Getting from one to the other

Nobody rebuilds their way into this and you should not try. The route that works is incremental and starts with the cluster you already have.

Pick the group of pages that duplicate each other most. Decide which one is canonical. Point the others at it rather than deleting them, because deleting has real risk and pointing has almost none. That single move fixes the sales problem immediately.

Then take the most repeated page type you have, usually integrations or use cases, and move it to a data source. Not all of them, one type. You will find out quickly whether the model is right, and the cost of being wrong is one type rather than a site.

Then decide where pricing lives and make every other mention a reference. That is usually a day of work and it removes the most expensive category of drift.

Three moves, none of them a rebuild, and the site is materially more durable than it was.

Why we care about this

Six years of Webflow delivery for SaaS teams and agencies, and the pattern was the same regardless of who built the site. The sites that stayed good were the ones where somebody had decided which pages were allowed to exist. The sites that decayed had excellent templates and no answer to that question.

Creogen is being built around the operational half: which pages state the same fact, which of them disagree, and which one is supposed to be canonical. Creobot sits on the input side, collecting the questions visitors ask that no page currently answers, which is the most honest source of what should be written next. Both are in private development.

The three moves above need none of that. They need somebody with the authority to say which page is canonical, which is usually the actual constraint.