MedicalOrganization, Hospital or MedicalClinic: Choosing the Right schema.org Type

This post is for clinic owners, hospital web teams and the marketers who brief them. If your developer has asked "which schema type do you want?" and the honest answer was a shrug, this is the decision guide. It assumes you already know what JSON-LD is and want to choose the type for a facility, not learn the syntax.

The question is narrow: for a single clinic, a multi-specialty hospital and a diagnostics chain, which schema.org type belongs on which page, which subtypes cause trouble, and what you should not expect Google to do with the answer. Our complete implementation guide covers how to write and deploy the markup. This article is about the choice that comes before.

One caution first. Google's structured data gallery does not list a medical-specific feature. Type choice here is about accurate description and a consistent entity, not about a rich result you can unlock. Choose the type that is true.

How the types relate

The schema.org types you will meet sit in a small family. MedicalOrganization is a subtype of Organization, and its own subtypes are Dentist, DiagnosticLab, Hospital, MedicalClinic, Pharmacy, Physician and VeterinaryCare. Three properties are defined at this level: medicalSpecialty, isAcceptingNewPatients and healthPlanNetworkId.

The inheritance is not a single line, and that matters for pitfalls later.

• Hospital inherits through MedicalOrganization, through CivicStructure and through LocalBusiness and EmergencyService. It adds availableService, medicalSpecialty and healthcareReportingData.
• MedicalClinic sits under both MedicalOrganization and LocalBusiness through MedicalBusiness. It adds availableService and medicalSpecialty.
• Physician is defined as "an individual physician or a physician's office considered as a MedicalOrganization". It adds hospitalAffiliation, availableService, occupationalCategory and usNPI, the last being a United States identifier that does not apply to Indian practitioners.
• DiagnosticLab is a MedicalOrganization and adds availableTest.

Because Hospital, MedicalClinic and Physician are all LocalBusiness descendants, Google's local business documentation applies to them. It asks for the most specific LocalBusiness subtype possible and treats address and name as required. It also says each physical location should be marked up as its own entity.

Type selection by facility profile

Start with the physical thing the page is about, then pick the most specific type that is true for that thing.

Hypothetical illustration: a diagnostics brand with 40 branches across Delhi NCR. Each branch page describes one address, one set of opening hours and one phone line, so each is a DiagnosticLab. The brand page describes the company, so it is an Organization or MedicalOrganization without branch details. Branch pages point to the brand with parentOrganization.

Pitfalls by subtype

Marking the group as a Hospital. A hospital group's home page is not a hospital. If the page lists three campuses, three addresses and one corporate name, the entity on that page is an organisation. Putting Hospital there with an array of addresses produces one blurred node that Google, Maps data and LLM tools all struggle to reconcile with the individual campuses.

Using MedicalOrganization as a lazy default. It is valid, and it is the right supertype when you genuinely describe an organisation that is not a specific facility, such as a health network. If the page is about a place where care is delivered, a more specific type is both more accurate and consistent with Google's guidance on local business subtypes. Treat the generic type as a fallback you justify, not a default.

Stacking types. Google allows an array of types for LocalBusiness. That does not mean you should write ["Hospital", "MedicalClinic", "Physician"] for a hospital with an outpatient wing. Each added type is a claim. A hospital that is also a clinic is a hospital with a clinic department or a related clinic node; model that, do not blur it.

Using Physician for a department. A cardiology department is not a physician or a physician's office. Use the `department` property on Organization, whose expected value is another Organization, and keep individual doctors as Physician nodes on their own profile pages.

Using Physician for a doctor who works across facilities. The doctor's page is about the doctor. Link them to each hospital with hospitalAffiliation, which expects a Hospital. Do not put the doctor's name inside the hospital's name.

Treating MedicalBusiness as a medical-only type. MedicalBusiness is a LocalBusiness subtype and the parent of MedicalClinic, Physician and some others. You rarely need to use it directly, and it adds nothing that MedicalClinic does not already say.

Leaving transient fields in place. isAcceptingNewPatients is a Boolean that goes stale the moment a doctor stops taking new patients. If you cannot keep it current from the same source that drives the appointment page, leave it out.

Putting usNPI on Indian profiles. It is defined as a ten-digit United States identifier. Do not repurpose it for an NMC registration number. If you want to show the registration number, show it as visible text and, if you mark it up, use a generic identifier property and make clear what it is. Have the doctor's clinical team confirm the number before it goes live.

Decide using four questions

When a page is awkward, ask these in order.

1. What is the physical or legal thing this URL describes? A place of care, an individual doctor, or a company? If it is more than one, you have two pages' worth of content on one URL.
2. Does it have its own address, phone and hours? If yes, it is its own LocalBusiness-type node. If it only shares the parent's, it is a department or a service.
3. Is there a more specific type? Dentist, DiagnosticLab, Pharmacy, MedicalClinic, Physician and Hospital are all more specific than MedicalOrganization.
4. Can the visible page support every property? Google's general guidelines say not to mark up content that is not visible to readers. A medicalSpecialty that is not on the page is a mismatch.

Align the type with your other signals

Schema is one of several descriptions of the same facility. Your Google Business Profile primary category, the name and address on the page, the footer and your directory listings should tell the same story. A page marked MedicalClinic whose profile category is "Hospital" is a small inconsistency that invites a cleanup. Check NAP consistency at the same time, and note that the Google Business Profile is the system most patients actually see.

If you run several locations, the type decision interacts with page structure. A branch page that is thin or duplicated needs fixing before markup helps it. The multi-location SEO service page describes how we set that up, and the schema markup service page covers the markup itself.

Two worked decisions

A diagnostics chain with home collection. Suppose the chain has staffed labs, small collection centres and a home sample collection service. The labs and centres are places, so each gets a DiagnosticLab node with its own address and hours. Home collection is not a place. It is a service the brand offers, so it belongs on the brand page or a service page, described in visible text and, if you mark it up, as an offering of the brand with an area served. Do not invent a lab address for it. List tests with availableTest only on locations that actually run or collect them, and have the lab's technical lead confirm the list.

A hospital with a standalone clinic in another suburb. Hypothetically, a 200-bed hospital in Pune opens an outpatient clinic six kilometres away under the same brand. The clinic has its own address, timings and doctors. It is a MedicalClinic with a parentOrganization pointing to the hospital or the group, not a second Hospital and not a department of the hospital, because a department shares the hospital's premises. If staff rotate between the sites, each doctor keeps one profile page and lists both places in visible text; the hospitalAffiliation property then links to the hospital.

What the type will not do

Be honest with stakeholders about outcomes. No documentation says that choosing Hospital over MedicalClinic changes ranking. Google also states that it does not guarantee that structured data will appear in search results as a feature. The benefit of a correct type is a clear, machine-readable statement of what the page is, which can reduce ambiguity for any system reading it. That is useful and modest.

Specialty is a better place to spend attention. Use the medicalSpecialty property with values from the MedicalSpecialty enumeration only where the clinical team confirms the specialty is offered at that location. Do not assign a specialty because a doctor visited once or because the group offers it elsewhere.

A checklist before you ship

• Every URL describes exactly one primary entity, and its type is the most specific that is true.
• Group pages use an organisation type; branch pages use a facility type; doctor pages use Physician.
• Departments are modelled with department, not with extra Hospital nodes.
• name, address and telephone match the visible page and the Business Profile.
• Specialty and service claims are approved by the provider's clinical team.
• Stale-prone fields such as isAcceptingNewPatients have an owner or are omitted.
• No United States identifiers appear on Indian practitioners.
• The markup passes the Rich Results Test and the Schema Markup Validator, which check different things.

If your facility does not fit any row of the table, write down what it is in a sentence before choosing a type. If the sentence needs the word "and", you probably have two pages.