Why entity SEO now matters more than link building
Historical SEO built brand authority through link volume. That model has not stopped mattering, but it has stopped being the highest-leverage lever for a healthcare brand. AI answer engines — Google AI Overview, ChatGPT with browsing, Perplexity, Gemini — all ground their citations on entities before they weight backlinks. A brand with a hundred backlinks and no Physician entity behind its doctor bylines is a weaker citation candidate than a brand with twenty backlinks and clean entity infrastructure, because the model can disambiguate the second brand and only guess at the first.
This is not speculation. It is visible every time SIE re-runs the Rank OS Authority stage after Physician schema deploys on a client. The Authority-stage score moves, the AI Share of Voice score follows, and the citation lift is measurable inside 30–60 days on the tracked cluster. Link work would take considerably longer to produce the same movement.
The five entities every healthcare brand needs to declare
- Organization / MedicalBusiness / Hospital. The brand itself, tied to address, specialty set, area served. This is the trunk of the entity tree; every other declared entity references back to it.
- Physician. Every named doctor with credentials, specialty, alumniOf, worksFor. This is the single most underused entity in Indian healthcare and often the fastest citation lever.
- MedicalProcedure. Every named procedure the brand performs, with prep, recovery, alternatives, contraindications. Ties keyword pages to the entity they are actually about, not just the string they optimise for.
- MedicalCondition. Every named condition the brand treats, with symptoms, causes, differential diagnoses. Feeds condition-first queries ("what causes melasma", "symptoms of hypothyroidism").
- Dataset. Where real outcome data exists. Never invented, always sourced.
Declaring the five in isolation is not enough. What matters is the cross-reference: Physician worksFor MedicalBusiness, MedicalBusiness availableService MedicalProcedure, Physician knowsAbout MedicalCondition. The cross-reference makes the graph coherent; without it, five isolated declarations still leave the model doing the disambiguation work.
The three-layer strategy: on-site declaration, off-site signal, disambiguation
Layer 1 · On-site declaration
JSON-LD blocks in the page head or footer, declaring each entity, with stable @id URIs that stay constant across page rewrites. Use the site's own domain in the entity IDs so the graph unambiguously belongs to the brand. Deploy the entity model once at architecture level, not page by page as bespoke schema — that way every new page inherits the entity graph automatically.
Layer 2 · Off-site signal
A search engine will accept the on-site declaration; it grows more confident when the same entities are corroborated off the site. High-authority directory placements, credentialled academic listings, published research author pages, Wikidata entries where the entity meets notability, and Wikipedia mentions where legitimately eligible. Never fabricated, always earned.
Layer 3 · Disambiguation
If a doctor shares a name with another physician in the same city, or a clinic shares a name with a business in a different vertical, the entity graph has to make the disambiguation unambiguous. This is where the About page, the author bio schema, the alumniOf and worksFor cross-references pay their weight in gold — they give the model something the same-name-string alternatives do not.
A worked path: from zero to Knowledge Graph presence
Assume a mid-sized dermatology chain with four locations, twelve doctors, no Physician schema anywhere, no MedicalBusiness entity, three Google Business Profiles that were set up years ago and never touched. Here is the typical sequence that gets the brand into the Knowledge Graph inside 4–6 months.
- Weeks 1–2: Entity audit. Map what entities should exist against what actually does. Assign stable
@id URIs. Draft the JSON-LD architecture.
- Weeks 3–4: Deploy Organization + MedicalBusiness + Hospital entities across the site. Wire GMB profiles to match declared entity data (address, specialty, hours). Fix conflicting NAP data.
- Weeks 5–7: Roll out Physician schema across all twelve doctors. Credentialled bylines wired via the site's byline component. Cross-reference every doctor's worksFor to the correct MedicalBusiness entity.
- Weeks 8–10: MedicalProcedure and MedicalCondition entities on treatment pages. Cross-reference to the Physician entities. Add knowsAbout tagging.
- Weeks 11–16: Off-site strengthening — high-authority directory placements, journal author-page cleanup, Wikidata entries where notability threshold is met.
- Months 5–6: Monitor for Knowledge Graph card appearance on branded searches. Watch AI Share of Voice lift as an early indicator; the Knowledge Graph card follows.
This is not fast. Knowledge Graph presence is earned over quarters, not weeks. But once earned it compounds — the same entities that carry AIO citation carry ChatGPT citation, Perplexity citation, and eventually Google's own zero-result knowledge panel treatment.
Common failure modes we routinely undo
- Duplicate Physician entities across pages. The same doctor declared three different ways under three different
@id values. The graph reads that as three doctors with matching names; disambiguation collapses.
- Physician entity without credentials. A Person schema with a name and a photo but no medicalSpecialty, no alumniOf, no worksFor. Signals presence but not authority.
- Same-city same-name conflict left unresolved. Two Dr Meera Nairs in Bangalore, both dermatologists, both at neighbouring clinics. Without disambiguation both entities get merged in the graph, and neither gets cited cleanly.
- Wikidata entries created without meeting notability. These get removed by editors, and the removal is often a slower-to-recover signal than never having the entry in the first place. Wikidata should be pursued only where the brand or doctor legitimately meets the platform's notability guidelines.
