Does mobile-first indexing really demand a mobile-friendly site?

Why does Google separate indexing and mobile experience?

The distinction made by John Mueller reveals a layered algorithmic architecture. Mobile-first indexing only relates to which version of your site Googlebot crawls and indexes — desktop or mobile. It's a technical choice for data collection, not a qualitative judgment.

The evaluation of mobile-friendliness, however, occurs during the ranking phase. It relies on signals like Core Web Vitals, the absence of intrusive interstitials, the size of clickable areas, or a properly configured viewport. Two distinct processes, two different moments in the ranking pipeline.

What does

Is this statement consistent with field observations?

Yes, and it's one of the few Google communications that perfectly aligns with what we observe in production. I audited desktop-only sites (yes, they still exist in industrial B2B) that remain indexed and ranked despite a disastrous mobile experience. Their content is indeed in the index — we confirm it through specific "site:" queries.

However, their visibility on competitive queries collapses. Why? Because Google indexes them through the mobile bot, retrieves all the content (no missing parity), but crushes them at ranking based on Page Experience criteria. Two processes, two impacts — exactly what Mueller states.

What nuances should be added to this claim?

The phrase "all content is present" remains vague on the tolerance thresholds. In practice, a minor difference (an absent sidebar block on mobile, a few fewer links in the footer) does not prevent indexing. Google tolerates variations as long as the main content and key structural signals are identical.

Be cautious of the temporal dimension as well. A site migrated to mobile-first with imperfect content parity may take several weeks to reveal negative impacts. Indexing happens quickly, while ranking degradation is more gradual. I’ve seen sites lose 30% of traffic over 8 weeks post-migration without visible changes in the index. [To verify]: Google communicates little about the exact timelines for re-evaluating UX signals after detecting a change.

In what cases does this rule not apply fully?

Sites with client-side dynamically generated content (heavy JavaScript, React/Vue without proper SSR) present a specific problem. If the content is not rendered during the mobile crawl, Google will not see it — regardless of whether it is "technically present". Parity then becomes a theoretical concept.

Another edge case: sites with mobile variants on separate subdomains (m.example.com). The mobile-first logic applies, but handling canonical, hreflang, and conditional redirects complicates matters. A misconfiguration can result in indexing the wrong version despite perfect content parity on paper.

What should you prioritize auditing on a mobile-first site?

First reflex: crawl your site with a mobile user-agent (Screaming Frog, Oncrawl, Botify) and compare with a desktop crawl. Look for textual, image, internal link, and structured data discrepancies. Any significant difference in the main content is a red flag.

Next, check that your meta robots, canonical, hreflang tags are consistent on mobile. Google indexes what it sees on the mobile version — if your directives are absent or contradictory, you create algorithmic confusion. I've seen sites with desktop-only canonicals pointing to URLs that do not exist on mobile, causing partial de-indexation.

What critical mistakes should you avoid?

Never hide strategic content behind accordions or tabs without correct technical implementation. If the HTML is not present in the initial DOM (late Ajax loading, display:none without ARIA attributes), Google can ignore it. Content parity requires that the text is in the mobile source code, not just displayed after user interaction.

Another recurring pitfall: poorly configured lazy-loading images. If your main images use lazy loading without a fallback and Googlebot can’t scroll, they may not be indexed. Use the native loading="lazy" attribute or ensure your JS solutions are compatible with Google's rendering (test via Mobile-Friendly Test and URL Inspection Tool).

How to verify that your mobile-first implementation is correct?

Leverage Search Console extensively, section "Settings" > "Indexing". Google specifically states if your site uses mobile-first indexing. If so, review the "Coverage" and "Experience" reports filtering on mobile to catch anomalies.

Complement with manual tests via the URL inspection tool: submit your strategic pages, request indexing, and compare the HTML rendering provided by Google with your source code. Look for discrepancies — missing structured data, truncated content, blocked resources. It’s time-consuming but the only way to validate that Google sees exactly what you think you’re sending.

• Crawl the site with mobile user-agent and compare with the desktop version to detect content discrepancies
• Check the presence and consistency of meta robots, canonical, hreflang tags on mobile
• Ensure that hidden content (accordions, tabs) is present in the initial DOM and accessible for crawling
• Test lazy-loading images via Mobile-Friendly Test to confirm that Google is indexing them
• Consult Search Console to confirm the mobile-first status and analyze the Coverage/Experience reports on mobile
• Use URL inspection tool to validate rendering and indexing of strategic pages