We audited 27 dental websites across the GTA. Nobody fails the basics any more. They fail on weight.

Every site in the sample is on HTTPS, mobile-ready and correctly crawlable. The old advice about dentist websites is out of date. What we found instead is a page-weight problem severe enough to be measured in whole megabytes — and it tracks closely with one tool.

GreenMotion · measured 29 August 2026 · 27 GTA sites attempted, 23 in the published set · Full methodology below

We pointed our own audit engine at dental practice websites across Toronto, Brampton, Mississauga, Scarborough, Etobicoke, North York and Halton, then measured each one three times on 29 August 2026 and took the median. Of 28 sites gathered, one turned out not to be in the GTA at all and four blocked the auditor outright. All five were excluded rather than guessed at, leaving 23 in the published set.

Nobody fails the basics

This is the finding that surprised us, and it kills a whole genre of sales pitch. Across all 23 sites, not one failed on any of these:

If someone cold-calls a practice offering to make its website "mobile-friendly", they almost certainly have not looked at it. That problem was solved years ago.

The real problem is weight

The median practice homepage ships 205 KB of raw HTML — before a single image, font or script is fetched. Nine of 23 exceed 300 KB. The heaviest in the sample serves over a megabyte of HTML alone, fifty-one times more than the leanest site in the same set, which does the same job in 21 KB.

The page-builder tax

Ten of the 23 sites run the Elementor page builder. Their median HTML weight is 391 KB, against 164 KB for the thirteen that do not — 2.4 times heavier to present the same information. Stylesheet count tells its own story: on the twelve sites where that check applied at all, not one passed it.

On the day we measured, one site answered in 10.9 seconds on one attempt, 0.8 and 0.9 on two others, and refused the connection outright on a fourth. The interesting number is not any one of those — it is the spread. A visitor who arrives during the bad minute simply leaves, and nothing in the practice's analytics will ever explain why.

Platforms

Two practices are invisible in their own search result

Two sites in the sample have neither an H1 heading nor a meta description, and neither carries any JSON-LD either. Google writes their search snippet from whatever scraps it can find. They hand it less to work with than any other site in the sample.

These are not expensive problems. A meta description is one line of markup. Structured data for a dental practice is a twenty-line block. They are invisible failures: nothing looks broken, the phone simply rings less.

The number we got wrong ourselves

Structured data has the friendliest-looking result in this report: 20 of 23 sites pass. That number flatters everyone, and it is our own check's fault. It asks whether any JSON-LD exists — not whether it says a dentist practises here.

So we read the actual markup on all 23 sites, type by type:

Only one practice in five publishes review markup. That is the single number in this report we would most want a practice owner to see. Review stars are the thing a patient actually looks at in a list of search results, and eighteen of these twenty-three practices are not eligible to show them.

Three sites pass the presence check on markup containing no business at all — page, website, breadcrumb, image, search box. That is SEO-plugin boilerplate. It tells Google the page exists; it does not tell Google a dentist works there. A further three carry no JSON-LD whatsoever.

Taken together, the markup that actually feeds the map pack — business type, address and opening hours in combination — is complete on 16 of 23. So the honest reading is not "20 of 23 are fine": seven practices in this sample have gaps in exactly the data that decides whether they appear when someone searches for a dentist nearby.

We are marking our own homework here. The audit engine's structured-data check is presence-only, so it reports the flattering 87% figure and not the 70% one; the depth analysis above was done by hand for this report. The engine also reads only JSON-LD — six of these sites carry their markup as microdata instead, which it does not parse, and its wording now says "no JSON-LD business markup" rather than "no structured data" for exactly that reason. We would rather publish our own limitations than quietly take credit for the kinder number.

Scores

Median 86 · mean 83.3 · range 63 to 97. Scores include server response time, which we measured three times per site; see the caveat below.

Methodology, and what this does not show

We believe published research should be checkable, so here is exactly what we did and where it is weak.

What we did

Each measurement was a single request from Cloudflare's edge, with the returned HTML parsed for the checks listed above. Every site was measured three times and the median taken, because single-sample response times proved volatile. Before publishing, we re-fetched the sample independently and compared the engine's byte counts and its claims about titles, viewports, structured data and headings against the actual markup. Twenty-two of the 23 were independently re-fetched, and every one matched the engine's byte count within 3%; these pages carry per-request content such as nonces and timestamps, so exact equality is not a reasonable bar. There were no contradictions on any content finding. The twenty-third rate-limited our verification requests.

What we excluded, and why

One site was not in the GTA. A practice we picked up as "Scarborough family dentistry" turned out to be in Scarborough, Maine — US phone number, US address in its own markup. It was in our first draft, which is precisely why we are telling you rather than quietly renumbering. It is removed. The remaining Scarborough practice in the set is genuinely in Ontario.

Four of the 27 GTA sites returned a 174-byte stub to our auditor while serving a full page to an ordinary browser — they block automated requests by IP. An earlier version of our engine scored those stubs and reported five failures each on sites that are in fact well built. That was wrong, we caught it in review, and the engine now refuses to score any page it could not genuinely read. Those four are excluded rather than guessed at. One further site could not be independently re-verified because it rate-limited us; its results were consistent across three passes and are included with this note.

Speed numbers move, and ours are dated

The one thing in this report we would not bet on repeating is latency. Across measurement windows the count of sites slower than 1.5 seconds has read five, then three, then one — without a single site changing anything about its markup. Every figure here is from the run on 29 August 2026. Because server response time feeds our score, the score table moves with it; the content findings do not, and were identical across every pass we ran. If you re-run these sites and get different speeds, that is the measurement being honest, not us.

What this does not show

This is a convenience sample drawn from search results, not a random sample of GTA practices, so it describes these 23 sites and not the market as a whole. A single edge request cannot see JavaScript-rendered content, real Core Web Vitals from actual visitors, image weight, third-party scripts loaded after paint, or anything behind a login. Nothing here is a judgement about the dentistry — only about the markup.

Why the platform table is coarse

Three platforms appear once each in this sample. We have merged them into a single "other" row on purpose: a category containing exactly one site, sitting on the same page as a superlative like "the heaviest in the sample", stops being a statistic and becomes a name. Collapsing the row costs nothing analytically and closes the easiest way to identify an individual practice.

Why we are not naming the worst sites

We measured real businesses that did not ask to be measured. Publishing a league table of local practices by how bad their website is would be a cheap way to get attention at their expense. The aggregate is the interesting part; the individual results stay with us.