Since 2018, and fully since 2023 for the entire index, Google uses a page's mobile version as the primary version for crawling, indexing and ranking, regardless of whether the end user is searching from a phone or a desktop computer. This shift, known as mobile-first indexing, has a very specific technical consequence many teams still haven't internalized: if your mobile version shows less content, fewer links or less structured data than your desktop version, it's the mobile version (the more limited one) that determines what Google knows about that page, not the desktop one.
Why Google switched to mobile-first
The underlying reason is simple: most global search traffic has been mostly mobile for years, so indexing based on the desktop version meant, in practice, evaluating an experience most real users would never have. The change doesn't affect sites with responsive design (where the same HTML visually adapts via CSS depending on screen size, without changing the content served), which today is the vast majority of the modern web, but it does critically affect sites that still serve different HTML depending on the device.
Sites with separate mobile URLs: the case that carries the most technical risk
Some sites, mostly legacies of older designs, serve a mobile version on a different URL (m.yourdomain.com instead of www.yourdomain.com), with its own stripped-down HTML. Under mobile-first, Googlebot crawls and indexes m.yourdomain.com as the primary version, so any content, internal link, or structured data that exists only in the desktop version (www.yourdomain.com) and not in the mobile one is effectively invisible to Google's index. It's an increasingly rare pattern (most sites have migrated to responsive), but where it still exists, it requires a content-parity audit between both versions.
Content parity: the central technical requirement
The principle that sums up all of mobile-first indexing is content parity: everything that exists in the desktop version (text, images with their alt, internal links, structured data, metadata) must also exist, equivalently, in the mobile version. Common mistakes that break this parity: hiding "secondary" content on mobile via display: none to simplify the experience (content hidden with CSS remains indexable, but any content directly removed from the mobile HTML isn't); trimming the mobile navigation menu by removing links that do exist in the desktop menu, reducing the real internal linking Google can follow; and serving lower-resolution images or dropping the alt attribute on mobile to save weight, losing the context signal those images provided.
// Quick check: compare how many internal links exist on
// each version from the browser console
document.querySelectorAll('a[href]').lengthInterstitial ads: the element that hurts mobile the most
Google explicitly penalizes intrusive interstitials on mobile: full-screen pop-ups that cover the main content right after the page loads, before the user has been able to interact with anything. There are legitimate, explicitly allowed exceptions, like legally required cookie notices or age-verification interstitials, but a full-screen promotional or subscription pop-up in the first second of mobile load is one of the few user-experience elements Google treats as an explicit negative technical signal, not just a bad design practice.
Mobile speed: the bar is more demanding than on desktop
As explained in the Core Web Vitals guide, Google's reference thresholds are calibrated mostly around the typical performance of a mid-range mobile device, with far more limited CPU than a desktop computer. A site that loads smoothly on a modern laptop can clearly fail those same thresholds on a real phone, precisely because mobile-first indexing makes mobile performance, not desktop, the one that counts for the ranking factor.
How to verify your own site's parity
The most direct check is Search Console's URL Inspection, which shows the HTML exactly as Googlebot sees it (in its mobile version, by default since the full mobile-first migration) and lets you compare it directly against what you see inspecting the same URL in a desktop browser. Any discrepancy in content, links or structured data between the two views is a real loss of ranking signal.
Frequently asked questions
Does mobile-first mean my site is only evaluated on how it looks on mobile?
It means crawling and indexing use the mobile version as the primary content source, regardless of what device the actual searching user is on. A desktop user can still see your site's desktop version; what changes is which version Google uses to decide what it knows about that page.
Does a responsive design automatically protect me from any problems?
In most cases yes, precisely because the same HTML is served to every device and only the visual presentation changes via CSS. The real risk lies in deliberate decisions to hide or remove content specifically for the mobile view within that same responsive design.
Does hiding content with CSS on mobile count as "not indexable"?
Not necessarily: content hidden with display: none or similar remains in the HTML and, in principle, remains indexable. The real problem shows up when content is directly removed from the HTML served on mobile (for example, via conditional JavaScript rendering), not when it's only visually hidden.
How do I know if my site has already moved to mobile-first indexing?
Search Console indicates, in site settings, whether Google is using the desktop or mobile (smartphone) crawler as primary for that domain. Since 2023 virtually every site in Google's index already uses the mobile crawler.
Does this affect sites that only get desktop traffic?
Yes, and it's the part that surprises people most: even if 100% of a site's real traffic came from desktop, Google still indexes and ranks that site based on what it sees in its mobile version, because mobile-first indexing doesn't depend on traffic origin but on a global decision by Google about how it crawls the entire web.