Mobile-First Indexing Explained: What Google Indexes

Mobile-first indexing means Google uses the mobile version of your pages, fetched by its smartphone crawler, as the version it indexes and ranks. If something is on your desktop site but not on your mobile site, Google does not see it, and that applies to the results it shows desktop searchers too. There is one index, and it is built from what a phone would get.

This is no longer a transition. Since July 2024 Google has crawled and indexed every site with Googlebot Smartphone. It has said that a site which cannot be loaded on a mobile device is not indexable at all. For a responsive site that sends the same HTML to every device there is little to do. Check that nothing is hidden on small screens, that lazy-loaded content appears without a tap, and that the page is fast on a phone. For a site with a separate mobile version, or one that trims content for mobile, the risk is real and usually invisible until rankings slip.

Below: what mobile-first indexing changes in practice, the content parity checks we run, and why mobile speed is the speed that counts. Then how to see what Googlebot Smartphone actually fetched, and how we build for it.

What mobile-first indexing actually means

Google has one index. For each page it stores one version of the content, and that version is the one its smartphone crawler received. Googlebot Smartphone identifies itself with a user agent containing both "Googlebot" and "Mobile" and renders pages with a phone-sized viewport. Google still uses a desktop crawler for a few purposes, but nothing on your site should depend on it.

Three consequences follow. First, text, links, images and structured data that exist only in the desktop layout are, for ranking purposes, absent. Second, a heading structure that changes on mobile (an H1 swapped for a logo, section headings dropped to save space) is the structure Google reads. Third, the mobile page is also the one whose metadata counts: title, description, canonical, hreflang and robots directives all need to be present and identical on the mobile version.

What has not changed: desktop visitors still matter for your business, and Google's Core Web Vitals are measured separately for phones and desktops. Mobile-first is about which copy of the page Google keeps, not about ignoring desktop users.

Content parity: the checks that matter

Parity means the mobile page carries the same content and signals as the desktop page. On a responsive site the HTML is identical and parity is nearly automatic. The problems come from CSS that hides elements, scripts that only run on wide screens, and menus that drop links. These are the items we check:

Same main content. Every paragraph, table and list in the desktop version is present in the mobile HTML, not removed with a "mobile" class or a separate template.
Same headings. One H1 and the same H2 and H3 outline on both. Collapsing sections into accordions is fine; Google has said content in tabs and accordions is indexed normally. Removing the sections is not.
Same internal links. A hamburger menu is fine because the links are still in the HTML. A footer trimmed to three links on mobile removes the other twenty from what Google crawls.
Same images, same alt text, same URLs. A mobile image swapped in through CSS backgrounds has no alt text and is not indexed as an image. Use srcset or the picture element so the markup stays the same and only the file served changes.
Lazy loading that works without interaction. Googlebot does not scroll or tap. Native loading="lazy" on images and an IntersectionObserver for other content both work; content fetched on a scroll event or a "load more" tap does not exist to Google. Our guide to lazy loading images covers the safe pattern.
Same structured data and metadata. JSON-LD, canonical, hreflang, title and description must be in the mobile HTML, not injected only for desktop.
Nothing blocked for the smartphone crawler. robots.txt must allow the CSS, JavaScript and image paths the mobile layout needs. The server must not serve a different, lighter page when it sees a Googlebot user agent.
No interstitials covering the content. A full-screen pop-up on arrival is both a poor experience and something Google's page experience guidance penalises. Cookie notices that take a strip of the screen are fine.
Viewport meta tag present. Without <meta name="viewport" content="width=device-width, initial-scale=1"> the phone renders the desktop layout shrunk down, and everything else on this list is moot.
Error pages and redirects behave the same. A page that returns 200 on desktop and redirects to the homepage on mobile is, to Google, a redirect.

Separate mobile sites on an m. subdomain can still be made to work with paired canonical and alternate tags. But Google recommends responsive design, and every parity problem above is harder to avoid when two sets of templates have to be kept in step. If the mobile site is also client-rendered, the content has to survive Google's JavaScript rendering as well; our guide to server-side versus client-side rendering explains what that involves.

Mobile speed is the speed that counts

Because the indexed version is the mobile version, the speed that matters most is what real visitors on phones experience. Google measures this through Core Web Vitals field data, collected from Chrome users and reported at the 75th percentile. The thresholds are 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint and 0.1 for Cumulative Layout Shift. A page that passes on an office desktop and fails on a mid-range phone over mobile data fails. Our Core Web Vitals guide covers each metric and where to read the data.

The fixes are the familiar ones, applied with a phone in mind:

images served at the size the phone layout actually displays rather than the desktop size scaled down
fonts that do not block text
third-party scripts cut to the ones that earn their place
layout space reserved for anything that loads late

Interaction to Next Paint is the metric most often missed on phones specifically. The reason is that the same JavaScript that feels instant on a laptop takes several times longer on a cheaper handset.

How to check what Googlebot Smartphone sees

Google retired its Mobile-Friendly Test tool and the Mobile Usability report in Search Console, so the checks now live in URL Inspection and in your own tools.

URL Inspection in Search Console. Inspect a page and look for "Crawled as: Googlebot smartphone". Open "View crawled page" to see the HTML Google stored, the screenshot it rendered, and any resources it could not load. If the HTML there is missing content you can see on desktop, parity is broken.
Test live URL. The same panel can fetch the page fresh, which shows whether a fix has worked before Google recrawls on its own schedule.
Fetch the page as the smartphone crawler yourself. Request it with the Googlebot Smartphone user agent and compare the result with a desktop fetch. A quick parity check is to count headings and links in each:

UA="Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
curl -s -A "$UA" https://example.com/services/ | grep -c "<h2"
curl -s -A "$UA" https://example.com/services/ | grep -c "<a href"

If the counts differ from the desktop fetch, the server or the templates are serving different pages, and that is where to look. Chrome DevTools device mode and a Lighthouse run in mobile mode cover the layout and speed side. For a whole site, the crawler script in our technical SEO audit checklist can be run with the smartphone user agent and its output compared against a desktop run. Our free website health check reports the mobile speed and SEO basics for any page.

How we build for it

Every site we build sends one HTML document to every device and lets CSS handle the layout. Nothing that matters is hidden with display: none at small widths. The navigation collapses but its links stay in the document. Images use srcset so the phone downloads a phone-sized file from the same markup. The H1 and heading outline are the same at every width. The staging site every client clicks through before launch is checked on real phones, not only in a resized browser window.

For shops this matters more than anywhere, because most shoppers arrive on a phone and the product page they see is the one Google indexed. The online shops we build show the full product description, price in the shopper's currency and postage on mobile exactly as on desktop. The checkout takes Apple Pay and Google Pay so paying on a phone is a couple of taps rather than a form.

Questions people ask

Does mobile-first indexing mean the desktop site no longer matters?

For indexing, the mobile version is the one that counts. For your business, desktop visitors still convert, and Core Web Vitals are assessed for desktop separately. Build one responsive site and both are covered.

Is my site on mobile-first indexing?

Yes. Every site is crawled and indexed with Googlebot Smartphone. URL Inspection will confirm it with "Crawled as: Googlebot smartphone".

Does content hidden in tabs or accordions still count?

Yes, as long as it is in the HTML. Google has said content in tabs and expandable sections is indexed normally on mobile. Content that is only fetched after a tap is the problem.

What to do this week

Inspect your three most important pages in Search Console and read the stored HTML for each. Check that the main content, the headings, the footer links and the structured data are all there. Then open the same pages on a phone and compare them with the desktop view, looking for anything the phone version drops.

If everything matches, mobile-first indexing is not a problem you have, and the remaining work is speed. If something is missing, that missing content has been invisible to Google for as long as it has been missing. Restoring it is the fastest ranking fix available to you.