Agent Experiences

Healthcare AXO Guide

An answer engine repeating a wrong price costs someone money. An answer engine repeating a wrong dosage is a different category of harm entirely. In healthcare, optimizing for agent readability and optimizing for accuracy are the same project — and where they conflict, accuracy wins without discussion.

Everything in this guide follows from one constraint: your content may be paraphrased, stripped of its surrounding context, and delivered to someone who will act on it without ever seeing your page. That was always somewhat true of search. It is now the default. Write and structure accordingly.

Why the stakes are different here

Answer engines compress. They take a page written with caveats, qualifiers, and a "talk to your doctor" framing, and return two sentences. The compression is not malicious and it is not going away — it is what the interface does. What it means for a health publisher is that every sentence has to survive being extracted alone.

Two consequences follow. First, the qualifier has to live in the same sentence as the claim, not two paragraphs later. "Take 400 mg every six hours" and "Adults without kidney impairment typically take 400 mg every six hours, up to a maximum of 1,200 mg per day without medical supervision" extract very differently, and only one of them is safe on its own. Second, the population a statement applies to has to be stated, every time. Dosing that is correct for an adult and dangerous for a child is a single missing clause away from harm.

This is also the vertical where the zero-click reality bites hardest. With roughly 68% of US Google searches ending without a click between January and April 2026 (SparkToro/Datos), the assumption that a reader will arrive at your page and encounter your context is no longer safe. Most of the people your content reaches will meet it as a fragment.

The trust signals that matter most

Health content gets scrutinized more heavily than any other category, by search quality systems and by readers. Three signals do most of the work.

Named clinician authors with verifiable credentials

"Written by the editorial team" is not authorship. A named clinician with a stated specialty, a license or board certification, and a resolvable professional identity is — and it is checkable, which is the point. Credentials belong in structured form rather than as a string after the name; see the schema guide on why hasCredential takes an EducationalOccupationalCredential object.

A useful and honest pattern is separating the writer from the reviewer. A health journalist writes, a board-certified physician reviews, and both are named with their roles stated. That is more credible than implying the physician drafted it, and it matches how good health publishing actually works.

Medical review dates, distinct from publication dates

These are three different facts and health content needs all three: when it was first published, when the text last changed, and when a clinician last confirmed it still reflects current guidance. The third is the one that matters most and the one most sites do not track. A page whose copy was edited last month but whose clinical content was last reviewed in 2021 is stale in the way that counts, and a single dateModified hides that.

Show all three visibly, mark up lastReviewed and reviewedBy, and put a real review cadence behind it. A review date is a claim that someone looked; if nobody looked, do not print one. Freshness genuinely correlates with citation — Ahrefs' 2026 analysis found AI-cited URLs skew roughly 25.7% fresher (source) — but a fabricated review date in a domain where guidance actually changes is exactly the wrong way to chase that.

Citations to primary literature

Cite the trial, the systematic review, or the clinical practice guideline — with a DOI or PubMed identifier — rather than another site's summary of it. Secondary sourcing compounds error: each retelling drops a qualifier, and health claims degrade fast through that chain. Linking the primary source also lets anyone, human or machine, verify the claim rather than take your word for it.

  • Name the source in text, not just in a link: "a 2025 Cochrane review found…" survives extraction; "studies show" with a hyperlink does not.
  • Include the identifier — DOI, PMID — so the citation resolves even when stripped of formatting.
  • State the evidence level plainly. A randomized trial, an observational cohort, and expert consensus are not interchangeable, and saying which one you have is more useful than sounding certain.
  • Prefer current guideline bodies for anything clinical, and date the guideline you are citing. Guidelines get superseded; a citation without a year cannot be checked for currency.

Medical schema

Schema.org has a health vocabulary that expresses exactly the things above. The key page-level type is MedicalWebPage, which carries lastReviewed and reviewedBy alongside the audience and specialty the content is written for.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "MedicalWebPage",
  "@id": "https://example-health.org/conditions/atrial-fibrillation",
  "url": "https://example-health.org/conditions/atrial-fibrillation",
  "name": "Atrial Fibrillation: Symptoms, Diagnosis, and Treatment",
  "description": "An overview of atrial fibrillation for patients, covering symptoms, how it is diagnosed, and current treatment approaches.",
  "inLanguage": "en-US",
  "datePublished": "2024-02-19",
  "dateModified": "2026-07-30",
  "lastReviewed": "2026-07-28",
  "reviewedBy": {
    "@type": "Person",
    "@id": "https://example-health.org/#/schema/person/aokafor",
    "name": "Amara Okafor, MD",
    "url": "https://example-health.org/reviewers/amara-okafor",
    "jobTitle": "Attending Cardiologist",
    "sameAs": [
      "https://www.doximity.com/pub/amara-okafor-md",
      "https://orcid.org/0000-0002-1825-0097"
    ],
    "hasCredential": {
      "@type": "EducationalOccupationalCredential",
      "name": "Board Certification in Cardiovascular Disease",
      "credentialCategory": "certification",
      "recognizedBy": {
        "@type": "Organization",
        "name": "American Board of Internal Medicine",
        "url": "https://www.abim.org/"
      }
    },
    "memberOf": {
      "@type": "MedicalOrganization",
      "name": "Example Health Cardiology Group"
    }
  },
  "author": {
    "@type": "Person",
    "name": "Daniel Reyes",
    "jobTitle": "Senior Health Writer",
    "url": "https://example-health.org/authors/daniel-reyes"
  },
  "publisher": { "@id": "https://example-health.org/#organization" },
  "about": {
    "@type": "MedicalCondition",
    "name": "Atrial fibrillation",
    "alternateName": "AFib",
    "code": {
      "@type": "MedicalCode",
      "codeValue": "I48",
      "codingSystem": "ICD-10"
    }
  },
  "medicalAudience": {
    "@type": "MedicalAudience",
    "audienceType": "Patient"
  },
  "specialty": "https://schema.org/Cardiovascular",
  "citation": [
    {
      "@type": "ScholarlyArticle",
      "name": "2023 ACC/AHA/ACCP/HRS Guideline for the Diagnosis and Management of Atrial Fibrillation",
      "identifier": "10.1161/CIR.0000000000001193",
      "datePublished": "2023-11-30"
    }
  ]
}
</script>
  • lastReviewed and dateModified are different fields on purpose. Populate both, from different sources, and render both visibly. If your CMS only has one date field, that is the thing to fix first.
  • medicalAudience is not decoration. Content written for patients and content written for clinicians differ in what can be safely omitted. Declaring which one this is helps any consumer avoid delivering clinician-facing material to a worried patient.
  • A note on Physician. Schema.org defines Physician as a MedicalOrganization subtype — an individual physician or a physician's office. It fits a provider listing with an address, phone, and accepted insurance. For an author or reviewer byline, a Person with hasCredential is the cleaner modelling, which is why the example above uses it.
  • Use MedicalOrganization for the practice or hospital itself, with medicalSpecialty, address, and sameAs pointing at registries and directories that independently confirm you exist.
  • Match your markup to your page. The reviewer named in JSON-LD must be the reviewer named on the page, and the review date must be the one displayed. The general rule against markup that contradicts visible content applies here with the extra weight the subject matter deserves.

YMYL, doubled

Google's quality rater guidelines have long treated health as Your Money or Your Life content — topics where inaccurate information can damage a person's health, safety, or finances, and where raters are told to hold expertise and trustworthiness to a much higher standard. That framing predates generative search.

Answer engines make it apply twice over, for a structural reason. In classic search, a reader saw the domain, the byline, and the caveats before deciding whether to believe a claim. In an AI answer, the claim arrives detached from every one of those cues — often stated in the assistant's confident, uniform voice, which flattens the difference between a hospital system and an affiliate blog. The reader loses the ability to weigh the source, so the burden shifts entirely onto whether the underlying content was correct in the first place.

The practical translation: assume no reader will ever see your credentials, your review date, or your disclaimer. Those signals still matter — they are what makes a system more likely to select and correctly attribute you — but they cannot be what makes your content safe. Only the content being right does that.

Regulatory care

HIPAA and what belongs on a public page

If you are a covered entity or a business associate, the pressure to publish compelling, specific, human content runs directly into the rule that protected health information does not go on the public web without valid authorization. The failure modes are usually well-intentioned.

  • Patient stories. Require written authorization, and understand that de-identification is harder than removing the name. A rare condition plus a city plus a treatment date can re-identify someone.
  • Testimonials and reviews. A patient may disclose their own information freely; you responding in a way that confirms they are a patient is a disclosure by you. This catches practices constantly on public review platforms.
  • Case studies and clinical imagery. Same authorization requirements, plus the metadata question — imaging files carry identifiers in places people forget to strip.
  • Third-party scripts on patient-facing pages. Analytics, ad pixels, chat widgets and session recorders on pages where patients look up conditions or book appointments have been the subject of substantial regulatory and litigation attention. This is a legal review question, not a marketing one.
  • Forms. Any intake or contact form that could collect health information needs to be on infrastructure covered by an appropriate agreement, not a generic form service chosen for convenience.

None of this is a reason to publish thin content. Aggregate outcomes data, clearly-explained treatment approaches, named clinician expertise, and genuinely useful condition information are all publishable, differentiating, and exactly what a patient is asking an assistant about.

Do not let optimization pressure produce diagnostic-sounding claims

There is a real and specific temptation in this vertical: agent readability rewards direct, unhedged statements, so the optimization instinct is to strip qualifiers and answer decisively. Applied to health content, that instinct converts educational information into something that reads like individualized medical advice.

The distinction to hold is between being specific and being diagnostic. "Chest pain that radiates to the jaw or left arm is a recognized presentation of myocardial infarction and warrants emergency evaluation" is specific, extractable, and correct. "If your chest hurts and it spreads to your arm, you are having a heart attack" is a diagnosis, and it is wrong on both ends — it will frighten people who are not having one and falsely reassure the ones whose presentation differs.

  • Describe populations and typical presentations, not the reader's individual case.
  • Keep the safety-critical qualifier inside the sentence it qualifies, where extraction cannot separate them.
  • State when to seek care in concrete terms — that is genuinely useful, extraction-safe, and not a diagnosis.
  • Do not let "be quotable" become "be certain." Where the evidence is mixed, saying so is the accurate answer, and a hedge that reflects real uncertainty is not a hedge.
  • Keep disclaimers, but do not rely on them. A disclaimer in your footer will not travel with an extracted sentence.

Accessibility, as a requirement

Healthcare sites serve a population disproportionately likely to have visual, motor, or cognitive impairments — that is close to definitional. Accessibility here is a genuine obligation to the people you exist to serve, with legal weight behind it for many providers, and it should not be reframed as an SEO tactic.

It happens to also be the single highest-leverage piece of agent-readability work, because the two need the same things: content in the DOM rather than in images, real semantic structure, text alternatives, and meaning that does not depend on visual presentation. Do it for the first reason. Note the second when you are asking for budget.

  • Never put clinical information in an image alone. Dosing charts, symptom tables and interaction grids as flat images are unusable by screen readers and invisible to non-rendering fetchers. Use a real table; keep the image as an enhancement.
  • Semantic headings that reflect actual structure — symptoms, causes, diagnosis, treatment, when to seek care — so both a screen reader user and an extractor can navigate to the relevant section.
  • Plain language alongside clinical terms. Give the medical term and the everyday one together. This serves low-literacy and non-native readers, and it also means your page matches how patients actually phrase questions.
  • Labelled, keyboard-operable forms for appointment booking and symptom intake, with errors that name the problem in text.
  • Sufficient contrast and resizable text without layout collapse. Vision impairment is common in exactly the populations reading health content.
  • Server-rendered content. Condition information that loads only after JavaScript executes is unavailable to some assistive technology configurations and to most AI fetchers alike.

Healthcare AXO checklist

  • Named clinician reviewer with structured, verifiable credentials on every clinical page
  • Publication date, modification date, and medical review date tracked separately and shown
  • A real review cadence, with review dates that reflect an actual review
  • Primary-source citations with DOI or PMID, named in text with their evidence level
  • MedicalWebPage markup with reviewedBy, lastReviewed, and medicalAudience
  • Safety-critical qualifiers inside the sentences they qualify, so extraction cannot strip them
  • Populations stated explicitly wherever guidance differs by age, pregnancy, or comorbidity
  • No PHI on public pages; third-party scripts on patient-facing pages reviewed by counsel
  • No clinical information locked in images; real tables, real headings, real forms
  • Everything server-rendered and verifiable in the raw HTML

Related reading: trust and authority signals for the general credibility patterns, schema markup for the markup mechanics, and the glossary for terminology.

This page is guidance on publishing practice for healthcare organizations. It is not medical, legal, or compliance advice. Regulatory obligations vary by jurisdiction and organization type — involve your compliance and legal teams before publishing patient-facing content.

Stay Updated

Analysis of AI search, crawler policy and agent standards — sent when there is something worth reading, roughly twice a month. Unsubscribe anytime.

We store your email address only to send you this newsletter. See our privacy policy.

Back to Industries