Physician schema, on its own, has never earned a single clinic client of ours a rich result in Google India. MedicalClinic on the parent page plus Physician on the individual doctor page, with sameAs pointing to the NMC registration URL, is what actually moves the needle — and even that, honestly, about sixty percent of the time. The other forty percent stays stubbornly invisible in the SERP no matter what we do, which is the part of the job nobody wants to write a blog post about.
We've been building clinic and small-hospital sites in India since around 2019, mostly 5-to-40 doctor group practices — dental chains, IVF centres, ENT groups, a couple of ortho practices in Tier-2 cities. The structured data conversation with these clients almost always starts the same way: their previous developer added Physician schema to every doctor page, ran Google's Rich Results Test, saw green ticks, and then nothing happened in Search Console for eleven months. That's the baseline this post is written against.
The five schemas, and why the order matters
The five we add by default are MedicalClinic, Physician, MedicalSpecialty, FAQPage, and (only sometimes) LocalBusiness. What matters is not that there are five — it's the relationship between them, and specifically which sits at the top of the JSON-LD graph.
MedicalClinic goes on the homepage and on the "about" or "our clinic" page, as the parent entity. It carries the address, the phone, the opening hours, the medicalSpecialty array covering everything the group does, and — this is the bit most implementations get wrong — a member array that lists every doctor by @id, not by name. Each of those @id values then resolves on the individual doctor page, where the Physician schema actually lives. So the doctor's page carries a Physician object that's referenced from the MedicalClinic parent, not duplicated inside it. Google India's crawler seems to handle the reference cleanly; the duplicate-nested version, less so. We used to nest the full Physician object inside MedicalClinic's member array. We stopped after a Chennai dental group's twelve-doctor page hit some kind of parser limit and Search Console just... quietly dropped the whole markup. No error. No warning. Just gone from the Enhancements report between two weekly checks.
MedicalSpecialty goes on the service pages — "Root Canal Treatment", "IVF Consultation", that kind of thing. It's usually consumed as a property of the parent MedicalClinic or the individual Physician, but on a dedicated service page we mark it up as a standalone entity too. This one has never, in our experience, directly produced a rich result. But when we remove it, doctor-page rich results degrade in a way we can't fully explain. So it stays.
FAQPage — we'll get to why we still add it, given that most sites can't earn the rich result anymore.
LocalBusiness is the schema we stopped adding on multi-location clinics after a specific incident. A six-clinic dental chain in Pune, October 2022 (or thereabouts — the exact month is on a Trello board somewhere we can't easily find). We had LocalBusiness on the parent site, MedicalClinic on each location page. Google collapsed the knowledge panel to the head-office address across all six locations for weeks. The Baner branch showed up in the Kothrud SERP. The client's front desk started fielding calls from patients who'd shown up at the wrong branch. We ripped the parent LocalBusiness out and let each location's MedicalClinic stand alone. Panels straightened out in about three weeks. Since then, on any group practice with more than one physical location, LocalBusiness only appears at the location level, and only if the clinic operates as a genuinely standalone business unit at that address. For a single-location clinic — one address, one phone, one set of hours — LocalBusiness at the top of the graph is fine and often helps. For anything multi-location, it forces Google to pick one address, and Google will pick the wrong one.
Where Google India diverges from the Schema.org documentation
The Schema.org docs don't tell you this: Google India's medical SERP treats sameAs as a citation-graph signal, and it weights Indian medical citation sources very differently from what the US-focused documentation implies.
The single highest-leverage sameAs target we've found is the doctor's NMC (National Medical Commission) registration page — the URL on the state medical council registry that confirms registration number, year, and qualifying institution. That URL, dropped into sameAs on the Physician object, does something the equivalent US move (linking to a state medical board) doesn't quite replicate. Our working theory is that Google's India SERP quality raters have been given the NMC and state council registries as an authoritative EEAT source, and the crawler treats the sameAs as identity confirmation. Whatever the mechanism, it's the single change that most consistently flips a doctor page from "no knowledge panel" to "knowledge panel", and it's the change that made the difference for the Jaipur ENT group we re-marked-up on 12 August: six doctors, Physician-only markup that had produced zero rich results in eleven months, MedicalClinic-plus-Physician-plus-NMC-sameAs produced knowledge panel entries for four of the six within nineteen days.
Four of six. Not six of six. Which brings us to the last section.
The other sameAs targets that matter for Indian medical SERPs, roughly in the order we've seen them help: Practo profile URL, the doctor's page on MyHealthRecord (or whichever Ayushman-adjacent registry the doctor is on — this has been in fits and starts since the ABDM rollout, and honestly we're not always sure which registry Google is reading), the hospital-group profile if the doctor also has admitting privileges somewhere larger, and LinkedIn last. In the US, LinkedIn tends to sit higher up that pecking order. In India, Practo and the government registries dominate, and stuffing LinkedIn as the first sameAs entry doesn't help the way the generic tutorials suggest.
Two tool gotchas worth naming, because they cost us time we won't get back. Google's Rich Results Test will happily pass Physician markup, show you the green tick, render a preview, and then Search Console's Enhancements report will simply never surface that markup as an eligible enhancement. No error, no warning, no "ineligible" flag. It just... isn't there. Rich Results Test validates syntax; it does not predict eligibility. The Schema Markup Validator (validator.schema.org) is stricter on the JSON-LD structure itself and will catch nested-reference errors that Google's tool misses, so we run both. Riya spent a Tuesday afternoon last month diffing the JSON-LD output of a client's staging build against production, one doctor at a time, trying to figure out why three doctors on staging showed up in the Enhancements report and the same three on production didn't. The answer was that the production build was serving the JSON-LD after a client-side hydration step, and Googlebot's rendering was inconsistent about picking it up. Server-side render the JSON-LD. Every time. This should be obvious. It wasn't obvious to us for embarrassingly long.
On FAQPage: Google quietly deprecated FAQ rich results for most non-authoritative sites around August 2023 — the announcement was somewhere in the Search Central changelog, we're going off memory here. For clinic sites, the FAQ rich result almost never renders now. We still add FAQPage schema, though, for one specific reason: the AI Overviews and the SGE-style answer boxes in Google India seem to pull from FAQPage markup as a ranked source when they generate summarised answers for symptom or procedure queries. Whether this shows up as attribution or just as unattributed lifted text depends on the query, and we haven't found a clean pattern. But removing FAQPage from a client's site last year (a small experiment on a two-doctor dermatology practice) correlated with the practice disappearing from a "cost of hair transplant in Delhi" AI Overview citation within about a month. Might be coincidence. Might not. We put it back.
What we still can't get to render — and our current guess as to why
The Jaipur ENT group again. Same MedicalClinic parent. Same JSON-LD template applied to all six doctor pages. Same NMC sameAs, same alumniOf populated with the qualifying institution, same medicalSpecialty, same photo dimensions, same URL structure. Four doctors got knowledge panels within three weeks. Two didn't, and still don't as of last week.
We've looked at everything we can think of. The two doctors who don't render are not the newest joiners, not the least experienced, not missing any structured field the other four have. Their NMC registrations validate. Their Practo profiles exist and are linked. One of them has more Google reviews than two of the doctors who did get panels. Our current guess — and it's genuinely a guess — is that there's some entity-disambiguation step happening upstream of the SERP where Google's Knowledge Graph decides whether a person entity is already "known enough" from other sources to bind the structured data to, and if the entity isn't in the graph yet, the markup alone won't create one. But that's speculation, and we've been wrong about this kind of thing before.
If someone has cracked why identical Physician markup renders a knowledge panel for one doctor in a group practice and nothing at all for the doctor sitting at the next desk, with symmetrically populated NMC sameAs, education, and specialty fields — we'd genuinely like to hear from you. This one has been open on our internal wiki for almost a year now.