Ask ChatGPT what your organisation does. Then ask Gemini and Perplexity. Then search your organisation’s exact name, in quotes, on Google and look at the right-hand side of the results page.
For most healthcare organisations, this five-minute exercise is uncomfortable. The AI answers are partially right, mixed with facts about a similarly named clinic in another city. A consultant is attributed to a hospital they left in 2021. There is no knowledge panel, or there is one, and it belongs to somebody else. The services listed are a subset of what you actually do, drawn from a directory profile nobody has updated in four years.
None of this is a content problem. Your content may be excellent. It is an identity problem. The machines that now mediate how patients, referrers and commissioners find you have not resolved who you are, and everything else — the E-E-A-T work, the clinical content, the review trails, the authority building — is being credited to an ambiguous blur rather than to you.
This piece is the build guide for fixing that. It is the practical companion to our piece on E-E-A-T in healthcare, where we made an argument some readers found surprising: medical schema is not a ranking lever, and the industry routinely oversells it. That argument holds. What schema and entity work actually do is something more foundational, and in healthcare, more valuable: they teach the machines exactly who you are, so that every other signal you build lands on the right target.
What an Entity Is, and Why Healthcare Has a Worse Version of the Problem
An entity, in the sense search engines and language models use the term, is a singular, unique, well-defined and distinguishable thing. An organisation. A person. A place. A condition. A procedure. Modern search does not primarily rank pages against keywords; it resolves pages into entities inside a knowledge graph, then reasons about the relationships between those entities: this clinician works for this organisation, is qualified in this specialty, treats this condition, is registered with this regulator.
When resolution works, authority compounds correctly. A journal citation, a media mention, a new review, a published paper – each attaches to the right entity and strengthens it. When resolution fails, the signals scatter. Some attach to a namesake. Some attach to an old employer. Some attach to nothing, because the machine could not decide who they belonged to.
Healthcare has a structurally worse version of this problem than most sectors, for reasons anyone who works in it will recognise:
- Clinician names collide constantly. The UK has many practising clinicians who share full names, sometimes within the same specialty. Without disambiguating signals, their identities blur into each other.
- Organisations rename, merge and federate. Trusts merge. Private groups acquire clinics and keep, or half-keep, the old brand. The same building hosts an NHS service, a private practice and a diagnostics partner. Each reorganisation fragments the entity graph a little further – a problem we see routinely in post-merger visibility work.
- Clinicians hold multiple simultaneous affiliations. An NHS post, private practice at two hospitals, a university appointment. Machines that cannot model these relationships pick one, usually the one with the strongest existing signals, and suppress the rest.
- The subject matter is itself an entity space. Conditions, procedures, medications and specialties are all entities with their own graph presence. Your pages either connect into that graph precisely, or they float alongside it.
The cost of ambiguity in healthcare is not abstract. It is a patient being shown a namesake’s disciplinary history. A referrer finding the old practice address. An AI answer attributing your consultant’s expertise to the hospital they left. In a sector where trust decides everything, the machines’ confusion becomes the patient’s confusion.
Honest Framing First: What This Work Does and Does Not Do
Before the build, the expectations, because entity SEO is sold with the same inflated claims as everything else in healthcare marketing.
What it does not do: directly improve rankings. Google supports no medical rich result types – MedicalWebPage, Physician, MedicalOrganization and their siblings trigger no search feature. Google’s AI documentation states there is no special structured data needed to appear in AI Overviews or AI Mode. The one published controlled test of adding schema to already-cited pages found no positive effect on AI citations. We covered all of this, with sources, in the E-E-A-T piece, and none of it changes here.
What it does: resolve identity. And identity resolution is upstream of almost everything that does move visibility. The Digital Bloom’s 2025 analysis found brand and entity recognition to be the strongest single predictor of whether a large language model cites an organisation – stronger than backlinks or any purely technical signal. You cannot be a recognised entity while the machines are still deciding which of three similarly named organisations you are.
The adoption picture makes this a genuine opportunity rather than a hygiene chore. Medical schema types sit in a low adoption band across the web – the joint Schema.org and Google usage dataset places MedicalOrganization, Physician, MedicalWebPage, Hospital and MedicalCondition in the 10,000-to-100,000-domain tier, orders of magnitude below commercial types. And a meaningful share of the sector that has tried got it wrong: the Web Data Commons crawl records malformed variants in the wild, including schema.orgMedicalOrganization with a missing slash and MedicalWebpage with invalid capitalisation. More of the web is machine-readable about dinner than about disease, and some of the medical markup that does exist does not parse.
In a field this empty, an organisation that builds its entity graph correctly is not keeping up. It is pulling ahead.
The Four-Layer Healthcare Entity Graph
The build has four layers, and the order matters, because each layer references the one before it. The connective tissue throughout is the @id pattern: every entity gets one stable, canonical identifier, and every other schema block references that identifier rather than re-declaring the entity from scratch. Isolated schema blocks duplicated across pages are how most healthcare sites do it today, and it is precisely what leaves the graph fragmented. The graph is the point. Unlinked nodes are decoration.
Layer 1: The organisation
Choose the most specific container type that is true: Hospital, MedicalClinic, Dentist or MedicalBusiness, rather than defaulting to generic LocalBusiness. The specific types carry medical-only properties, most usefully medicalSpecialty and availableService, which should be populated to match how patients and referrers actually filter: the specialties you practise, the services you genuinely provide.
Alongside the basics – canonical name, address, phone, matching everywhere they appear – include the identifiers that anchor you to external validation: your CQC provider ID, company or charity registration number, and for relevant organisations MHRA registration. These are the machine-readable ends of the regulatory proof points the E-E-A-T piece told you to stop burying in footers.
Layer 2: The people
One Physician or Person node per clinician, and this is where healthcare entity work earns its keep. Each node should carry:
hasCredential– qualifications and certifications, stated preciselyalumniOf– medical school and training institutionsmedicalSpecialty– mapped to the recognised specialty, not a marketing phraseworksFor– referencing the organisation’s@id. Without this link, the machine treats the clinician as an unattached island rather than part of your entity graph, and their authority accrues to nobodysameAs– the verification chain, and the single most valuable property in the entire build
The sameAs chain is what lets a machine confirm that your Dr Smith is this specific Dr Smith. For UK clinicians, link each person node to their entry on the relevant statutory register – the GMC register for doctors, the NMC register for nurses and midwives, the GPhC for pharmacists, the HCPC for allied health professionals – plus their NHS profile page where one exists, their ORCID profile if they publish, and their institutional page at any university appointment. Each link is a triangulation point connecting your on-site claim to an independently verifiable record. (For organisations operating in the US, the same chain runs through the NPPES NPI registry, state medical board licensure and ABMS board certification. The principle is identical; only the registers change.)
Layer 3: The clinical subject matter
Condition and procedure pages get MedicalCondition and MedicalProcedure markup, populated with the properties that describe the actual medicine – signOrSymptom, possibleTreatment, riskFactor – and, critically, cross-linked to the Physician nodes of the clinicians who treat that condition. This is the layer that connects what you treat to who treats it, which is exactly the relationship a patient, a referrer or an AI system is trying to establish when they evaluate you.
Two compliance cautions, both of which we see violated regularly in healthcare audits. Never apply Product schema to medical service pages; it can trigger Search Console warnings or manual actions. And only use review or rating markup for genuine first-party reviews displayed on the page itself – importing Google Business Profile star counts into AggregateRating markup, or fabricating counts, is a structured data policy violation, and in this sector it is also precisely the kind of unverifiable claim the ASA is scanning sixty million ads a year to find.
Layer 4: The connections
The final layer is not a new schema type but the discipline of linking the first three: every page’s markup referencing the canonical @id nodes, the organisation referenced by every clinician, every condition connected to its clinicians, the whole graph internally consistent. FAQ content can be tied to the relevant condition and procedure entities through the same referencing pattern – noting, as covered in the E-E-A-T piece, that FAQ markup no longer produces rich results and should be treated as graph structure, not as a visibility feature.
| Layer | Schema | The question it answers for the machine |
|---|---|---|
| 1. Organisation | Hospital / MedicalClinic / MedicalBusiness + identifiers | Which organisation is this, exactly, and who regulates it? |
| 2. People | Physician / Person + worksFor + sameAs chain | Which clinician is this, who employs them, and can I verify the credentials? |
| 3. Subject matter | MedicalCondition / MedicalProcedure, linked to people | What does this organisation treat, and who specifically treats it? |
| 4. Connections | Stable @id graph across all pages | How does all of this fit together into one coherent identity? |
Off-Site: The Graph Does Not Stop at Your Domain
Entity resolution triangulates across the wider web, which means the off-site record has to agree with the on-site claim. The audit is unglamorous and effective: search your organisation’s name, each senior clinician’s name, your specialties and your locations across Google, the NHS website, the major private healthcare directories and your own historical press coverage, and correct every inconsistency you find. Old addresses. Pre-merger names. A consultant listed under a specialty they no longer practise. Credentials rendered three different ways across three directories.
Consistency of name, address and phone across directory profiles, plus claimed and complete Google Business Profile listings per location, remains the baseline for local entity recognition. Above that baseline, weight matters more than volume: editorial validation – a named clinician quoted in a health publication, cited in coverage, referenced by a professional body – does more for entity authority than any quantity of directory listings, because it is third-party recognition rather than self-declaration.
The simplest diagnostic for how the whole effort is going costs nothing: search your organisation’s exact name in quotes. A knowledge panel appearing, with correct details, means the graph is resolving. No panel, or a wrong one, means the signals are still too fragmented or too weak – which is not a verdict, it is a baseline to measure the work against.
The Citation Landscape You Are Building Toward (Honestly Described)
It is worth being clear-eyed about the environment this work feeds into, because the data on how AI systems cite healthcare sources is genuinely uncomfortable and genuinely unsettled.
The largest relevant study – SE Ranking’s analysis of 50,807 German-language healthcare prompts, published January 2026 – found that YouTube was the single most-cited domain in health AI Overviews, at 4.43% of citations, ahead of every hospital network, insurer and medical association. Trusted medical sources collectively accounted for 34.45% of citations. Academic journals and government health institutions combined: roughly 1%. And only 36% of AI-cited URLs appeared in Google’s top ten organic results for the same queries – the citation layer is already diverging from the ranking layer.
Three caveats belong next to those numbers, and we would rather state them than be quoted without them. The study is German-language; no UK equivalent exists. Different engines behave differently – vendor analyses consistently suggest ChatGPT leans toward government and academic sources while Google’s AI Overviews favour large branded institutions, though the precise splits vary too much across datasets to quote as settled fact. And the landscape is actively contested: following a Guardian investigation published in January 2026 that found AI Overviews giving inaccurate and potentially harmful health information, Google removed some health-related AI summaries entirely.
What survives all three caveats is the strategic conclusion. Citation behaviour is volatile, engine-specific and being corrected in public. The one durable asset underneath it is a cleanly resolved entity: whichever engine is citing, whatever it favours this quarter, it can only credit you if it knows who you are. Chasing each engine’s current citation pattern is weather-watching. Entity work is climate. This is the foundation our generative engine optimisation services build on, with conventional SEO services underneath – and the reason we sequence it this way is exactly the argument of this article.
The Rollout Sequence
The order below matters because later steps depend on the entity foundation existing first. A realistic timeline for a mid-sized provider is one to two quarters, with the first two steps achievable inside a month.
- Baseline the entity. Run the diagnostics: quoted-name search, AI-engine questioning, clinician-name searches, directory sweep. Document every error, conflation and gap. This is the “before” photograph.
- Build the organisation node. Most specific type, full identifiers, deployed sitewide with a stable
@id. - Build a person node per clinician. Credentials,
worksFor, and thesameAschain to statutory registers. Prioritise the clinicians who front your clinical content – this is also where the E-E-A-T byline work and the entity work become the same task. - Retrofit condition and procedure markup onto existing clinical pages, cross-linked to the clinicians who treat each condition.
- Fix the off-site record. Directories, Google Business Profiles, NHS profiles, old press mentions where correctable. One canonical rendering of every name, address and credential.
- Pursue editorial validation. Named-clinician commentary, publication citations, professional body visibility. Weight over volume.
- Re-run the baseline quarterly. Treat vague or incorrect AI descriptions of your organisation as the diagnostic they are: the graph is still fragmented at that point. Fix, re-measure, repeat.
The Entity Health Check
Ten checks, one point each. Under 5: your identity is being assembled by machines from fragments, and some of those fragments are wrong. 5 to 7: the foundation exists; the graph is incomplete. 8 or above: you are one of the few healthcare organisations whose entity is genuinely resolved, and every other signal you build now lands where it should.
- Searching your exact name in quotes produces a correct knowledge panel
- ChatGPT, Gemini and Perplexity describe your organisation accurately when asked
- Organisation markup uses the most specific true type, with CQC and registration identifiers
- Every senior clinician has a person node with credentials and
worksFor - Every clinician node carries
sameAslinks to their statutory register entry - Condition and procedure pages are marked up and linked to the clinicians who treat them
- All markup shares one stable
@idgraph rather than duplicated isolated blocks - Name, address and credentials render identically across your site, directories and Google Business Profiles
- No Product markup on services; no imported or fabricated review markup anywhere
- At least one editorial citation names each of your key clinicians in independent coverage
Most healthcare organisations score between 2 and 4 on first audit – not because the work is hard, but because nobody has ever owned it. It sits between marketing, IT and clinical governance, and so it belongs to no one. Assign it an owner, run the sequence above, and re-score quarterly. The wider strategic context lives in the Fuel Room.
The Healthcare Entity Setup Guide
- Run the five-minute diagnostic today. Quoted-name Google search, then ask ChatGPT, Gemini and Perplexity what your organisation does and who works there. Screenshot everything. This is your baseline and your business case in one.
- Assign an owner. Entity work fails because it sits between marketing, IT and governance. Name one accountable person before touching any markup.
- Build the organisation node with the most specific true type. Hospital, MedicalClinic or MedicalBusiness – not generic LocalBusiness – with medicalSpecialty, availableService, CQC provider ID and registration numbers, on a stable @id.
- Create a person node per clinician, chained to the registers. hasCredential, worksFor pointing at the organisation’s @id, and sameAs links to the GMC, NMC, GPhC or HCPC entry, NHS profile and ORCID where they exist. Start with the clinicians who front your content.
- Connect what you treat to who treats it. MedicalCondition and MedicalProcedure markup on clinical pages, cross-linked to the relevant clinician nodes.
- Reconcile the off-site record. One canonical name, address and credential rendering across directories, Google Business Profiles, NHS profiles and legacy coverage. Fix pre-merger ghosts.
- Respect the two compliance red lines. No Product schema on medical services. No review markup that is not genuine, first-party and on the page. Pair schema decisions with compliance review.
- Set expectations honestly with your board. This is identity infrastructure, not a ranking tactic. The payoff is correct attribution, coherent AI descriptions, and authority compounding to the right entity – the prerequisite for citation, not a shortcut to it.
- Pursue editorial weight over directory volume. One named-clinician citation in independent health coverage outweighs a hundred generic listings.
- Re-run the baseline quarterly and score against the ten-point check. Vague or wrong AI descriptions are your ongoing diagnostic. The graph is finished when the machines stop guessing.
Find out what the machines think you are.
Free healthcare entity health check. We will show you how search engines and AI systems currently resolve your organisation, your clinicians and your services, and where the graph is broken.
Frequently Asked Questions
What is an entity in SEO terms, and why does it matter for healthcare?
An entity is a singular, well-defined, distinguishable thing: an organisation, a clinician, a clinic location, a condition, a procedure. Search engines and AI systems do not primarily read pages; they resolve pages into entities inside a knowledge graph and reason about the relationships between them. Healthcare is unusually exposed to this because its entities collide constantly: common clinician names, similar clinic names, merged trusts, group brands and personal practices sharing addresses. If the machines cannot resolve which Dr Smith you are, which organisation employs them, and which conditions they treat, every other investment in content, E-E-A-T and visibility is built on an ambiguous foundation.
Will implementing medical schema improve our rankings?
Not directly, and it is important to be honest about this. Google supports no medical rich result types, and its AI features documentation states there is no special schema.org structured data you need to add. The one published controlled test of adding schema found no positive effect on AI citations. What schema does in healthcare is entity disambiguation: it tells machines, unambiguously, who your organisation is, who your clinicians are, what they are qualified in, and what you treat. That resolution is the prerequisite for consistent branding in AI answers, correct knowledge panels, and authority accruing to the right entity rather than a near-namesake. Implement it as identity infrastructure, not as a ranking tactic.
Which schema types should a UK healthcare organisation implement first?
Four layers, in order. First, the organisation: MedicalOrganization or a more specific type such as Hospital, MedicalClinic or Dentist, carrying name, address, phone, medicalSpecialty and availableService, plus registration identifiers such as your CQC provider ID. Second, the people: a Physician or Person node per clinician with hasCredential, alumniOf, worksFor pointing at the organisation’s @id, and sameAs links to verifiable registers such as the GMC, NMC or GPhC entry. Third, the clinical subject matter: MedicalCondition and MedicalProcedure pages cross-linked to the clinicians who treat them. Fourth, the connections: a stable @id graph linking all of it, rather than isolated schema blocks duplicated across pages. The graph is the point. Unlinked nodes are just decoration.
How do we check what our entity currently looks like to machines?
Three quick diagnostics. Search your organisation’s exact name in quotes on Google: no knowledge panel usually means the entity signals are too fragmented or weak to resolve. Ask ChatGPT, Gemini and Perplexity what your organisation does and who works there: errors, conflations with similarly named organisations, and outdated facts show you exactly where the graph is broken. And search each senior clinician’s name plus your organisation: if the results mix them up with namesakes, or surface a previous employer first, the person entity is not resolved. Document all of it. That is your baseline, and re-running the same checks quarterly is how you measure progress.
Does this apply to medtech and B2B health brands, or just providers?
It applies at least as strongly. A medtech or health tech company is an entity whose graph should connect the organisation, its named clinical and scientific leadership, its products, its regulatory status and its published evidence. Buyers and the AI systems they use to shortlist both need to resolve who you are, who validates you, and how your claims connect to evidence. For B2B health brands the sameAs chain points at different validators: MHRA registration, published trials, peer-reviewed papers, ORCID profiles for scientific staff, and framework listings. The mechanics are identical. Only the registers change.
Sources
- Schema.org – MedicalOrganization, MedicalClinic, Hospital, Physician, MedicalCondition and MedicalProcedure type definitions; properties including medicalSpecialty, availableService, hasCredential, worksFor and sameAs
- Google structured data search gallery – no medical rich result types supported
- Google, AI features and your website – “no special schema.org structured data that you need to add”
- Google structured data policies – markup must reflect genuine on-page content; misuse can trigger manual actions
- Ahrefs (May 2026) – controlled test, 1,885 pages adding JSON-LD vs 4,000 matched controls: no positive effect on AI citations. Vendor-published, reported against its own commercial interest
- Web Data Commons, October 2024 Common Crawl – MedicalWebPage on 6,738 domains vs Recipe on 28,996 (of 11.5m schema.org JSON-LD domains); malformed medical markup variants recorded in the wild
- Schema.org / Google public structured data usage dataset (2026) – medical schema types in the 10,000–100,000 unique-domain band; reports domain counts in bands, not percentages
- The Digital Bloom (2025) – brand and entity recognition the strongest single predictor of LLM citation (directional)
- SE Ranking (January 2026) – 50,807 German-language healthcare prompts: YouTube most-cited domain at 4.43%; trusted medical sources 34.45%; academic journals and government institutions combined ~1%; only 36% of cited URLs in Google’s top 10 organic. German market; no UK equivalent exists
- The Guardian (January 2026) – investigation into inaccurate health information in AI Overviews, after which Google removed some health-related AI summaries (verified via multiple secondary reports)
- Google Search Quality Rater Guidelines (September 2025) – E-E-A-T assessed on verifiable credentials, not self-declared expertise (§5.6); YMYL pages with no creator information rated Lowest
- ASA & CAP Annual Report 2025 – 60 million ads scanned by automated monitoring; health and beauty the most complained-about sector
- Registers referenced for the sameAs verification chain: GMC medical register, NMC register, GPhC registers, HCPC register, CQC provider profiles, ORCID
