Blog · By industry

AEO when every claim needs approval

Published 8 October 2026 · Updated 12 October 2026 · 8 min read

AEO when every claim needs approval
Photograph: Markus Spiske / unsplash

The short answer: Treat the approved claim as the unit of work, not the page. Write each cleared statement as one self-contained sentence with its qualifier attached, serve it in HTML, keep preview controls off it, publish the review date in markup, and re-check the prompts after legal signs off. Approval slows publishing. The failure we keep finding is narrower: the cleared sentence is the one piece of text the site stops an engine from using.

Pharma, insurance, lending, medical devices, licensed advice. We have met the same pattern in each of these sectors, though what follows comes from client work and one day of spot checks rather than from a survey. A sentence cannot go on the site until somebody with authority has signed it, and the machinery built to enforce that signature is the machinery that keeps the sentence out of an answer.

Retrieval lifts the sentence, not the page

A retrieval system generally does not hand a whole page to the model. It cuts documents into passages, keeps a handful, and writes from those. None of the engines publish how they chunk or rank passages, so treat that as the shape of the mechanism rather than a description of any one product. The practical question is not whether the approved copy exists somewhere on the site. It is whether a passage that happens to be retrieved still carries the whole approved statement.

Approval tends to split a claim from its condition. The claim lands in the hero. The qualifier lands in a footnote, a modal, an expandable panel, or a disclosure page one click away. Legally the page is complete. Mechanically the paragraph that gets lifted contains the claim with nothing attached, which is the precise outcome the review process existed to prevent. Compliance reviews the page; retrieval reads the paragraph.

The fix is boring. Write the cleared statement as a single sentence that holds its own limit: who it applies to, over what period, under what conditions, in the same sentence. Put it in body text near a heading that uses the question's own words. Repeat it, word for word, everywhere it appears, so no second version can compete with it. This is the same discipline the AEO for fintech work demands of a rate, applied to a claim that a reviewer rather than a pricing table owns.

The preview controls your compliance team asked for

Here is the mechanism most regulated teams have not connected. Google's robots meta tag documentation states that nosnippet prevents the content from being used as a direct input for AI Overviews and AI Mode, and that max-snippet limits how much of the content may be used that way. The data-nosnippet attribute does the same job to a chosen span, div or section.

Now picture the request that produced those tags. Legal, reasonably, did not want a fragment of a regulated claim appearing out of context in a search preview, so the ticket said to suppress snippets on the claim block. Engineering wrapped the claim in data-nosnippet, or set max-snippet:0 at the template level, and closed the ticket. The approved, correct, carefully worded version of your claim is now the one piece of text on the page that Google's AI surfaces are told not to use. Everything else about you remains fair game, including the stale paraphrase on an aggregator that nobody cleared.

Two checks, five minutes:

`` curl -sL yoursite.com/<claim-page> | grep -o 'data-nosnippet' | wc -l curl -sL yoursite.com/<claim-page> | grep -o -i 'max-snippet:[-0-9]*' ``

Structured data is treated separately, at least at Google. Google's robots meta documentation states that robots meta tag limitations do not affect the use of schema.org structured data for search presentation, with article.description and other creative-work description values as the exception. Other engines do not document an equivalent rule. If a claim genuinely must be suppressed in prose, the markup is still a route for the facts that are safe to state plainly.

The block nobody approved

We ran a check on 8 October 2026. Ten product, policy and therapy-area pages from large pharmaceutical, insurance, banking and health organisations were fetched twice from one machine, seconds apart: once with an ordinary desktop browser user agent, once with ChatGPT's search crawler user agent. Three pages returned 200 to the browser string and 403 to the search crawler string. Two refused both. Five served the page either way.

Ten pages is a sample, not an industry rate, and we are not naming the sites. One run from one network, on one day, cannot tell you how often this happens. The useful part is the shape of the failure. A same-second, same-IP difference between two requests that vary only by user agent points to a rule keyed on the agent name. We could not see any of these sites' configuration, so that is an inference from the responses we got, not a rule we observed. On one of those three, the published robots.txt lists that same crawler in a group it allows. The stated policy is open. The edge said no to us.

That gap has an owner problem behind it. Compliance signs the robots policy. Security runs the web application firewall, often with a managed bot ruleset. We cannot see what any of these rulesets were set to do, so the ownership split is what we have met in client work, not something this check measured. Neither team is wrong in isolation. Nobody is looking at the two together, and the result can be a brand that has spent a quarter approving content which the one crawler string we tested was refused. Verify blocks against the crawler IP ranges the engines publish before you conclude anything from a single curl, since a datacentre address can be refused on reputation alone.

Publish the approval, since you already track it

Regulated teams typically keep a review date and a reviewer function for every claim. On the sites we have audited, that metadata stays inside the approval system and never reaches the page. Schema.org defines fields for it: lastReviewed on WebPage is defined as the date the content was last reviewed for accuracy or completeness, and reviewedBy is defined as the people or organisations that reviewed it. Health content can use MedicalWebPage with medicalAudience and specialty to say who the page is written for.

Of the five pages that served us HTML in the 8 October check, none carried lastReviewed or reviewedBy in the markup we received. We read the source as served to a desktop browser string and did not render the pages, so markup added later by script would not have shown up. The review had happened. The source we were served simply did not say so.

Set reviewedBy to an organisation, not a named individual: the medical affairs function, the compliance office, the clinical review board. It keeps a person's identity out of your markup while still stating that a competent body cleared the text. Pair it with a visible review line in the page itself, since the prose is what gets retrieved as passages and the graph is parsed separately.

An operating loop that both sides can live with

Keep a register of approved claims rather than approved pages. One row per claim: the exact sentence, its qualifier, the approval date, the expiry date, the regulation or submission it traces to, and every URL where the sentence appears. The register gives legal a diff when a claim changes, engineering a find-and-replace target, and you a measurable question set, because every approved claim is a prompt you can test.

Then run the loop. Before approval, record what the engines currently say about that claim, including which third-party source they lean on. Ship the approved sentence. Wait a crawl cycle. Re-run the same prompts on more than one engine, several times each, since one run is an anecdote. The things worth logging are whether you were named, whether the qualifier travelled with the claim, and whether the engine still prefers somebody else's description of your product.

Where this becomes urgent is anything an agent transacts against. Price, eligibility, coverage limits and contraindications all have approved values, and an agent reading a feed has little way to tell a stale value from a current one, as covered in agentic commerce: what an agent needs from your catalogue. An expired claim in a product feed is an unapproved claim being served at machine speed. Our self-check covers the ten access and legibility tests you can run on a claim page this afternoon without tooling.

If you want the sector-by-sector version of what changes, start with AEO by industry: where the work differs. If somebody in the room is still arguing about labels, the short version lives in AEO vs GEO vs SEO: what the three terms actually mean.

Honest limits

The 8 October check is ten pages fetched once each from a single machine on a single day. It shows that a user-agent-keyed refusal exists on some regulated sites; it does not give a rate, and a datacentre IP can be refused on reputation alone, so some of those refusals may have nothing to do with the crawler name. We did not see any site's firewall or robots configuration, so the ownership split we describe is inference plus client experience, not measurement. The snippet and structured-data behaviour above is documented by Google and we have not verified an equivalent rule at any other engine.

We also cannot see inside an engine's handling of health, financial and legal topics, and which sources any extra caution favours is not documented anywhere we can cite. Nor do we know how quickly a corrected claim displaces the old one in a model's answers. Fixing access shows up within a crawl cycle. Replacing a wrong claim that third parties have repeated for two years takes longer, and the length is not predictable from anything you control.

FAQ

Does blocking AI crawlers keep an unapproved claim out of answers? Not reliably, and it removes the approved claim too. Your own site is the one place the correct wording is certain to exist. Shut the door and an engine has to work from whatever else it holds: distributors, review sites and old press coverage, which carry versions nobody cleared.

Can structured data say something the page body does not? It should not. Markup that contradicts the visible text is a markup problem and a compliance problem at once. Use the graph to state the same approved facts in a form a parser cannot misread.

Who should own this inside a regulated company? Somebody has to hold access, identity and claim accuracy together. In practice that is a marketing or digital lead with a standing line to compliance and to whoever runs the edge. The failure mode is three teams each doing their job correctly in isolation.

How do we handle claims that differ by country? Separate URLs, explicit market language in the body, correct hreflang, and the applicable regulator or jurisdiction stated in the sentence rather than in a banner. An engine that cannot tell which market a claim belongs to has to guess, and the guess is not yours to control.

Sources

Related reading

AEO by industry: where the work differsAEO for fintechAgentic commerce: what an agent needs from your catalogueAEO vs GEO vs SEO: what the three terms actually meanAEO for agencies, adding it to a retainerAEO for B2B SaaS