Dispatch
What Is Mobile-First Indexing?
Mobile-first indexing is the way Google evaluates and ranks web pages today: rather than crawling a site primarily with a desktop user agent and treating the mobile version as secondary,...
On this page
Mobile-first indexing is the way Google evaluates and ranks web pages today: rather than crawling a site primarily with a desktop user agent and treating the mobile version as secondary, Google predominantly uses the mobile version of a site’s content for indexing and ranking. In practice, this means the version of your page that Googlebot Smartphone sees, including its text, images, links, and structured data, is the version that determines how (and whether) the page shows up in search results.
This matters because plenty of sites still build their desktop experience first and treat mobile as an afterthought, trimming navigation, shortening copy, or hiding sections behind interactions to save space on a small screen. Under mobile-first indexing, any content that only exists on the desktop version is largely invisible to Google. If your mobile page says less than your desktop page, Google effectively knows less about your page than you think it does.
Why Google Moved to a Mobile-First Model
Google first announced its intention to experiment with mobile-first indexing in November 2016, explaining that its indexing systems would start to rely on the mobile version of content even for ranking results shown to desktop users. The underlying reason was straightforward: mobile devices had become the primary way most people search the web, so continuing to build an index based primarily on desktop crawling no longer reflected how the majority of searches were actually happening.
The rollout took years, not months. Google originally aimed to have most sites migrated to mobile-first indexing by around September 2020, later extended toward the end of March 2021 as it worked through sites with mobile usability problems. Even after that extended deadline, a residual set of sites with no usable mobile version remained on desktop-only crawling. Google didn’t declare the transition fully wrapped up until October 2023, when it published a post titled “Mobile-first indexing has landed,” noting that only a small number of sites that genuinely don’t work on mobile devices are still crawled with desktop Googlebot. That’s a separate fact from the ordinary background crawling pattern: Google’s own overview of its crawlers notes that even for sites fully on mobile-first indexing, the majority of crawl requests come from the mobile crawler but a minority still come from Googlebot Desktop, so spotting an occasional desktop user agent in your server logs isn’t, by itself, a sign that a site has fallen back to desktop-first treatment. So while “March 2021” is the date most often repeated, the more accurate statement is that the migration effectively concluded in late 2023, several years after the original target.
Three Ways to Serve Mobile and Desktop Content
Google documents three accepted configurations for serving content to mobile and desktop visitors. They aren’t equally easy to maintain, and Google is explicit about which one it prefers.
| Configuration | How it works | Google's guidance |
|---|---|---|
| Responsive web design | Same HTML and same URL for every device; CSS and media queries adjust the layout | Recommended as the easiest pattern to implement and keep in sync |
| Dynamic serving | Same URL, but the server returns different HTML depending on the requesting device | Workable, but requires correctly configured <!–INLINECODE0–> signaling so Google (and caches) know the response differs by device |
| Separate URLs | Distinct URLs for mobile (often an "m." subdomain) and desktop versions | Discouraged for new sites; Google has said it does not recommend separate mobile URLs because of the configuration issues and user confusion this pattern has caused over the years |
If you’re building something new, responsive design avoids most of the failure modes described below simply because there’s only one version of the page to keep correct.
Content Parity: What Has to Match
The single most common cause of mobile-first indexing problems is content that exists on desktop but not on mobile. Google’s guidance is specific about what needs to carry over to the mobile version of a page:
- Primary content. The substantive text, images, and video on the page need mobile equivalents. Layout can differ (for example, organizing the same content into accordions or tabs on mobile to save vertical space), but the underlying content itself should be present, not removed.
- Structured data. Schema.org markup, including types like Product, Breadcrumb, and VideoObject, needs to appear on both versions. Structured data that only exists on desktop is effectively invisible once a site is on mobile-first indexing.
- Titles and meta descriptions. Title tags and meta descriptions should match across versions, since the page’s indexed metadata now comes from the mobile page.
- Images and video. The same images, with matching alt text and file names, should appear on both versions; swapping in different (often lower-resolution) mobile-only images can cause ranking or image-search visibility to shift during a migration.
It is fine for content hidden behind accordions or expandable tabs on mobile to be collapsed by default for usability. Google’s own documentation on mobile-first indexing acknowledges that the same primary content can be organized differently across devices, including behind tabs and accordions, as long as it’s actually present in the page rather than omitted. The mistake isn’t using collapsible UI patterns; it’s using them as an excuse to leave content out of the mobile version entirely.
Common Mistakes That Hurt Mobile-First Indexing
A handful of technical missteps account for most mobile-first indexing problems:
- Lazy-loading that depends on user interaction. Google’s guidance on lazy-loaded content is direct: don’t lazy-load primary content behind actions like clicking, swiping, or typing, because Googlebot does not interact with a page the way a human visitor does. Content that only loads after a tap or swipe may simply never be seen by Google. Lazy-loading triggered by scroll position or viewport visibility, implemented correctly, is generally fine; lazy-loading gated behind a click is not.
- Blocking mobile resources in robots.txt. If CSS, JavaScript, or images required to render the mobile page are disallowed in robots.txt, Google’s rendering systems may not be able to reconstruct the page the way a mobile visitor would actually see it, which can cause content to be misread or missed entirely. Google’s JavaScript SEO documentation warns that blocking rendering-critical resources commonly causes pages to be misunderstood or excluded from ranking consideration.
noindexor restrictive directives applied only to mobile. On separate-URL configurations especially, it’s easy to accidentally apply anoindextag, anofollowdirective, or a broken canonical only to the mobile version while leaving the desktop version untouched, effectively telling Google not to index the version of the page it actually relies on.- Inconsistent structured data or metadata between versions. As noted above, if structured data lives only on desktop, it won’t be reflected in how the page is indexed.
- Slower or broken mobile experiences. Pages that serve error pages, redirect loops, or broken layouts to mobile visitors (while working fine on desktop) will be indexed based on that broken mobile experience.
How to Check Whether Your Site Is Affected
You don’t need to guess which crawler Google is using on your pages. Search Console’s URL Inspection tool shows a “Crawled as” field reporting which version of Googlebot last crawled a given URL, along with the indexed status, canonical and indexing-directive details, and any structured data (rich results) detected. Checking a handful of key templates (homepage, a representative product or article page, a category page) will tell you whether Google is reading the mobile version and whether it matches what you’d expect. Note that Search Console’s standalone Mobile Usability report and the separate Mobile-Friendly Test tool were retired in December 2023: with mobile-first indexing covering essentially the whole web, Google folded mobile usability into its broader page-experience guidance instead of a dedicated report, and now points site owners toward tools like Lighthouse for rendering-level mobile checks.
For a site-wide view, the Page indexing report in Search Console (the report formerly known as the Index Coverage report) shows how many of your URLs are indexed versus excluded, and why, which is useful for spotting patterns like an entire template being excluded due to a robots.txt rule or a noindex directive that only fires on mobile.
The Bottom Line
Mobile-first indexing isn’t a future change to plan for. It has been Google’s default approach for essentially the entire web for several years now, with only a small residual set of unworkable sites still excluded. The practical implication for site owners is simple to state and easy to get wrong in implementation: whatever you want Google to know about a page, including its full text, its images, its structured data, and its metadata, needs to actually be present and accessible on the mobile version, not just the desktop one. Responsive design, used correctly, removes most of the risk by ensuring there’s only one version of the page to keep right. If you’re on dynamic serving or separate mobile URLs, the burden shifts to you to keep both versions in sync, and to verify that sync periodically using Search Console rather than assuming it holds over time.