Deep Audit Case Study: The New Patients a Dental Group Is Losing to Missing Schema

Second in our monthly series. Last month we started at the top — the largest injury firm in America — to show that even category leaders leave structured data on the table. This month we drop down to where it actually hurts: a mid-sized regional business that competes for every new customer. We run a real Deep Audit, publish what came back, and write the fixes.

A regional dental group scored 4.16 out of 5 on AI readability and 2.54 on classic SEO. The content is genuinely good. The machine-readable layer barely exists. For a practice whose patients arrive through "dentist near me," that gap is the most expensive thing on the site.

This month's subject is Dental Associates, a family-owned dental group with clinics across Wisconsin — big enough to have a real website and marketing budget, small enough that fixing its SEO turns directly into booked appointments.

The output

Deep Audit — https://www.dentalassociates.com
==============================================================
  LAI Score: 3.70/5  (good)   confidence 71.34%
  AI 4.16/5   SEO 2.54/5   Local n/a
  Tasks scored: 5847  (passed 2609, warned 1532)

Section scores (0-5):
  S1  Technical Foundation & Rendering   4.69
  S2  Crawlability & Site Architecture   4.25
  S3  Content Quality & Entity Semantics 3.95
  S4  Core Web Vitals & Performance      3.25
  S5  Technical SEO & Index Control      4.40
  S6  Schema, Local, Trust & E-E-A-T     2.42   ← weakest
  S7  Security & Privacy                 4.48
  S8  Multimodal Content & Media         2.85
  S9  Off-Site Signals & Reputation      2.96

Section 6 (Schema, Local, Trust & E-E-A-T) is a 2.42 — the lowest section we have published in this series. Local n/a is the tell: the engine could not find machine-readable local-business data, so it could not score the local dimension at all.

In plain English: this practice has written a genuinely helpful website that Google and ChatGPT struggle to connect to a real dentist, in a real city, with real reviews.

Findings that matter for a dental group (we have dropped the ones that don't apply, like Event and JobPosting):

Finding What it means What it costs
S6 6.1.01 No Organization schema Site never identifies itself as a business No knowledge-panel eligibility
S6 6.2.01 No Service schema Implants, Invisalign, etc. aren't marked up Miss service-specific results
S6 6.8.01 No Review schema Patient reviews not in markup No stars in the SERP
S6 6.9.01 No AggregateRating Aggregate rating not exposed No star rating = fewer clicks
S6 6.7.01 No FAQPage Common questions unmarked Miss AI answer citations
S6 6.16.01 No BreadcrumbList No SERP breadcrumb trail Weaker listing
Local n/a No LocalBusiness data No dentist/location entity Handicapped in the local pack
S3 3.10.01 No llms.txt No AI-crawler guidance Weaker answer-engine presence
S2 2.7.02 Text-to-HTML 4% 96% markup/script Drags Core Web Vitals (S4 = 3.25)

Fix 1 — The money fix: Dentist / LocalBusiness schema per location

This is the finding that explains Local n/a. A multi-location group should output a Dentist entity — a LocalBusiness subtype — per clinic, each with its own address, phone, hours, and geo-coordinates. Google's local business structured data guide is the spec to build against.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Dental Associates — Milwaukee",
  "url": "https://www.dentalassociates.com/locations/milwaukee",
  "image": "https://www.dentalassociates.com/milwaukee.jpg",
  "telephone": "+1-414-000-0000",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "1000 W Example Ave",
    "addressLocality": "Milwaukee",
    "addressRegion": "WI",
    "postalCode": "53201",
    "addressCountry": "US"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": 43.0389, "longitude": -87.9065 },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "08:00", "closes": "17:00"
  }]
}
</script>

Ship one per location page. Worth being precise about what this does and does not do: schema makes the practice eligible and legible to the local pack. It does not by itself rank you there. Proximity to the searcher, a claimed and complete Google Business Profile, and review volume do most of that work. Schema is the prerequisite they are all read against, which is why it goes first.

Fix 2 — Show the stars: Review + AggregateRating

A dental group has hundreds of patient reviews. None are marked up, so their result is a plain blue link next to competitors showing ★ 4.8. Google's review snippet documentation covers the requirements.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Dental Associates — Milwaukee",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "612"
  }
}
</script>

The rule we never break: only mark up reviews that are real and displayed on the page. The numbers above are placeholders — ship the location's real, verifiable figures. Fabricated ratings violate Google's structured data guidelines and are a manual-action risk, not a clever shortcut.

Fix 3 — Mark up the services: Service schema

Clears 6.2.01. "Dental implants Milwaukee," "Invisalign near me," and "emergency dentist" are high-intent searches. Marking each service ties it to the practice.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "Dental Implants",
  "provider": { "@type": "Dentist", "name": "Dental Associates" },
  "areaServed": { "@type": "State", "name": "Wisconsin" }
}
</script>

Fix 4 — Organization + sameAs, WebSite, BreadcrumbList, FAQPage

  • Organization + sameAs (6.1.01, 4.9.01/02) — the parent brand plus links to their verified Facebook, LinkedIn, and Google Business profiles. This is how an answer engine confirms identity.
  • WebSite (6.4.01) — enables the sitelinks search box.
  • BreadcrumbList (6.16.01) — a navigable trail in the result, per Google's breadcrumb guide.
  • FAQPage (6.7.01) — with a correction to the usual advice. Google deprecated the FAQ rich result and stopped showing it in Search as of May 7, 2026. If you have read that FAQPage wins you rich results, that guidance is out of date. Ship it anyway — answer engines still parse it, and the insurance and new-patient questions are exactly what an AI assistant gets asked — but do not expect a Google SERP feature, and do not sell one to a client.

See our schema-by-business-type checklist for the full healthcare set.

Fix 5 — Ship an llms.txt

Clears 3.10.01. With a 4.16 AI-readability score, this practice is already the kind of content answer engines want to quote — an llms.txt tells them where the good pages are. See our llms.txt guide.

Being honest about its status: llms.txt is a proposed convention, not a standard any major AI vendor has committed to honoring. It is cheap to ship and plausibly useful. It is not a guaranteed channel, and we would not rank it above Fixes 1 and 2.

Fix 6 — The 4% text-to-HTML ratio and Core Web Vitals

S2 2.7.02 and the 3.25 on Section 4 travel together — 96% of the page is markup and script. Server-render the primary content, defer non-critical third-party JS, trim unused CSS, and lazy-load below-the-fold media only. We break this down in fixing a low text-to-HTML ratio, including why the ratio itself is a symptom rather than a ranking factor. On mobile, where most "near me" searches happen, LCP is the number that matters.

What this wins back — honestly

We cannot redeploy their site, so there is no fabricated "after" score, and we are not going to put a dollar figure on it. What we can say precisely:

  • Fixes 1 + 2 move the practice from invisible-to-the-local-pack with no stars to eligible with a star rating. Eligibility is not placement — but you cannot win a race you are not entered in.
  • Fix 3 makes high-intent service searches legible.
  • Fixes 4–5 are the trust and answer-engine layer.

The schema work is roughly one to two days for a developer and would pull Section 6 out of the low 2s. That much we have measured repeatedly, including on our own site. Whether it produces new patients depends on their market, their Google Business Profile, and their competitors — none of which an audit can see.

Run it on your own practice

Every number here came from one Deep Audit call:

curl -X POST "https://seoscoreapi.com/site-audit" \
  -H "X-API-Key: YOUR_KEY" -H "Content-Type: application/json" \
  -d '{"url": "https://yourpractice.com"}'

Poll the job id for the full nine-section score and every finding, then fix in priority order — starting, almost certainly, with local schema.


See plans and pricing → — Pro and Ultra include 20 and 100 Deep Audits a month, so you can audit every location and re-audit to confirm the fixes land.

Next month: a mid-sized DTC ecommerce brand heading into the holidays — same treatment, same question.