Why Dentists need this
In BrightLocal's dentist case study, a practice with more pages and links still lost map-pack ground to a nearby rival that kept collecting fresh reviews, so the website is only one part of local visibility. Patients who tap through from that map listing are usually on a phone, and what they find decides whether they call. If the page they land on is a squeezed desktop layout with zoom switched off, the effort you put into local rankings leaks away at the last step. The same goes for treatment pages. People search for whitening, implants or an emergency appointment rather than just 'dentist', and those service pages are where phone visitors arrive. Because dentistry is a health topic, Google's guidance gives extra weight to accurate, trustworthy content, and a page that is awkward to read on a phone does nothing to help patients trust it. The Mobile-Friendly Checker reads the HTML of one page and flags the markup signals behind a poor phone experience: the viewport tag, zoom blocking, media queries, srcset images and fixed widths. It takes a minute to run on your homepage, a treatment page and your contact page.
Dentists specific guidance
Which pages to test first
Start with the pages a patient lands on from a phone search, not only the homepage. Run three URLs one at a time: your homepage, one treatment page such as https://www.example-dental.com/services/teeth-whitening, and your contact or booking page. Each run covers a single page, so a clean homepage says nothing about the others, which may use a different template. In the next ten minutes you can also open one page's source in your browser (right-click, View page source) and search for 'viewport' to see the tag the tool will read. The checker fetches the HTML from the SeoMods server, not from a phone, so it cannot tell you whether your phone number is tappable or a booking form is easy to use. Pick up your own phone afterwards and try to call from the page.
Reading the score and the verdict
Look at the verdict line before the number. 'This page is likely NOT mobile-friendly' appears whenever the viewport tag or width=device-width is missing, whatever the score. Then read Issues to Fix, which carries a priority for each item; the viewport tag, width=device-width and Responsive CSS are the Critical ones. Be careful with 'Media queries: Not detected'. The check looks for @media in the page HTML, in a stylesheet link whose media attribute sets a min- or max-width, and in up to three stylesheets on your own domain. A practice theme that loads its responsive rules from a CDN or another domain can therefore show Not detected while behaving well on phones. Likewise, No fixed-width layout only looks for a table or div with a width attribute of 100 or more, or an inline style width of 400px or more, which is why the check flags a possible problem rather than proving a broken layout. The score is SeoMods' own weighting, not a Google rating, and it says nothing about speed, rankings or indexing.
What to fix, and in what order
Fix the viewport first, because it and width=device-width together carry 50 of the 100 points. On a classic WordPress theme, the tag usually sits in header.php (edit it through a child theme or ask your developer, since theme updates overwrite direct edits); look for a meta tag named viewport with the content width=device-width, initial-scale=1. If your practice site sits on a dental-marketing platform you cannot edit, send your web designer the Copy fix text from the report. Next, remove user-scalable=no or maximum-scale=1 from that tag, since blocking zoom makes small print hard for older patients. Only after that deal with srcset and any fixed-width tables or boxes. Re-run the same URL and compare the two results. A passing result does not prove the call button works, the text is large enough or the page loads quickly. Use the Page Speed tool for load time and check the call button by hand.
Example scenarios
1. Old homepage theme with no viewport tag
- Situation
- Illustrative example: a solo practice still runs a website theme installed around 2014, before responsive layouts were standard, and nobody has touched the template since. Patients on phones see a tiny desktop page.
- Input
https://www.example-dental.com/- Reading the result
- The verdict would read likely NOT mobile-friendly, with Viewport meta tag shown as Missing and width=device-width failing, both Critical. initial-scale defined fails with them as a Medium issue, so 58 of the 100 points are lost and the overall score cannot exceed 42. Adding one correct viewport tag is the single biggest gain.
2. Implants page that blocks zoom
- Situation
- Illustrative example: a designer copied a viewport tag from an old snippet that included user-scalable=no to stop pages jumping around. The implants page is full of cost and recovery detail that patients want to enlarge.
- Input
https://www.example-dental.com/services/dental-implants/- Reading the result
- The viewport and width=device-width checks would pass, but Zoom not disabled (a11y) would fail as a Medium issue, costing 8 points. With everything else passing the score would be 92 and the verdict would still read This page appears MOBILE-FRIENDLY. Remove user-scalable=no and re-run.
3. Responsive site with a CDN stylesheet and a fixed-width table
- Situation
- Illustrative example: an emergency dentist page uses a modern theme that loads all its CSS from a CDN domain, and an old opening-hours table still carries width=600 in its markup.
- Input
https://www.example-dental.com/emergency-dentist-springfield/- Reading the result
- Media queries would show Not detected (14 points, Critical), because stylesheets on another domain are not read, and No fixed-width layout would fail (8 points, Medium) because of the table. With everything else passing that gives 78 and the verdict Mostly mobile-friendly — a few improvements recommended. The media row may be a false alarm, so check the page on a real phone; the table width is worth fixing.
Common mistakes
- Testing only the homepage. Treatment and booking pages often use different templates, so a clean homepage run tells you nothing about them. Test each page a patient might land on.
- Trusting a high score as proof of a good phone experience. The score comes from text patterns in the HTML, not from a phone rendering the page. Always tap through the page on a real device as well.
- Panicking over Media queries: Not detected. Responsive rules loaded from a CDN or another domain are not seen by the check. Compare the result with how the page really looks on your phone before changing the theme.
- Leaving user-scalable=no in the viewport tag. It is a common leftover from old templates and it stops patients enlarging text. Removing it costs nothing and fixes an accessibility warning.
- Treating this as the whole dental SEO job. It does not look at reviews, listings, treatment content or rankings. Use it as one technical check beside your local and content work.
Frequently asked questions
Does my dental website need to be mobile-friendly to rank on Google Maps?
Map-pack position depends mostly on listing signals such as reviews, citations and proximity, and this checker does not test any of those. What it covers is the page patients reach after tapping your listing: whether its markup tells phones to scale the layout, allows zoom and includes media queries. A weak result will not by itself drop you from the map pack, but a page that is hard to use on a phone can lose the patient who found you. Treat it as a conversion check.
Why does the checker say no media queries when my dental site works fine on my phone?
The check reads @media in the page HTML, a stylesheet link whose media attribute sets a min- or max-width, and up to three stylesheets on your own domain. If your practice theme loads its responsive rules from a CDN or another domain, or from a fourth stylesheet onward, the tool does not see them and reports Not detected even though the layout adapts. If your phone shows a clean layout, treat this row as a false alarm and focus on any viewport or zoom failures instead. Confirm by opening the page on your phone and rotating it.
Can this check whether patients can tap to call or book from my dental website?
No. It reads markup signals in the page's HTML, such as the viewport tag, zoom settings, media queries and fixed widths. It does not measure tap-target size or test a booking form. After a clean run, open the page on your own phone, tap the phone number and walk through booking as a new patient would. If the number is plain text rather than a link, ask your web designer to make it a tap-to-call link.
Is a free mobile-friendly test enough for my dental practice SEO?
It covers one slice. Dental SEO also depends on treatment pages, reviews, consistent listings and trustworthy health content, none of which this checker evaluates. Use it as a quick technical gate on your key pages, then move to local and content work. Note that Google retired its own Mobile-Friendly Test in December 2023, so a markup check like this, combined with a manual look on a real phone, is a reasonable stand-in for a quick review.
Which dental website pages should I run through the mobile checker?
Each run checks one URL, so test your homepage, your main treatment pages and your contact page separately. The tool is free with no signup, but runs are rate-limited to 5 per 10 seconds and 20 per minute per session, so space out a larger batch. A bare domain gets https:// added automatically. It requests the live HTML once from the SeoMods server, so changes you publish show up on the next run.
Reference: The case study in BrightLocal's dentist local rankings investigation shows a practice losing map-pack ground to a rival with a steadier stream of recent reviews.