Generating the page was never the expensive part

The part that was already cheap

Every few months a founder asks me whether they should be generating pages at scale, and what it would do to their marketing budget. It is a fair question and the honest answer starts somewhere unhelpful, which is that page production has been getting cheaper for fifteen years and websites have not correspondingly improved.

It is worth remembering how much page production has already fallen in cost before treating generation as a step change.

Fifteen years ago a new page meant a developer. Then templates meant a page meant a designer. Then component systems meant a page meant a marketer with an afternoon. Then no code builders meant a page meant a marketer with an hour. Each of those was a genuine reduction and each of them was received as transformative.

None of them reduced the number of websites that decay. Sites did not get better as pages got cheaper to make, and in several respects they got worse, because the constraint that used to limit page count was cost and that constraint stopped applying.

Generation is the next step on the same line. It is real and it is useful and it acts on the part of the problem that was already the least expensive.

The two costs that have not moved

There are two things a website costs that generation does not touch, and both of them are judgement rather than production.

The first is deciding a page should exist. Which page, for whom, answering what, and why this one rather than the eleven other things somebody suggested. That decision requires knowing your buyers, your sales conversations and what your site already says. A model has none of that unless somebody supplies it, and supplying it is the work.

The second is keeping the page correct after it exists. Pricing changes, the product gets renamed, the positioning shifts, and the page that was right in March is wrong by October. That is not a writing task, it is an ownership task, and it recurs for as long as the page exists.

Both of those are the expensive parts of a website, and neither has become cheaper. Which means that making the cheap part cheaper changes the total cost of a website less than anybody expects.

What actually happens when you generate a lot of pages

I want to be careful here because this is where the argument usually becomes a complaint about quality, and quality is not really the issue.

Generated pages are often fine. The problem is not that they read badly. It is that a site which produces pages faster than it can decide about them accumulates faster, and accumulation is the failure mode that already governs most sites.

So the observable outcome is a site with a great many pages, several of which say almost the same thing, none of which anybody has decided is canonical, and all of which now have to be kept correct by a team that is the same size it was before.

The decay is not different in kind from what happens without generation. It arrives sooner and at a larger scale, which is the same problem with the clock sped up.

Making pages cheaper does not make a website better. It makes whatever your site already does happen faster.

Generation against operations, honestly compared

The two are often discussed as competing approaches, which is wrong. They act on different parts of the problem and a site needs both. The comparison below is about what each one can be responsible for.

The row worth reading twice is the last one, because it is the one that determines whether the site is better in two years.

Where generation genuinely earns its place

None of the above is an argument against using it, and I do not want to be read as a person telling founders to write everything by hand.

Drafting against a decision somebody already made. The gap is identified, the sources are named, the audience is known. Turning that into a first draft is real work removed, and it is the case where the output is most reliably good, because the hard input was supplied.

Producing structural variants of a thing that genuinely repeats. Integration pages, location pages, comparison pages where the underlying facts come from a data source. This is a real use and it is also where the discipline matters most, because the difference between this and thin page generation at scale is entirely whether the underlying data is real.

Rewriting for a different reader. The same argument for a technical buyer and an economic buyer is a legitimate translation task and a genuinely tedious one.

Finding inconsistency. Reading forty pages and reporting which ones disagree about pricing is a task a model is good at and a person is bad at, and it is the operations direction rather than the production direction.

Where it fails, specifically

Four failures worth naming, all of which I have watched happen rather than predicted.

It cannot tell you that a page should not exist. Ask for twenty pages and you get twenty pages. The judgement that fourteen of them are the same page is not available unless somebody applies it, and the person who asked for twenty is not usually the person who will notice.

It cannot know what your company decided. Product names that were argued about, positioning that was chosen over an alternative, wording a lawyer approved. All of that looks like ordinary prose and gets improved.

It cannot see the rest of your site unless you give it to it. So the natural output is a page that is internally coherent and externally contradictory, which is the hardest kind of wrong to notice because nothing on the page looks off.

And it does not reduce the ownership burden by a single page. Every generated page is another thing that needs to be correct in eighteen months, and the generation step supplied no owner.

The economics nobody runs

There is an arithmetic here that almost nobody does before committing to a generation programme, and it is not complicated.

Take the number of pages you intend to produce. Multiply by the number of times per year something on your site changes that would affect them: a price, a plan name, a product rename, a positioning shift. That is the number of page reviews you have just committed somebody to, annually, forever.

Then ask who that somebody is and how many hours they have. In most companies the honest answer is that the person is the same marketer who was already behind, and the hours do not exist.

I am not going to attach numbers to this because they depend entirely on your site and your rate of change. But doing the multiplication once, out loud, in the meeting where the page count is being decided, changes the conversation more than any argument about quality does. The page count stops being a target and becomes a liability with a maintenance schedule attached.

The version of this that works is to pick the number of pages you can keep correct rather than the number you can produce. Those are very different numbers and only one of them appears in most plans.

The question that sorts good uses from bad ones

Before generating anything, one question sorts most of it: was the decision made by a person, and can you name them.

If a person decided this page should exist, for this audience, answering this question, and generation is producing the draft, that is a good use and the output will usually be good.

If the decision was made by the volume of pages you wanted, generation is doing the part nobody was struggling with and creating obligations for people who were already behind.

This is not a sophisticated test and it does not need to be. Most of the bad outcomes I have seen came from a plan that specified a number of pages rather than a set of questions to answer.

The one use I would prioritise above all the others

If a team asked me where to point generation first, I would not point it at producing pages at all.

Point it at reading your existing site and telling you where it contradicts itself. Which pages state a price and whether they agree. Which product names are in use and whether any of them are retired. Which pages describe a feature that has changed. Which questions your sales team answers have no page behind them.

That is a reading task across a large corpus, which is exactly what these systems are good at and what a person is genuinely bad at, because it requires holding forty pages in mind at once without getting bored.

It also produces something a founder can act on immediately, which drafting a new page does not. And it is the direction that makes the site better rather than larger, which is the whole distinction this article is about.

The reason almost nobody does this first is that it produces a list of problems rather than a list of deliverables, and lists of problems are harder to celebrate.

Where teams get this wrong

Measuring output. Pages published per month is the easiest thing to count and the least informative. A team that doubles its page output and does not change what its site says has spent money to make the site harder to maintain.

Treating the model's fluency as a signal of correctness. Generated pages are confident by construction. Confidence is not evidence and a page can be well written and factually stale in the same sentence.

Skipping the source decision. If you cannot say which page authoritatively states a fact, generating a fourth page that also states it makes the situation worse rather than better.

Deferring ownership. The most common version is that the pages get generated in a project and assigned to nobody afterwards, which is the same handover failure as a rebuild, arriving faster.

What good looks like, and how to check

A team using this well does not publish more pages. In several cases they publish fewer, because the decision step became explicit and rejected things that would previously have gone through on momentum.

What changes is where the time goes. Less time producing drafts, more time deciding what should exist and checking that what exists is still true. That is a better allocation and it is not the one most tools are sold on.

Concretely: every generated page traces to a question somebody actually asked. There is one authoritative page per fact and generation references it rather than restating it. Every generated page has a named owner and a review date from the day it ships. And somebody is running consistency checks across the site, which is the part generation is genuinely good at and is almost never used for.

Four questions, answerable in a conversation rather than a dashboard.

The last one is the one that matters most and is asked least.

• Can you name the question each generated page answers, and where that question came from?
• Has the number of pages saying substantially the same thing gone up or down?
• Does every generated page have a named owner and a review date?
• In six months, will anybody notice if one of these pages becomes wrong?

Where Creogen fits, and the short version

Creogen is a website operations platform and it is in private development. I would rather say that plainly than describe it as more finished than it is, because the argument in this article does not need it to exist.

What it is designed to do is the right hand column of that table. Tie findings to specific URLs. Record which pages state the same fact and which of them disagree. Record what a change was meant to achieve and check afterwards. Notice when a page has not been reviewed in a year.

What it is not is a page factory with better marketing. Generation sits inside it as one step in a loop that starts with a question somebody actually asked and ends with a check on whether the change helped. Creobot supplies the first half, collecting the questions visitors ask that no page answers.

Neither is required for anything above. The comparison table is a conversation you can have with your team this week, and the ownership question costs nothing and predicts most of the outcome.

Page production has been getting cheaper for fifteen years and websites have not got correspondingly better. That should tell you where the constraint actually is.

The constraint is deciding what should exist and keeping it right. Generation acts on neither and speeds up everything around them, which on a site with an owner is genuinely useful and on a site without one is an accelerant.

So the question to answer before generating anything is not how many pages. It is who decided, and who owns it afterwards.