The short version
- Google indexes the mobile version of your site. Content missing on mobile is effectively missing.
- The main risk is content parity — text, links or structured data present on desktop but hidden or omitted on mobile.
- Responsive design mostly solves this. Separate mobile sites and conditional rendering do not.
- Check the mobile rendering in the URL Inspection tool rather than assuming your responsive layout is equivalent.
Mobile-first indexing has been the default for long enough that it no longer gets much attention, which is exactly why the problems it creates go unnoticed. The rule is simple: what Google sees on mobile is what Google indexes. The desktop version is not being assessed.
For a responsive site that renders the same content at every width, this is a non-issue. Problems arise wherever the mobile experience genuinely differs from the desktop one.
Where parity actually breaks
The third row is the most commonly overlooked. Collapsing a large navigation into a mobile menu is fine if the links are still in the HTML. Rendering a reduced set of links on mobile changes the internal link graph that actually gets crawled — see internal linking.
What to check
- URL Inspection in ((google-search-console|Search Console)) — view the rendered HTML and confirm your main content, links and structured data are present.
- Compare source at both widths. Responsive CSS changes layout; conditional rendering changes content. Only the second is a problem.
- Check structured data on mobile specifically, not just on the desktop template.
- Test Core Web Vitals on mobile in PageSpeed Insights — mobile field data is usually much worse than desktop and is what counts.
- Confirm tap targets and font sizes are usable, which affects engagement even where it does not affect indexing.
The performance side of mobile-first
Indexing parity is the part people know about. The part that quietly costs more is performance, because mobile field data is what Core Web Vitals assessment uses and it is almost always substantially worse than desktop. A page that scores well on a laptop over broadband can fail its assessment entirely on the devices and networks real visitors are using.
Two things drive most of that gap: JavaScript execution, which is far more expensive on a mid-range phone than on a development machine, and images served at desktop dimensions to small screens. Both are measurable in PageSpeed Insights with the mobile tab selected — which is the tab worth looking at, since it is the one that reflects what is being judged. See field vs lab data.
The habit worth building is simply to test on mobile by default. Most teams develop on desktop, review on desktop, and check performance on desktop, then are surprised by a report describing an experience nobody on the team has had. Setting your browser to a mobile viewport with network throttling for routine review costs nothing and closes most of that gap in perception.
Interstitials deserve a specific mention because they are a mobile-only problem in practice. A cookie banner, newsletter modal or app-install prompt that covers a desktop page politely can cover a mobile page entirely, and the visitor arrives at content they cannot read. That harms engagement directly and is the kind of experience people-first guidance is pointed at, quite apart from any indexing question.
Responsive is the safe default
One HTML document, one URL, CSS handling layout. Because the markup is identical at every width, parity problems cannot arise by construction. Almost every mobile-first indexing problem traces back to a setup that serves genuinely different markup to different devices.