Mobile-First Indexing: What Still Trips Sites Up

Mobile-First Indexing: What Still Trips Sites Up

ByAdam


Google indexes the mobile version of your site. Learn the content, structured data and image parity issues that still cost sites rankings on mobile-first.

Google has used mobile-first indexing for all new sites since 2019 and completed the rollout to all sites by 2023. What this means in practice: Google uses the mobile version of your page — the version seen by smartphone users — as the primary version it crawls, indexes, and ranks. The desktop version is secondary. If your mobile version shows different content, fewer headings, or stripped-down structured data compared to your desktop version, Google is seeing and ranking the lesser version.

Most responsive sites handle this correctly by default — because the responsive design serves the same HTML to both desktop and mobile, just styled differently. The problems appear in specific patterns that still trip sites up.

The Short Version

  • Google ranks based on the mobile version of your page — content, schema, or images missing from mobile simply don’t count.
  • Most responsive sites are unaffected by default; the risk concentrates on sites with separate mobile URLs, adaptive serving, or JavaScript-driven content hiding.
  • Content removed from mobile via CSS or JS (not just visually collapsed) may never be indexed at all — that’s a different and more serious problem than a collapsed accordion.
  • Check the URL Inspection tool’s “Crawled as” field to confirm whether Google is using Googlebot Smartphone or Desktop for any given page.

Four parity issues at a glance

IssueWhat goes wrongHow to check
Content parityContent present on desktop is removed (not just collapsed) on mobileCompare mobile vs desktop HTML via Chrome device simulation
Structured data paritySchema only injected into the desktop templateRich Results Test with smartphone crawling option
Image and mediaLower-resolution images served on mobile, or scroll-triggered lazy load never fires for GooglebotInspect mobile-rendered HTML for actual image src/srcset
Intrusive interstitialsFull-screen popups blocking content for mobile visitors from searchLoad the page on mobile as a first-time visitor from a search referrer

Content parity: the most common issue

Some sites hide content on mobile that’s visible on desktop — a “Read more” expansion that starts collapsed on mobile but open on desktop, a sidebar with contextual links that disappears on small screens, or content in a tab that’s not visible by default. If this content is hidden behind a click on mobile, Google can still index it (hidden-but-accessible content is treated as full content) — but if the content is literally not present in the mobile HTML (removed via CSS display:none or JavaScript), Google may not index it at all.

Check for content parity by comparing the mobile and desktop versions of your most important pages: use Chrome’s device simulation (F12 → mobile icon) and check that headings, body content, internal links, and any important text are present in both versions. If you use a page builder that hides entire sections on mobile, verify those sections are still in the HTML rather than being server-side removed.

Structured data parity

If structured data is rendered differently on mobile vs desktop — for example, if it’s added via a desktop-specific script or only injected into the desktop template — the mobile version may have no structured data at all. Google evaluates structured data from the mobile version, so markup that only exists on desktop won’t earn rich results.

Verify this through the Rich Results Test: test the mobile URL version (the Rich Results Test has a smartphone crawling option) and confirm that the expected schema types are present in the rendered mobile version.

Image and media issues

Images that display differently on mobile create two separate issues. First, if the mobile version uses a smaller, lower-quality image (served via a CSS background-image swap or a JavaScript-based responsive image implementation), Google’s mobile crawler may index the lower-resolution version for image search. Second, images that load via lazy-load scripts on mobile need to be crawlable — if the lazy-load implementation only triggers on scroll and Googlebot doesn’t scroll, images below the fold on mobile may not be indexed.

Use the <img> tag with srcset for responsive images rather than JavaScript-only implementations wherever possible — this is natively supported and correctly crawled by Googlebot.

Intrusive interstitials on mobile

Google’s Page Experience guidelines penalise intrusive interstitials — full-screen popups or overlays that block content on mobile. A popup that covers the main content on mobile when a user arrives from search is a specific signal Google has said it will use to downgrade ranking. Cookie consent banners and login dialogs are excepted; full-screen promotional overlays are not. If your site shows a large email capture popup immediately on mobile load for first-time visitors from search, this is worth testing and adjusting.

For the full technical audit framework, see the SEO audit checklist. For Core Web Vitals specific to mobile, see how to fix Core Web Vitals.

A worked example: a hidden mobile FAQ section

A service business noticed its FAQPage rich results were appearing reliably in desktop search previews during testing, but Search Console showed the FAQ rich result almost never appearing for actual mobile searches — even though the vast majority of the site’s traffic was mobile. Testing the mobile URL specifically in the Rich Results Test (rather than the default desktop crawl) revealed the cause: the page builder’s “hide on mobile” setting for the FAQ section removed it from the DOM entirely on small screens, rather than just collapsing it visually. The FAQPage schema referenced Q&As that, on mobile, didn’t exist on the page at all — a direct violation of the visible-content-must-match-markup rule, and exactly why Google wasn’t surfacing the rich result for mobile queries.

The fix was switching the builder setting from “hide on mobile” (DOM removal) to a CSS-only collapse that kept the FAQ content present but visually condensed into an accordion on small screens. Within two weeks of Google re-crawling the mobile version, the Rich Results Test showed valid FAQ markup on mobile, and the FAQ rich result began appearing in mobile search results for the relevant queries — recovering a CTR advantage that had effectively been invisible to the team because their own testing habitually happened on desktop.

Frequently asked questions

Check the Crawl Stats in Google Search Console (Settings → Crawl Stats) and look at the user-agent breakdown. A site using mobile-first indexing shows crawls from “Googlebot Smartphone” as the primary crawler, with “Googlebot Desktop” as secondary or absent. You can also check individual URLs with the URL Inspection tool — the “Crawled as” field shows which user-agent Google most recently used to crawl that specific page. If it says “Smartphone,” you’re on mobile-first indexing.

For most responsive sites, mobile-first indexing is effectively transparent — the same HTML is served to all devices, and Google’s mobile crawler sees the same content as the desktop crawler. The issues described above (content parity, structured data parity, image implementation) are worth verifying, but if your site is built on a responsive framework with no separate mobile content, you’re unlikely to have mobile-first indexing problems. The sites most at risk are those with separate mobile URLs (m.domain.com), adaptive serving (different HTML based on user agent), or complex JavaScript that renders content differently on small screens.

Separate mobile URLs (m.domain.com) require additional technical implementation: canonical tags pointing from mobile URLs to their desktop equivalents, and rel=”alternate” annotations pointing from desktop to mobile. Without these, Google may index and rank the mobile version independently, splitting authority between the two versions. Separate mobile URLs were a common pattern before responsive design became standard, but they’re now considered technically complex and risky compared to responsive design. If you’re running a separate mobile site and considering a redesign, moving to responsive is worth doing for the long-term technical simplicity alone.

Google maintains separate indexes for mobile and desktop searches. A page ranking #3 on desktop may rank #5 on mobile (or vice versa) because mobile searches have different result types, different featured snippet patterns, and are influenced by local intent signals more strongly. Mobile-first indexing means Google uses the mobile version of the page as its primary data source for ranking decisions — but those rankings play out separately for mobile and desktop queries. In practice, for most content sites with responsive design, desktop and mobile rankings are closely correlated. The divergences appear in local, voice, and informational queries where mobile search behaviour differs significantly from desktop.

Use the URL Inspection tool in Search Console and click “Test Live URL,” then view the rendered screenshot and the HTML tab — this shows the page as Googlebot Smartphone actually rendered it, which is the most accurate representation available. Chrome’s device simulation mode (F12 → toggle device toolbar) is a good first-pass check during development, but it simulates viewport size rather than Googlebot’s specific rendering behavior, so treat Search Console’s tool as the authoritative check before concluding a parity issue is or isn’t present.

Yes, regardless of where your traffic currently comes from — mobile-first indexing determines what Google crawls and ranks for both mobile and desktop search results, since Google uses one primary version (the mobile one) to build its index. A B2B site with 80% desktop traffic still has its ranking signals derived from the mobile version of its pages. If the mobile version is missing content or schema present on desktop, that affects desktop rankings too, even though the visitors arriving on desktop never see the gap themselves.

What Google sees on mobile is what gets ranked

The shift to mobile-first indexing isn’t something to act on urgently if your site is already responsive and serving consistent content across devices. But it’s worth knowing: when something goes wrong with indexation, or when your desktop and mobile traffic diverge unexpectedly, the mobile version is where to start the investigation.

If you’d like a mobile-first indexing check included in a broader technical audit, get in touch.

Similar Posts