Google Knowledge Panel for Doctors in India — The Full Build Guide
Backed by App\Support\NamedExperts::get(). --}}
What the panel actually is (and is not)
A Google Knowledge Panel is Google's entity-level summary of a person, organisation, place or thing. For doctors, the panel that matters is the Person-type panel — the one that appears on the right rail of a desktop Search and above the fold on mobile when you Google a well-known doctor's name. It draws its content from the Knowledge Graph, which in turn is populated from four ranked signal sources.
It is not a Google Business Profile. It is not a paid directory listing. It is not a paid product. It cannot be "requested" via any form. There is a "Suggest an edit" link that verified subjects can use to correct panel content once the panel exists — but that link does not create a panel, it only edits one that has already appeared.
The four entity signals — in trigger-order
Across the panels we have engineered for doctors at ICG, the reliable pattern is four signals that must all be present. The order below is the sequence in which they compound.
Signal 1 — Person schema on the doctor's website with a resolving sameAs array
The single most under-used lever. Person schema (schema.org/Person) on the About page of the doctor's website tells search engines: "this website is the official self-published source about this entity." Combined with a sameAs array that points to every other public profile of the doctor (LinkedIn, YouTube, ORCID, PubMed, hospital page, Wikipedia if it exists) and each of those profiles linking back to the website, you create what entity SEO calls a resolving identity graph. Google follows the sameAs edges, confirms they all describe the same person, and treats your website as the entity's home node.
A minimum working Person schema block for an Indian doctor looks like this:
{
"@context": "https://schema.org",
"@type": "Physician",
"name": "Dr Priya Menon",
"medicalSpecialty": "Reproductive Endocrinology",
"alumniOf": [
{"@type":"CollegeOrUniversity","name":"AIIMS New Delhi"},
{"@type":"CollegeOrUniversity","name":"Royal College of Obstetricians and Gynaecologists"}
],
"worksFor": {"@type":"Hospital","name":"Menon Fertility Centre","address":"..."},
"url": "https://drpriyamenon.com/",
"sameAs": [
"https://www.linkedin.com/in/dr-priya-menon-example/",
"https://www.youtube.com/@drpriyamenon-example",
"https://orcid.org/0000-0000-0000-0000",
"https://www.wikidata.org/wiki/Q000000"
]
}
SIE → the entity-signal tracking view inside SIE — schema coverage and sameAs resolution monitored alongside keyword rank.
Signal 2 — a Wikidata entry with sourced claims
Wikidata is the structured-data backbone Google leans on when building panels for non-Wikipedia-eligible entities. You can create a Wikidata entry for a doctor even if the doctor does not qualify for a Wikipedia page — the notability bar is lower — provided every claim on the entry is backed by a reference. Minimum viable Wikidata for a doctor: instance of (human), occupation (physician), medical specialty, employer, educated at, country of citizenship. Each claim linked to a source URL from the doctor's website, hospital page, journal author profile, or a media article.
Wikidata entries created without references are auto-flagged and often deleted. The DoctorBrand workflow drafts the entry with every claim pre-cited and submits from a Wikidata account with existing edit history — new anonymous submissions face higher review scrutiny.
Signal 3 — Wikipedia page (if eligible; skip if not)
If the doctor meets WP:NACADEMIC or WP:BIO notability, a policy-compliant Wikipedia page is the strongest single signal you can add. Google's Knowledge Graph treats Wikipedia as a first-class source for biographical facts — birth year, career milestones, notable publications, awards. See our Wikipedia eligibility guide for the two paths.
If the doctor does not meet notability, skip this signal — do not attempt a page. Deleted Wikipedia pages become negative entity signals; Google notices the deletion and downgrades entity confidence.
Signal 4 — third-party authoritative citations
The fourth signal is what makes the first three settle. Google cross-verifies the identity graph against independent authoritative sources: a hospital directory page, a conference speaker page, a journal author profile, a media feature, an educational institution alumni page. Four to eight independent citations is typically the threshold. Each citation should name the doctor the same way — full form once, standard short form thereafter — so Google's entity resolver treats them as referring to the same person.
SIE → how often the doctor's name surfaces in AI Overviews and citation-worthy mentions once the four entity signals are in place.
The 90-day build calendar we run
Weeks 1-2: Doctor website audit; Person schema block deployed; sameAs array complete; canonical name locked.
Weeks 3-4: Wikidata entry drafted; claims cited; submitted from established editor account.
Weeks 5-8: Third-party citation build — hospital page update; conference speaker page audit; PubMed / ORCID profile completion; two media pitches submitted.
Weeks 9-12: Wikipedia eligibility assessment (Scale tier only); social profile parity check; monthly re-crawl monitoring via Search Console.
Weeks 13-20: Panel typically triggers. If not, gap analysis on which entity signal is missing.
YODA → YODA's AIO Lab flags which doctor-name and specialty queries are already surfacing AI Overviews — used to prioritise which entity signals to build first.
Wikidata claims that matter most for doctors
A Wikidata entry with the right claims accelerates panel appearance. The claim set we prioritise for Indian doctors:
- P31 instance of → Q5 (human)
- P106 occupation → physician + specialty (surgeon, gynaecologist, dermatologist as applicable)
- P108 employer → the primary hospital or clinic, linked to its own Wikidata entity if one exists
- P69 educated at → each medical college and fellowship institution, referenced to a hospital or academy source
- P27 country of citizenship → India
- P734 family name and P735 given name — helps entity resolution against similar-name doctors
- P166 award received — where applicable, referenced to an academy or ministry source
- P856 official website — the doctor's own site, closing the sameAs loop
- P2002 X/Twitter, P2035 LinkedIn, P2397 YouTube channel — social identifiers each with their own source URLs
Every claim needs a reference URL that unambiguously supports it. Unreferenced claims trigger review; unreferenced entries get deleted.
YODA → Topic-cluster mapping in YODA shows the video and content clusters that reinforce a doctor's entity authority alongside the Knowledge Panel build.
Angryturtle → the NAP and citation-consistency audit that feeds name-form discipline into the third-party citation signal.
How to know the panel has appeared
Search the doctor's name in an incognito window from an India IP. If a right-rail card appears with the doctor's photo (or a placeholder silhouette) and biographical rows, the panel is live. Once live, the verified-subject "Suggest an edit" flow becomes available. Do the identity verification early — it locks control of panel content and lets you correct any facts Google inferred wrongly.
Verifying the panel and using the "claim this Knowledge Panel" flow
Once a panel appears, the subject can claim it via Google's verified-subject flow. Claiming does not create the panel and cannot manufacture one that Google has not built — but for panels that already exist, claiming unlocks the ability to correct facts, suggest a preferred profile photo, and hide social-profile links the doctor no longer uses. The verification flow requires a Google account and a two-factor identity check (typically a video selfie plus government-ID upload). Verification usually completes in 5-10 working days.
Panels sometimes trigger with incorrect data — wrong medical specialty, wrong hospital affiliation, wrong photo pulled from a stale profile. This is where verified-subject editing matters. Uncorrected wrong data damages the doctor's positioning; Google trusts the panel more than any single web result.
What breaks a panel after it appears
Panels appear and then disappear when entity signals contradict each other. Common breakage patterns: sameAs array with a broken link (LinkedIn profile URL changed, YouTube handle switched), Wikidata claim contradicted by a new authoritative source, name form drift across new citations, Wikipedia page deletion after the fact. The DoctorBrand ops layer includes a monthly parity check across all four signal sources.
The most damaging single break we have observed: a doctor changes practice location, updates their LinkedIn but does not update their website Person schema, does not update Wikidata employer, and does not correct the panel via the verified-subject flow. Within 60-90 days Google's confidence in the entity's workplace claim drops, and in about 30% of cases we have seen the panel weaken visibly (fewer rows displayed) or disappear entirely for 4-8 weeks while the entity resolver reconciles. The fix is not complicated — update all four surfaces on the same day the practice moves — but it requires the discipline to treat entity signals as first-class metadata, not incidental profile information.
Knowledge Panel not appearing yet?
We audit which of the four signals is missing or contradicting, and rebuild the identity graph. Every DoctorBrand engagement includes Knowledge Panel work — full build at Growth and Scale tiers, setup at Starter.
See DoctorBrand pricing → WhatsApp ICG →