Anatomy of a product page that LLMs can actually quote

Most product pages were designed for two audiences: a human skimming on a phone, and a search crawler counting keywords and links. There is now a third reader — a language model deciding, mid-answer, whether your product deserves a sentence.

That reader behaves differently. It doesn't convert on emotion. It synthesizes an answer from fragments it can extract with confidence, and it strongly prefers fragments that look like facts: a number, a source, a clear subject. If your page's most important claims are "revolutionary performance" in a hero banner and a spec sheet inside a PDF, the model has nothing to work with — and it will build the answer from a competitor's page, or from a Reddit thread about you that you've never read.

This post walks the full anatomy, top to bottom. None of it requires new tooling. All of it requires discipline about what a claim is.

How an LLM actually reads your page

Whether the engine is ChatGPT with browsing, Perplexity, or Google's AI Overviews, the pipeline is roughly the same: retrieve a handful of pages, chunk them into passages, and synthesize an answer from the passages that best match the question — often with citations back to the source.³ Your page is not competing as a page. It's competing as a set of passages.

That framing changes the writing job. A passage wins when it can survive being ripped out of context: it names the product (not "it" or "our solution"), states a verifiable fact, and ideally carries its own evidence. The GEO study out of Princeton and collaborators quantified this — of nine tactics tested across ~10,000 queries, the winners were exactly the ones that make passages more extractable: adding citations, quotations and statistics, with visibility gains up to roughly 40%.¹ Keyword stuffing, the old reflex, did nothing.

The blueprint at a glance

Here is the full skeleton. Every zone has one job: hand the model a claim it can quote and attribute.

The H1 and the 40-word answer

Your H1 should name the category plus the differentiator, not just the product name. "Vellum" tells a model nothing. "Vellum CO₂ Sensor — wall-mount NDIR monitor for commercial HVAC" gives it the category (CO₂ sensor), the mechanism (NDIR), and the context (commercial HVAC) in one string. When a buyer asks "best NDIR CO₂ sensor for office buildings," the retrieval match starts at your H1.

Directly under it, write the paragraph you'd want quoted verbatim — roughly 40 words, fully self-contained:

"The Vellum C2 is an NDIR CO₂ sensor for commercial HVAC systems. It measures 0–5,000 ppm with ±30 ppm accuracy, ships pre-calibrated, and integrates with BACnet and Modbus. Typical installed cost is $310 per zone."

Test it by deleting everything else on the page. If that paragraph alone answers "what is this and should I care," it's ready. If it needs the surrounding page to make sense — pronouns, vague superlatives, no numbers — rewrite it.

Spec tables and evidence-first claims

Specs belong in a semantic HTML <table>, with one attribute per row and units in every cell. Not a PDF datasheet. Not a PNG export from your design tool. Retrieval systems chunk and parse HTML; a PDF two clicks away might as well not exist, and an image of a table is invisible text.

Then apply the evidence-first pattern to every claim that matters commercially. The formula is number + source + method:

The left column gives a model nothing it can repeat without embarrassment. The right column is exactly the kind of statistic the GEO research found engines love to lift.¹ If you don't have the number, that's a research task, not a copywriting task.

The FAQ section and its schema mirror

Your FAQ is not a dumping ground for objection handling — it's a retrieval surface. Source the questions from reality: sales-call transcripts, support tickets, and the questions buyers actually type into assistants. Keep the buyer's phrasing in the question ("Does it work with BACnet?" not "Interoperability options"), and make each answer self-contained in two or three sentences, because each Q&A pair will be judged as a standalone passage.

Then mirror the page in structured data: Product schema for the specs and offer, FAQPage schema for the Q&A.² Schema won't rescue a thin page, but it removes ambiguity — price, availability, and attribute names become machine-readable assertions rather than things a parser has to guess from your layout.³ Keep the JSON-LD in sync with the visible page; a schema price that contradicts the on-page price is worse than no schema at all.

The comparison section: name your competitors

This is the section most teams refuse to build, and it's the one with the most leverage. Buyer prompts are overwhelmingly comparative — "X vs Y," "best alternative to X" — and if you don't publish the comparison, the model builds it from whoever did, usually a competitor or an affiliate site with its own incentives.

Name the competitors. State honestly where each option wins: "Choose [Competitor] if you need a battery-free, energy-harvesting install; choose the C2 if you need BACnet integration and per-zone accuracy guarantees." Honest concessions do double duty: they make the passage credible enough to quote, and they steer the frame of comparison to the attributes where you're strong. A comparison page that declares you the winner on every row reads as marketing — to humans and models alike — and gets skipped.

Anti-patterns that make pages unquotable

Three failure modes account for most invisible product pages:

1. Marketing-speak as load-bearing copy. "Revolutionary," "next-generation," "seamless," "unparalleled" — a model can't verify any of it, so it can't repeat any of it. Adjectives aren't claims. Every superlative on the page is a slot where a number should be.
2. JavaScript-only rendering. If your specs, prices and FAQ only exist after a client-side framework hydrates, you're gambling that every AI crawler executes your JavaScript — and many fetch pages far more simply than Googlebot does. Server-render or statically generate anything you want quoted, and check by fetching your page with curl: what you see there is your worst-case representation.
3. Gated and buried facts. Specs behind a "download datasheet" form, pricing behind "contact sales," comparisons behind a login. Every gate is a wall between your facts and the answer. Gate the lead magnet if you must — never the product facts themselves.

The ship checklist

Before a product page goes live — or as an audit of the pages you already have:

• H1 names category + differentiator, not just the brand name.
• First paragraph is a liftable ~40-word answer containing at least two numbers.
• Specs live in an HTML table; the PDF datasheet is a supplement, not the source of truth.
• Every commercial claim follows number + source + method.
• FAQ questions match transcript phrasing; each answer stands alone.
• Product and FAQPage schema validate and match the visible content.
• The page renders meaningfully without JavaScript (verify with curl).
• A comparison section names real competitors with honest trade-offs.

One more habit worth stealing from measurement teams: after you rewrite a page, watch what changes. Mentions in AI answers move on retrieval timescales — days to weeks — so a rewrite in March should show up in sampled answers well before summer.⁴ If it doesn't, the page isn't the bottleneck; corroboration is.

Frequently asked questions