Three different questions are routinely collapsed into one
Schema.org defines a vocabulary. Google documents a smaller set of structured-data features it may use in Search. A particular page contains facts that may or may not justify either. “The property validates” answers only the first question.
| Question | Authority | What a yes establishes |
|---|---|---|
| Is this type or property valid? | Schema.org vocabulary and validator | The statement conforms to the vocabulary. |
| Does Google document a search feature for it? | Google Search Central feature documentation and Rich Results Test | The page may be eligible when every feature guideline is met. Display is not guaranteed. |
| Is the statement true on this page? | The practice's current records and visible page content | The markup describes what the reader can actually verify. |
Google explicitly advises relying on its Search Central documentation for Google behavior rather than assuming every Schema.org term powers a result feature. Its current gallery includes Local Business, Organization, Article, Breadcrumb, and other documented features. It does not list a generic medical-procedure or physician rich result. Those medical types can still express meaning to consumers of Schema.org; that is different from promising a Google enhancement.
Choose the thing before choosing its type
A medical group, one physical clinic, and a physician are not interchangeable nodes. Start by drawing the actual entities and URLs. Then choose the most specific type that accurately represents each one.
- Organization can represent the group or operating organization.
- MedicalClinic is a subtype of MedicalBusiness and LocalBusiness for a clinic facility.
- Physician is defined by Schema.org as an individual physician or physician's office considered as a MedicalOrganization. In the current vocabulary it is not a subtype of Person, despite the name.
- Article describes an article. A medical topic does not turn the publisher into a physician.
The awkwardness around Physician is a reason to model carefully, not to
invent properties. If the site's content and information architecture treat a doctor
as a person while the chosen schema type behaves as an organization and local business,
validate every relationship rather than copying a plugin's graph.
Map each field to a source that can keep it current
Structured data becomes expensive when nobody knows which system owns a fact. Make the source explicit before adding the property.
| Statement | Reasonable source | Failure to prevent |
|---|---|---|
| Name, address, telephone, hours | Practice and location records used by the visible contact page | Schema disagrees with the page or Business Profile after a move. |
medicalSpecialty | Services and specialties the provider publicly and accurately represents | A broad taxonomy label overstates the actual practice. |
usNPI on Physician | The exact provider's NPI record | An identifier is assigned to the wrong namesake or organization. |
isAcceptingNewPatients | An operational field the practice can update | A stale conversion claim remains in markup after availability changes. |
sameAs | An official URL that unambiguously identifies the same entity | A directory profile for a different doctor or branch is treated as identical. |
A sameAs link states identity. Schema.org does not say it transfers ranking
weight, board certification, or “E-E-A-T” to the page. Likewise, usNPI makes
an identifier explicit to systems that consume the property; it does not promise a
Knowledge Panel or ranking change.
A small, factual graph beats a comprehensive fiction
This example describes one clinic location. The names and values are placeholders; production markup must use facts visible on the corresponding page and omit anything the practice cannot maintain.
{
"@context": "https://schema.org",
"@type": "MedicalClinic",
"@id": "https://example.com/locations/central/#clinic",
"name": "Example Clinic, Central",
"url": "https://example.com/locations/central/",
"telephone": "+1-555-0100",
"address": {
"@type": "PostalAddress",
"streetAddress": "100 Example Street",
"addressLocality": "Example City",
"addressRegion": "CA",
"postalCode": "90000",
"addressCountry": "US"
},
"openingHoursSpecification": [{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "17:00"
}]
}Do not add ratings that are not displayed and sourced correctly, a service-area polygon to imply geographic relevance, or every medical term available in the vocabulary. The objective is an accurate description of the page's main entity, not the largest JSON object a generator can produce.
Validation is a release process
- Validate the full graph with the Schema.org validator.
- Run the Google Rich Results Test to see which documented Google features, if any, recognize the page.
- Compare every marked-up fact against visible content and the current source record.
- Publish a small set first, inspect the rendered HTML and URL in Search Console, then observe rather than promising an outcome.
- Assign ownership for changes to hours, physicians, locations, and availability so the markup does not become a fossil.