Last updated: November 1, 2026.
The bot has reached your page. Chapter 9 covered how to check that: which bots show up, what they see on the page and what they miss. But reaching a page isn’t enough to get its information into an AI answer. The model has to be able to read the page, understand what it says and lift the right passage into its answer.
In Chapter 3 we saw that AI uses pages in pieces rather than as a whole, and that Google pushes back on chopping content into bite-sized chunks for AI. Put those two together and the job becomes clear. We’re not writing a separate page for AI. We’re taking a page written well for readers and organizing it so a machine can read it easily too. That organization comes down to headings, where the answer sits, definitions, paragraphs, tables and numbers. Structured data (Schema) turns out to be a smaller part of it than most people think.
1. A citable page
If you can take an important paragraph from the page, put it somewhere else, and it’s still correct, clear and obviously yours, the page is citable.
That definition asks for three things. The text has to be readable, meaning it sits in the page’s HTML in a form a machine can extract; not inside an image, behind JavaScript or on page 14 of a PDF. Each section has to say what it answers through its heading and first sentence. And each paragraph has to carry its own context, give concrete information and be verifiable.
There’s data linking these qualities to citations. In February 2026, Kevin Indig published an analysis of 18,012 verified citations drawn from about 1.2 million ChatGPT answers (Search Engine Journal):
- 44.2% of citations came from the first 30% of the text.
- Definitive, defining language appeared in 36.2% of highly cited text, compared with 20.2% in rarely cited text.
- In highly cited text, the density of proper nouns and specific entities was 20.6%.
This is correlation, not causation, and it covers one platform over one period. But it lines up with what good editors have said for years: Put the answer first, say it plainly, be specific.
2. Headings that read like a table of contents
Google’s guide to generative AI search recommends organizing content into paragraphs and sections with clear headings that make it easy to navigate. The same guide says perfect semantic HTML isn’t required, but you should use it where you can because it also helps other users, such as people using screen readers (Google Search Central).
Here’s a simple test. Delete every paragraph on the page and keep only the headings. Does what’s left tell you what the page answers? “General Information,” “Details” and “Features” fail. “Filling speed for foaming products,” “Which bottle sizes does it work with?” and “Service and spare parts lead times” pass.
Use a single H1 that states the page’s main topic. H2s should carry the main questions a user asks when deciding, or the main sections of the page, and H3s the details under them. Heading levels are chosen for structure, not design; using an H2 just to make text look bigger breaks the structure. Keep each section to one topic. If capacity, service and price are all covered under one heading, it gets harder to pull the right passage out of that section.
In the same guide, Google also asks that the main content be easy to tell apart from everything else on the page. Text that gets lost among menus, promo banners, pop-ups and related-product boxes wears out readers and machines alike.
3. Putting the answer first
Journalism has a rule called the “inverted pyramid”: the most important information first, the details after. In AI search that rule is worth more than it used to be. In Indig’s data, nearly half of all citations came from the first third of the text.
The rule works on two levels. The page’s first paragraph should answer the page’s main question: on a product page, what the product is, who it’s for and how it mainly differs; in a guide, the short answer to the question. And the first sentence under every heading should answer that heading. Details, conditions and exceptions come after.
Say a filling machine manufacturer’s page has a heading that reads “Which filling system works for foaming products?” The paragraph below it could start in one of two ways:
- “Since 1998, our company has been producing solutions for the industry, tailored to the different needs of our customers…”
- “The most common method for foaming products is submerged-nozzle filling; because the nozzle starts filling from the bottom of the bottle and rises with the liquid, it reduces foaming.”
The first doesn’t answer the question. The second gives the answer, explains why and can be quoted on its own. A section where readers can’t find what they’re looking for in the first sentence is no use to AI either.
This doesn’t mean shortening the page. Google’s guide says plainly that there’s no ideal page length. Once the answer is up front, you can add as much detail, examples, exceptions and comparison as you like.
4. One-sentence definitions
Some of the most common questions people ask AI are definitions: “What is a submerged nozzle?”, “What does piston filling mean?”, “What does a CIP system do?” The answer is usually a single sentence. For the model to take that sentence from your page, the definition has to be written on your page as a clear sentence.
A good definition has three parts: the term, the category it belongs to and the feature that sets it apart from others in that category.
A piston filling machine is a filling machine that measures liquid by volume using a cylinder and piston; this method is used especially for thick products such as creams and pastes.
That sentence has the term (piston filling machine), the category (filling machine) and the distinguishing feature (volumetric measurement with a cylinder and piston). It still makes sense when lifted off the page.
Be definite, but don’t overstate. Adding “usually,” “in some cases” or “may” to every sentence blurs the text. Claims like “the best” or “the only solution” make you an unreliable source if they aren’t true. Use definite language for information that is definite.
Call the same thing by the same name every time. If one page says “submerged nozzle,” another “diving nozzle” and a third “bottom-up filling,” readers and machines both have to guess whether these are the same thing. If there’s a synonym, mention it once where the term first appears, then stick to one term.
Put the definition where the term is used, too. A separate glossary page can help, but the product or guide page where the term first appears should also include a short definition.
5. Paragraphs that stand on their own
In Chapter 3 we said every paragraph should carry its own context. That’s harder to do than it sounds, because we all write as if the text will be read from top to bottom.
The most common problem is words that leave the context in the previous paragraph: “this model,” “the system in question,” “as mentioned above,” “for this reason.” Here’s the same information written two ways:
- Before: “This model’s nozzle count can be increased. That doubles the capacity.”
- After: “The X-200 filling machine’s nozzle count can be increased from 4 to 8. With that change, hourly capacity roughly doubles.”
The second version is a little longer, but it stays correct when taken out of the paragraph. You can tell which machine it is, what changed and what the result was. It also fits Indig’s finding that highly cited text has a high density of proper nouns. Specific names, such as a model, brand, city or standard, make a paragraph understandable on its own.
The goal isn’t to repeat your brand name in every sentence or to cut the text into small chunks for AI; we saw Google’s warning about that in Chapter 3. The goal is that a reader who lands directly on a section doesn’t get lost. The same goes for someone who drops into the middle of the page from a search result, a link or an AI answer.
6. Tables for comparisons
If you need to compare several items on the same attributes, a table is the best tool. Model comparisons, technical specs, pricing tiers, capacity ranges and compatibility lists are much easier to read in a table. Think of the user from Chapter 1: for someone asking about “3,000 bottles a day, foaming product,” the easiest thing to read is the matching row of a table.
The table below is for a hypothetical manufacturer. The model names and values aren’t real:
| Model | Filling method | Nozzles | Capacity (bottles/hour) | Suitable for foaming products? |
|---|---|---|---|---|
| X-100 | Piston | 2 | 400–600 | No |
| X-200 | Submerged nozzle | 4–8 | 800–1,600 | Yes |
| X-400 | Submerged nozzle | 8–12 | 1,600–2,400 | Yes |
In this table the unit sits in the header: “Capacity (bottles/hour)” instead of just “Capacity.” That leaves only numbers in the cells and makes comparison easier. Each cell holds one value; writing “4–8, optional 12, on request” in a cell turns the table back into text. There are no merged cells either. Merged cells look tidy, but for a machine they blur which value belongs to which row. And there’s a sentence before the table saying what it compares.
Above all, the table has to be a real HTML table. A table inside an image, in a PDF catalog or filled in later by JavaScript doesn’t exist for some of the bots we discussed in Chapter 9. A manufacturer that uploads its spec sheet as a catalog image is hiding its most valuable information from machines.
Tables aren’t the right tool for everything. Explaining a process, a reason or the logic behind a decision takes a paragraph. Tables answer “what” well; text answers “why” and “when.” The best pages use both: the table compares, and the paragraph below it explains which row to pick in which situation.
7. Lists, steps and FAQs
Lists carry structure too, but each kind has its own job. Numbered lists are for things with an order: installation steps, maintenance routines, order stages. If changing the order changes the meaning, use numbers. Bulleted lists are for parallel items with no order: suitable product types, cities with service coverage, what’s in the box. A reason, a condition or the logic of a comparison needs a paragraph; break it into bullets and the connections get lost.
Overusing lists is a problem as well. On a page where everything is a bullet, it’s no longer clear why any piece of information is there. I find this split works: lists for what readers will scan, paragraphs for what they need to understand.
The FAQ section is a special case. Done right, it’s one of the most valuable sections for AI search, because it answers the user questions we covered in Chapter 6 directly. Doing it right takes three things:
- Real questions: the ones your sales team, call center and customer emails bring up most. Not marketing questions like “Why should you choose us?”
- The answer in the first sentence. “Does it work with foaming products?” should start with “Yes” or “No,” followed by which model and under what conditions.
- Answers consistent with the rest of the page. If the FAQ says “4-week lead time” and the product description says “6–8 weeks,” AI has to pick which one to pass along.
As of May 7, 2026, Google stopped showing FAQ rich results in search (Search Engine Journal). That doesn’t make the FAQ section less valuable; it just means FAQ markup no longer produces a visible result on Google. We write the FAQ for readers anyway.
8. Numbers with units, conditions and dates
The information AI passes along most often is concrete: capacity, price, lead time, dimensions, address, date. In Chapter 3 we saw that AI can state wrong information with full confidence. A good part of that risk comes from concrete information that’s vague or out of date.
Write numbers with units: “1,600 bottles an hour” instead of “high capacity,” “6–8 weeks after order” instead of “fast delivery.” Put the condition next to the number, too. “1,600 bottles an hour (500 ml, water-thin product)” gets quoted far more safely than a number whose condition sits in another paragraph.
If you publish prices, include the currency and the date they’re valid from. If you don’t, say so clearly and explain what the price depends on; otherwise AI fills the gap from another source. On pages with pricing, regulatory or technical information, show the last-updated date, but only change it when the content changes. Updating the date without touching the content misleads readers.
If you cite a standard, a test result or a statistic, link to the source. That’s the on-page version of the trust signals we covered in Chapter 2.
Then there’s the single source of truth. If the same information appears in several places on your site (product page, PDF catalog, FAQ, blog post, campaign page), it has to match everywhere. If you don’t know where a value appears when it changes, sooner or later the old value survives somewhere, and AI finds it.
The same logic applies to the pages you open to indexing. In the Filmler.com example from Chapter 2, out of roughly 450,000 cast and crew records we opened only the pages with content to indexing, not all of them. Keeping empty or thin pages out of the index also cuts down the number of wrong or inadequate sources AI might read.
9. Where structured data helps
Structured data means marking up the information on a page in a standard format machines can read easily. The most common vocabulary is Schema.org and the most common format is JSON-LD. Google also recommends JSON-LD where possible (Google Search Central).
Google says it uses the structured data it finds on the web to understand page content. Instead of guessing whether a number is a price, a stock count or a model number, it can read it. Structured data is also still required for rich results such as product, price, availability, review rating and business information, which is why Google’s AI guide recommends you keep using it.
On the commerce side, having price, availability and shipping information match across the page, the markup and the product feed is the foundation of the shopping experiences we’ll cover in Chapter 15. Markup also connects entities. Organization markup tells machines your brand name, logo, address and official profiles; Product markup gives the product’s brand and model; Article markup gives the author and publish date. Brands and entities are covered in Chapter 13.
Microsoft is sending a similar message. According to Search Engine Land, Bing’s Fabrice Canel confirmed at SMX Munich that Schema markup helps Microsoft’s large language models understand content (Search Engine Land).
For a manufacturer or e-commerce site, Organization (on the home page), Product and Offer (on product pages), LocalBusiness (if you have a physical address or branch), Article (on blog posts and guides) and BreadcrumbList (for page hierarchy) are enough to start with. Getting these right and consistent is worth more than adding dozens of types halfway.
10. What not to expect from Schema
AI search has loaded structured data with big expectations. Advice like “Add Schema for AI and get cited” is everywhere. The evidence we have doesn’t support it.
Google’s position is clear. Structured data isn’t required for generative AI search, and there’s no special Schema.org markup you need to add (Google Search Central).
Tests point the same way. In a test published in May 2026, Ahrefs compared 1,885 pages that added JSON-LD with similar pages that didn’t. In the 30 days after adding it, citations rose 2.2% in ChatGPT and 2.4% in AI Mode, but both were within the range of random variation. In AI Overviews there was a small 4.6% drop relative to the control group (Search Engine Journal). The test has limits: all the pages were already visible in AI, and 30 days may not show slower effects. Still, it doesn’t support the idea that adding Schema gets you cited.
Another experiment covered in the same article found that five AI systems tested by searchVIU did not use JSON-LD, Microdata or RDFa when fetching a page live. That test says nothing about training or indexing, but it’s a reminder that during a live read, what the model actually sees is the text on the page.
Rich results are shrinking, too. Starting in January 2026, Google began dropping Search Console support for some structured data types (Search Engine Land). In May 2026, FAQ rich results went away entirely. Google says leaving this markup on the page does no harm, but it no longer produces a visible result.
Markup can’t get ahead of the content on the page, either. Google’s rules are clear: don’t mark up content readers can’t see, and structured data has to be an accurate representation of the page. Markup that breaks the rules can lead to a manual action (Google Search Central). Trying to get information that isn’t on the page “noticed by AI” through Schema doesn’t work, and it carries risk.
Structured data is a machine-readable copy of the accurate information on your page. If the information on the page is incomplete, vague or wrong, markup won’t fix it. If the information is good, markup helps it get read correctly and consistently. So fix the page first, then the markup.
Before the page goes live
None of the rules in this chapter were invented for AI. A good editor would also ask for meaningful headings, the answer up front, numbers with units and the model’s name instead of “this model.” What’s changed is that a page that ignores these rules now loses not just the reader but also the model that would have read and quoted it.
To start, open a few of the pages that bring in the most sales and read only their headings and the first sentence of each section. If you can’t tell what the page answers from that, that’s where the work begins. Once the format is fixed, the next question is content: Why isn’t informational content enough on its own anymore, and does a page still have a job after the user has the answer? Chapter 11 takes that on.
Checklist
| Check | Where to look | Why it matters |
|---|---|---|
| Headings describe the page on their own | Reading only the headings | Models and readers recognize a section by its heading |
| Heading levels follow the structure | H1, H2, H3 order in the page source | Headings chosen for looks break the structure |
| Each section’s first sentence gives the answer | Reading the first sentence of each section | Most citations come from the start of the text |
| Key terms have a one-sentence definition | Product and guide pages | Being the source for definition questions |
| One term is used for each concept | Site search, content inventory | Different terms create ambiguity |
| Paragraphs carry their own context | Reading a paragraph on its own | The model uses the passage, not the page |
| Comparisons are in HTML tables | table tag in the page source | Tables in images and PDFs may not get read |
| Table headers include units, no merged cells | Reviewing the table | Values stay tied to the right row |
| FAQs come from real questions and the answers are consistent | Comparing with the sales team | Conflicting answers get passed on wrong |
| Price, lead time and capacity are written with units and conditions | Page content | Concrete information gets passed on correctly |
| The same information matches everywhere on the site | Comparing product page, catalog, FAQ and blog | If an old value lingers somewhere, AI finds it |
| Structured data matches the page exactly | Rich Results Test, comparison with page content | Mismatched markup doesn’t work and carries risk |
Sources
- Google Search Central: Optimizing for generative AI search (last updated July 10, 2026)
- Google Search Central: Introduction to structured data (last updated December 10, 2025)
- Google Search Central: General structured data guidelines (last updated July 10, 2026)
- Search Engine Journal: The science of how AI pays attention (Kevin Indig, February 17, 2026)
- Search Engine Journal: Schema markup didn’t move AI citations in Ahrefs test (May 11, 2026; original study: Ahrefs)
- Search Engine Journal: Google drops FAQ rich results (May 10, 2026)
- Search Engine Land: Google to remove more search features (structured data support removed starting January 2026)
- Search Engine Land: Microsoft Bing/Copilot use schema for its LLMs (SMX Munich report)
Previous: Chapter 9, How AI Bots See Your Site · Table of contents · Next: Chapter 11, Content in the Age of AI