Mobile-first indexing
Google indexes and ranks the mobile version of a page, crawled with the smartphone agent — which means the mobile rendering, not the desktop one, is the document everything downstream reads.
Karl-Gustav Kallasmaa, Founder & CEOLast updated Mobile-first indexing is Google's practice of using the mobile rendering of a page as the document it indexes and ranks. Google's own wording: "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking. This is called mobile-first indexing."
It is worth stating what this is not. It is not a ranking boost for responsive sites, and not a penalty for desktop-heavy ones. It is a decision about which version of your page becomes the canonical text. Everything downstream — the index entry, the snippet, the passage a retrieval system later pulls — reads that version.
Google announced the transition complete in a Search Central blog post dated October 2023, "Mobile-first indexing has landed." There is nothing left to migrate; the question is only whether your mobile rendering is the page you think it is.
The mechanism, and what it changes
A crawler fetches the URL with the smartphone agent, renders it at a mobile viewport, and indexes what comes back. If your site serves one responsive HTML document to every agent, this is uneventful. If it serves different markup by device — separate m-dot hosts, dynamic serving, or a component library that drops sections below a breakpoint — the mobile branch is the one that counts and the desktop branch is, for indexing purposes, unread.
The consequences fall out mechanically:
- Content parity. Google's guidance is to "make sure that your mobile site contains the same content as your desktop site." Content collapsed behind an accordion but present in the HTML is fine. Content omitted from the mobile build is not indexed.
- Structured data parity. "Make sure that your mobile and desktop sites have the same structured data." Markup that only ships on desktop is markup Google does not see.
- Robots meta parity. "Use the same robots meta tags on the mobile and desktop site. If you use a different robots meta tag on the mobile site (especially the
noindexornofollowtags), Google may fail to crawl and index your page." This is the highest-severity item on the list, because it fails silently and totally. - Images. Google asks sites to "provide high quality images" and warns "don't use images that are too small or have a low resolution on the mobile site," with alt text kept consistent across versions.
- Interaction-gated content. "Don't lazy-load primary content upon user interaction. Google won't load content that requires user interactions (for example, swiping, clicking, or typing) to load."
Why it matters to anyone trying to be cited by an agent
Because it establishes a principle that now applies well beyond Google: the fetched rendering is the document.
A retrieval-based assistant does the same thing in a cruder way. It requests a URL, takes whatever HTML comes back, and works from that text. It generally does not run your click handlers, does not swipe your carousel, and does not wait for a section that loads on scroll. A page whose substance appears only after interaction presents an empty document to every automated reader, and mobile-first indexing was the first large system to make that explicit.
So the discipline mobile-first indexing forces — everything important present in the first server response, at a small viewport, with no interaction required — is the same discipline that makes a page eligible to be quoted by an assistant. See crawling and indexing for how the fetch itself is decided.
Speed compounds this. Google's Largest Contentful Paint guidance of 2.5 seconds or less is assessed at the 75th percentile and segmented across mobile and desktop, so a mobile experience carried by a fast desktop average is not passing. A retrieval fetch with a timeout behaves the same way: slow enough is indistinguishable from absent.
Failure modes
- A `noindex` that ships only on mobile. Usually a device-conditional template or a stale m-dot rule. It removes the page entirely and looks like a ranking mystery.
- Sections dropped below a breakpoint. A design decision made in CSS-in-JS becomes a content decision in the index, without anyone deciding it.
- Structured data on desktop only. Common when markup is injected by a script that only runs in a desktop layout branch.
- Content behind a tap. Tabs and "read more" that fetch on click rather than hiding already-present HTML. Hidden is fine; absent is not.
- Mismatched canonicals between an m-dot host and the desktop host. Two hosts, two opinions about the canonical URL, and an unstable index entry. See canonical URLs.
- Low-resolution mobile image variants. Serving a thumbnail-grade asset to the smartphone agent when that agent's rendering is the one being judged.
- Testing on a desktop browser narrowed to a phone width. That is not the same fetch. Test the URL as it is served to the smartphone agent, not as it reflows in your window.
Terms related to Mobile-first indexing
The two separate stages that decide whether a page can be retrieved at all, and the reason a serving rule on a blocked page is never read.
Google's three published field metrics for loading, responsiveness and visual stability, with the exact thresholds and the percentile they are judged at.
The one URL you nominate as the indexable version of a page, how the rel=canonical hint is actually weighted, and what a split canonical costs you when an agent needs a link to cite.
The standardised file that tells crawlers what they may fetch, now the main place where AI training and AI retrieval access are decided separately.