Skip to main content

Mobile-first indexing: what Google actually sees

5 min read

You open a page in a desktop browser and everything looks right: the text is there, the title is correct, the product details are in place. But search engines mostly read the mobile version of that page, and the mobile version can be a different page.

If the mobile version hides content, loads different HTML, or serves a stripped-down page to save data, that is what determines ranking. For most sites the desktop version barely matters. This is the invisible layer, the kind of problem that never raises a warning. Here it is especially deceptive, because the version you look at and the version search engines read are not the same page.

What mobile-first indexing means

Google switched to mobile-first indexing in 2019 for new sites and finished moving the remaining sites in 2024.

Googlebot, Google's crawler, now requests pages from most sites with its smartphone user agent, which means it identifies itself to servers as a phone browser. The content it sees on mobile is what gets indexed. If content exists on desktop but is missing from the mobile HTML, search engines do not see it. This usually happens in one of two ways: a page template shows the content only to desktop visitors, or the content loads only after a tap or swipe.

What breaks ranking

These problems appear when the mobile version of a page differs from the desktop version, which can happen with a separate mobile site, with servers that switch content by device, or with scripts that change the page by screen size.

  • Content missing on mobile. Text inside a collapsed accordion or tab is generally fine if it is in the HTML. Text that only the desktop version renders, whether through server logic or separate templates, is not used for indexing.
    <!-- collapsed by default, still in the HTML: usually indexed -->
    <details>
      <summary>Shipping policy</summary>
      <p>Orders ship within two days.</p>
    </details>
    
    <!-- avoid: rendered only for desktop requests, so the mobile HTML has no such paragraph -->
    <p>Orders ship within two days.</p>
  • Structured data on desktop only. Structured data is extra labeling that tells search engines what a page is about, such as an article or a product, and JSON-LD is the usual format for it. If JSON-LD is added to the desktop layout but not the mobile layout, search engines see no structured data.
    <!-- desktop page head -->
    <script type="application/ld+json">{ "@context": "https://schema.org", "@type": "Article", "headline": "..." }</script>
    
    <!-- mobile page head: no script, so search engines see no structured data -->
  • Different titles or descriptions per device. The mobile version is the one search engines use, so a stronger desktop title does nothing if the mobile version carries a weaker one.
    <!-- desktop -->
    <title>Waterproof hiking boots | Free delivery | Acme</title>
    
    <!-- mobile: this is the title search engines read -->
    <title>Boots | Acme</title>
  • Lower-quality mobile images. Images that are too small or low-resolution on mobile can hurt how the page appears in image results, and using different image URLs for mobile can cause a temporary loss of image traffic. Responsive images let the browser choose the size without a separate mobile file.
    <!-- avoid: the mobile version gets a tiny, heavily compressed file under its own URL -->
    <img src="hero-mobile-200.jpg" alt="Waterproof hiking boots">
    
    <!-- use: one set of image URLs, with the browser choosing the size -->
    <img srcset="hero-480.webp 480w, hero-1600.webp 1600w" sizes="100vw" src="hero-1600.webp" width="1600" height="900" alt="Waterproof hiking boots">
  • Content that loads only after a tap or swipe. Google does not load content that needs a swipe, a click, or typing to appear, so primary content that waits for one of those is never seen.
    <!-- avoid: the text loads only after a tap, so search engines never see it -->
    <button onclick="loadReviews()">Show reviews</button>
    
    <!-- use: the text is already in the HTML, and the page only folds it away -->
    <details>
      <summary>Reviews</summary>
      <p>Great boots, kept my feet dry all week.</p>
    </details>
  • Different robots rules per version. Use the same robots meta tags and the same robots.txt rules on both versions. A noindex tag or a blocked folder that exists only on the mobile version can keep a page, or its images, out of results.
    <!-- desktop page -->
    <meta name="robots" content="index, follow">
    
    <!-- avoid: the mobile page says noindex, so the page can drop out -->
    <meta name="robots" content="noindex">

Responsive design versus a separate mobile site

A responsive design at the same URL is the simplest case. It is one URL with one set of HTML, and CSS handles the layout differences. That removes the problem of keeping two versions in sync, but content that is hidden or rendered conditionally by screen size can still be missing on mobile.

A separate mobile site at m.example.com is where things drift. Its canonical tags, which tell search engines which address is the main version of a page, must point from the m. host to the matching desktop URLs, and the desktop pages must point to the mobile URLs with a rel="alternate" tag that carries a media attribute. Content, structured data, titles, and meta descriptions need to be equivalent on both, and URLs in the mobile structured data must be the mobile URLs. Every change has to be made twice, so the two sites tend to fall out of step.

<!-- on the desktop page: point to the mobile page -->
<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/page">

<!-- on the mobile page: point back to the desktop page -->
<link rel="canonical" href="https://www.example.com/page">

How to audit it

Open Chrome DevTools, toggle the device toolbar, select a phone, and reload. That shows how a mobile browser renders the page. It is not an exact copy of Googlebot, which may handle JavaScript differently, for instance by not running scripts that wait for a tap or scroll. It still catches most content differences.

For a closer check, open URL Inspection in Google Search Console, the free tool for seeing how Google reads your pages, and choose View Crawled Page. It shows the rendered HTML, meaning the page after its scripts have run, as Googlebot last saw it. Search that HTML for a sentence from your page. If the sentence is on your screen but not in the HTML, you have found the gap. The Page indexing section of the same report has a Crawled as field that says whether the page was last crawled as mobile or desktop.

What the build process will not tell you

No build step compares the mobile version against the desktop version for content differences. A template that accidentally renders only on desktop produces no warning. The build passes and the desktop page looks complete.

The ranking drop can show up days or weeks later, once search engines visit the pages again. The Pages report in Google Search Console, under Not indexed, lists a reason for each page it excludes, but it will not point to a difference between the mobile and desktop versions. The check that catches it is searching both the desktop page source and the crawled HTML for the same sentence and the same JSON-LD after each template change.