One profile, two specialists: what schema.org's Physician type separates on a North Bangalore clinic page

Chitra's Lifeline Clinic in Yelahanka New Town runs one page for two specialists: Dr. Akshay Hari, a neurosurgeon and spine surgeon, and Dr. Bindiya, a dermatologist and cosmetologist. That is a common shape for a small multispecialty clinic in North Bangalore, where the economics rarely support a doctor-per-page website. Less obvious is what that single page tells a search engine, and whether it tells Google or an AI Overview two separate things or one blurred one.

One page, two doctors, one address

The clinic sits at LMN Arcade in Yelahanka New Town, opposite the Rail Wheel Factory, open Monday to Saturday from 11am to 8pm. Dr. Hari's neurosurgery work covers minimally invasive spine surgery and cranial cases, and he also runs a separate spine-only practice near Yelahanka. Dr. Bindiya's work is aesthetic dermatology: chemical peels, PRP, laser treatments, skin biopsies. A patient searching for either doctor lands on one shared page, reads both bios, and calls one of two numbers.

What schema.org's Physician type separates

Schema.org's Physician type gives each doctor three properties that matter here: medicalSpecialty, which states the doctor's field; hospitalAffiliation, which names a hospital or clinic they work with; and memberOf, which connects the doctor to a wider organisation. There is no practicesAt property on Physician, whatever a few marketing guides claim; the affiliation runs through hospitalAffiliation and memberOf instead. Get that wrong and the point of marking up two doctors separately is lost before it starts.

Why a shared page usually reads as one blurred entity

Most clinic sites that put two doctors on one page do it with prose, not structured data: a paragraph about Dr. Hari, a paragraph about Dr. Bindiya, and a single MedicalClinic block wrapping the whole page with one generic description. A search engine can read the prose fine, but the structured data is doing none of the separating. Schema App's healthcare markup guide documents the fix: nest two distinct Physician objects inside the page, each with its own name, medicalSpecialty, and hospitalAffiliation, rather than one clinic-level specialty value trying to cover both a spine surgeon and a dermatologist. A single specialty string sitting on the clinic entity tells a crawler far less than two Physician nodes that each state their own field plainly.

What that changes for an AI Overview

A search for a neurosurgeon in Yelahanka and a search for a dermatologist in Yelahanka New Town are asking for two different entities that happen to share an address. If the page's structured data describes only one blended MedicalClinic, an AI Overview has to infer the split from prose, which it does inconsistently. Two properly nested Physician entities give it an explicit answer to both questions from the same page, without duplicating the address or either phone number. The North Bangalore clinics that combine surgery and dermatology under one registration face the identical structural choice, and most make it the same way Chitra's Lifeline does: prose first, structured data an afterthought.

What a single-specialist page does differently

Neospinex, Dr. Hari's dedicated spine and neurosurgery practice, does not carry this problem at all: one doctor, one specialty, one Physician entity that matches the entire page. The trade-off runs the other way. A single-specialty page is simpler to mark up correctly but cannot answer a dermatology query, while the shared Chitra's Lifeline page can answer both if the structured data does its job rather than leaving it to the paragraph text.

The address problem this also solves

A shared clinic page has one more decision buried in it: the address and phone number appear once, but two Physician entities both need to point back to it. hospitalAffiliation and memberOf both accept an Organization value, so each doctor's markup can reference the same MedicalClinic object rather than repeating the street address, postal code, and opening hours twice. Duplicated address blocks are how a lot of shared-page markup ends up inconsistent within months: someone updates the phone number in one place, the visible footer, and forgets the copy sitting inside a second Physician node. Pointing both doctors at one Organization reference means there is only one address to keep current, which matters more for a clinic with two specialists than one with a single doctor, simply because there are twice as many places the same fact could go stale.

What a patient search reveals about the gap

None of this is visible to a reader browsing the page normally. Both bios read fine, the phone numbers work, and nothing looks broken. The gap only shows up in how a search engine or an AI system answers a narrower question, such as which doctor at a given Yelahanka address handles a herniated disc versus which one handles a chemical peel. A page that never states the distinction in markup, only in prose, leaves that answer to inference, and inference is exactly where the two searches drift apart from what the clinic intended.

Frequently asked questions

Q: Does sharing one page between two doctors hurt either doctor's search visibility?

Not by itself. What hurts visibility is structured data that never names each doctor's specialty separately, which forces a search engine to guess which doctor answers which query. Two correctly nested Physician entities fix that without needing two separate URLs.

Q: What does the medicalSpecialty property cover?

It states which medical field one specific Physician entity practices in, separate from anything written at the clinic level. Schema.org defines it directly on the Physician type, and a clinic with two doctors needs the property set twice, once per doctor.

Q: Should a two-doctor clinic split into two separate doctor pages?

Not necessarily. Separate pages help if a clinic can keep both updated, but one well-structured shared page with two distinct Physician entities solves the same problem without doubling the content workload.