The schema markup every dental practice website needs
What schema markup actually is
Schema markup is a standardized vocabulary — published by the community-run schema.org project, which the major search companies founded and still participate in — for describing the content of a web page in a way that machines can parse without ambiguity. It is typically added to a page as a block of structured code (most commonly in JSON-LD format) that sits alongside the regular, human-readable content.
A simple way to think about the difference: a page's normal text might say "Dr. Chen has been seeing patients in Boulder for over fifteen years and offers same-day emergency appointments." A human reader parses that sentence easily. An AI system can also read it, but has to infer the specific facts — practice name, years in operation, service offered, whether "same-day" applies today — from unstructured prose. Schema markup states those same facts as discrete, labeled data: business name, service type, availability, all in a format designed to be read by software, not inferred by it.
This matters more for AI systems than it did for traditional search engines, because a generative engine is not just indexing a page — it is trying to build a confident answer, often in real time, often synthesizing information from several pages or sources at once. Structured data removes a layer of interpretation that would otherwise slow that process down or introduce room for error.
The four schema types a dental practice website needs
1. Dentist or MedicalBusiness schema
This is the foundational schema type for the practice itself, applied typically to the homepage and about page. It establishes the core facts: practice name, address, phone number, hours of operation, accepted payment types, and — critically — the specific medical specialty or specialties the practice covers.
Schema.org offers a Dentist type specifically, which is more precise than the more general MedicalBusiness type and should be used where it fits. For practices offering orthodontic services under the same roof, additional or combined schema may be appropriate. The goal is specificity: the more precisely the schema describes what kind of practice this is, the less an AI system has to guess.
Getting the basic facts right here also matters because this is one of the sources an AI system may cross-reference against Google Business Profile data. Inconsistency between the two — a different phone number, a different set of listed hours — creates exactly the kind of ambiguity that undermines confidence rather than building it.
2. Service schema for individual procedures
A practice offering general dentistry, cosmetic dentistry, Invisalign, implants, and pediatric care is, from an AI system's perspective, five different things a patient might be searching for, not one undifferentiated "dental services" offering. Service schema applied to individual procedure pages makes each of these explicit and independently discoverable.
This is particularly valuable for higher-consideration procedures. A patient asking an AI system "which dentist in Boulder does Invisalign for adults" is served far better by a website with a dedicated Invisalign page carrying Service schema than by a website that mentions Invisalign once in a paragraph on a general services page. The schema gives the AI system a clean, structured answer to point to rather than a fragment of prose to interpret.
3. FAQPage schema for common patient questions
FAQPage schema marks up a page's question-and-answer content in a structured format, explicitly pairing each question with its answer. This is one of the more directly useful schema types for AI search visibility, because it matches the exact shape of what many AI systems are trying to produce: a clear question paired with a concise, trustworthy answer.
A practice with a well-built FAQ page — covering insurance questions, first-visit expectations, cost ranges, and emergency triage — carrying proper FAQPage schema gives an AI system content that is nearly ready to use as-is. One thing it no longer does is earn anything in Google's results: Google stopped showing FAQ rich results for every site on 7 May 2026 and removed the documentation for them in June. FAQPage is now machine-readable structure for answer engines and nothing more, and anyone selling it as "the markup that gets you a rich result" is describing a feature that does not exist. We cover the content strategy behind these pages in more depth in our FAQ content article.
4. IndividualPhysician for each dentist — and why not Review
The fourth type is the one most dental sites skip: markup for the people. IndividualPhysician, with practicesAt pointing at the practice, lets you state that Dr. Chen is a real, named provider who works at this address, rather than leaving an engine to infer it from a staff-page headshot. For a question like "which dentist in Boulder does adult Invisalign," a named provider an engine can resolve is worth more than another paragraph of prose.
Where a provider splits time between two offices, practicesAt should name both rather than leaving a single undifferentiated staff list for a patient asking whether Dr. Chen sees patients at the Longmont office on Thursdays. Google also permits a separate Business Profile for an individual practitioner alongside the practice's own listing: in a multi-practitioner practice the profile title is the practitioner's name alone, and for a solo practitioner it takes the form "[brand]: [practitioner name]". That is the mechanism most practices overlook when they assume a profile can only describe a whole office.
What does not belong here is Review or AggregateRating markup on your own testimonials. Google's review snippet guidelines make self-serving reviews — where the entity being reviewed controls the reviews about itself — ineligible, and separately prohibit aggregating ratings collected on other websites. So a testimonials carousel marked up as Review, or an AggregateRating assembled from your Google stars, is at best ignored and at worst a guidelines problem. Publish the testimonials as ordinary page content, and use sameAs to point at the profiles where the reviews actually live. There is also a legal floor underneath this: the FTC's rule on consumer reviews and testimonials (16 CFR Part 465) bans fake and incentivized reviews outright.
What a scan of six Boulder practices found
In September 2026 we ran our own scanner over the public websites of six Boulder dental and orthodontic practices. This was an automated scan of one page per site, not one of our seven Growth Snapshot research batches — none of which has covered dentistry — so it is a snapshot of six local sites rather than a survey of the field.
Two of the six had no structured data whatsoever. Only three stated a complete set of business facts — street address, postal code, phone and opening hours — in markup rather than only in visible text. Three of the six carried no review or rating markup of any kind, which left reputation the weakest dimension in the scan by a wide margin, at a median score of 9 out of 100. Technical foundations, by contrast, were near-perfect: a median of 94, with every site linking its social and directory profiles.
That combination is the point. These are not neglected websites — they are well-built sites whose structured layer was never part of anyone's scope. Schema markup produces no visible change to the page, so it is genuinely easy to overlook. We have not published which practice scored what. The same free scan, linked at the end of this article, will tell you where your own site sits.
A second office doubles the facts that have to agree
One office is one entity: one name, one address, one phone number, one set of hours, one profile, one website stating one set of facts. A second office is not that entity with an extra address bolted on. It is a second entity that has to be independently resolvable in its own city — a patient asking for a dentist in Longmont should not need to know or care that the practice also has a Boulder office — while still reading as part of the same established practice. Both halves are worth something, and the markup is where they get reconciled.
In practice that means each location carries its own Dentist block with that location's street address, phone and opening hours, and each block names the shared practice with parentOrganization instead of being a copy of the other with the address swapped. An engine can then resolve the Longmont office as a real, specific place and still attach it to the organization the patient may already have heard of.
Two failure modes account for most of the trouble, and both are unglamorous.
Facts that quietly drift apart. A phone number changed at one office and never propagated to the website. A suite written "Suite 200" on the location page, "#200" in the markup, and omitted entirely from an insurance directory. Hours updated on one profile after a schedule change and not the other. Each is trivial in isolation; across two offices and every listing per office, they add up to precisely the ambiguity structured data exists to remove. Audit both offices' name, address, phone and hours across the website, both profiles, and every directory the practice appears in — annually as a deliberate exercise, and immediately after a move, a rebrand, or a phone system change.
Location pages that say the same thing twice. The common pattern is a page template built once and duplicated per city, where the only things that change are the city name and the embedded map. Schema on such a page can be perfectly valid and still leave the practice no better off, for the reason the next section gives: markup describes what is genuinely on the page, it does not create facts. A page substantively about the Longmont office — which providers see patients there, its actual hours, any equipment or services particular to it — gives an engine something location-specific to state. A page that is ninety percent the Boulder page gives it a city name in a heading. Share the template; do not share the content.
Implementation notes worth knowing
Schema markup should be validated after implementation. Use schema.org's Schema Markup Validator to confirm the code is syntactically correct and the types and properties are real — it checks the vocabulary itself. Google's Rich Results Test answers a narrower question: whether the page qualifies for a rich result Google still supports. It will say nothing useful about Dentist, Service or IndividualPhysician, and since May 2026 it no longer tests FAQPage either, because that rich result was retired. A page can be perfectly valid and still return nothing from the Rich Results Test. Invalid or malformed schema is generally ignored rather than partially credited, so validation is not an optional step.
Schema should also stay in sync with the actual content of the page. If a Service schema states a procedure is offered but the corresponding page content is thin or has been removed, the mismatch is a liability rather than a neutral technicality. Schema markup describes what is genuinely on the page — it does not create facts that do not otherwise exist in the content.
Because schema implementation is a one-time technical project rather than an ongoing content commitment, it is often one of the more efficient early investments in a GEO effort — the cost is largely fixed, and the benefit persists as long as the underlying page content stays accurate.
- GEO for dentists: how to get recommended when patients ask AI for "the best dentist near me"
- New patient FAQ content: the highest-leverage pages a dental website can build for AI search
- Google Business Profile optimization for dental practices in the age of AI answers
If you want to know which schema types are missing from your website, our free AI Visibility Audit at novasapienlabs.com/audit reads the page you give it — plus robots.txt, your sitemap and llms.txt — and reports what a machine can and cannot state about your practice. It queries no answer engine and it cannot see your Google Business Profile; it tells you what your own site says in markup.
Frequently asked questions
Will adding schema markup change how our website looks to visitors?
No. Schema markup is invisible to human visitors browsing the site normally. It exists specifically for search engines and AI systems to read, and has no effect on layout, design, or the visible text on the page.
Do we need a developer to add schema markup, or can we do it ourselves?
Some website platforms offer plugins or built-in fields that generate basic schema automatically, which can cover foundational `LocalBusiness` or `Dentist` markup. The more specific types — `Service`, `FAQPage`, and `IndividualPhysician` with `practicesAt` — typically require either a developer comfortable with JSON-LD or a platform with more advanced structured data support.
How do we know if our schema markup is working correctly?
Use schema.org's [Schema Markup Validator](https://validator.schema.org/) — it checks whether the markup on a URL is valid, whatever the type. Google's Rich Results Test only reports on rich results Google still supports, so a valid `Dentist` block returns nothing there and that is not a fault. Validate immediately after implementation and again after any website redesign, which is the most common way existing markup silently disappears.
We have two offices — does each one need its own markup, or can one block cover the practice?
Each office needs its own block, with its own address, phone and hours, pointing at the shared practice with `parentOrganization`. A single block listing two addresses asks an engine to decide which set of facts applies to the city the patient asked about, and the safe thing for it to do with an ambiguity like that is name someone else.
Does each office need its own Google Business Profile as well?
Yes. A separate profile per physical location is Google's requirement in most cases and a practical necessity besides, since each office needs its own verifiable hours, services and reviews — reviews attach to the profile they were left on, so a practice that only ever asks patients at its flagship office ends up with a second location that looks unproven.
Does schema markup guarantee an AI system will recommend our practice?
No. No engine publishes what guarantees a recommendation, and our own research measured which businesses were named rather than why. What schema does is remove ambiguity: it states your facts instead of leaving them to be inferred. That is a precondition for being described accurately, not a lever that produces recommendations on its own, and it works alongside a complete Google Business Profile, real reviews and specific content rather than instead of them.
Is schema markup a one-time project or does it need ongoing maintenance?
The initial implementation is largely a one-time technical project. After that, schema needs periodic review any time the practice's services, hours, or core facts change, and after any website redesign, since a new site build can sometimes strip existing schema markup if it isn't explicitly carried over.
New to GEO?
Start with the fundamentals, then apply them to your niche.
More in Dentists
See what AI search can read about your practice.
We scanned six Boulder dental and orthodontic practices in September 2026 — scores ran 35 to 79, median 64. The free scan runs the current version of those checks against your site.
Run the free scan AI search for Boulder dentists