Medical Schema Markup for Healthcare Websites – Copy-Paste JSON-LD Guide (2026)

Medical schema markup is structured data added to a healthcare website so that search engines can read your providers, locations, services, and medical content as machine-readable facts rather than inferring them from prose.

It does not directly raise your rankings. What it does is make rich results possible and resolve entity ambiguity; which is increasingly important both for traditional SERP features and for AI-generated answers.

This guide covers implementation only: the correct JSON-LD blocks, the schema types that actually produce Google rich results, and the types that do not. For local SEO for medical practices, including GBP and citations, that post covers the ranking and local-discovery side. For building a trust-first healthcare website, that covers the design layer. This post is the markup layer.

Does Schema Markup Help Healthcare SEO?

No, not directly. Schema markup does not boost rankings as a standalone signal. What it does:

1. makes your content machine-readable so search engines resolve entities correctly.
2. Makes specific rich result formats possible.
3. Removes ambiguity about who your providers are and what your facility treats. Google does not guarantee a rich result even with correct markup.

Healthcare Schema: Supported vs Unsupported by Google

The most important thing to understand about medical schema markup is that Schema.org defines many more healthcare types than Google supports for rich results. Most competing guides recommend implementing MedicalCondition, MedicalTherapy, and Drug schema. None of these produce a Google rich result. Implementing them is not harmful, but it is not the priority.

Schema Type	Google Rich Result?	Valid Schema.org?	Recommended Action
MedicalOrganization (+ subtypes)	Yes; Local Pack, Knowledge Panel	Yes	Implement first. Use most specific subtype.
Hospital	Yes; Local features	Yes	Use instead of generic MedicalOrganization for hospitals.
MedicalClinic	Yes; Local features	Yes	Use for multi-specialty and single-specialty clinics.
Physician	Yes; Provider cards, Local	Yes	Implement on every provider profile page.
Dentist	Yes; Local Pack	Yes	Dental subtype with full address and hours.
Optician	Yes; Local features	Yes	Use for optometry and eye care practices.
FAQPage	Limited; Reduced in 2023+	Yes	Implement with caveat: FAQ rich results heavily reduced.
BreadcrumbList	Yes; Breadcrumb trail	Yes	Implement site-wide.
MedicalWebPage	No direct rich result	Yes	Aids entity understanding. No visible SERP feature.
MedicalCondition	No rich result	Yes	Valid but produces nothing in Google SERP.
MedicalTherapy	No rich result	Yes	Valid but produces nothing in Google SERP.
Drug	No rich result	Yes	Valid but produces nothing in Google SERP.
MedicalProcedure	No rich result	Yes	Valid but produces nothing in Google SERP.
MedicalTest	No rich result	Yes	Valid but produces nothing in Google SERP.

MedicalOrganization Schema: The Correct Starting Point

The MedicalOrganization type is the parent class for all healthcare facility markup. Always use the most specific subtype that accurately describes your facility. The subtype table below maps facility type to schema type:

Facility Type	Correct Schema Subtype	Key Additional Properties
General hospital (50+ beds)	Hospital	numberOfBeds, availableService, department
Multi-specialty clinic	MedicalClinic	medicalSpecialty (array), availableService
Single-specialty clinic	MedicalClinic	medicalSpecialty (single value)
Dental practice	Dentist	paymentAccepted, openingHoursSpecification
Eye care / optometry	Optician	availableService
Psychiatric or mental health	Psychiatric	availableService, medicalSpecialty
General practitioner / family medicine	MedicalClinic	medicalSpecialty: “GeneralPractice”

MedicalOrganization JSON-LD Block: Hospital Example

The following JSON-LD block is the foundation for any hospital or multi-location healthcare network. Every property shown is supported by Google and will pass Rich Results Test validation. Replace the placeholder values with your actual facility data.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Hospital",
  "@id": "https://www.example.com/#hospital",
  "name": "Sunrise General Hospital",
  "url": "https://www.example.com",
  "telephone": "+91-22-1234-5678",

  "address": {
    "@type": "PostalAddress",
    "streetAddress": "42 Medical Colony Road",
    "addressLocality": "Mumbai",
    "addressRegion": "Maharashtra",
    "postalCode": "400001",
    "addressCountry": "IN"
  },

  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 19.0760,
    "longitude": 72.8777
  },

  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "https://schema.org/Monday",
        "https://schema.org/Tuesday",
        "https://schema.org/Wednesday",
        "https://schema.org/Thursday",
        "https://schema.org/Friday"
      ],
      "opens": "08:00",
      "closes": "20:00"
    }
  ],

  "medicalSpecialty": [
    "https://schema.org/Cardiovascular",
    "https://schema.org/Musculoskeletal",
    "https://schema.org/Gynecologic"
  ],

  "availableService": [
    {
      "@type": "SurgicalProcedure",
      "name": "Cardiac Surgery"
    },
    {
      "@type": "SurgicalProcedure",
      "name": "Knee Replacement"
    }
  ],

  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "name": "NABH Accredited",
    "url": "https://nabh.co"
  }
}
</script>

MedicalClinic Schema: Multi-Location Networks

For multi-location hospital networks, implement a separate JSON-LD block per location. Do not use a single organisation-level block for all locations. Each location has its own address, phone, hours, and medical specialties, and Google indexes each page independently. For how to structure keywords across a multi-location hospital network, that post covers the keyword architecture. This post covers the markup layer.

MedicalClinic JSON-LD Block: Multi-Specialty Clinic Example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "MedicalClinic",
  "@id": "https://www.example.com/locations/ahmedabad/#clinic",
  "name": "Apollo Specialty Clinic, Ahmedabad",
  "url": "https://www.example.com/locations/ahmedabad/",
  "telephone": "+91-79-2345-6789",

  "address": {
    "@type": "PostalAddress",
    "streetAddress": "15 SG Highway",
    "addressLocality": "Ahmedabad",
    "addressRegion": "Gujarat",
    "postalCode": "380054",
    "addressCountry": "IN"
  },

  "medicalSpecialty": [
    "https://schema.org/Endocrine",
    "https://schema.org/Obstetric",
    "https://schema.org/Dermatology"
  ],

  "parentOrganization": {
    "@type": "Hospital",
    "@id": "https://www.example.com/#hospital"
  },

  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "https://schema.org/Monday",
        "https://schema.org/Tuesday",
        "https://schema.org/Wednesday",
        "https://schema.org/Thursday",
        "https://schema.org/Friday",
        "https://schema.org/Saturday"
      ],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],

  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "name": "NABH Entry Level Accredited"
  }
}
</script>

[SKYMOON ANALYSIS] In the healthcare accounts we have audited, the most common schema implementation error for multi-location networks is a single Organisation-level block on the homepage with no per-location markup. Each location page is indexed independently and ranked independently.

Without per-location markup, Google cannot reliably associate the correct address and hours with each location’s search appearance. The fix is straightforward: one MedicalClinic block per location, linked to the parent organisation via parentOrganization with an @id reference.

Physician Schema Markup: Provider Profile Pages

Physician schema is implemented on individual provider profile pages, not on the clinic or hospital homepage. The properties that matter most for patient search behaviour are: medicalSpecialty (so Google can match the doctor to condition-specific searches), affiliation (the link between the provider and the institution), and credentials (education, board certifications, and NMC registration in India).

Physician JSON-LD Block: Doctor Profile Example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Physician",
  "@id": "https://www.example.com/doctors/dr-priya-sharma/#physician",
  "name": "Dr. Priya Sharma",
  "url": "https://www.example.com/doctors/dr-priya-sharma/",
  "image": "https://www.example.com/images/dr-priya-sharma.jpg",

  "medicalSpecialty": "https://schema.org/Cardiovascular",

  "description": "Interventional cardiologist with 14 years of clinical experience at Sunrise General Hospital.",

  "hospitalAffiliation": {
    "@type": "Hospital",
    "@id": "https://www.example.com/#hospital",
    "name": "Sunrise General Hospital"
  },

  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "degree",
      "name": "MBBS, MD (Cardiology)",
      "recognizedBy": {
        "@type": "Organization",
        "name": "National Medical Commission, India"
      }
    },
    {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "certification",
      "name": "DM Cardiology",
      "recognizedBy": {
        "@type": "Organization",
        "name": "National Board of Examinations"
      }
    }
  ],

  "sameAs": [
    "https://www.practo.com/doctor/dr-priya-sharma"
  ]
}
</script>

[NOTE] India-specific: The National Medical Commission (NMC) is the regulatory body for medical practitioners in India, replacing the Medical Council of India in 2020. Reference NMC as the recognizedBy organisation for MBBS and MD credentials.

For NABH accreditation at the facility level, use the hasCredential structure shown in the Hospital block above. There is no single standard schema property for an NMC registration number; use identifier with a PropertyValue nested type if you want to express the registration number explicitly.

Dentist Schema Markup

Dental practices use the Dentist subtype, which inherits all LocalBusiness properties and adds the healthcare-specific fields. The key distinction from a general MedicalClinic: the Dentist type signals the specialty to Google without needing the medicalSpecialty property.

Dentist JSON-LD Block: Dental Practice Example

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://www.example.com/#dentist",
  "name": "Smile First Dental Centre",
  "url": "https://www.example.com",
  "telephone": "+91-80-3456-7890",

  "address": {
    "@type": "PostalAddress",
    "streetAddress": "22 Indiranagar Main Road",
    "addressLocality": "Bengaluru",
    "addressRegion": "Karnataka",
    "postalCode": "560038",
    "addressCountry": "IN"
  },

  "medicalSpecialty": "https://schema.org/Dentistry",

  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "https://schema.org/Monday",
        "https://schema.org/Tuesday",
        "https://schema.org/Wednesday",
        "https://schema.org/Thursday",
        "https://schema.org/Friday",
        "https://schema.org/Saturday"
      ],
      "opens": "09:30",
      "closes": "19:30"
    }
  ],

  "priceRange": "₹₹",
  "paymentAccepted": "Cash, Credit Card, UPI",
  "currenciesAccepted": "INR"
}
</script>

Medical Webpage Schema: What It Does and Does Not Do

MedicalWebPage (also written as medical web page schema in search queries) is a schema.org type for health content pages: condition pages, treatment pages, symptom guides.

It produces no Google rich result. Its value is entity understanding: it tells Google and AI systems that this page is authored medical content, who reviewed it, when it was last reviewed, and for which medical audience.

Implement MedicalWebPage on condition and treatment content pages with these properties:

• reviewedBy: Physician or MedicalOrganization who reviewed the content
• lastReviewed: ISO date of the most recent medical review
• medicalAudience: the intended reader (Patient, Clinician, MedicalResearcher)
• about: the MedicalCondition the page describes
• mainContentOfPage: reference to the main content block

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "MedicalWebPage",
  "name": "Endometriosis: Symptoms, Diagnosis, and Treatment Options",
  "url": "https://www.example.com/conditions/endometriosis/",
  "dateModified": "2026-07-15",
  "lastReviewed": "2026-07-15",

  "reviewedBy": {
    "@type": "Physician",
    "@id": "https://www.example.com/doctors/dr-priya-sharma/#physician",
    "name": "Dr. Priya Sharma"
  },

  "medicalAudience": {
    "@type": "Patient"
  },

  "about": {
    "@type": "MedicalCondition",
    "name": "Endometriosis",
    "sameAs": "https://en.wikipedia.org/wiki/Endometriosis"
  }
}
</script>

Schema Markup Mistakes Healthcare Websites Make

Error 1: MedicalOrganization and LocalBusiness as Competing Blocks

The most common healthcare schema implementation error: shipping both a MedicalOrganization block and a separate LocalBusiness block on the same page, with the same name and address.

Google sees two entities that appear to be the same business described by two different types. This creates ambiguity rather than resolving it.

MedicalOrganization is a subtype of LocalBusiness. It inherits every LocalBusiness property: address, telephone, openingHours, priceRange, geo, review, aggregateRating. Use the most specific type and include all the address and hours properties in that single block.

Error 2: Implementing Unsupported Types as the Primary Focus

As the table above shows, MedicalCondition, MedicalTherapy, Drug, and MedicalProcedure produce no Google rich result. Many healthcare SEO agencies bill for implementing these types and present schema validation tool screenshots as evidence the work is done.

A page that validates is not the same as a page that earns a rich result. Ask specifically which supported types will produce which visible SERP features.

Error 3: Implement and Never Monitor

Most schema implementations are deployed once and never checked again. A template change, CMS update, or plugin conflict can silently break JSON-LD.

Google Search Console’s Enhancements report will show structured data errors, but only if you look. Set a recurring reminder to check the Enhancements report monthly. For measurement methodology, the on-page SEO checklist’s schema section covers what to monitor.

Error 4: Review Schema Without Reading Google’s Policy

AggregateRating and Review schema are supported on Physician and MedicalOrganization. But Google’s review snippet policies for medical and healthcare entities are strict: reviews must come from an independent third-party platform, not be collected and self-published on your own site.

The risk of a manual action for “misleading structured data” is real for healthcare entities that publish self-collected reviews with AggregateRating markup.

[LEGAL / POLICY NOTE] Review schema policy changes. What is permitted for medical entities specifically may differ from general local business reviews. This is general guidance, not legal advice.

Check Google’s review snippet documentation at the time of implementation, and consult a qualified professional on the regulatory side if your market has specific advertising standards for healthcare testimonials. In India, ASCI guidelines apply to healthcare advertising claims.

FAQPage Schema for Healthcare Websites

FAQPage schema is supported by Google and still produces rich results in some contexts, but Google significantly reduced the frequency of FAQ rich results in 2023.

The current primary value of FAQPage schema for healthcare websites is AI Overview extraction: AI systems read the structured Q&A pairs as ready-to-cite answers. Implement it on pages with genuine patient Q&A sections.

FAQPage JSON-LD Block: Healthcare FAQ Example

<script type="application/ld+json">{ "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Does schema markup improve healthcare SEO rankings?", "acceptedAnswer": { "@type": "Answer", "text": "No, not directly. Schema markup makes rich results possible and helps search engines resolve entity information correctly. It does not boost rankings as a standalone signal." } }, { "@type": "Question", "name": "What schema type should a hospital use?", "acceptedAnswer": { "@type": "Answer", "text": "Start with the Hospital subtype of MedicalOrganization. Include address, telephone, openingHoursSpecification, medicalSpecialty, and geo properties in a single JSON-LD block." } } ]}</script>

Healthcare Schema Markup and AI Search

Structured data helps AI systems parse entities unambiguously. A Physician block that explicitly names a doctor’s specialty, affiliation, and credentials gives an AI more to work with than inferring those facts from unstructured prose. Whether schema markup directly influences AI Overview or ChatGPT citations is not confirmed by any search engine. The evidence is correlational.

For the full argument on how AI systems choose which sources to cite, how AI engines choose which sources to cite covers that territory in depth. The schema contribution to AI visibility is entity disambiguation: Google and AI systems resolve “Dr. Priya Sharma” as a specific person with specific credentials at a specific institution when the Physician block makes those relationships explicit. That is measurable and useful. Claiming it guarantees AI citations is not supportable.

How to Add Schema Markup to a Healthcare Website: Validation Workflow

Four steps to implement and verify healthcare structured data json ld correctly:

• Step 1: Implement in JSON-LD. Add a script tag with type=”application/ld+json” in the page head or body. Do not use Microdata or RDFa. Paste the block from this guide and replace all placeholder values with real data.
• Step 2: Validate in Google’s Rich Results Test (search.google.com/test/rich-results). This confirms whether the markup is eligible for a Google rich result. A green result means eligible; not confirmed.
• Step 3: Validate in Schema Markup Validator (validator.schema.org). This checks conformance to the Schema.org specification independently of Google’s rich results. A type that fails here is incorrect. A type that passes here but not in the Rich Results Test is valid but unsupported by Google for rich results.
• Step 4: Monitor in Google Search Console > Enhancements. After Google crawls the page, the Enhancements report shows valid items, warnings, and errors per schema type. Most implementers deploy schema once and never open this report. Check it monthly. Enable Search Console alerts for new structured data issues.

[SKYMOON ANALYSIS] In the audits we have conducted across healthcare websites, the Enhancements report in Search Console is the single most consistently ignored QA step.

We routinely find hospitals with broken MedicalClinic markup that passed the Rich Results Test on deployment but was broken by a CMS template update six months later. A validation pass at launch is a snapshot, not ongoing coverage. Monthly monitoring is the actual quality control.

India-Specific Schema Fields: NABH and NMC

India-specific implementation notes for healthcare schema markup. For healthcare SEO strategy for the Indian market, that post covers the broader India market context.

• NABH accreditation: Express using hasCredential with EducationalOccupationalCredential nested type. Name: “NABH Accredited” or “NABH Entry Level Accredited”. URL: https://nabh.co. As of 2026, over 4,200 hospitals in India hold NABH accreditation; including it in schema signals quality to both search engines and patients researching facilities.
• NMC registration: The National Medical Commission (NMC) is the statutory body for medical education and practice registration in India. For physician schema, use hasCredential with recognizedBy referencing the NMC. There is no standard schema property for a registration number; use identifier with PropertyValue nested type if you need to express the number.
• ABHA/ABDM identifiers: If your facility is ABDM-registered and has a Health Facility Registry (HFR) ID, express it using identifier with PropertyValue. This is not currently a documented Google schema use case, but it is valid structured data and aids machine readability for Indian health platforms.
• Hindi/vernacular content pages: Apply MedicalWebPage with inLanguage: “hi” for Hindi content. The medicalAudience property works for any language. There is no language-specific schema type required.

Frequently Asked Questions

What schema type should a hospital use?

Facility Type	Start With	Then Add
General hospital	Hospital	medicalSpecialty, availableService, department, numberOfBeds
Multi-specialty clinic	MedicalClinic	medicalSpecialty (array), availableService, parentOrganization
Dental practice	Dentist	availableService, paymentAccepted
Individual doctor	Physician	medicalSpecialty, affiliation, hasCredential

Implementing Healthcare Schema Markup

The JSON-LD blocks in this guide cover the five schema types that produce verifiable Google rich results for healthcare websites: Hospital, MedicalClinic, Physician, Dentist, and FAQPage. Start with the facility-level block, then implement Physician markup on every provider profile. Add MedicalWebPage to condition and treatment content pages as a secondary step.

Validate after every implementation and monitor the Search Console Enhancements report monthly. For healthcare SEO services that include a structured data audit alongside the full SEO implementation, that page describes how Skymoon approaches healthcare schema alongside the wider SEO programme.