If your organisation publishes guidance, this is the most useful thing you can do with a day of development time this year.
It isn’t glamorous and it isn’t clever. It’s just making sure that the machines describing your position to your members can read the actual position, rather than someone else’s summary of it.
Here’s how, in four steps.
Step 1: Get the substance out of the PDF
The pattern is almost universal in this sector. The guideline is a designed PDF. The web page is two paragraphs and a download button.
That’s a good format for clinicians who want the version of record. It’s a poor one for everything else — search engines index PDFs unevenly, AI systems parse them inconsistently, and neither handles a two-column layout with sidebars well.
What to do: publish the substance as an HTML page as well. Not a summary — the actual recommendations, in text, with headings.
Keep the PDF. Link it prominently, and make clear it’s the citable version of record. You’re not replacing it; you’re making sure the content also exists in a form that can be read.
If that sounds like a lot of work, start with your three most-referenced documents. It’ll take a day and it will do more for you than any other item on this list.
Step 2: Put dates where they can be read
Every guidance page needs three things, in text, visible on the page:
- Published — when this version was issued
- Last reviewed — when it was last checked, even if unchanged
- Next review due — when to expect the next one
“Last reviewed: March 2026” as readable text is worth more than any amount of metadata, because it’s the thing that distinguishes your current position from your 2019 one.
Step 3: Mark superseded documents loudly
This is where membership organisations lose most often.
You publish version 4 of a guideline. Version 3 stays at its original URL — quite rightly, because people have cited it and links shouldn’t break. But nothing on that page says it’s been superseded.
A machine reads version 3, finds no indication it’s historical, and quotes it as your current position. Confidently.
What to do: put a clear banner at the top of every superseded page, in text, not an image:
This guidance was superseded in March 2026. It is retained for reference. See the current version.
Then link forward to the current version, and back from the current version to the archive. It takes ten minutes per document and prevents the single most damaging error we see.
Step 4: Add the schema almost nobody uses
Schema markup is structured data in the page’s code that states facts unambiguously, rather than leaving them to be inferred.
Most sites have a bit of it. Almost no healthcare membership organisation has the parts that matter for guidance — and there’s a very specific opportunity here.
Schema.org has a MedicalGuideline type, designed exactly for this: “any recommendation made by a standard society or consensus statement that denotes how to diagnose and treat a particular condition.” It carries properties for evidence level, evidence origin, the date the recommendation was made, the condition it concerns, and — importantly — recognizingAuthority, which is where you name your organisation as the body behind it.
According to Google’s own usage data, fewer than 1,000 domains worldwide use it.
That’s the opportunity. A schema type built for precisely what you publish, and effectively nobody in your sector has implemented it.
A simplified example of what it looks like on a guidance page:
{
"@context": "https://schema.org",
"@type": "MedicalGuidelineRecommendation",
"guidelineDate": "2026-03-15",
"evidenceLevel": "https://schema.org/EvidenceLevelA",
"evidenceOrigin": "systematic review and consensus panel",
"recognizingAuthority": {
"@type": "Organization",
"name": "Your Organisation",
"url": "https://yourorganisation.org"
},
"guidelineSubject": {
"@type": "MedicalCondition",
"name": "The condition this concerns"
}
}
Alongside it you want Organization markup on your site describing who you are, and MedicalScholarlyArticle on published papers.
One important caveat: structured data must be accurate and must match what’s visible on the page. Marking up a guideline with the wrong evidence level or a wrong date is worse than not marking it up at all — you’d be stating an error in the most machine-readable way possible. This is work to do carefully, with someone from your clinical or editorial side checking it.
What this adds up to
Do these four things and you’ve changed your organisation from something a machine has to interpret into something it can read directly.
You’ve said, in a form that requires no inference: this is the guidance, this is who issued it, this is when, this is the evidence behind it, and this earlier version is no longer current.
That’s not marketing. It’s the same instinct that made you publish the guideline carefully in the first place, applied to a reader you didn’t used to have.
A note on keeping it true
The catch with all of this is that it decays. Guidelines get revised, review dates pass, versions supersede, and structured data quietly goes stale — stating last year’s position with perfect machine-readable confidence.
That’s ongoing work, and it’s exactly the kind of thing that slips when you’re running a congress and shepherding a policy response. It’s included in our Website Care Plan for that reason.
Sources: Schema.org — MedicalGuideline · Schema Markup Validator
Not sure where your guidance stands? Our AI Visibility Check looks at exactly this — which of your documents machines can read, which they can’t, and what’s being quoted instead.
