Medical Practice Schema Markup: JSON-LD for Every Physician Specialty
Ik heb physician directory sites gebouwd voor multi-location health systems, solo dermatology practices, en alles daartussenin. En de grootste gemiste kans die ik zie op healthcare websites is structured data. Niet het generieke LocalBusiness type -- ik bedoel de specifieke Physician en MedicalSpecialty schema types die Google precies vertellen wat een provider doet, waar ze praktijk houden, en waarom patiënten hen kunnen vertrouwen.
De meeste medical practice websites worden geleverd zonder schema markup of, erger nog, met onjuiste markup gegenereerd door een WordPress plugin die een cardiology practice behandelt als een pizzeria. Deze guide geeft je production-ready JSON-LD voor echte medical specialties -- cardiology, pediatrics, urology, orthopedics, en meer -- samen met de redenering achter elke property keuze.
Table of Contents
- Why Medical Schema Markup Matters in 2026
- Schema.org Types for Medical Practices
- Understanding MedicalSpecialty Enumeration Values
- Base Physician JSON-LD Template
- Specialty-Specific JSON-LD Examples
- MedicalOrganization and MedicalClinic Schema
- Connecting Physicians to Organizations
- Properties That Build E-E-A-T
- Validation and Testing
- Common Mistakes to Avoid
- FAQ

Why Medical Schema Markup Matters in 2026
Google's AI Overviews domineren nu healthcare queries. Als een patiënt "cardiologist accepting new patients near me" zoekt, scant Google niet meer alleen je pagina tekst -- het leest je structured data om entity relationships op te bouwen, knowledge panels in te vullen, en AI-gegenereerde antwoorden te voeden.
Hier is wat juiste medical schema markup kan triggeren:
| Rich Result Type | Triggered By | Impact |
|---|---|---|
| Review snippets | AggregateRating on Physician |
Star ratings in SERPs |
| Knowledge panel | Physician + sameAs links |
Brand presence for named doctors |
| Local pack enhancement | MedicalClinic + openingHours |
Map listing details |
| FAQ rich results | FAQPage schema (healthcare sites still eligible) |
Expanded SERP real estate |
| AI Overview citations | Complete entity graph | Cited as source in AI answers |
Een 2025 BrightLocal study ontdekte dat healthcare listings met review snippets 37% hogere click-through rates zagen dan die zonder. En Schema App's research bevestigde dat physician pages met complete structured data 2,8x vaker verschenen in AI Overview citations.
De bottom line: als je physician pages geen juiste schema markup hebben, laat je zichtbaarheid op tafel liggen.
Schema.org Types for Medical Practices
Voordat we code schrijven, moeten we de type hiërarchie begrijpen. Schema.org geeft ons verschillende types die relevant zijn voor healthcare, en de juiste kiezen is belangrijk.
Thing
└── Organization
└── LocalBusiness
└── MedicalBusiness
├── MedicalClinic
├── Optician
├── Pharmacy
└── Physician
Physician is een subtype van MedicalBusiness, wat zelf een subtype is van LocalBusiness. Dit is belangrijk omdat het betekent dat een Physician entity alle local business properties erft (address, hours, geo coordinates) plus medical-specifieke properties zoals medicalSpecialty en hospitalAffiliation.
Voor een solo practitioner's website is Physician je primaire type. Voor een multi-provider clinic wil je een MedicalClinic of MedicalOrganization als parent entity met individuele Physician entries nested of gelinkt via member of op aparte pagina's.
When to Use What
| Your Setup | Primary Type | Secondary Types |
|---|---|---|
| Solo doctor, one location | Physician |
MedicalOrganization (optional) |
| Group practice, single location | MedicalClinic |
Physician per provider page |
| Health system, multiple locations | MedicalOrganization |
MedicalClinic per location, Physician per provider |
| Hospital | Hospital |
Physician, MedicalClinic (departments) |
Understanding MedicalSpecialty Enumeration Values
De medicalSpecialty property accepteert values van Schema.org's MedicalSpecialty enumeration. Dit zijn geen free-text velden -- het zijn specifieke, voorgedefinieerde values. Hier zijn de waarden die je het meest zult gebruiken:
| Specialty | Schema.org Value | Notes |
|---|---|---|
| Cardiology | Cardiovascular |
Covers cardiology and cardiovascular surgery |
| Pediatrics | Pediatric |
General pediatrics |
| Urology | Urologic |
Includes pediatric urology |
| Dermatology | Dermatology |
Also DermatologyLaserSurgery variant |
| Orthopedics | Musculoskeletal |
Orthopedic surgery falls here |
| Neurology | Neurological |
Distinct from Psychiatric |
| Obstetrics & Gynecology | Obstetric and/or Gynecologic |
Can specify both |
| Emergency Medicine | Emergency |
ER physicians |
| Family Medicine | PrimaryCare |
General practice, family medicine |
| Oncology | Oncologic |
Cancer treatment |
| Pulmonology | Pulmonary |
Lung and respiratory |
| Gastroenterology | Gastroenterologic |
GI specialists |
| Endocrinology | Endocrine |
Diabetes, thyroid, etc. |
| Ophthalmology | Optometric |
Eye care |
| Psychiatry | Psychiatric |
Mental health physicians |
Een volledige lijst is beschikbaar op schema.org/MedicalSpecialty. Merk op dat sommige specialties breder categorieën mappen dan je misschien verwacht -- er is bijvoorbeeld geen aparte "Interventional Cardiology" value. Je zou Cardiovascular gebruiken en de subspecialty beschrijven in de physician's description of knowsAbout properties.

Base Physician JSON-LD Template
Hier is een solide starttemplate voor elke physician page. Ik zal de sleutel beslissingen annoteren.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Physician",
"@id": "https://example.com/doctors/jane-smith#physician",
"name": "Dr. Jane Smith, MD, FACC",
"image": "https://example.com/images/dr-jane-smith.jpg",
"url": "https://example.com/doctors/jane-smith",
"telephone": "+1-555-867-5309",
"description": "Board-certified cardiologist specializing in interventional cardiology and structural heart disease with 15 years of clinical experience.",
"medicalSpecialty": "https://schema.org/Cardiovascular",
"isAcceptingNewPatients": true,
"address": {
"@type": "PostalAddress",
"streetAddress": "450 Heart Center Drive, Suite 200",
"addressLocality": "Austin",
"addressRegion": "TX",
"postalCode": "78701",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 30.2672,
"longitude": -97.7431
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "08:00",
"closes": "17:00"
}
],
"sameAs": [
"https://www.healthgrades.com/physician/dr-jane-smith",
"https://www.doximity.com/pub/jane-smith-md",
"https://www.linkedin.com/in/drjanesmith"
],
"alumniOf": {
"@type": "CollegeOrUniversity",
"name": "Johns Hopkins University School of Medicine"
},
"hasCredential": [
{
"@type": "EducationalOccupationalCredential",
"credentialCategory": "Board Certification",
"name": "American Board of Internal Medicine - Cardiovascular Disease"
}
],
"hospitalAffiliation": {
"@type": "Hospital",
"name": "St. David's Medical Center",
"url": "https://stdavids.com"
},
"worksFor": {
"@type": "MedicalOrganization",
"@id": "https://example.com/#organization",
"name": "Austin Heart Specialists"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.8",
"reviewCount": "142",
"bestRating": "5"
}
}
</script>
Een paar dingen die ik wil benadrukken:
@id: Dit creëert een unieke identifier voor deze entity. Gebruik de pagina URL plus een fragment. Dit wordt kritiek wanneer je physicians aan organizations linkt over pagina's heen.medicalSpecialty: Ik gebruik de volledige URL vorm (https://schema.org/Cardiovascular) in plaats van alleen de string. Beide werken, maar de URL vorm is explicieter.isAcceptingNewPatients: Dit is een nieuwere property specifiek voorPhysician. Gebruik het. Patiënten zoeken hier constant naar.sameAs: Link naar geverifieerde third-party profielen. Dit is hoe Google entity confidence opbouwt en potentieel knowledge panels triggert.aggregateRating: Alleen opnemen als je reviews zichtbaar op de pagina toont. Google's guidelines zijn streng hierover -- verborgen ratings schenden hun policies.
Specialty-Specific JSON-LD Examples
Laten we voorbeelden uitwerken voor de specialties die mensen werkelijk zoeken.
Cardiology (Cardiovascular)
{
"@context": "https://schema.org",
"@type": "Physician",
"name": "Dr. Robert Chen, MD, FACC",
"medicalSpecialty": "https://schema.org/Cardiovascular",
"knowsAbout": [
"Interventional Cardiology",
"Cardiac Catheterization",
"Coronary Artery Disease",
"Heart Failure Management",
"Echocardiography"
],
"availableService": [
{
"@type": "MedicalProcedure",
"name": "Cardiac Catheterization",
"procedureType": "https://schema.org/PercutaneousProcedure"
},
{
"@type": "MedicalTest",
"name": "Stress Echocardiography"
},
{
"@type": "MedicalTest",
"name": "Electrocardiogram (ECG/EKG)"
}
]
}
De availableService property is uniek voor Physician en laat je exacte procedures en tests specificeren. Voor cardiology, deze onderscheiding tussen MedicalProcedure en MedicalTest map natuurlijk naar de interventional vs. diagnostic splitsing.
Pediatrics
{
"@context": "https://schema.org",
"@type": "Physician",
"name": "Dr. Maria Gonzalez, MD, FAAP",
"medicalSpecialty": "https://schema.org/Pediatric",
"knowsAbout": [
"Well-Child Visits",
"Childhood Immunizations",
"Developmental Screening",
"Adolescent Medicine",
"Newborn Care"
],
"availableService": [
{
"@type": "MedicalTherapy",
"name": "Pediatric Vaccination Program"
},
{
"@type": "MedicalTest",
"name": "Developmental Milestone Assessment"
}
],
"hasCredential": [
{
"@type": "EducationalOccupationalCredential",
"credentialCategory": "Board Certification",
"name": "American Board of Pediatrics"
}
]
}
Pediatrics is interessant omdat de MedicalSpecialty value gewoon Pediatric is -- er is geen aparte value voor pediatric subspecialties zoals pediatric cardiology. Voor een pediatric cardiologist zou je beide specialties opnemen:
"medicalSpecialty": [
"https://schema.org/Pediatric",
"https://schema.org/Cardiovascular"
]
Ja, medicalSpecialty accepteert een array. Gebruik het.
Urology
{
"@context": "https://schema.org",
"@type": "Physician",
"name": "Dr. Michael Torres, MD, FACS",
"medicalSpecialty": "https://schema.org/Urologic",
"knowsAbout": [
"Robotic-Assisted Surgery",
"Prostate Cancer Treatment",
"Kidney Stone Management",
"Urinary Incontinence",
"Male Infertility"
],
"availableService": [
{
"@type": "MedicalProcedure",
"name": "Robot-Assisted Laparoscopic Prostatectomy",
"procedureType": "https://schema.org/SurgicalProcedure"
},
{
"@type": "MedicalProcedure",
"name": "Extracorporeal Shock Wave Lithotripsy (ESWL)",
"procedureType": "https://schema.org/NoninvasiveProcedure"
},
{
"@type": "MedicalTest",
"name": "Cystoscopy"
}
]
}
Orthopedics
{
"@context": "https://schema.org",
"@type": "Physician",
"name": "Dr. Sarah Kim, MD",
"medicalSpecialty": "https://schema.org/Musculoskeletal",
"knowsAbout": [
"Total Joint Replacement",
"Sports Medicine",
"Arthroscopic Surgery",
"Fracture Care",
"Rotator Cuff Repair"
],
"availableService": [
{
"@type": "MedicalProcedure",
"name": "Total Knee Arthroplasty",
"procedureType": "https://schema.org/SurgicalProcedure"
},
{
"@type": "MedicalProcedure",
"name": "Arthroscopic ACL Reconstruction",
"procedureType": "https://schema.org/SurgicalProcedure"
}
]
}
Merk op dat de medicalSpecialty value Musculoskeletal is, niet "Orthopedic." Dit verwart mensen constant.
MedicalOrganization and MedicalClinic Schema
Je organization-level schema is de foundation. Elke physician entity moet ernaar verwijzen. Hier is een compleet MedicalClinic voorbeeld:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "MedicalClinic",
"@id": "https://example.com/#clinic",
"name": "Austin Heart Specialists",
"url": "https://example.com",
"logo": "https://example.com/images/logo.png",
"image": "https://example.com/images/clinic-exterior.jpg",
"telephone": "+1-555-867-5309",
"medicalSpecialty": "https://schema.org/Cardiovascular",
"address": {
"@type": "PostalAddress",
"streetAddress": "450 Heart Center Drive",
"addressLocality": "Austin",
"addressRegion": "TX",
"postalCode": "78701",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 30.2672,
"longitude": -97.7431
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "07:30",
"closes": "17:30"
}
],
"availableService": [
{
"@type": "MedicalTest",
"name": "Cardiac Stress Testing"
},
{
"@type": "MedicalProcedure",
"name": "Cardiac Catheterization"
}
],
"member": [
{
"@type": "Physician",
"@id": "https://example.com/doctors/jane-smith#physician"
},
{
"@type": "Physician",
"@id": "https://example.com/doctors/robert-chen#physician"
}
],
"sameAs": [
"https://www.facebook.com/austinheartspecialists",
"https://www.google.com/maps/place/?q=place_id:ChIJ_____"
]
}
</script>
De member array gebruikt @id verwijzingen om physician entities gedefinieerd op hun individuele pagina's te linken. Dit creëert een verbonden graph die Google kan traverseren.
Connecting Physicians to Organizations
Dit is waar de meeste implementaties mislopen. Je hebt bidirectionele verwijzingen nodig:
- Organization → Physician: Gebruik
memberop de organization pagina - Physician → Organization: Gebruik
worksForop de physician pagina
Beiden moeten naar dezelfde @id verwijzen. Denk er als een foreign key in een database aan. Als de IDs niet matchen, kan Google ze niet verbinden.
// On the physician page:
"worksFor": {
"@type": "MedicalClinic",
"@id": "https://example.com/#clinic",
"name": "Austin Heart Specialists"
}
// On the organization page:
"member": [
{
"@type": "Physician",
"@id": "https://example.com/doctors/jane-smith#physician"
}
]
Voor multi-location practices zou elke locatie een aparte MedicalClinic entity moeten zijn met zijn eigen @id, en physicians die op meerdere locaties praktiseren moeten practicesAt (een array) gebruiken in plaats van worksFor.
Als je deze sites bouwt op headless CMS platforms, deze soort relationele data modeling map perfect naar content references in systemen zoals Sanity of Contentful. We behandelen dit exacte patroon in ons headless CMS development werk -- het CMS content model spiegelt de schema.org entity graph.
Properties That Build E-E-A-T
Google's quality raters evalueren Experience, Expertise, Authoritativeness, en Trustworthiness voor YMYL (Your Money or Your Life) inhoud. Healthcare is de quintessentiële YMYL categorie. Deze schema properties ondersteunen direct E-E-A-T signalen:
| Property | Type | E-E-A-T Signal |
|---|---|---|
hasCredential |
EducationalOccupationalCredential |
Expertise |
alumniOf |
CollegeOrUniversity |
Expertise |
memberOf |
Organization |
Authoritativeness |
hospitalAffiliation |
Hospital |
Authoritativeness, Trust |
award |
Text |
Authoritativeness |
knowsAbout |
Text or Thing |
Expertise |
medicalSpecialty |
MedicalSpecialty |
Expertise |
sameAs |
URL |
Trust (cross-reference verification) |
aggregateRating |
AggregateRating |
Trust (social proof) |
Kritieke regel: je kunt alleen inhoud markeren die zichtbaar op de pagina is. Als je board certifications in je schema oplijst maar ze nergens op de physician's profiel pagina toont, schend je Google's structured data guidelines. Voeg eerst de inhoud toe, markeer het dan.
Validation and Testing
Voordat je alles naar production pusht:
- Google Rich Results Test (search.google.com/test/rich-results): Valideert geschiktheid voor rich results
- Schema Markup Validator (validator.schema.org): Controleert syntax en conformiteit met Schema.org vocabulary
- Google Search Console: Monitor de "Enhancements" sectie na deployment op fouten
Hier is mijn testing workflow:
# If you're generating schema programmatically (Next.js, Astro, etc.)
# Output the JSON to a file and validate locally first
node -e "const schema = require('./generate-schema.js'); console.log(JSON.stringify(schema, null, 2))" > schema-output.json
# Then paste into validator.schema.org or use their API
Als je bouwt met Next.js of Astro, kun je deze JSON-LD blokken dynamisch genereren uit je CMS data. Beide frameworks hanteren <script type="application/ld+json"> injectie netjes -- Next.js via de <Script> component of next/head, Astro via zijn <head> slot.
Common Mistakes to Avoid
Generic LocalBusiness gebruiken in plaats van Physician. Je verliest alle medical-specifieke properties. Een Physician is een LocalBusiness, dus je krijgt alles wat LocalBusiness biedt plus meer.
Free-text medicalSpecialty values. Schrijven "medicalSpecialty": "Cardiology" in plaats van de juiste enumeration value gebruiken (Cardiovascular) betekent dat Google de specialty misschien niet correct begrijpt.
Geo coördinaten ontbreken. Lat/long data helpt Google je practice te associëren met location-based queries. Sla dit niet over.
Duplicate @id values over verschillende entities. Elke entity heeft een unieke @id nodig. Ik heb implementaties gezien waar elke physician dezelfde @id suffix deelt -- dat breekt volledig de entity graph.
Inhoud markeren die niet op de pagina is. Dit verdient herhaling. Google's guidelines zijn expliciet: alles in je structured data moet overeenkomen met zichtbare inhoud. Schendingen kunnen resulteren in manual actions.
isAcceptingNewPatients negeren. Dit is een high-intent signaal. Patiënten filteren hierop. Voeg het toe en houd het up-to-date.
FAQ
What's the difference between Physician and MedicalBusiness schema types?
Physician is een subtype van MedicalBusiness. Gebruik Physician voor individuele provider pagina's en MedicalBusiness (of meer specifiek, MedicalClinic) voor de praktijk zelf. Physician erft alle properties van MedicalBusiness en voegt physician-specifieke toe zoals hospitalAffiliation, availableService, en isAcceptingNewPatients.
Can I list multiple medical specialties for one physician?
Ja. De medicalSpecialty property accepteert een array. Een physician die zowel pediatric als cardiovascular specialist is kan beide opnemen: "medicalSpecialty": ["https://schema.org/Pediatric", "https://schema.org/Cardiovascular"]. Dit is gebruikelijk voor dual-boarded physicians.
Does medical schema markup directly improve Google rankings?
Structured data is geen directe ranking factor. Echter, het maakt rich results mogelijk (star ratings, FAQ dropdowns, knowledge panels) die click-through rates significant verbeteren. Het voedt ook Google's entity understanding, wat invloed heeft op hoe je practice verschijnt in AI Overviews en local pack resultaten. De indirecte SEO impact is substantieel.
What schema type should I use for a hospital's physician directory?
Gebruik Hospital als je top-level entity, MedicalClinic voor individuele departments (bv. Department of Cardiology), en Physician voor elke provider pagina. Verbind ze met member, worksFor, en department properties. Dit creëert een volledige organizational graph.
Is JSON-LD the only format for medical schema markup?
Nee -- je kunt ook Microdata of RDFa ingebed in je HTML gebruiken. Maar Google recommandeert expliciet JSON-LD en het is het format dat ze gebruiken in al hun documentatie voorbeelden. JSON-LD is ook veel makkelijker te onderhouden omdat het gescheiden is van je page layout. Je kunt het programmatisch genereren uit CMS data zonder templates aan te raken.
How do I handle a physician who practices at multiple locations?
Gebruik de practicesAt property met een array van MedicalClinic of Hospital entities, elk met zijn eigen @id. Dupliceer de physician entity niet over locaties heen -- creëer één canonieke Physician entity en link het naar meerdere practice locaties. Elke location's schema zou ook naar de physician verwijzen via member.
Should I include patient reviews in my physician schema?
Alleen als de reviews zichtbaar op de physician's pagina worden getoond. Gebruik de aggregateRating property op het Physician type en voeg ratingValue, reviewCount, en bestRating toe. Google neemt dit serieus -- markeren van verborgen of nep reviews kan resulteren in manual penalties. Als je reviews verzamelt via third-party platforms zoals Healthgrades, link naar ze via sameAs in plaats.
How often should I update medical practice schema markup?
Werk je structured data bij wanneer de onderliggende informatie verandert: nieuwe openingstijden, een physician vertrekt of sluit zich aan, een provider stopt met het accepteren van nieuwe patiënten, of contactinformatie verandert. Voor praktijken met een headless CMS met dynamische schema generation gebeurt dit automatisch wanneer content editors de CMS bijwerken. Als je JSON-LD hardcoded, stel een driemaandelijks review cadence in op zijn minst. Verouderde structured data -- vooral onjuiste isAcceptingNewPatients of telephone values -- erodeert vertrouwen bij zowel Google als patiënten.