When not to use AI for a page

Ask this before you open a chat: if this page were wrong, who would be embarrassed, and about what?

• Nobody, or the reader learns something slightly off: a model can draft it from your facts.
• A customer, because you quoted them: write it yourself.
• You, because you claimed something you do not believe: write it yourself.
• Your company, because the claim is a promise about money, data or safety: write it yourself, and have someone read it.

The line is not about quality of prose. A model writes clean sentences. The line is about accountability: who stands behind the claim, and whether the claim came from anywhere.

A model produces text from patterns in what it has read. Facts it was never given are filled with plausible substitutes: figures, features, dates, policies. That is not a flaw to be prompted away; it is how the thing works.

The six pages above are made almost entirely of facts it was never given. Your customer's number. Your reasoning. Your infrastructure. Your prices. Your history. Hand it those pages and it does what it always does: it produces the average version, confidently.

It also has no first-hand experience and no opinion, which is what the opinion piece and the method page are made of. It can imitate having one, which is worse than not having one.

The rule is not “keep the model away”. It is “keep the material yours”. Once the facts and the judgement exist, the model has work to do.

1. 1

   Interview you

   Ask it for the twenty questions a reader would ask about your method or your story. Answer them out loud, paste the answers back, and let it order them into sections.

2. 2

   Structure the case study

   Give it the customer's words, the before figure, the after figure and what was done. Ask for the standard shape: who, the problem in their words, what was done, the result, the quote.

3. 3

   Draft from your notes

   Your security page starts as a list of true statements from your engineer. The model turns the list into sentences. You check every one.

4. 4

   Write the questions, not the answers

   For a pricing FAQ, ask it what buyers ask. Answer each one yourself. The questions are pattern; the answers are policy.

5. 5

   Edit, once you have written

   Cut the length, plain up the register, catch the repetition. This is where it is genuinely good and where nothing is at risk.

Most pages are not in the six. Guides, explainers, comparisons, documentation and how-tos are drafted with a model every day without a problem, as long as the facts came from somewhere.

• A guide to a public subject: fine, with a brief and sourced facts.
• A comparison of your product with a rival: draft the structure, write the claims yourself, and check every feature on the rival's own site the day you publish.
• Product documentation: fine, from the actual behaviour, and only if someone who has used the feature reads it.
• An integration page: fine for the shape, not for the setup steps, which must be the ones that actually work.
• A page family generated per city, per tool or per combination: this is where the grey zone ends. Google's spam policies name scaled content abuse, which is producing many pages primarily to rank rather than to help, whoever produces them.

The SEO cost is the least of it. A thin guide ranks nowhere and you lose an afternoon. The other costs are larger and slower.

• A wrong claim on a pricing or security page is a promise you did not make, and the person reading it is about to pay you.
• A case study with a number the customer did not give you ends the relationship, and they will say why in public.
• An opinion piece you cannot defend is answered in the replies by someone who has done the work.
• A founder page that reads like everyone else's removes the one advantage a small product has over a large one.

Write those six yourself, badly if necessary. A plain page in your own words outperforms a polished page that is not true.