Most treatment center websites we audit were designed on a desktop monitor, reviewed on a desktop monitor, and signed off in a conference room. Google does not look at that version. It indexes what a phone receives. When the two versions differ, the desktop-only content is not a ranking factor that counts for less. It is content Google does not use at all.
This post explains what mobile-first indexing actually means, the specific ways a mobile page ends up thinner than its desktop twin, and a check you can run in Search Console today to see which version Google stored.
What mobile-first indexing means, in one paragraph
Google indexes and ranks pages using the mobile version of their content, fetched with its smartphone crawler. Google began mobile-first crawling and indexing in 2016 and announced on October 31, 2023 that the move was complete, so for any site that works on phones, the smartphone version is the version in Google’s index. Google’s own best-practices page states that only the content shown on the mobile site is used for indexing. A paragraph, image, heading or link that exists on the desktop layout but not in the HTML a phone receives does not help that page rank.
Both of those statements come straight from Google: the Search Central announcement that mobile-first indexing has landed and the mobile site and mobile-first indexing best practices documentation.
“We’re responsive” is not the end of the conversation
Google describes three ways to build a mobile-friendly site: responsive design (same HTML, same URL, different layout by screen size), dynamic serving (same URL, different HTML depending on the user agent), and separate mobile URLs, often called m-dot sites. Google recommends responsive design, and its documentation says that with a true responsive build, content and metadata are the same on both versions.
The catch is the word “true.” In practice, a site can be responsive in the visual sense and still deliver different content to phones. The patterns we run into on behavioral health and treatment sites are rarely deliberate. They come from themes, page builders and plugins doing something the marketing team never saw, because nobody on the team reads the page source on a phone.
How desktop-only content happens: the common causes
These are the mechanisms behind most mobile parity gaps we find. Each one maps to a failure mode Google lists in its troubleshooting documentation.
- Content loaded on tap: Google does not swipe, click or type, so text fetched only after a visitor taps “Read more” or opens a tab that requests content from the server never reaches the index.
- Server-side mobile templates: A plugin or theme that detects phones and serves a stripped-down template sends Google’s smartphone crawler the short version, which is the version Google indexes.
- Different robots meta tags: A
noindexornofollowthat appears only on the mobile version tells Google not to index that page or not to follow its links, even when the desktop version is clean. - Missing structured data: Markup added to a desktop-only header or footer block disappears from the mobile HTML, so Google never sees it.
- Images and alt text that only exist on desktop: Facility photos placed in a desktop-only slider, or mobile images without the alt text the desktop versions carry, drop out of what Google can index.
- Mobile redirects to the home page: On m-dot sites, when several desktop URLs all redirect phones to the mobile home page, Google says all of those pages will be missing from the index.
- Robots.txt rules that differ by version: Blocking the mobile host or mobile resources while allowing desktop leaves Google’s primary crawler unable to fetch the page it actually indexes.
Hiding content in accordions or tabs is not on this list. Google’s best-practices page specifically suggests moving long content into accordions or tabs on mobile rather than removing it. What matters is whether the text is in the HTML when the page loads, not whether it is visible before a tap.
Why this hits treatment center websites harder
Behavioral health sites tend to carry exactly the content that gets trimmed from mobile layouts: long level-of-care descriptions, clinical team bios, accreditation and licensing details, insurance information, and admissions FAQs. Designers working on a small screen often treat that material as clutter. A common request is “simplify the mobile homepage,” and the simplification sometimes happens on the server instead of in the CSS.
That material is also what demonstrates experience and expertise on health-related pages. When a clinician bio or a licensing statement is missing from the mobile HTML, the page Google evaluates is thinner than the page your team approved.
Navigation is the second blind spot. Some mobile menus are built only when a visitor taps the hamburger icon. If the links to service and location pages are not in the HTML until that tap, Google’s smartphone crawler sees fewer internal links than the desktop menu shows, and pages deeper in the site get discovered less reliably. For multi-location providers whose city pages depend on internal links, that matters.
The same index sits underneath AI features in Google Search. Google’s documentation for AI Overviews and AI Mode says a page needs to be indexed and eligible to show a snippet to appear as a supporting link. Content that never made it into the mobile HTML is not available to quote there either. No llms.txt file, special AI markup or content chunking changes that, and Google says so plainly.
A check you can run today in Search Console
This takes about five minutes per page. Pick a page where content matters to admissions, such as a level-of-care page or your insurance page.
- Open the page on desktop and copy one distinctive sentence from the lower half of the content, plus one sentence from a clinician bio or FAQ if the page has them.
- In Search Console, paste the page URL into the URL Inspection bar at the top.
- Click Test live URL. When it finishes, click View tested page and open the HTML tab.
- Search that HTML for each sentence you copied. If a sentence is missing, Google’s crawler did not receive it.
- Switch to the Screenshot tab and confirm the rendered page shows your headings and primary content, not a blank template or an interstitial covering the page.
- Repeat for the indexed result by clicking View crawled page instead, which shows the HTML Google stored on its last crawl.
Google’s URL Inspection tool documentation covers the live test, the rendered screenshot and the crawled HTML view. If the live test passes but the crawled page does not, the fix may already be in place and simply waiting on a recrawl.
A faster spot check for anyone without Search Console access: in Chrome, open DevTools, switch on the device toolbar, choose a phone profile, reload the page, and search the Elements panel for the same sentences. This does not replicate Google’s crawler exactly, but it catches templates that change the HTML by device.
An inconvenient detail about where to look
Older SEO checklists tell you to confirm which crawler indexes your site in Search Console’s settings page. That information is gone. In the same October 31, 2023 announcement, Google said it was turning off the indexing crawler information in Search Console settings because all sites that work on mobile devices are now primarily crawled with the mobile crawler. If you want to see how Google is fetching your site, the Crawl Stats report is where Google points you now.
Google also said it would keep crawling a very small set of sites that do not work on phones at all with the legacy desktop crawler, and re-evaluate that list a few times a year. The errors it named were pages that show errors to all mobile users, mobile versions blocked by robots.txt while desktop is allowed, and mobile sites that redirect every page to the home page. Being on that list is not a safe harbor. It means the site is broken for most of the people searching for it.
What to fix first
When a parity gap shows up, the order we work in is simple:
- Robots directives and redirects first: a mobile
noindexor a redirect to the home page removes pages outright, so these come before anything else. - Primary content second: restore any text, headings and bios missing from the mobile HTML, using accordions or tabs if space is the concern.
- Structured data, titles and meta descriptions third: Google asks for these to be equivalent across versions.
- Images and alt text last: keep the same image URLs on both versions where possible, since Google notes that new mobile image URLs can cause a temporary image traffic loss.
For sites still on separate m-dot URLs, the longer-term fix is usually a move to a single responsive build. That is a site migration with its own redirect planning, not a theme toggle, and it should be scoped that way.
If you would like a second set of eyes on whether your mobile pages carry the same content as your desktop pages, our SEO services team runs this parity check as part of every technical audit. When the gap is baked into the theme itself, our web design team rebuilds templates so the phone and the desktop receive the same HTML from the start.
