Medical schema markup: Physician, Hospital, MedicalProcedure

Medical schema markup no longer earns FAQ rich results, and medical types have no dedicated rich result, but it remains the clearest way to tell Google which hospital, units, doctors and procedures exist and how they connect. Use Hospital per unit, IndividualPhysician per doctor with practicesAt, and MedicalWebPage with MedicalProcedure on procedure pages, generated from your data and validated per template.

Most hospital sites I audit have structured data, and most of it is wrong in one of three ways: it was pasted in once by an agency and never updated, it describes things that are not on the page, or it was added to chase rich results Google no longer shows. Medical schema markup is worth doing properly, but only if you are clear about what it does today and build it from your data rather than by hand.

This is the implementation guide, with JSON-LD examples for a hospital, a doctor and a procedure page, and a process to validate and deploy it at scale. The strategic question of which schema matters for a hospital, and why, is in structured data for hospitals. Read that first if you are deciding whether to invest; read this when you are ready to build.

What medical schema markup does now, and what changed

Two changes should reset your expectations.

First, the vocabulary improved. For years, schema.org’s Physician type was ambiguous: it could mean a doctor or a doctor’s office. In release 24.0, published in January 2024, schema.org added IndividualPhysician and PhysiciansOffice as subtypes of Physician to separate the two. Physician is still defined as an individual physician or a physician’s office considered as a MedicalOrganization, and IndividualPhysician is now the precise type for a single practitioner, with a practicesAt property for where they practise.

Second, the rewards shrank. Google’s Search Central changelog records that FAQ rich results stopped appearing from May 2026 and their documentation was removed in June 2026, after a string of other structured data features were retired in 2025. None of the medical types has ever had a dedicated rich result of its own.

So why bother? Because structured data remains one of the clearest ways to tell Google, and the systems built on it, which entities exist on your site and how they relate: this hospital, at this address, with these departments, where these doctors practise these specialties and perform these procedures. That is entity clarity, not decoration, and it feeds the local and AI surfaces the rest of this series is about.

Build a graph, not snippets

The single most useful habit is to give every entity a stable identifier, using @id, and to reference it rather than repeat it. The group organisation has one @id. Each unit hospital has one and points to the group as its parentOrganization. Each doctor has one and points to the unit with practicesAt. Each procedure has one and is referenced by the units that offer it.

This matters for three reasons. Your markup stays consistent because each fact is defined once. A doctor who practises at two units is one entity with two relationships, not two doctors. And when a doctor moves or a unit changes its phone number, you change it in one place in your data, and every page that references it updates.

At the top of the graph sits the group itself. Mark up the home page, or the about page, with an Organization or MedicalOrganization entity carrying the legal or brand name, logo, main website, official social profiles in sameAs, and a contact point for the central helpline. Every unit’s parentOrganization then points to it. Keep the group’s head office address out of unit pages; the group entity lives on group pages only.

BreadcrumbList is worth adding across the directory as well. It expresses the hierarchy a patient already sees, such as home, specialty, unit, doctor, and it costs almost nothing once the template exists.

Use a URL on your own site plus a fragment as the @id, for example the doctor’s canonical page URL followed by #physician. It never needs to resolve to anything else; it only needs to be stable and unique.

Hospital and unit markup

Every unit page should carry Hospital markup for that unit, not the group. Hospital inherits from MedicalOrganization, LocalBusiness and CivicStructure, so it accepts the usual local business properties plus medicalSpecialty and availableService. Google’s local business documentation requires only a name and address, recommends telephone, url, geo and opening hours, and explains that a business with departments, each with its own hours or phone, can mark each up with the department property.

An example for a fictional unit (all names, numbers and URLs are illustrative):

{
  "@context": "https://schema.org",
  "@type": "Hospital",
  "@id": "https://www.examplehospital.in/indore/#hospital",
  "name": "Example Hospital Indore",
  "url": "https://www.examplehospital.in/indore/",
  "telephone": "+91-00000-00000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Example Road",
    "addressLocality": "Indore",
    "addressRegion": "Madhya Pradesh",
    "postalCode": "452001",
    "addressCountry": "IN"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": 22.72, "longitude": 75.86 },
  "parentOrganization": { "@id": "https://www.examplehospital.in/#organization" },
  "medicalSpecialty": [
    "https://schema.org/Cardiovascular",
    "https://schema.org/Musculoskeletal"
  ],
  "availableService": { "@id": "https://www.examplehospital.in/indore/knee-replacement/#procedure" },
  "department": {
    "@type": "MedicalClinic",
    "name": "Example Hospital Indore Emergency",
    "telephone": "+91-00000-00001",
    "openingHoursSpecification": {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday","Sunday"],
      "opens": "00:00",
      "closes": "23:59"
    }
  }
}

Notes on the example. medicalSpecialty takes values from schema.org’s MedicalSpecialty enumeration, which has members such as Cardiovascular, Oncologic, Pediatric and Musculoskeletal; there is no Orthopedic member, so orthopaedics maps to Musculoskeletal. The phone number should be the unit’s own line, matching the unit’s Business Profile. Only list departments that are real, public-facing and have their own contact details.

Physician schema: IndividualPhysician on the doctor page

The doctor page is where physician schema earns its keep, because doctor-name searches are among the highest-intent queries a hospital gets. Use IndividualPhysician for the doctor, link to the units with practicesAt and hospitalAffiliation, and use properties from the Organization side of the hierarchy, since IndividualPhysician inherits from MedicalOrganization and LocalBusiness rather than Person. Helpfully, knowsLanguage and hasCredential work on organisations as well as people.

{
  "@context": "https://schema.org",
  "@type": "IndividualPhysician",
  "@id": "https://www.examplehospital.in/doctors/dr-a-sharma/#physician",
  "name": "Dr A. Sharma",
  "url": "https://www.examplehospital.in/doctors/dr-a-sharma/",
  "image": "https://www.examplehospital.in/images/doctors/dr-a-sharma.jpg",
  "medicalSpecialty": "https://schema.org/Cardiovascular",
  "practicesAt": { "@id": "https://www.examplehospital.in/indore/#hospital" },
  "hospitalAffiliation": { "@id": "https://www.examplehospital.in/indore/#hospital" },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Example Road",
    "addressLocality": "Indore",
    "addressRegion": "Madhya Pradesh",
    "addressCountry": "IN"
  },
  "knowsLanguage": ["en", "hi"],
  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "credentialCategory": "degree",
    "name": "DM (Cardiology)"
  }
}

A few decisions to make deliberately:

• Clinic or doctor. Use PhysiciansOffice for a clinic that is a place, and IndividualPhysician for the person as a practitioner. A solo doctor’s clinic may warrant both, linked.
• Registration numbers. The usNPI property is US-only. If you publish a doctor’s medical council registration number on the page, the generic identifier property with a PropertyValue is the way to express it; if it is not on the page, leave it out of the markup.
• Several units. practicesAt accepts more than one organisation. Keep one doctor entity with several practicesAt values instead of creating a doctor per unit.
• The page itself. Google’s profile page documentation lists “an employee page on a company website” as a valid use of ProfilePage, so a doctor page can declare itself a ProfilePage with the doctor as its main entity.

The ranking side of doctor pages, including URL structure and what to do when a doctor leaves, is in doctor profile pages that rank and convert.

Procedure and specialty pages: MedicalProcedure and MedicalWebPage

MedicalProcedure describes a process of care, diagnostic, therapeutic, preventive or palliative, and has more specific subtypes such as SurgicalProcedure, DiagnosticProcedure and TherapeuticProcedure. It carries properties like bodyLocation, howPerformed, preparation and followup, and, as a MedicalEntity, relevantSpecialty.

On a procedure page, I wrap the procedure in MedicalWebPage, because the page-level properties lastReviewed and reviewedBy let you state, in markup, the clinical review that should already be visible on the page.

{
  "@context": "https://schema.org",
  "@type": "MedicalWebPage",
  "@id": "https://www.examplehospital.in/indore/knee-replacement/#webpage",
  "url": "https://www.examplehospital.in/indore/knee-replacement/",
  "name": "Knee replacement at Example Hospital Indore",
  "lastReviewed": "2026-09-01",
  "reviewedBy": { "@id": "https://www.examplehospital.in/doctors/dr-b-rao/#physician" },
  "about": {
    "@type": "SurgicalProcedure",
    "@id": "https://www.examplehospital.in/indore/knee-replacement/#procedure",
    "name": "Total knee replacement",
    "bodyLocation": "Knee",
    "relevantSpecialty": "https://schema.org/Musculoskeletal"
  }
}

Keep procedure markup lean. Only mark up what the page says, and never put clinical claims into markup that a reviewer has not approved on the page. howPerformed, preparation and followup are optional; if you use them, the text must match the reviewed content. For specialty landing pages, the unit’s Hospital entity with medicalSpecialty and availableService usually says enough, and a MedicalWebPage with a specialty value can describe the page.

FAQPage, reviews and other traps

Four habits cause most of the trouble I find.

• FAQPage for rich results. FAQ rich results are no longer shown. FAQPage remains valid vocabulary and can still describe a genuine FAQ section, but do not add it expecting extra space in results, and never mark up questions that are not visible on the page.
• Self-serving review stars. Google’s review snippet guidelines say that if an entity controls the reviews about itself, its pages using LocalBusiness or any other Organization markup are not eligible for star review features. Hospital and physician types are organisations, so marking up your own testimonials earns nothing and adds risk. Publishing patient testimonials raises separate professional conduct questions for doctors too.
• Markup that disagrees with the page. Google’s general structured data guidelines say not to mark up content that is not visible to readers, and that markup must be a true representation of the page. A doctor listed in markup at a unit the page does not mention is exactly that problem.
• Services that the unit does not offer. A group-wide list of procedures copied into every unit’s availableService claims capability that some units do not have. Build the list per unit from the same source the unit page uses.
• Language versions left in English. If you publish a Hindi or Tamil version of a page, its markup should describe that page in that language, with its own URL, rather than repeating the English page’s values.
• Group markup on every page. A site-wide block that repeats the head office address on every unit and doctor page tells Google every page is about the head office.

Validating and deploying healthcare structured data at scale

Hand-written JSON-LD works for five pages. A hospital with hundreds of doctors needs healthcare structured data generated from the same database that renders the page. The sequence I follow:

1. Model the entities. List organisation, units, departments, doctors, specialties and procedures, with their @id pattern and relationships.
2. Map to your data. For each property, name the source field in the CMS or doctor database. If there is no reliable source, drop the property.
3. Template it. Generate JSON-LD in the page template, server-side, so it is present in the initial HTML.
4. Validate the vocabulary with the Schema Markup Validator, and check Google features with the Rich Results Test, for one page of each template.
5. Check rendering with URL Inspection in Search Console to confirm Google sees the markup on live pages.
6. Monitor the enhancement reports in Search Console after release, and re-test templates whenever they change.

Include schema in your release checks, which I describe in how to run a healthcare SEO audit. Markup breaks silently when a developer renames a field.

A checklist before you ship

• Every unit page has its own Hospital or clinic entity, with the unit’s own phone and address.
• Every doctor has one IndividualPhysician entity with a stable @id, referenced wherever the doctor appears.
• Specialties use MedicalSpecialty enumeration values, mapped from your own specialty list.
• Procedure pages show a named clinical reviewer and date on the page, reflected in lastReviewed and reviewedBy.
• No self-serving review markup, no hidden content in markup, no FAQPage added purely for rich results.
• Markup is generated from the database, validated for each template and monitored after release.

Structured data is one part of making Google understand who you are; the rest is in entity SEO for doctors and hospitals, and it all sits within the local SEO playbook for hospitals. If you want to see how AI systems currently describe your hospital before and after the work, the AI search visibility audit gives you a baseline, and getting a hospital cited by AI search explains why entity clarity matters there.

Questions people ask