Most pages cannot be quoted, and that is a structural problem

The three things an answer engine needs

A client asked me last year why their competitor kept getting quoted in AI answers and they did not. Their page was better. Better written, better designed, more accurate, and it had been through two rounds of review by people who knew the product. The competitor's page read like it had been assembled by someone in a hurry. It was getting cited anyway.

The answer had nothing to do with quality and everything to do with shape. This is a commercially annoying thing to tell someone who has just paid for a copywriting exercise, so it is worth being precise about what is actually going on.

When something quotes your page, whether that is a search summary, a chat assistant, or somebody's internal tool, it has to do three things in order. Find the claim. Work out where the claim starts and stops. Decide that the claim belongs to you and can be attributed.

Most marketing pages make the first one possible and the second one nearly impossible. The claim exists somewhere on the page, but it is threaded through two paragraphs of positioning, so any extract either cuts it off or carries the positioning with it. A system that has to choose between quoting something incomplete and quoting something that reads as an advert usually quotes neither, and moves to a page that made the choice easier.

This is a structural property of the page, not a quality of the writing. Some of the least quotable pages I have looked at are beautifully written. The prose is doing a different job, which is carrying a reader from interest to conviction, and that job requires exactly the continuity that makes extraction hard.

Good persuasive writing and good quotable writing pull in opposite directions. A page can do both, but not in the same paragraph.

Where the claim sits

Take a real shape you will recognise. A section headed something like Built for teams that move fast. Underneath it, three paragraphs. The second sentence of the second paragraph mentions that the platform supports single sign on for enterprise plans. That is the claim somebody will eventually search for.

It is unfindable in any useful sense. The heading does not mention it. The paragraph is about something else. There is no boundary around it. A system looking for whether you support single sign on has to read the entire section and infer, and inference is exactly what a careful system avoids on factual questions.

The fix is not to delete the persuasive writing. It is to make sure the claim also exists somewhere with a boundary around it: a specification row, a plain heading with a plain sentence under it, a FAQ entry. The persuasive version and the extractable version can both exist on the same page. Most pages only have the first.

The heading is doing the most work

If I could change one thing on most marketing sites it would be the headings. Not for keywords, which is the usual reason given and the wrong one, but because headings are the only structural signal most pages have about what is where.

A heading that reads Built for teams that move fast tells a machine nothing about the content beneath it, and it tells a skim reading human very little either. A heading that reads Single sign on and provisioning tells both exactly what follows. The first is a positioning statement wearing a heading's clothes.

The version I use as a test is whether the heading would still make sense as the answer to a question. Does this plan include single sign on. How does billing work when we add seats. What happens to our data if we cancel. If the heading answers a question a real person asks, the section under it is findable. If it announces a theme, it is not.

Bounding: the part nobody thinks about

Bounding is knowing where a claim ends. It sounds trivial and it is the most common failure I see.

A paragraph that starts by stating a limit and ends by describing an exception to that limit is one claim in human terms and two contradictory claims in extractable terms. Whatever quotes the first half is now wrong. Whatever quotes the whole thing is quoting something too long and hedged to be useful.

The practical remedy is to give the exception its own boundary. The limit gets a sentence. The exception gets a sentence, or a row, or its own line in a list. This makes the page slightly less elegant to read and considerably more useful to quote, and on pages that carry facts rather than argument, that is the right trade.

Tables are the strongest bounding device available and they are underused on marketing sites because they look less designed. A table row is unambiguous about where a claim starts and stops, which is why specification tables get quoted so much more often than the prose around them.

Attribution: one page should own each claim

The third requirement is that the claim can be attributed. In practice this means the system has to decide which page is authoritative for a fact when several pages mention it.

If your pricing is stated on the pricing page, restated on the enterprise page, summarised on the comparison page and mentioned in a blog post, you have four candidates and no signal about which is current. Worse, in most sites they will not agree, because three of them were updated at different times.

Restating a fact does not reinforce it. It dilutes it. One page should own each claim, and the others should point at it. That is a content architecture decision rather than a writing one, and it is the same decision that stops your site drifting into contradiction internally, so it pays twice.

How to tear down one of your own pages

This is the pass I run when someone asks why a page is not getting cited. It takes about twenty minutes per page and needs no tooling.

Do it on the page you most want quoted, not on your homepage. Homepages are usually the least quotable pages on a site and that is largely fine, because they are answering a different question.

A worked teardown, in the abstract

Take a security page, the kind almost every B2B site has. It usually opens with a paragraph about taking security seriously, then covers encryption, access control, compliance and data handling in prose, then ends with a contact line for the security team.

Every fact a buyer needs is on that page. Almost none of it is quotable. Encryption at rest is mentioned inside a sentence that also mentions encryption in transit and a compliance framework, so no extract covers one without the others. Access control is described as a philosophy rather than stated as a capability. The data retention period, which is the single most asked question on a page like this, appears once as a subordinate clause.

The restructure does not require new information. Give each of the four areas a heading that states the fact rather than naming the topic. Move retention into a two column table with the other data handling facts, because a table row has edges and a subordinate clause does not. Leave the opening paragraph exactly as it is, because it is doing a real job for a human reader and no machine needs to quote it.

The page gets slightly longer, reads about the same, and goes from having roughly one extractable claim to having eight. That is the whole exercise. It is unglamorous and it takes an afternoon.

Where teams get this wrong

The most common mistake is doing this as a keyword exercise. Somebody decides the page should be quotable, and the remedy applied is inserting the phrasing they think a machine wants. The result is a page that is worse to read and no more extractable, because the underlying structure did not change. Adding a keyword to an unbounded paragraph produces an unbounded paragraph with a keyword in it.

The second is adding an FAQ block that repeats the page. FAQ sections are genuinely useful for bounding, and they are useful because they contain questions people ask that are not answered elsewhere on the page. An FAQ that restates the three paragraphs above it adds nothing and creates another candidate for the same claim.

The third is treating structured data as separate from the page. Markup that describes something the page does not say is worse than no markup. It is checkable, and when the check fails you have told an automated system that you are unreliable.

The fourth is applying this everywhere. Pages whose job is persuasion should stay persuasive. This work belongs on the pages that carry facts, which is usually pricing, specifications, integrations, security and support.

How to evaluate whether this worked

You cannot really measure this by watching rankings, because too much else moves at the same time and the attribution is hopeless. There are two checks that are actually informative.

The first is manual and immediate. Ask a few different assistants the question your page is supposed to answer, and see whether the answer resembles your page and whether it cites you. Do it before the restructure and after. This is not a metric, it is an observation, and it is more honest than pretending you have isolated a variable.

The second is internal and more useful over time. Count how often your sales or support team still has to answer the question the page now answers. If the page is genuinely quotable it is usually also genuinely findable by humans, and the repeat question rate drops. That number is yours, it is not affected by anyone else's ranking algorithm, and it points at the thing you actually cared about.

• Ask two or three assistants the question the page answers, before and after
• Check whether the answer resembles the page, and whether it cites the page
• Count how often the question still reaches sales or support
• Check that the structured data still says the same thing the prose says
• Confirm no other page on the site now contradicts the restructured one

What good looks like

A quotable page does not read like it was written for a machine. That is the test, and it is why the keyword version fails it.

It reads as a page where somebody decided what questions it was answering and then answered them in order. The headings say what is underneath. Facts sit in places with edges: a table row, a short paragraph under a plain heading, a list item. Exceptions have their own lines instead of being appended to the rule. There is one place on the site where each fact is authoritative, and the structured data agrees with the prose.

Read aloud, that page is often better for humans too, which is the part that makes this worth doing regardless of what any answer engine does next year. Someone skimming for whether you support single sign on has the same problem a machine does.

Why this connects to what we build

This is the least tool dependent thing we write about. Everything above is a structural edit somebody can do in an afternoon with no software at all.

Where it connects is that keeping it true is the hard part, not making it true once. The moment somebody restates pricing on a fifth page, the attribution problem is back. Creogen is being built to notice that: which pages state the same fact, which of them disagree, and which one is supposed to be canonical. Creobot sits on the other side, collecting the questions visitors ask that no page currently answers, which is the most reliable source of what should be written next.

Both are in private development. The teardown above works today with a spreadsheet and twenty minutes, and I would rather you did that than waited for anything of ours.