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 thatFAQPagewins 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.