For healthcare sites, add JSON-LD marking of MedicalWebPage, MedicalCondition, and MedicalOrganization first, then tag authors with clear credentials. Healthcare schema is Schema.org structured data that helps search engines and AI systems understand and cite your medical pages. It supports web discoverability, not clinical data exchange, which belongs to standards like FHIR and USCDI.
TL;DR:
- Match each template to its entity: pair condition articles with MedicalWebPage and MedicalCondition, use Person for clinician profiles, and Service for procedure pages.
- Set audience and specialty deliberately, and add ICD codes, SNOMED, or MeSH identifiers when a match exists; include public page content only, never patient records.
- For each author, publish credentials and institutional affiliation, then link sameAs to an institutional bio, ORCID, or Wikidata; clinics can expose specialties and insurance networks.
- Validate every template with Schema.org and Google’s Rich Results Test, then check canonical pages after releases and sample AI citations monthly.
- Start with priority condition, provider, and service pages, then phase controlled vocabularies and broader rollout across editorial, clinical, and development teams.
Table of Contents
- Which Schema.org types fit each healthcare page?
- How do you implement healthcare schema in JSON-LD?
- How do you build E-E-A-T into your markup?
- What should you test, and how often?
- What mistakes break healthcare schema most often?
- Why is Schema.org different from FHIR and USCDI?
- Where should a healthcare team start?
- How we help healthcare teams ship schema that sticks
- FAQ
- Sources
Which Schema.org types fit each healthcare page?
Schema.org’s health and medical types cover conditions, drugs, guidelines, web pages, and scholarly articles. The trick is matching each type to the template you actually publish.
- MedicalCondition: the entity behind a condition article, such as a page on type 2 diabetes.
- MedicalWebPage: the page wrapper for health content, signaling that the page is medical information.
- MedicalOrganization: a clinic, practice group, or health system as an organization.
- Hospital: a hospital facility page with services and locations.
- Person: the physician or author, with credentials and affiliation.
- Service: a procedure or care offering on a services page.
- Drug: a medication page with its own entity.
- MedicalGuideline: a clinical guideline summary you publish or cite.
- FAQPage: question-and-answer blocks on any template.
In practice, a condition article pairs MedicalWebPage with MedicalCondition. A provider profile uses Person. A clinic page uses MedicalOrganization, and a procedures page uses Service. Research pages can use MedicalScholarlyArticle.
Schema.org also provides audience, specialty, and aspect properties. Audience tells machines whether content targets patients or clinicians, and aspect signals the focus, such as diagnosis or treatment. Set them deliberately, because a patient-facing page labeled for clinicians sends a muddled signal.
How do you implement healthcare schema in JSON-LD?
Use JSON-LD, the format Schema.org documentation points to for medical markup. Place it in a script block in the head or body of the page. Because it sits apart from your visible HTML, editors can update it without touching layout.
Here is a condition page pattern you can copy and edit:
{
"@context": "https://schema.org",
"@type": "MedicalWebPage",
"name": "Type 2 Diabetes: Symptoms and Treatment",
"audience": {"@type": "PatientsAudience"},
"about": {
"@type": "MedicalCondition",
"name": "Type 2 diabetes",
"code": {
"@type": "MedicalCode",
"codeValue": "E11",
"codingSystem": "ICD-10"
}
},
"author": {
"@type": "Person",
"name": "Jane Doe, MD",
"jobTitle": "Endocrinologist"
}
}
For a physician, use Person with jobTitle, affiliation, and sameAs. For a clinic, use MedicalOrganization or Hospital with medicalSpecialty and availableService. For procedures, add a Service entity. For Q&A, add FAQPage with Question and Answer pairs.
Where recognized vocabularies exist, annotate with them. Schema.org and SEO practitioners recommend codes from SNOMED, MeSH, or ICD-10 to improve precision. Sanitize everything you publish: markup should describe public page content only, never patient records, PHI, or EHR data.
If you want boilerplate to start from, a JSON-LD schema generator can produce skeleton markup that your clinical reviewers then correct.
| Page template | Primary type | Key properties |
|---|---|---|
| Condition article | MedicalWebPage + MedicalCondition | about, audience, code |
| Provider profile | Person | jobTitle, affiliation, sameAs |
| Clinic page | MedicalOrganization | medicalSpecialty, availableService |
| Hospital page | Hospital | address, availableService |
| Services page | Service | name, provider, areaServed |
| FAQ block | FAQPage | mainEntity |
How do you build E-E-A-T into your markup?
Trust is the hardest thing to fake and the easiest thing to state clearly in code. Mark every author as a Person with a name, credential string, and affiliation. Link out with sameAs to an institutional bio, an ORCID record, or a Wikidata entry so machines can resolve who this person is without guessing.
At the organization level, MedicalOrganization supports properties that matter to patients and to AI systems alike:
- medicalSpecialty: the specialties the practice covers.
- isAcceptingNewPatients: a live signal that answers a very common query.
- healthPlanNetworkId: the insurance networks you participate in.
Annotate audience and specialty on each page, and tie entities to authoritative identifiers wherever they exist. A condition marked with an ICD-10 code is far less ambiguous than a condition marked by name alone.
Pro Tip: Spell out credential strings (for example, “MD, board certified in cardiology”) and name the institution in the affiliation field, so the expertise is stated in the markup and not left to inference.
What should you test, and how often?
Treat validation as a recurring process, not a launch task.
- Run each template through a Schema.org validator and Google’s Rich Results Test, and save screenshots and logs as a baseline.
- Add an automated check to your CMS publishing flow or CI/CD pipeline that fails when JSON-LD disappears from a page.
- Review Google Search Console for structured data errors and warnings after each release.
- Sample AI answers for your priority topics each month and note whether your pages get cited.
- Watch site-level signals that can silently break things: canonical tags staying intact, uptime, and API publishing paths that strip script blocks. An SSL monitoring guide explains why certificate health feeds the credibility of the whole site.
What mistakes break healthcare schema most often?
Most failures are small and fixable.
- Syntax errors and invalid types: a stray comma or a misspelled type name breaks the block. Validators flag the exact line.
- Markup stripped on publish: some APIs and rendering frameworks drop script tags. Confirm the JSON-LD survives on the live canonical URL.
- PHI in markup: never include clinical or patient-level data in Schema.org fields.
- Missing authorship: add Person markup with credentials to every clinical page.
- No controlled vocabularies: add ICD-10, MeSH, or SNOMED codes wherever a match exists.
Why is Schema.org different from FHIR and USCDI?
Schema.org markup serves search and web discovery. FHIR is the standard for exchanging electronic health information between systems, and the two should not be conflated. In the U.S., clinical data exchange follows the United States Core Data for Interoperability, and ONC published USCDI v7 in July 2026. If you ever need to map web content to clinical data, treat it as a translation project with privacy review and governance, never as a markup shortcut. The USCDI platform tracks version updates.
Where should a healthcare team start?
Audit first. List your highest-value pages: condition pages, provider profiles, and service pages. Then phase the work: core types, then authorship, then controlled vocabularies, then scale. Give ownership to editorial, development, clinical or legal review, and SEO together, since schema fails when any one group assumes another owns it. Measure with citation samples and structured data error counts, and resist the urge to mark up everything at once. A small set of correct, credentialed pages beats a sprawling set of sloppy ones.
— Derek
How we help healthcare teams ship schema that sticks
Schema only pays off when it survives redesigns, plugin updates, and publishing workflows. We run a technical schema audit, build a prioritized implementation plan, and then keep the markup healthy through ongoing SEO and website design work, so templates carry structured data by default. Our strategy and management engagement gives you governance and a rollout schedule your editorial, clinical, and development teams can follow. We work in healthcare often, and the approach is project-based and practical. Book a strategy session with us and we will show you which pages to mark up first.
This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.
FAQ
What best describes a schema in healthcare?
A schema is a structured vocabulary that labels the meaning of content so machines can interpret it. In healthcare web publishing, it means Schema.org markup, usually written in JSON-LD, that describes conditions, providers, and organizations.
What is structured and unstructured data in healthcare?
Structured data is labeled in a consistent format machines can read, such as coded fields or JSON-LD. Unstructured data is free text, such as clinical notes or a plain article paragraph. Schema markup adds structure to the unstructured text on your web pages.
Is Schema.org the same as FHIR?
No. Schema.org improves search visibility for web content, while FHIR handles electronic health information exchange between clinical systems. Use each for its own job and keep patient data out of web markup.
Which schema types should a clinic page use?
Start with MedicalOrganization or Hospital, and add medicalSpecialty, availableService, and isAcceptingNewPatients where they apply. Add Person markup for the physicians listed on the page.