QBiz Leads AI

Dental Practice Schema Markup Guide: JSON-LD That Makes Your Practice Machine-Legible

Summary

A dental website needs four kinds of schema markup, all written as JSON-LD, the format Google recommends: Dentist for the practice itself, FAQPage for your question-and-answer blocks, MedicalProcedure or Service for each treatment, and AggregateRating only in the narrow case where it is genuinely eligible. Schema will not make an AI engine recommend you out of thin air. What it does is remove the ambiguity that stops engines describing your services, location and hours with confidence, and that confidence is what gets your name into an answer.

This guide covers the part most "dental schema" advice skips: the actual code. Every section below answers a real question a practice owner or their web person asks, and several carry a clean, copy-paste JSON-LD block you can drop in and edit. It is written for UK practices, and it gets two things right that competitors routinely get wrong: the specific type a dentist should use, and the rule on marking up your own reviews.

The short version

  • Use Dentist, not bare LocalBusiness. It is a formal subtype, so it inherits every local property while telling the engine exactly what kind of business you are.
  • Mark up only what is visible. FAQ and service markup must describe content a human can actually see on the page, never hidden text written only for the engine.
  • Never mark up your own star rating. Self-serving AggregateRating is not eligible for rich results; let your stars live on your Google Business Profile.
  • Keep one source of truth. Define the practice once with an @id, then reference it from each treatment page instead of restating it.
  • Validate every block. A single syntax error can make an engine discard the whole thing, so test in Google's Rich Results Test and the schema.org validator.

What is schema markup, and why should a dental practice care in 2026?

Schema markup is a set of machine-readable labels you add to your web pages that tell a search system, in terms it cannot misread, exactly what each thing on the page is: this is a dental practice, this is its address, these are its opening hours, this is a treatment it offers, this is a frequently asked question and its answer. A human reads "we are a friendly dental practice in Reading offering Invisalign and emergency appointments" and understands it instantly. A machine reads the same sentence and has to guess at the parts. Schema removes the guessing.

It is worth doing because the clarity pays off in measurable ways. Google's own documentation reports that across industries, structured data lifts how often people click: Rotten Tomatoes, the film-review site, added structured data to 100,000 pages and measured a 25% higher click-through rate for the marked-up pages, and Nestlé, the consumer goods group, found pages shown as rich results had an 82% higher click-through rate than pages without[1]. These are large-site case studies from Google itself, measuring click-through specifically on rich results rather than anything dental. Treat them as proof the technique works, not as a number you should expect to see repeated for a single local practice.

The reason it matters more in 2026 than it did five years ago is where answers now appear. Pew Research analysed the browsing of 900 US adults and found that 58% ran at least one Google search in March 2025 that produced an AI-generated summary, and that users very rarely clicked the sources cited beneath it[4]. More and more, the patient reads a summary the engine wrote rather than visiting your site. Schema is how you make sure the facts the engine writes from are yours, and correct. For the wider picture of how practices earn a place in those answers, our companion guide covers how dentists get recommended by ChatGPT.

Does schema markup actually help me show up in ChatGPT and AI Overviews?

It helps, but not in the way the hype suggests, and the real mechanism is worth understanding because it tells you what to expect. Schema does not act as a ranking lever you pull to make ChatGPT name you. What it does is make your practice unambiguous to the engines that write the answers.

How marked-up facts feed an AI answer, shown as a three-stage flow. Stage one, the JSON-LD you paste: a Dentist schema block with labelled values for type, name, address, telephone, opening hours and area served, using placeholder details. Stage two, the facts the engine reads without guessing: each value becomes a clean labelled fact: this is a dental practice, here is its address, these are its hours, this is its phone number, with a note that the same plain sentence a human reads is now unambiguous to a machine. Stage three, the answer a patient sees: a confident, cited reply that names the practice, marked as high engine confidence, with a row of gold citation chips. Schema does not force a recommendation; it removes the ambiguity that makes an engine reach for a competitor it is surer about.

An AI answer about a dentist is assembled from whatever the engine can find and verify: your website, your Google Business Profile, directory and NHS listings, reviews. When those sources are vague or contradict each other, the engine is less sure of its facts, and an engine that is unsure tends to reach for a practice it is sure about instead. Schema supplies your services, location, hours and credentials as clean, labelled data the engine cannot misread, which is the cleanest way to be the practice it is most confident describing.

So the realistic claim is this: schema will not invent demand or override a thin, inconsistent online presence, but it makes a well-run practice legible, and legibility is a precondition for being named. Anyone selling schema as a switch that forces an AI recommendation is overstating it. Used properly, it is the groundwork that lets your other signals count.

Which schema types does a dental practice need?

Five types cover almost every dental website, and using the right one for each job is what separates a guide that works from a guide that looks busy. Here is what each is for and when to use it.

Dentist and LocalBusiness: your practice identity

Dentist is your foundation, and it is a real, specific type. Schema.org defines Dentist as a formal subtype of both LocalBusiness and MedicalBusiness, which means it inherits every useful local property: address, telephone, openingHoursSpecification, geo, areaServed and more[2]. Most guides tell dentists to use the generic LocalBusiness type. Using Dentist instead is strictly more precise: it says what kind of local business you are, which is exactly the kind of disambiguation an AI engine relies on.

Use this on your homepage or a dedicated practice or contact page, once per practice. It is the block that answers "who and where is this practice", and it is the single most important piece of markup you will add.

MedicalClinic and MedicalBusiness: when they apply

MedicalBusiness is the broader healthcare parent that Dentist already sits under, so for a standard dental practice you do not need to add it separately; choosing Dentist covers it. MedicalClinic is worth knowing about if your site describes a multi-discipline clinic where dentistry is one service among several (say a combined dental and aesthetics clinic), but for the great majority of practices Dentist is the correct and sufficient identity. Do not stack all three types onto one entity hoping more is better; one accurate type beats three competing ones.

FAQPage: your question blocks, and the AI-citation workhorse

FAQPage markup labels a list of genuine questions and their answers on a page. It earns its place in this guide because those question-and-answer pairs are exactly the self-contained snippets an AI Overview or a chatbot lifts to answer a patient. If you publish a clear answer to "how much is a private check-up?" and mark it up as an FAQ, you have handed the engine a quotable unit.

Two rules keep it safe. The questions and answers must be genuinely visible on the page to a human visitor, not hidden markup written only for the engine, and they should be real questions you actually answer, not keyword-stuffed filler. Use it on service pages and any dedicated FAQ page.

One thing has changed about what FAQPage markup earns you. Google deprecated the FAQ rich result, the expandable Q&A box that used to appear directly in search results: the deprecation notice went up in May 2026 and the documentation was removed in June, with Google stating the feature is no longer shown in Google Search results[5]. That does not make FAQPage markup pointless; it changes the reason to use it. The value now is what this guide already calls it, the AI-citation workhorse: a clean, structured question-and-answer pair is exactly the self-contained unit an AI answer engine can lift and quote, rich result or not.

MedicalProcedure and Service: your treatments

Each treatment you offer (Invisalign, implants, whitening, routine examinations) can be described with MedicalProcedure or, more simply, as a Service the practice provides. This is what lets an engine connect "teeth whitening in Cardiff" to your specific whitening page rather than your homepage. Use one block per treatment page, naming the treatment the way patients name it.

AggregateRating and Review: the one most guides get wrong

This is where competitors lose authority, so read it carefully. Many dental schema guides tell you to mark up your own star rating with AggregateRating so it shows in search. Google's structured-data guidelines explicitly forbid this for a local business describing itself: review and rating markup for a local business is supported "only for sites that capture reviews about other local businesses", and self-serving review markup, where you add a review or rating about your own practice, is not eligible for rich results[3].

In plain terms: you cannot legitimately paste your own four-and-a-half stars into your own site's schema and expect a rich result. The right move is to let your star ratings live where they belong, on your Google Business Profile and genuine third-party platforms, which is where both engines and patients look for them anyway. Only use AggregateRating in the narrow, genuinely eligible case (for example, a directory rating other businesses), and if you are unsure, leave it out.

The review-markup rule most dental schema guides get wrong, shown as a wrong-to-right correction. On the left, the tempting move: an AggregateRating schema block added to your own practice site claiming your own star rating, struck through and marked ineligible: Google does not allow self-serving review or rating markup about your own business on your own site, so it earns no rich result and can be treated as a violation. An arrow labelled let them live where they belong leads to the right: your stars belong on your Google Business Profile and on genuine third-party review platforms, which is where both engines and patients look for them anyway.

Person and physician: your named dentists and their credentials

Marking up your individual clinicians as Person entities, with their name, role and qualifications, gives the engine the named, credentialled humans behind the practice. This is the bridge to the wider question of expertise and trust that AI engines weigh, and it connects directly to the work in our companion guide on E-E-A-T for dentists. Keep every credential accurate and current; this is markup that must never overstate.

Copy-paste JSON-LD starters for a dental website

Here are the blocks that competitors do not give you. Each is valid JSON-LD you can paste into the <head> of the relevant page and edit. One important note before you start: JSON does not allow comments, so where you see a value in capital letters, replace the whole value with your own real detail. Do not paste a block with those capitalised values left in, and do not add // notes inside the code, as that will make the JSON invalid.

A complete Dentist block (name, address, phone, hours, geo, area served)

Put this on your homepage or contact page, once.

Example: Dentist block
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "PRACTICE NAME",
  "url": "https://www.yourpractice.co.uk",
  "image": "https://www.yourpractice.co.uk/assets/practice.jpg",
  "telephone": "+44-118-000-0000",
  "priceRange": "££",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1 Example Street",
    "addressLocality": "Reading",
    "addressRegion": "Berkshire",
    "postalCode": "RG1 0AA",
    "addressCountry": "GB"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": "51.4543",
    "longitude": "-0.9781"
  },
  "areaServed": "Reading and surrounding Berkshire",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:30",
      "closes": "17:30"
    }
  ],
  "medicalSpecialty": "Dentistry"
}
</script>

Every value above must match your Google Business Profile and NHS listing exactly. A phone number or set of hours that disagrees across listings is one of the fastest ways to lose the engine's confidence.

A FAQPage block (with two example dental questions)

Put this on a page where the same questions and answers are genuinely visible to visitors.

Example: FAQPage block
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do you accept new NHS patients?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "We are currently accepting new NHS patients, including children and exempt adults. Availability changes, so we update this the day it does."
      }
    },
    {
      "@type": "Question",
      "name": "How much does a private check-up cost?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A new-patient private examination is £65 and includes a full assessment, any necessary X-rays and a written treatment plan."
      }
    }
  ]
}
</script>

A MedicalProcedure or Service block for a treatment page

Put this on the page for one specific treatment.

Example: MedicalProcedure block
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "MedicalProcedure",
  "name": "Invisalign clear aligners",
  "procedureType": "https://schema.org/NoninvasiveProcedure",
  "howPerformed": "A course of custom, near-invisible aligners worn over the teeth, changed every one to two weeks and reviewed at the practice roughly every six weeks.",
  "provider": {
    "@type": "Dentist",
    "name": "PRACTICE NAME",
    "url": "https://www.yourpractice.co.uk"
  }
}
</script>

Nesting it together: one practice, several services

You do not need to repeat your full practice details on every page. Define the practice once with an @id, then have each treatment page reference that @id as its provider, so the engine understands all the services belong to the same practice.

Example: one practice with an @id and several offers
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "@id": "https://www.yourpractice.co.uk/#practice",
  "name": "PRACTICE NAME",
  "url": "https://www.yourpractice.co.uk",
  "telephone": "+44-118-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1 Example Street",
    "addressLocality": "Reading",
    "postalCode": "RG1 0AA",
    "addressCountry": "GB"
  },
  "makesOffer": [
    {
      "@type": "Offer",
      "itemOffered": {
        "@type": "Service",
        "name": "Dental implants"
      }
    },
    {
      "@type": "Offer",
      "itemOffered": {
        "@type": "Service",
        "name": "Teeth whitening"
      }
    }
  ]
}
</script>

Then on the implants page, the MedicalProcedure block's provider can point at "@id": "https://www.yourpractice.co.uk/#practice" instead of restating the whole practice. One source of truth, referenced everywhere.

Where do I put the schema, and how do I add it without breaking my site?

JSON-LD goes inside a <script type="application/ld+json"> tag, and the cleanest place for it is the <head> of the relevant page, though Google reads it correctly in the <body> too. The key discipline is one block per page topic: the Dentist identity on your homepage or contact page, an FAQPage block on a page whose questions are actually visible, a treatment block on each treatment page. Do not paste every type onto every page, and do not run two blocks that describe the same thing differently on one page, as that gives the engine a contradiction to resolve.

If you are on WordPress, you have two sound routes. A reputable schema or SEO plugin can generate and inject the markup for you through a settings screen, which suits practices without a developer. Alternatively, your web person can add the JSON-LD directly to the page template or through Google Tag Manager. Both are legitimate; the plugin route trades a little control for not having to touch code. Whichever you choose, the rule is the same: the schema must describe what is genuinely on the page, and your facts must agree with your other listings.

How do I check my schema is working?

You can verify every block you add, free, in a couple of minutes, and you should before considering it done. Two tools do the job. Google's Rich Results Test tells you whether your markup is valid and whether it is eligible for any rich result. The Schema Markup Validator at schema.org checks your JSON-LD against the vocabulary itself and flags anything malformed or unrecognised.

The workflow is simple: paste your page URL or the code block into the tool, read the errors and warnings, fix anything flagged, and re-test until it is clean. Errors are genuine problems to fix; warnings are usually optional properties you could add but do not have to. Run this every time you change a block. A piece of schema with a syntax error is worse than none, because the engine may discard the whole block.

This self-check is the floor, not the ceiling. It tells you the code is valid; it does not tell you whether your schema, your name-address-phone details and your wider on-page signals are consistent and machine-legible across your whole site, or where a competitor is out-describing you. Widening that view from a single block to the whole practice is the job of an answer engine optimisation approach for a dental clinic, and the free check below is the quickest way to see where you stand.

The mistakes that get dental schema ignored or penalised

Most schema failures come from a short list of avoidable errors. Work through these before you publish.

Where to start

If you do only three things from this guide, take them in order. First, add one correct Dentist block to your homepage or contact page, with your name, address, phone and hours matching your Google and NHS listings exactly. Second, add FAQPage markup to a page whose questions and answers are genuinely visible, using the real questions patients ask. Third, validate everything in Google's Rich Results Test and the schema.org validator until it is clean. Those three give an engine the clear, correct facts it needs to describe your practice with confidence. They are the schema groundwork behind any wider AI SEO for dentists programme.

If you would rather see where your existing schema, listings consistency and AI-readiness actually stand, a free QBiz Leads AI visibility check parses your pages in about thirty seconds and returns a plain pass or fail on whether your schema and structure let an engine read your practice without guessing, then points you to what to correct first. It is the no-cost first step before any spend.

Get your free AI visibility check →

Frequently asked questions

What schema type should a dentist use, LocalBusiness or Dentist?

Use Dentist. Schema.org defines it as a formal subtype of LocalBusiness (and MedicalBusiness), so it inherits all the local properties like address, hours and telephone while also telling the engine specifically that you are a dental practice. That extra precision is exactly the kind of disambiguation an AI engine rewards. Plain LocalBusiness works but says less about you.

Can I add my Google star rating to my own website with schema?

No. Google does not allow self-serving review or rating markup, where a business adds a rating about itself to its own site; it is not eligible for rich results and can be treated as a violation. Your star ratings should live on your Google Business Profile and genuine third-party review platforms, which is where engines and patients look for them anyway. Use AggregateRating only in the narrow case where it is genuinely eligible, such as a site rating other businesses.

Does schema markup help me appear in ChatGPT?

Indirectly, yes. Schema does not force a recommendation, but it makes your services, location, hours and credentials machine-readable and unambiguous, which is what every AI answer engine relies on to describe a business accurately and confidently. Think of it as removing the doubt that makes an engine reach for a competitor it is surer about, rather than as a switch that guarantees a mention.

Do I need a developer to add schema, or can I use a plugin?

Either works. On WordPress, a reputable schema or SEO plugin can generate and inject valid JSON-LD through a settings screen, which suits practices without technical help. If you have a developer, they can add the code directly to your page templates or through Google Tag Manager for more control. Both are legitimate; the only non-negotiable is that the markup describes what is genuinely on the page and matches your other listings.

How do I test if my dental schema is set up correctly?

Use two free tools. Google's Rich Results Test checks whether your markup is valid and eligible for rich results, and the Schema Markup Validator at schema.org checks your JSON-LD against the vocabulary. Paste in your page URL or the code, fix anything flagged as an error, and re-test until it is clean. Do this every time you change a block, because a single syntax error can make the engine discard the whole thing.

Does FAQPage schema still create a visible FAQ box in Google search results?

No. Google deprecated the FAQ rich result feature in May 2026 and removed its documentation in June 2026, stating the feature is no longer shown in Google Search results. FAQPage markup is still worth adding: it gives AI answer engines a structured, unambiguous list of question-and-answer pairs to cite, which is the reason it earns its place as the AI-citation workhorse among the five schema types above, just not for that retired visual snippet.

Sources

Leave a comment

Thoughts on this post? Leave a comment below. Comments are moderated before they appear, so yours will not show on the page straight away.

Your email is used only to contact you about your comment if needed — it is never published.

Comments

No comments yet. Be the first to leave one above.