From E-E-A-T to AI Citability: Rebuilding the Medical Review Workflow

Does having a doctor review my health content help with AI search?

There is no evidence that it does, and there is some evidence against it. In the most careful study available, 615 sources cited by ChatGPT across 100 consumer health questions were audited for authority signals. Only 29.6% carried a medical review statement. Broken down by publisher type the pattern inverts what a trust model would predict: commercial health information platforms carried one 71.1% of the time, government resources 13.4% and peer reviewed journals 11.4%. In other words a review statement is a reliable indicator that you are a consumer health publisher and an unreliable indicator of anything else. Keep doing medical review. It is the correct practice for readers, it is what a regulator and a plaintiff's lawyer will ask about, and in pharmaceutical promotional content it is mandatory. What should change is the business case and the output. Stop funding review on a promise of AI citation lift that the data does not support, and start publishing what the review produced, because the output is useful to an answer engine in a way the badge is not.

What the audit actually found, in full
 

The selective version of this data is already circulating, so here is all of it. These figures come from a single academic preprint examining ChatGPT answers to consumer clinical questions, and that limitation is real and is stated again at the end of this page.

The schema row is the one most often quoted out of context, so read it carefully. Schema markup was present on 74.3% of cited pages. It is also present on most pages published by any organisation with a median domain authority of 89, because those organisations have engineering teams and content management systems that emit it by default. A correlation between schema and citation in a sample skewed toward strong domains is not evidence that schema causes citation. The next section tests that directly, and the result is worse than inconclusive.

The markup problem: hidden data is not read

If structured data were a channel into AI answers, a value placed only in structured data would come out the other end. Somebody finally tested that. The design is small and fictional and the finding is unambiguous within its scope.

The results. Each cell is the number of the eight prices the system retrieved.

Read down the format axis rather than the engine axis and the finding is stark. Not one of the five systems retrieved the price that existed only in JSON-LD. Not one retrieved the price in hidden Microdata. Not one retrieved the price in hidden RDFa. The two markup formats that did work, visible Microdata and visible RDFa, worked because the value was rendered on the page where a reader could see it. Which means they did not work as markup at all. They worked as text.

A separate test in early 2026 points the same way from the opposite direction. A fabricated company address was placed inside deliberately invalid JSON-LD, markup that no compliant parser would accept, and two engines repeated the address back. That is the behaviour you would expect from a model reading the contents of a script block as plain text, and not the behaviour you would expect from a system parsing structured data. That second test is secondary reporting rather than a primary write up, and it is consistent with the controlled experiment, which is why it is worth a sentence.

And Google says structured data does not affect ranking

This part is not contested and does not need a study, because Google publishes it. Structured data makes a page eligible for rich result appearances. It does not influence position in web search. Google's own documentation states that a structured data manual action does not affect how the page ranks and only removes rich result eligibility.

Two further points from the same policy matter more to this page than the ranking question. The first is the content requirement: do not mark up content that is not visible to readers of the page, because markup must be a true representation of what the page shows. The second is that incomplete markup is not eligible at all, so a reviewedBy property without the properties around it buys nothing even on Google's own terms.

The thesis, revised: publish the review rather than announce it

Here is what survives. The evidence says a review statement does not predict citation and hidden markup is not read. It does not say the review itself is worthless, and it could not, because nobody has measured the thing this page is about. Every study so far has looked for a badge. None has looked for an evidence trail, for the simple reason that almost no publisher publishes one.

Think about what a medical review actually generates. A clinician reads a draft on atrial fibrillation. They check the anticoagulation section against the current cardiology society guideline, note that the 2024 edition changed the threshold, flag that the dosing table is citing a superseded recommendation, and sign off once it is corrected. By the end of that review there exists, somewhere, a named guideline, an edition, a date, a specific clinical judgement and a record of what changed. Every one of those is the kind of fact an answer engine is built to retrieve and attribute.

And every one of them is deleted. It lives in a review ticket, a tracked change or a reviewer's email, and what reaches the rendered page is a line of boilerplate. The publisher paid for the provenance and shipped the badge.

The four artefacts a rebuilt review workflow should publish

All four are visible page content. The markup comes afterwards and mirrors them. None of the four requires the reviewer to do more clinical work. All four require the workflow tool to capture what the reviewer already decided and the template to render it.

Artefact 1: the reviewer identity block

The problem with a reviewer byline is that it is a string. Doctor Sarah Chen is not a person to a retrieval system, it is five characters and a space repeated across forty thousand other pages on the web belonging to different people. An identity block exists to make the reviewer resolvable, and resolvability is the one job structured data unambiguously does well.

The registration number is the row that distinguishes a serious implementation from a cosmetic one, and it is the one almost nobody does. A GMC reference number or an NPI is public, permanent and checkable by anyone in about fifteen seconds. Publishing it says the claim is auditable. Withholding it, while still asserting the credential, says the opposite, and increasingly says it to a reader who has been trained by three years of synthetic content to assume a byline may be fictional.

There is a practical dependency here worth naming. Most publishers do not hold registration numbers for their own reviewer panel. They hold a name, an email and an invoice address. Collecting and verifying those identifiers across a panel of fifty or two hundred clinicians is a one off data exercise, and it is the same resolution problem our platform solves for commercial teams, which is the only reason it appears on this page.

Artefact 2: stop collapsing three dates into one

Nearly every health CMS shows a single date, and that date is a lie by compression. It usually reads Last updated, and it moves when anything at all changes, including a typo fix or a template migration. The result is a signal that cannot be interpreted, which is probably part of why the audit found 40.7% of cited content predating 2020 or carrying no date while only 36.4% was dated 2024 to 2026. If dates meant something consistent, that distribution would be easier to read.

The discipline this requires is organisational rather than technical. The temptation to move the review date during a refresh cycle, because a fresher date is assumed to perform better, is strong and is exactly the behaviour that has made the signal meaningless across the category. If your refresh programme touches ten thousand pages and your clinical panel reviewed four hundred of them, then four hundred review dates move. A publisher who holds that line for two years ends up with the only interpretable date field in the vertical, which is a small but real moat.

Artefact 3: the evidence table, which is the part that matters

This is the one competitors cannot copy in a sprint, because it is not a template change. An evidence table lists the clinically weighted claims on the page and, against each, the source the reviewer accepted: the issuing body, the document, the edition and the date. It looks like this.

Four things happen when a page carries this, and only one of them is speculative.

1. The page becomes more useful to a reader, particularly a clinically literate one, who can now see what the advice rests on. This is not speculative and it is reason enough on its own.
2. The page becomes defensible. When a regulator, a complainant or a plaintiff's lawyer asks what the claim was based on, the answer is on the page with a date against it. For pharmaceutical content this moves from useful to close to mandatory.
3. Maintenance becomes tractable. When a guideline issues a new edition, you can query which pages depend on it instead of asking an editor to remember. At library scale this is worth more than the visibility question and is the argument that usually gets the project funded.
4. And the speculative one. A page that names its sources in extractable prose is giving an answer engine exactly the material it needs to attribute a claim. Whether that increases citation is unknown and is what the experiment at the end of this page exists to find out.

Note the order deliberately. Three solid reasons before the uncertain one. A project justified on the fourth alone will be cancelled the first time the measurement comes back flat. A project justified on the first three is worth doing whatever the measurement says, which is how it should have been scoped in the first place.

Artefact 4: the change log

One or two lines, dated, saying what the last review changed. Reviewed March 2026. Anticoagulation thresholds updated to the 2025 guideline edition. Dosing table corrected. That is the whole artefact and it costs nothing, because the information already exists in the tracked changes nobody reads.

It does something none of the other three do. It converts a freshness claim into a verifiable statement. A date says trust me, this is current. A change log says here is what changed and when, check it if you like. For a reader deciding whether a page is maintained or merely re-stamped, the second is worth far more, and it is the artefact that most visibly separates a publisher who reviews from one who refreshes.

The markup layer, done for the right reason

Having spent a third of this page explaining that markup is not read by answer engines, here is the markup specification, because the reason to deploy it is a different one. Structured data is not a channel into an AI answer. It is a disambiguation layer for systems that do consume it, principally Google's own index and knowledge graph, and it is close to free once the visible content exists. Deploy it as a mirror of the page, never as a substitute for it.

The reviewer as an entity, which is the one thing markup is genuinely good at

If you implement one thing from this section, implement this. A reviewedBy value of the string Doctor Sarah Chen is worth essentially nothing. A reviewedBy value that is a Person object carrying a registration number, an ORCID and a link to a profile page is a resolvable entity, and resolution is a real problem that structured data genuinely solves.

Carry these as identifier entries on the Person, with sameAs pointing at the public register entry or the ORCID record where a stable public URL exists. The underlying idea is not an SEO trick. It is that a credential which cannot be checked is not a credential, and the gap between asserting a reviewer and evidencing one is about to become the difference that matters, because the cost of fabricating a plausible reviewer byline has fallen to nothing.

The practical obstacle is data, not engineering. Very few publishers hold verified identifiers for their reviewer panel, and collecting them properly means matching names to registers and resolving the ambiguous cases. That is a bounded one off project for a panel of a hundred clinicians and it is the same identity resolution work described on our GenAI doctor data platform page. It is also entirely doable by hand for a small panel, and we would rather say that than pretend it needs a product.

Five markup mistakes that are worse than no markup

• Marking up a reviewer who is not displayed. Breaches Google's content policy, which requires markup to describe content visible to readers, and risks a manual action that removes rich result eligibility across the template.
• Setting lastReviewed to the editorial update date. This is the most common error and it quietly destroys the only field on the page that could have carried a trustworthy clinical signal.
• Attributing authorship to the reviewer. A clinician who checked a staff writer's draft did not write it. Asserting otherwise is a factual misstatement in your own markup, and the reviewer will object to it long before a search engine does.
• Emitting citation entries that point at nothing. A citation value that is a bare title with no resolvable reference is noise. If the evidence table has a source, cite the source, and if it does not, leave the property out.
• Deploying partial markup and reporting it as done. Google states that items missing required properties are not eligible at all. A half implemented MedicalWebPage is not half as good, it is inert, and it will sit on a roadmap as completed work for two years.

What are E-E-A-T requirements for health content in 2026?

Strictly speaking there are none, and the phrasing of the question is where most teams go wrong. E-E-A-T is not a specification and it is not a ranking factor. It is the vocabulary Google's human quality raters use when scoring sample results, and those scores train and evaluate systems rather than scoring your page directly. No property, badge or markup makes a page compliant with it, because there is nothing to comply with. What is concrete for health content in 2026 is narrower and more useful. Google's structured data policy requires that markup describe content visible to readers and states that structured data does not affect ranking. The only controlled test published found that no AI system retrieved a value present only in hidden structured data. And the only audit of cited health pages found that the trust markers the industry sells, bylines and review statements, were absent from the clear majority of them. So the defensible 2026 position is this: write content that demonstrates expertise in its substance rather than in its furniture, make the evidence behind it visible on the page, keep your dates honest and distinct, and make your reviewer resolvable to a public register. Everything in that list is worth doing for reasons that hold whether or not any engine ever rewards it, which is the correct test for any work justified by a framework nobody can audit.

What changed, and what did not

The useful way to frame 2026 is by what the arrival of answer engines changed about an idea that is now several years old.

The honest summary of the last row is that the pre AI playbook told you to decorate the page with signals of trustworthiness, and the measured evidence says the decorations are not being read. What has never been tried at scale is simply showing the work. That is not a sophisticated insight. It is what the review process was always producing and what the page was never printing.

Rebuilding the workflow, step by step

The template is the easy half and it is where most projects stop. A template can only render fields that exist, and the fields do not exist because the reviewer was never asked to fill them. This is a workflow change wearing a front end change as a disguise, and scoping it the other way round is why these projects stall at about seventy percent.

What this costs, honestly

Almost nothing in clinical time, which is the expensive input, and a real amount in operations and engineering time, which is not. The reviewer is already reading the guideline. Recording which guideline, in which edition, adds perhaps two minutes to a review that takes forty. The cost is concentrated in stages one, two and four, and it is one off.

The sentence to take into a budget conversation is that this project does not ask for more medical review. It asks for the medical review you already buy to leave a trace. If somebody proposes funding it by increasing reviewer hours, the proposal has been misunderstood.

Which pages to do first

Not the highest traffic pages, which is the usual instinct and the wrong one here. Pick the cohort where the four artefacts have the most to say and where the evidence base is actually contested, because a page whose claims are uncontroversial produces an evidence table that reads as filler.

How to find out whether it worked

This page specifies an intervention. It does not measure one, and the measurement belongs to another page in this cluster. What follows is the experimental shape only, so the design can be judged. The sample sizes, the detection thresholds and the engine mix all come from measuring AI visibility across a content library, and the question set construction comes from the health publisher's prompt map.

1. Pre register the hypothesis in one line, before anything ships. Pages carrying the four review artefacts will show a higher citation rate than matched control pages over two quarters. Write it down and date it, because the temptation to reinterpret the result afterwards is overwhelming.
2. Build the two cohorts properly. Matched on topic, on question intent type and on current citation performance. A treatment cohort made of your best pages and a control made of the rest will produce a flattering and meaningless result.
3. Establish the baseline before the template ships. Measure both cohorts for at least one full cycle beforehand. There is no way to recover a baseline afterwards, and this is the step most often skipped.
4. Set the detection threshold in advance and size for it. Decide the smallest change that would justify rolling out to the whole library, then check whether your sample can detect it. If it cannot, lengthen the measurement period rather than lowering the standard.
5. Report presence and recommendation separately. Provenance is more plausibly a recommendation signal than a presence signal, since it speaks to whether a source is worth pointing a reader at. A programme reporting a single blended score could miss the effect entirely.
6. Publish the result either way. A null result here is genuinely valuable to the category, because nobody has tested it. It is also the outcome this page considers most likely, given that cited pages had a median domain authority of 89 and a median page authority of 55.

7. Why we would publish a null result Because the other three reasons for doing this work do not depend on the answer. Reader usefulness, regulatory defensibility and guideline maintenance at scale are all sufficient on their own, and all three are unaffected by whether an answer engine notices. That is what makes this intervention safe to recommend in a category with almost no evidence. We are not asking anyone to bet on an unproven visibility theory. We are asking them to publish something they already produce, for reasons that stand up without it, and then to check whether it also helped. If it did not, the work was still worth doing, and we will say so on this page.

Limitations, and what would change our mind

This page makes a recommendation on a thin evidence base and reverses a thesis our own plan committed to. Both of those deserve a full accounting.

What would change our mind. A replication of the markup experiment on indexed rather than freshly fetched pages would test the authors' own caveat and could reverse the markup conclusion entirely, and it is the most useful single piece of work anybody could publish next. A peer reviewed authority signal audit with a larger multi engine sample would settle whether the review statement finding is real or an artefact of 100 questions on one engine. A well constructed cohort experiment showing a citation lift from published provenance would move this page's central claim from hypothesis to finding, and a well constructed one showing no lift would move it to refuted, which we would state here in the same place.

Conclusion: show the work

The medical review workflow was built for a search engine that no longer behaves the way it did when the workflow was designed, and the industry's response has been to decorate it rather than to rethink it. More bylines, more badges, more schema. The measured evidence is that bylines are absent from 64.7% of cited health pages, that review statements mark you out as a commercial publisher rather than an authoritative one, and that hidden markup is not read by any engine anybody has tested.
 

What has never been tried is the obvious thing. A medical review produces evidence, judgement and change, and publishers publish none of it. They publish the receipt. Putting the actual output of the review on the page, in prose and tables a reader and a machine can both read, is a specification rather than a theory, and it costs almost no clinical time because the work is already being done.
 

Whether it moves citation is unknown. It is worth doing anyway, because a page that shows which guideline its advice rests on, in which edition, checked by a named clinician whose registration number you can verify in fifteen seconds, is simply a better page. That was true before answer engines existed and it will be true if every claim in this article turns out to be wrong.
 

For the citation evidence that constrains everything here, see how AI engines decide which health publisher to cite. For the measurement design that tests it, see measuring AI visibility across a content library. For the page architecture the reviewer block sits inside, see condition hub architecture for AI answers. The framework and the governance position are in the generative engine optimisation pillar, the commercial case in GEO for medical publishers, the question set in the health publisher's prompt map, and the crawler access decision in licence, block or optimise.

Where Multiplier AI fits

Two parts of this page touch what we sell and we have tried to keep both at the level of method rather than pitch. Resolving a reviewer panel to verified registration numbers is the same identity problem our GenAI doctor data platform solves for commercial teams, and for a panel of a hundred clinicians it is also perfectly doable by hand.

The cohort experiment at the end is implemented in our pharma AI visibility and GEO platform, and the design is specified in enough detail across this cluster that an in house analytics team could run it without us. That is deliberate, for the same reason we published the sampling mathematics rather than describing a dashboard.

Our wider healthcare professional data work sits on the HCP data platform for healthcare recruitment, and everything we publish is indexed on the Multiplier AI blog.

Frequently Asked Questions For Medical Review and AI Citability