A parent in North York opens ChatGPT at 9:47 PM. Their seven-year-old just chipped a tooth on a hockey puck and the clinic they usually go to doesn't open until Tuesday. They type: "emergency pediatric dentist open tomorrow near North York." ChatGPT gives them three recommendations. Yours isn't one of them.
This is the scenario dental practice owners keep describing to us at Fade Digital. The phone calls are down. The new-patient form submissions are down. Google rankings look fine. Reviews look great. But somewhere between a prospective patient's intent and your chair, AI is quietly rerouting them.
The fix isn't "more SEO." It's entity architecture — a specific way of structuring your practice's data so that large language models can identify, trust, and cite you. For dental clinics specifically, we've found that nine entities, wired together correctly, do more for AI visibility than any amount of blog content or backlink building.
Here's the full framework. If you want the broader strategic context, start with our Ultimate Guide to AI SEO and Generative Engine Optimization in 2026. This post is the vertical-specific build for dental.
Why dental is harder (and easier) than other verticals
Dental sits in an awkward spot for AI search. It's hyper-local, which means LLMs rely heavily on structured location data. It's medical-adjacent, which means trust signals are weighted more heavily than for, say, a plumber. And it's procedure-driven, which means ChatGPT doesn't just need to know you exist — it needs to know which procedures you perform, on whom, and under what specialty.
That last part is where most dental websites fall apart. They'll have a "Services" page that lists fifteen procedures in a bulleted list with no schema, no individual URLs, and no entity relationships. To a language model, that page reads as one unstructured block of text. It has no idea whether your clinic actually does same-day crowns or just mentions them in passing.
The good news: dental is also easier than a lot of verticals because the entity set is small and well-defined. You don't need to model a sprawling SaaS product catalogue or a multi-brand retail operation. You need nine entities, and you need them linked. That's it.
The 9 entities, in order of priority
1. The Dentist as a Person entity
Every dentist in your practice should exist as a named, structured Person entity with its own URL. Not buried on a combined "Our Team" page. Their own profile page, with Person schema that includes jobTitle, alumniOf (dental school), memberOf (ODA, CDA, specialty associations), knowsAbout (procedures they perform), and sameAs links to their LinkedIn, their licensing board listing, and any publications.
LLMs disambiguate people through these relationships. A Dr. Sarah Chen with no schema is one of hundreds. A Dr. Sarah Chen linked to University of Toronto Faculty of Dentistry, the Ontario Dental Association, and a specific clinic in Leslieville is a specific, citable individual.
2. The clinic as a DentalClinic / LocalBusiness entity
Use @type: "Dentist" (which is a valid Schema.org subtype of LocalBusiness and MedicalBusiness). This gives you both the local-business signals Google uses and the medical-entity signals that AI systems weigh for healthcare queries.
The critical properties most clinics get wrong:
medicalSpecialty— list every specialty area served (General Dentistry, Cosmetic Dentistry, Orthodontics, Endodontics, Pediatric Dentistry).availableService— an array ofMedicalProcedurereferences, not strings.areaServed— specific neighbourhoods and postal-code prefixes, not just the city.paymentAccepted— yes, this matters, because AI assistants increasingly filter by "accepts my insurance."employee— array ofPersonreferences to the dentists from entity #1.
This is where the nine entities start to stitch together. Your clinic entity should reference your dentist entities, not re-declare them.
3. Each procedure as a MedicalProcedure entity
This is the single biggest lever we pull for dental clinics, and it's almost always missing. Every procedure your practice offers — Invisalign, same-day crowns, dental implants, wisdom-tooth extractions, pediatric sedation, teeth whitening — should exist as a MedicalProcedure entity with its own dedicated URL.
Why a dedicated URL? Because when ChatGPT is answering "who does same-day crowns in Toronto," it needs a canonical source to cite. A URL with MedicalProcedure schema that says "this clinic, this procedure, these outcomes, these patient types" is exponentially more citable than a bullet point on a generic services page.
At minimum, each procedure page needs:
{
"@context": "https://schema.org",
"@type": "MedicalProcedure",
"name": "Same-Day CEREC Crowns",
"procedureType": "Restorative",
"bodyLocation": "Teeth",
"preparation": "Initial consultation and digital impressions",
"followup": "Single follow-up visit at 2 weeks",
"howPerformed": "Short plain-language description of the process.",
"performedBy": { "@id": "https://yourclinic.com/#clinic" }
}
For the full JSON-LD pattern library, see our Schema Markup for AI templates. The templates there plug directly into this framework.
4. Medical specialties as explicit entities
Don't just mention "we offer cosmetic dentistry." Declare MedicalSpecialty as a named entity linked to the clinic and to the dentists who practice it. This matters because queries like "best cosmetic dentist in Toronto" are specialty-keyed. The LLM is looking for a triangulation: clinic + specialty + location. If any side of that triangle is missing from your structured data, you drop out of consideration.
Specialties to declare where applicable: General Dentistry, Cosmetic Dentistry, Orthodontics, Endodontics, Periodontics, Pediatric Dentistry, Oral Surgery, Prosthodontics.
5. Conditions treated as MedicalCondition entities
This one surprises people. You shouldn't just talk about what procedures you perform — you should talk about what conditions you treat. MedicalCondition entities for things like periodontal disease, bruxism, malocclusion, dental caries, and tooth loss give AI systems a mapping between symptom-driven patient queries and your practice.
When a user types "dentist for grinding teeth Toronto," ChatGPT is trying to match the condition (bruxism) to a provider. A clinic with explicit MedicalCondition schema linked to relevant procedures (night guards, Botox for bruxism, occlusal adjustment) gets picked up. A clinic that only lists procedures without the conditions they address doesn't.
6. Insurance plans as a structured list
Most practice websites have a sentence that says "we accept most major insurance." That's useless to an LLM. Instead, declare the specific insurance providers you work with as structured data.
You can use paymentAccepted on the clinic entity for the high-level list, but the bigger win is a dedicated insurance page with each provider mentioned by name in both the visible content and the schema. Queries like "dentist that takes Manulife near me" are increasing rapidly in AI search logs, and they're surprisingly un-competitive because almost no dental site has bothered to structure this data.
7. Reviews and AggregateRating — but linked correctly
Every dental site has reviews. Very few have them implemented in a way AI actually uses. The rule: AggregateRating belongs on the clinic entity, not floating on the homepage. Individual Review entities should be embedded with author, datePublished, reviewBody, and itemReviewed pointing to the clinic's @id.
And before you ask: no, Google reviews alone don't solve this. We wrote an entire post on why your 5-star Google reviews mean nothing to ChatGPT. The short version is that AI models weight first-party structured reviews on your own domain differently from third-party platform reviews, and you need both.
8. The physical place as a Place entity
A Place entity distinct from the LocalBusiness entity is worth the extra few lines of JSON-LD. It gives you a container for geo coordinates, hasMap, publicAccess, amenityFeature (wheelchair accessibility, free parking, on-site X-ray), and photo. These properties matter disproportionately for accessibility-driven queries, which are growing fast in AI search.
If you operate out of a multi-practitioner building or a medical plaza, also declare the parent Place and reference it. This is how LLMs build the mental model of "this clinic is inside this building at this intersection."
9. An FAQPage that answers the actual questions patients ask
FAQPage schema is the most abused markup on the internet. Most dental sites have fifteen FAQs that read like they were written for Google's old rich-result carousel: "How often should I brush my teeth?" — questions that have nothing to do with the decision to book with your clinic.
An FAQPage built for AI citation answers specific, high-intent, local questions:
- "Does [clinic name] offer sedation for pediatric patients?"
- "How much does Invisalign cost at [clinic name]?"
- "Is [clinic name] accepting new patients in 2026?"
- "Does [clinic name] offer same-day emergency appointments?"
These get cited verbatim by ChatGPT when users ask the matching question. Generic oral-hygiene FAQs do not.
How the nine entities work together
The mistake clinics make is treating each of these as a standalone checkbox. The real power comes from the graph — every entity referencing every other relevant entity via @id.
Dentist → employed by → Clinic → located at → Place → offers → Procedure → treats → Condition → covered by → Insurance → reviewed on → AggregateRating → answered in → FAQPage.
When an LLM parses your site, it doesn't read nine separate schema blocks. It assembles a small knowledge graph specific to your practice. The denser and more interlinked that graph is, the more confidently the model can cite you. For the architectural theory behind this, our AI Knowledge Graph Playbook covers how entity graphs propagate into AI citations across platforms.
What changes after deployment
We've run this setup on dental clinics in Toronto, Mississauga, and Barrie over the last year. The pattern is consistent. Inside the first 30 days, the clinic starts appearing in ChatGPT responses to long-tail queries ("dentist near me that does Invisalign and takes Sun Life"). Between 60 and 90 days, it starts showing up for specialty queries ("best pediatric dentist in [neighbourhood]"). Traditional Google rankings usually improve too, because the same structured data feeds Google's Knowledge Graph, but that's a secondary benefit at this point.
The clinics that see the fastest lift are the ones that don't try to shortcut the entity model. A partial implementation — clinic schema but no procedure pages, or dentist profiles but no specialty declarations — produces partial results. The graph is only as strong as its weakest node.
Where to start if you're a practice owner
If you're reading this and thinking "we have maybe two of these nine in place," you're in the same spot as 90% of the dental practices we audit. Start with entities 1, 2, and 3 — dentist profiles, clinic schema, and individual procedure pages — because those three produce the largest single jump in AI visibility. Everything else compounds on top.
This is exactly the kind of architecture we build as part of our GEO Architecture and Local Growth engagements for dental clinics. If you want to see what's actually happening when someone asks ChatGPT about your practice today, request a free AI visibility audit — we'll show you which of the nine entities are missing and which competitors are currently winning the queries that should be going to you.
The dentists who figure this out in 2026 are going to own the recommendation layer for the next decade. The ones who don't will keep wondering why the phones stopped ringing.