Healthcare schema markup: 95 medical nodes, and not one declared a specialty

What is healthcare schema markup, and which properties does it add?

Healthcare schema markup means using the health and medical types in the schema.org vocabulary instead of, or alongside, the generic business ones. The anchor type is MedicalOrganization, which schema.org version 30.1, dated 2026-09-16, describes as "A medical organization (physical or not), such as hospital, institution or clinic." It lists seven subtypes: Dentist, DiagnosticLab, Hospital, MedicalClinic, Pharmacy, Physician and VeterinaryCare.

What matters is not the label but the three properties MedicalOrganization defines that no generic type has. healthPlanNetworkId holds "the name or unique ID of a network", and the page notes that networks are often reused across insurance plans. isAcceptingNewPatients is a boolean for whether the provider currently takes on new patients. medicalSpecialty names a medical specialty of the provider. Those are the three facts that distinguish a care provider from a shop with an address, and they are the whole reason the type exists.

Hospital defines three of its own: availableService, pointing at a MedicalProcedure, MedicalTest or MedicalTherapy; healthcareReportingData; and medicalSpecialty again. Its place in the vocabulary is worth reading closely, because schema.org gives Hospital four parent chains and LocalBusiness appears in two of them, both through EmergencyService. A Hospital node is therefore a medical type and a local business type at the same time, which turns out to be exactly how the sites in this corpus treat it. MedicalWebPage sits in a different branch, Thing then CreativeWork then WebPage, and defines one property of its own, medicalAudience, described as "Medical audience for page."

So the vocabulary offers six type-specific properties across the three types that appear in this corpus. That number is the yardstick for the rest of this post, and it is small enough that a site declaring any of them would be visible immediately. This is the same question asked of the generic identity types in 277 of 448 identity nodes declaring no category, narrowed to the one vertical where a specialist vocabulary exists to be used.

How 123 healthcare hostnames became 91 readable home pages

The frame is fixed and committed rather than assembled for this post. worker/seeds/corpus-seeds-industry.json holds 1,027 hostnames in eight industry strata, and the healthcare stratum is 123 of them. It is a deliberately mixed set: hospital groups such as clevelandclinic.org and massgeneral.org, national health agencies such as rki.de and sanidad.gob.es, medical associations such as aafp.org and bma.org.uk, journals such as nejm.org, and consumer health publishers such as webmd.com.

Each hostname was asked for /robots.txt once on 19 October 2026 as LantadBot/1.0, with redirects followed and a twenty second timeout. Every root verdict was computed with this scanner's own parseRobotsTxt and evaluateRobots in core/src/robots.ts, never inferred from traffic. Not one of the 123 files disallowed LantadBot at the site root by a rule. Ten answered robots.txt with a 5xx, which robotsPolicyFromStatus treats as a site-wide disallow rather than a free pass, for the reason set out in a 404 on robots.txt allows every crawler and a 503 blocks them all, so those ten were not requested further.

Of the remaining 113, 91 answered HTTP 200 with an HTML content type. Nineteen answered HTTP 403, and three failed in the client before any status arrived, those being ha.org.hk, mhlw.go.jp and nhc.gov.cn. Two of the nineteen are worth naming because they served robots.txt successfully and then refused the page: jamanetwork.com and nejm.org both answered 200 for the file and 403 for the home page, which is the pattern measured across the whole corpus in 103 of 1,089 sites serving an unknown bot and refusing GPTBot. A 403 at this layer is an edge or CDN decision, not a robots.txt one, and this post counts it as a page nobody measured rather than as a page with no markup.

On those 91 pages there were 55 JSON-LD script blocks. 54 parsed as JSON; the one that did not was on icmr.gov.in, which served three blocks and had two parse. Flattening the 54 produced 463 typed nodes across 42 distinct type names, which is the ordinary long tail: PostalAddress at 99, Hospital at 84, Organization at 26, WebSite at 25, ContactPoint at 20. The concentration in a handful of types matches the web-scale picture in only 16 schema.org types reaching 10 million domains.

One limit belongs here rather than at the end. This stratum mixes care providers with ministries, journals and associations, and MedicalOrganization is the right type for some of those hosts and plainly wrong for others. A journal is not a medical organization. So the 12 figure is a count of declarations, not a count of sites that should have declared one, and this post does not claim the other 79 are in error. What the count does support is narrower and still useful: wherever a medical type was chosen, the properties that justify choosing it were absent.

12 of the 43 sites with markup named a medical type

Half the stratum published no machine-readable identity at all. 48 of the 91 readable pages carried no parseable JSON-LD, and the list includes some of the largest academic medical centres in the set: massgeneral.org, uclahealth.org, nyulangone.org, dana-farber.org, chop.edu, sickkids.ca, uhn.ca, karolinska.se, charite.de and amsterdamumc.nl among them. Also webmd.com, nice.org.uk and hse.ie. These are not sites that lack a web team. They are sites where structured data was not part of the build, which is the same proportion this blog found on a broader frame in 141 of 382 home pages carrying none in the raw HTML.

Of the 43 that did carry markup, 12 named a medical type and 21 named an organisation type with no medical type anywhere. That second group is the interesting one, because it is sites that went to the trouble of declaring who they are and then described a care provider as a generic organisation: cedars-sinai.org, kaiserpermanente.org, scripps.org, stjude.org, gosh.nhs.uk, humanitas.it and medlineplus.gov are in it, alongside agencies such as rki.de, rivm.nl, icmr.gov.in and moh.gov.sg where the generic type is arguably correct.

The 12 that named a medical type are a short enough list to print, and printing it is what makes a measurement checkable: aafp.org, acog.org, acibadem.com.tr, clevelandclinic.org, helios-gesundheit.de, hospitalangeles.com, mdanderson.org, mediclinic.co.za, nationwidechildrens.org, nyp.org, plannedparenthood.org and usz.ch. Nine declared MedicalOrganization, two declared Hospital as the outer type, and aafp.org declared MedicalWebPage. plannedparenthood.org declared two nodes, one combining Organization with MedicalOrganization and one combining MedicalOrganization with NonprofitOrganization.

The second read the same day is what gives these counts a confidence interval rather than a decimal point. 119 of the 123 hostnames reproduced the first read exactly on all three of readability, parseable JSON-LD presence and medical type presence. Four moved: aiims.edu served a 503 robots.txt first and a readable page second, inserm.fr gained a parseable block, and rivm.nl and seha.ae stopped answering. Critically, the 12 medical hosts, the 95 medical nodes and all six property counts came back identical, so the finding this post is named for did not move at all.

Not one of the 95 medical nodes declared a specialty

Across the 12 sites there were 95 nodes carrying a medical type: 84 Hospital, 10 MedicalOrganization and one MedicalWebPage. Every one of them was checked for the six properties the three types define. The result is a clean zero on all six. No node declared medicalSpecialty. None declared isAcceptingNewPatients, healthPlanNetworkId, availableService, healthcareReportingData or medicalAudience. A wider sweep for any property name containing medical, health, specialty, patient, doctor or physician returned nothing at all.

What the nodes did carry is the generic business set. 94 of the 95 had a name and 94 a url. 89 had a description, 87 an address, 66 a telephone and 53 a faxNumber. Below that the counts thin out fast: seven logo, six sameAs, six @id, five alternateName, five contactPoint, three image. The shape of the finding is easier to state than the list. These nodes carry contact details and nothing clinical. The fax number is the detail that lands hardest, because 53 nodes found room for a fax machine and zero found room for the specialty of the department it rings.

The nine MedicalOrganization nodes are individually readable and each one shows the same thing. acog.org declared @type, @id, url, name, logo and sameAs. nationwidechildrens.org declared name, url, logo, contactPoint and address. clevelandclinic.org declared alternateName, areaServed, description, foundingDate, legalName, name, numberOfEmployees, image, sameAs and url, which is ten properties and not one of them medical. mdanderson.org added award and legalName. Every one of these is a well-formed Organization node that happens to be typed MedicalOrganization, which is a different thing from a medical description of a provider. The same substitution of the easy property for the useful one turned up in 119 of 191 home pages with a clickable phone number naming no telephone in their markup and in 70 of 146 markup values that were not on the page.

It is worth being precise about what this does and does not establish. Six of the 95 carried a sameAs and six an @id, which are the two signals entity confidence weights for anchoring an identity outside the page, so these nodes are thin on external anchoring as well as on clinical detail. It is a presence measurement on one page per host, the home page, and a hospital group may well declare medicalSpecialty on a department or location page that this run never requested. That is a real limit and it is not a small one for a large provider with thousands of pages. What the run does establish is that on the one page every crawler reaches first, the specialty is not there, and the node that is there is indistinguishable from a listing for a shop.

One hospital group declared 83 of the 95 nodes

The 95 is not spread across the 12 sites. helios-gesundheit.de, a German hospital group, declared 83 of them: one outer MedicalOrganization wrapping 82 Hospital nodes, one per clinic in the group. The other eleven sites declared 12 nodes between them, and nine of those declared exactly one.

That concentration changes how the property counts should be read, so it is worth separating them. All 53 fax numbers and 64 of the 66 telephone numbers belong to the helios nodes. Strip helios out and the remaining 12 nodes carry 11 names, 11 urls, eight @context, seven logo, six sameAs and six descriptions, with two telephone numbers and no fax numbers at all. The zero on the medical properties is the one figure that survives the split untouched, because it is zero in both groups.

The helios markup is otherwise the best in the stratum and that is the point. It is a real directory, one node per clinic, each with a full PostalAddress, and a crawler reading it learns where 82 German clinics are. Here is one node exactly as delivered, with only the address indented for reading: name "DKD Helios Klinik Wiesbaden", description "DKD Helios Klinik Wiesbaden", url pointing at the clinic page, an address with streetAddress "Aukammallee 33", addressLocality "Wiesbaden", postalCode "65191" and addressCountry "DE", and @type "Hospital". It is valid, it is useful, and it says nothing about what the DKD clinic does. The description field repeats the name verbatim, which is the shape that shows up whenever a template fills a required field from the only string it has.

A directory of 82 clinics where each entry is a name and an address is a map. The specialty would make it a referral. For a site being read by an AI crawler rather than a human with a postcode, the difference between those two is most of the value, and it is the difference between appearing as a location and appearing as an answer. The same pattern of markup that validates while carrying nothing a reader needed appeared in 117 of 612 home pages with a JSON-LD defect and in 2 of 172 home pages carrying opening hours a machine could read.

Does Google show a rich result for medical schema markup?

No, and that is the honest half of this finding. Google's structured data gallery, last updated 2026-10-16 UTC, lists 25 features that structured data can produce in Search: Article, Breadcrumb, Carousel, Course list, Dataset, Discussion forum, Education Q&A, Employer aggregate rating, Event, Image metadata, Job posting, Local business, Math solver, Movie, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Speakable, Subscription and paywalled content, Vacation rental and Video. Not one is medical. There is no documented Search feature that reads MedicalOrganization, Hospital or MedicalWebPage, and no documented penalty for omitting them.

What there is, is Local business, and this is where the measurement and the documentation meet. Google's local business documentation, last updated 2026-09-08 UTC, says to "Use the most specific LocalBusiness sub-type possible" and lists exactly two required properties: address, "the physical location of the business", and name. Because Hospital inherits LocalBusiness through EmergencyService, a Hospital node qualifies. And 94 of the 95 nodes carried a name while 87 carried an address, which means these nodes are already complete for the one Google feature that can read them. The markup is not broken. It is finished, for a purpose narrower than the type suggests.

So the six zero-valued properties are not a compliance failure against any search engine's published requirements, and nobody should fix them expecting a rich result. The case for declaring medicalSpecialty is a different one: it is the only machine-readable place to state what kind of medicine a provider practises, on pages that are otherwise identical to a retail listing. Whether an answer engine reads it is not something this run measured and not something the vendors document. This blog has published what the evidence does support on that question, which is that structured data came third behind other factors in a 1,100 URL citation audit, and that 103 of 385 pages with JSON-LD named no organization at all.

The useful framing for anyone weighing the work is therefore not that these sites are failing a test. It is that the vertical with the most specific vocabulary available to it is using the least specific part of it, and that the gap costs nothing today in Google Search and is unmeasured everywhere else. That is a smaller claim than a headline would like, and it is the claim the measurement supports. The broader type-frequency picture across the corpus is in 88 of the 939 types schema.org defines reaching 626 home pages.

What to check on your own healthcare site

Four checks, in the order that the measurement above suggests they matter, and none of them depends on buying anything. The first is whether a crawler receives the page at all. 32 of the 123 hostnames here did not deliver one, and 19 of those were a 403 from an edge rather than a rule anybody wrote in robots.txt. That is the failure that makes every other check moot, and it is invisible from a browser because a browser is not what was refused. What GPTBot sees answers it for one page without an account.

The second is whether any typed node reaches the delivered HTML, before asking what type it is. 48 of the 91 readable pages had none, and a site in that group gains nothing from a conversation about medicalSpecialty. The third is whether the node that is there uses the most specific type that is true, which is the instruction Google's own local business page gives. A care provider declaring Organization is choosing a less specific type than the vocabulary offers, and 21 of the 43 sites with markup were in that position.

The fourth is the one this post was written about. If a medical type is declared, medicalSpecialty is the property that makes the declaration mean something, and on 95 nodes across 12 sites it was absent every time. It costs one string. isAcceptingNewPatients costs a boolean and answers a question patients phone to ask. Neither buys a rich result in Google Search today, and that is worth knowing before the work is scheduled rather than after.

A note on what none of this measures. AI visibility is not settled by markup, and this blog's own position is that the delivered prose matters more: the parity between what a browser renders and what a crawler receives carries the most weight in this scanner's grade, and a perfect medical node on a page that ships no readable text is worth nothing. The markup is the cheaper half of the job and the half that is skipped most often, which is why it is worth an hour. It is not the job.