This post is for web developers, SEO leads and practice managers who maintain doctor profile pages and want the structured data on them to do something useful. It assumes you already know what JSON-LD is and have probably added a Physician or Person block to profile templates. The question is narrower: does the markup connect the doctor to the other places that describe them, and does it say the same thing as the visible page?
The markup that tends to be shipped is a name, an image and a URL. That is valid, and it does little. The valuable fields are the ones that link: sameAs to profiles elsewhere, medicalSpecialty as an enumerated value, hospitalAffiliation as a node that matches the hospital's own page, and an identifier for the doctor's registration. The most common failure is not a syntax error. It is a mismatch between the markup and the text on the page, or between one page and another.
We will build the node field by field, explain the choices and the traps, and finish with an audit you can run on a sample of your own profiles. We do not report results from client sites here, and we do not promise that markup will produce a rich result. It will not, for reasons explained below.
What this markup is for, and what it is not
Be clear about the purpose before choosing fields. Google's documentation for profile page markup is aimed at creators in online communities, and it asks for a Person or Organization as mainEntity, recommending sameAs and identifier on that entity. We know of no Google rich result specific to a physician profile. Schema.org's own Physician type is described as an individual physician or a physician's office considered as a medical organization.
So the realistic goal is entity clarity: helping machines tell that the doctor on your profile, the doctor in the hospital directory and the doctor on a society's member list are the same person, and what that person practises. That may help with disambiguation in search and AI systems. It does not replace the visible page, authorship signals or reviews, and it is not a ranking lever by itself. Our general notes on healthcare schema markup cover the wider set of types.
If you have not yet implemented the basics, start with the guides on healthcare schema implementation and advanced medical schema, then return here. A third overview, healthcare schema markup implementation, covers the same ground. This post is about one type and its links.
Step 1: Choose the type
Physician in schema.org inherits from MedicalOrganization, MedicalBusiness and LocalBusiness. That is awkward for a person, but it is how the vocabulary is built. Its own properties are availableService, hospitalAffiliation, medicalSpecialty, occupationalCategory and usNPI. The more specific IndividualPhysician type describes a single practitioner and adds practicesAt, a MedicalOrganization where they practise.
There are two defensible patterns.
Pattern A: a single Physician or IndividualPhysician node. Use this when the doctor is the subject of the page and you want medicalSpecialty and hospitalAffiliation directly on them. It is the simpler option and keeps the specialty fields where schema.org defines them.
Pattern B: a ProfilePage whose mainEntity is a Person, with a separate Physician or MedicalBusiness node for the practice. This suits sites that want the Google-documented ProfilePage structure and keep the practice details separate.
We usually choose Pattern A for hospital doctor directories, with the page itself described as a ProfilePage whose mainEntity points to the physician node by @id. Whichever you choose, decide once and apply it to every profile through the template.
Step 2: Give the node a stable identity
Set @id to the profile URL with a fragment, for example the page address followed by #physician. Every other node on the site that refers to this doctor, such as an article's author or a department page's employee list, should reuse that same @id. This is what turns many mentions into one entity.
Set url to the canonical profile URL. Make sure the canonical tag on the page agrees. If the profile exists at two addresses (a legacy path and a new one), fix the redirect before adding more markup.
Use name exactly as it appears in the page heading, including title if you display it. If the doctor is known under variants (Dr. R. K. Sharma, Rajesh Kumar Sharma), put the other forms in alternateName. This matters for matching, and it matters most for common Indian names, where several doctors share a name and city.
Step 3: Specialty as an enumerated value
medicalSpecialty takes a value from schema.org's MedicalSpecialty enumeration, not free text. Values include Cardiovascular, Dermatologic, Gynecologic and Pediatric. Use the enumeration value as a URL such as https://schema.org/Cardiovascular where the vocabulary has a fit, and say the rest in description and in the visible text.
Two rules prevent trouble. First, the enumerated value must correspond to what the page says. If the page lists "interventional cardiology" and "structural heart disease", the markup of Cardiovascular is a fair summary. It would not be fair to add Neurologic because the doctor has once published on stroke. Second, the vocabulary has no entry for every subspecialty or for Indian qualification names. Do not stretch an unrelated value to fit. Leave the subspecialty in plain text.
Step 4: Affiliation that matches the hospital's own page
hospitalAffiliation expects a Hospital. Do not give it a bare string. Give it a node with the hospital's @id, name and url, where the @id is the same one used on the hospital's own page. On a group site, that means the profile page, the hospital page and the department page all point to one Hospital node per facility.
Check three things:
- The name in the markup is the name in the visible text. "Example Heart Institute" on the page and "Example Hospitals Pvt Ltd" in the markup is a mismatch.
- A doctor who works at three facilities lists three affiliations only if the page lists the same three, with their clinic days.
- If the doctor is a visiting consultant, say so in the visible text. Do not mark an affiliation that the hospital's own site does not support.
For practicesAt on IndividualPhysician, use the facility where the doctor sees patients. For many doctors this is the same node as hospitalAffiliation.
