Blog · By industry

AEO for healthcare, with compliance in mind

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

AEO for healthcare, with compliance in mind
Photograph: Tasha Kostyuk / unsplash

The short answer: In the regulated health sites we have audited, answer engine optimisation turns out to be mostly a permissions problem wearing a content costume. Blanket bot blocks and snippet suppression get applied to patient-facing pages, which keeps the pages indexed and unquotable, so the engine answers from a third-party summary instead. Fix the access rules first, separate training consent from search consent, then worry about how the page reads.

OpenAI documents separate crawlers for training and for search, so a hospital can decline the first and stay in the second. Our reading of health sites is that the two decisions tend to get fused in a risk review and stay fused. This is an argument about crawler controls, not legal advice about your obligations.

What a healthcare marketer should check first, in order

If you have one afternoon, work down this list rather than across it. An item that fails makes the ones under it moot, which is why the content work sits at the bottom.

First, your robots.txt as production serves it, not as the governance document describes it. If the search-facing crawlers are disallowed, nothing further on this list can reach an answer.

Second, the snippet directives on patient-facing templates. On Google's AI surfaces a page that is not eligible to be shown with a snippet is not eligible as a supporting link, however careful the clinical review behind it was.

Third, whether an approved sentence still holds together when it is lifted on its own, with its qualifier in the same sentence rather than in a footnote or a modal. That problem belongs to any page a reviewer signs, and it is worked through in AEO when every claim needs approval.

Fourth, the review metadata, meaning lastReviewed and reviewedBy in the markup, pointing at a function such as the medical affairs team rather than at a named person.

Measurement is deliberately not on that list. Run the prompt set against the engines instead of instrumenting patient pages harder, for the reason set out further down.

The block that nobody meant to make

Across the health system robots.txt files we have read in audits, two shapes recur. Either every AI user agent is allowed by default because nobody has looked, or a security review added a long disallow list in a single afternoon. We have not counted how common each shape is across the sector, and we would not trust a count drawn from a few dozen sites.

The second shape is the expensive one, and it is expensive because of a distinction OpenAI's crawler documentation makes explicitly. OpenAI runs separate crawlers for separate purposes. GPTBot collects material for model training. OAI-SearchBot is the one that feeds search inside ChatGPT, and the published guidance is blunt about the consequence: sites opted out of OAI-SearchBot will not appear in ChatGPT search answers. ChatGPT-User, the agent behind a user-initiated fetch, is not used to decide what can show up in search at all.

So a compliance team that wanted to say "do not train on our patient education library" can say exactly that, by disallowing GPTBot, while leaving the search crawler alone. Blocking all three because they arrived in the same risk memo removes the organisation from ChatGPT search answers and protects nothing extra against training. Google draws a comparable line with Google-Extended: its crawler documentation says the token controls whether a site helps improve Gemini Apps and Grounding with Google Search on Vertex AI, and that it does not affect inclusion in Google Search. That is two engines with a documented split. Other engines publish less, so check each one rather than assuming the split is standard.

Go and read your own file before you believe your own policy. The gap between what a governance document says and what the production robots.txt says is the finding we hit most often in the regulated-site audits we have run, a working sample in the dozens rather than a survey of the sector, and we have not kept a formal count of it. Read it as a pattern worth checking on your own site, not as a rate. The self-check has the exact fetches to run.

Indexed, but unquotable

The subtler failure is snippet suppression. For AI Overviews and AI Mode, Google's documentation on AI features states the entry condition plainly: to be shown as a supporting link, a page must be indexed and eligible to be shown in Google Search with a snippet, and there are no additional technical requirements. That is Google's rule for Google's surfaces. What it means in practice is a set of snippet controls that close the gate quietly.

nosnippet, max-snippet, data-nosnippet and noindex all do what they say. In healthcare they get applied for reasons that made sense at the time. A legal team wraps dosage guidance in data-nosnippet so no partial sentence can be lifted out of clinical context. A privacy team sets a site-wide max-snippet:0 on the patient portal subdomain and the rule leaks onto the public symptom pages through a shared template.

The page then behaves oddly on the Google surfaces that run on snippet eligibility. It ranks. It gets crawled. It does not get quoted, because the crawler is told it may not show text from it. The assistant answers anyway, from whoever else wrote about the condition, which in the cases we have looked at is often a large consumer health publisher or a forum thread. Your clinical review process produced the better page and your snippet directive pointed the citation elsewhere.

The check takes two minutes. Fetch a patient-facing URL with curl, grep the HTML for nosnippet, max-snippet and data-nosnippet, and confirm each hit is deliberate.

The thing that actually carries PHI risk

Content is rarely where protected health information escapes. Measurement is.

Think about the URL of a page a patient reaches after a symptom checker, or the query string on a provider search, or the referrer sent onward by a page whose path contains a condition name. Those strings can identify a person when combined with an IP address, and they travel to whatever third-party script sits on the page. That mechanism lives in the measurement stack, not in whether an answer engine can read the page. Whether it creates an obligation for you is a question for your own counsel, not for this post.

This matters for AEO because of how teams instinctively try to measure it. The reflex is to instrument patient pages harder: add a tag, add a session recorder, watch what AI referrals do. The better instrument points the other way. Run your prompt set against the engines, record what was said and which sources were used, and you learn whether you are in the answer without touching a patient's session at all. Off-site measurement collects no patient data by construction, which is why we prefer it here. We make the same argument for regulated money in AEO for fintech, where the constraint differs but the shape of the mistake does not.

Markup that signals review, not markup that signals marketing

Schema.org has carried medical vocabulary for years, and on the health sites we have audited almost none of it is in use. Two properties available on MedicalWebPage, both inherited from WebPage, are the ones we ask for first. Schema.org defines lastReviewed as the date on which the content was last reviewed for accuracy or completeness, and reviewedBy as the people or organisations that reviewed it.

Those two fields encode, in machine-readable form, the thing a clinical governance process already produces and then buries in a footer image or a PDF. A page that says it was reviewed on a date, by a named body, is making a checkable claim about its own currency. None of the five engines we test document how they weigh that field, and we cannot measure it from outside, so take this as cheap machine-readable provenance rather than a demonstrated ranking effect.

Pair it with medicalAudience, the one MedicalWebPage property of the three, which separates a page written for clinicians from one written for patients. Mixed-audience pages are where we most often see a passage pitched at a prescriber turn up in a reply aimed at somebody deciding whether to see a doctor. We have not quantified how often that happens.

One warning on FAQ markup, since healthcare sites lean on it heavily. Google's FAQ rich result is gone from Google Search. Google's Search Central changelog entry of 8 May 2026 deprecated the feature, said it would no longer appear in Search from 7 May 2026, and the entry of 15 June 2026 records the documentation being removed. An earlier changelog entry, 14 September 2023, had narrowed eligibility to well-known, authoritative government and health websites, so healthcare lost a visible feature it had kept after other categories lost it. This is a Google Search change, not a statement about what other engines do with the markup. Keep the FAQPage markup, because it still describes question and answer pairs cleanly for any parser that wants them. Stop counting on it for a blue-link rich result.

Who signs off, and how slow that makes you

The work above is cheap. Getting permission to do it is not, and that is the real difference between healthcare and an unregulated category.

A robots.txt change touches security. A snippet directive touches legal. Review markup touches clinical governance. In the engagements we have run, nobody owns the combination and proposals stall between functions. The teams that moved fastest for us were the ones that named a single owner before the first fix, which is the argument in who owns AEO inside a company, and the reason healthcare sits where it does in AEO by industry.

Package the work so each reviewer sees only their own decision, with the current state, the proposed state and the consequence of leaving it. Our audits present findings that way for exactly this reason, and the sample audit report shows the format.

Honest limits

This post establishes less than it may read as establishing. The crawler and snippet rules here are documented by OpenAI and Google for their own products, and we have verified them in those docs; we have not verified equivalent behaviour on any other engine, and nothing here should be read as a rule that holds across engines. The patterns we attribute to our own work, the robots.txt gap, the mixed-audience pages, the stalled sign-off, come from a working sample of regulated sites in the dozens with no formal count behind them, so they are observations, not rates. We cannot say how lastReviewed or reviewedBy are weighed by the five engines in our prompt set, because none of them publish the weighting and we cannot see inside the ranking. We have heard it said that health answers get stricter safety handling than other categories; we cannot verify that from any published source, so we are not asserting it, and we equally cannot promise that a fix survives the next model update.

If the terminology around all this is still fuzzy, start with AEO vs GEO vs SEO before you take anything to a review board. Arguing for a method is easier than arguing for an acronym.

FAQ

Does being cited by an AI assistant create a HIPAA obligation? Publishing public patient education and being quoted from it is not a disclosure of protected health information. The obligations attach to identifiable patient data, which usually travels through tracking and forms, not through the body copy of a public page. Treat the two reviews separately.

Can we stay out of model training and still appear in answers? For OpenAI, yes, by the documented split between GPTBot and OAI-SearchBot. Google documents that Google-Extended governs Gemini Apps and Vertex AI grounding and does not affect inclusion in Google Search. Those are the two engines we can cite. The answer varies by engine, so check each one's current documentation rather than assuming the rule generalises.

Should we remove data-nosnippet from clinical pages? Not blindly. Decide page by page. A directive placed to stop a dosage fragment being lifted out of context may be the right call, and a directive inherited from a template that nobody reviewed is not.

Is FAQ schema still worth adding on health pages? For parsing, yes. For a rich result in Google Search, no, because Google's changelog says the feature stopped being shown from 7 May 2026. Other engines do not publish what they do with the markup. Write the answers to stand alone and treat the markup as structure rather than as a feature request.

Sources

All five were opened and checked against the sentences that cite them on 12 October 2026.

Related reading