What Is Mobile-First Indexing?

Mobile-first indexing determines which version of a page Google treats as the primary source when crawling it, storing it in the index, and calculating its ranking: the one a phone sees, not the one a desktop computer sees. That holds regardless of which device the eventual searcher uses. If your mobile and desktop pages show different content, Google almost always knows and evaluates only the mobile one.

The rollout wasn't instant. Google started testing the approach in November 2016 and rolled it out gradually from March 2018, prioritizing sites that already followed best practices. On July 1, 2019, it became the default for any new domain Google hadn't seen before. For the rest of the web, migration dragged on well past the original plan: Google targeted September 2020, pushed that to March 2021, and by November of that year admitted it no longer had a fixed date, because some sites ran into technical issues it hadn't anticipated.

The official close came on October 31, 2023, in the blog post "Mobile-first indexing has landed." That's where Google confirmed that, barring a handful of exceptions, the entire index is now crawled and evaluated with Googlebot Smartphone. Any source that still describes mobile-first as "rolled out since 2020" is describing a midpoint in the process, not the date Google declared it finished.

Three separate concepts get mixed together here, and each solves a different problem. One is a Google indexing strategy. Another is a development technique. The third is a set of performance metrics.

A responsive site makes mobile-first much easier to satisfy, because both versions share the same HTML and nothing gets lost switching between them. They still aren't the same thing: a site can be responsive and still fail mobile-first if, say, it hides a text block with CSS on small screens and that block never becomes part of what Google indexes. Conversely, a site with separate mobile and desktop URLs (the old m.yoursite.com pattern) can satisfy mobile-first fine if the mobile version carries all the relevant content, even though Google now recommends responsive design precisely because it avoids that kind of parity mistake by default.

Core Web Vitals are a separate matter again: they measure how fast and how stable a page loads, not which version Google indexes. A site can pass mobile-first cleanly and still post a poor LCP on mobile, because the two are evaluated independently.

Most mobile-first problems don't come from lacking a mobile-friendly site. They come from mobile and desktop versions saying different things. The most common cases:

Trimmed text on mobile. It's common to shorten long paragraphs or drop entire sections on the mobile version to avoid cluttering a small screen. Google indexes that trimmed version. Any keyword or fact that only lived in the removed paragraph stops counting for ranking.

Elements Google can't see either. Tabs, accordions, and dropdown menus aren't a problem by themselves: Google does read content hidden behind a click if it's present in the HTML. The problem starts when that content only loads after a user interaction, a scroll, a swipe, a click that triggers a server request, because Googlebot doesn't interact with a page the way a person does.

Incomplete structured data. Schema.org markup often gets added only to the desktop template and forgotten on the mobile one, especially when the two run on separate templates. If Google only indexes the mobile version, a rich snippet that depends on that markup stops appearing, even if the desktop version is flawless.

Mismatched metadata. A title tag or meta description that differs between versions, sometimes trimmed to fit a narrower mobile template, means the search result shown isn't the one the desktop team actually approved.

Reduced internal linking. Mobile versions often simplify menus and footers to save space. If that strips out links that exist on desktop, the destination pages lose part of the signal they get through internal linking, without anyone having touched their own content.

Different technical blocks. Less common, but it happens: robots.txt rules or noindex directives applied to the mobile template but not the desktop one, or the reverse, usually a misconfiguration in the CDN or the server that serves each version.

The first stop is still Search Console, with one important caveat: the standalone "Mobile Usability" report that had existed since 2016 stopped being available on December 1, 2023, along with the Mobile-Friendly Test tool and its API. Google's reasoning was that once mobile-first covered the whole index, that specific check became redundant, and there are now more complete tools for the same job, Lighthouse chief among them.

To check what Google actually sees for a given URL, the right tool today is URL Inspection inside Search Console: it shows the already-rendered HTML, exactly as Googlebot processed it with the smartphone user agent. Comparing that result against what you see opening the same URL on a desktop browser reliably reveals a missing text block, structured data item, or link.

A second check, more manual but just as reliable, is opening the same URL in a browser's responsive dev-tools mode and comparing it section by section against the desktop version. Pay particular attention to anything hidden behind an accordion or tab: if it's present in the source HTML even while visually hidden, there's no problem; if it's only generated after an interaction, there is.

For structured data, Google's Rich Results Test validates markup the way the mobile crawler sees it, not the desktop crawler, so it's worth running it on the actual live URL rather than a reference template.

• Use responsive design with a single URL and a single HTML source for both versions: Google has recommended this since 2018 precisely because it removes the risk of mobile and desktop content drifting apart.
• Keep full structured data markup in the mobile template, not only the desktop one, even when the two are technically separate templates.
• Keep the title tag, meta description, and hreflang tags identical across both versions, even when screen space is tighter.
• If you need to hide secondary content on mobile for space, do it with accordions or tabs that remain present in the HTML, not by stripping it from the markup or loading it only after a user interaction.
• Check that menu and footer internal links aren't cut down so far on mobile that destination pages end up orphaned or harder to reach.
• Verify with URL Inspection in Search Console, not just a browser preview, since it's the only way to see the exact HTML Googlebot Smartphone processed.

• Hiding content with CSS (display: none or similar) assuming it only affects the mobile view: if that content never reaches the HTML Googlebot crawls, it no longer counts for desktop ranking either, because Google no longer treats the two cases separately.
• Assuming responsive design automatically satisfies mobile-first, without ever checking which specific version Google is actually indexing for your most important pages.
• Loading structured data only through JavaScript that runs after a user interaction, instead of having it present in the initial HTML or the DOM Google renders.
• Still auditing mobile usability by 2020 standards, without accounting for the fact that Search Console's dedicated report no longer exists and Lighthouse or URL Inspection are the current tools.
• Blocking resources like CSS or images via robots.txt that Google needs to render the mobile version correctly, which can make a page look worse optimized than it actually is.