Google reads the mobile version of every site:
Mobile-first indexing is Google’s policy of using the mobile version of a webpage as the primary source for indexing and ranking, rather than the desktop version. Despite the name, this isn’t about Google preferring mobile over desktop. It’s about Google standardizing on a single version, the mobile one, as the canonical representation of every page.
The policy reflects how the web is actually used. The majority of Google searches happen on mobile devices. The majority of page visits originate on mobile. A site that performs poorly on mobile is performing poorly for most of its visitors, even if the desktop experience is polished. By indexing the mobile version, Google’s index aligns with what most users actually see.
For most sites in 2026, mobile-first indexing is invisible. Responsive design means the mobile and desktop versions are the same HTML rendered differently. Google reads either and gets the same content. The change matters most for sites with structural differences between mobile and desktop, where one version contains content or signals the other doesn’t.
The shift, from desktop-primary to mobile-primary:
Until 2017, Google’s index was built primarily from the desktop version of pages. Googlebot crawled with a desktop user agent. The page content Google’s algorithm evaluated (the keywords, headings, internal links, structured data) came from the desktop rendering. Mobile rankings were partially derived from desktop content with adjustments for mobile-friendliness.
The shift to mobile-first indexing began as a pilot in 2016 and rolled out gradually across the web. Google announced the transition in late 2016, began moving sites individually in 2018, and continued the process for several years. Sites received notification in Google Search Console when their indexing transitioned. By 2023, Google declared the migration substantially complete, with effectively all sites indexed mobile-first.
The transition wasn’t a single switch flipped on a specific date. Google moved sites in waves, based on signals indicating each site was ready. Sites with responsive design transitioned first, since the mobile and desktop versions were already aligned. Sites with separate mobile architectures (m.example.com pattern) transitioned later, after Google had verified the mobile site contained the right content. Sites still without a usable mobile version were the last to be moved, sometimes years after the initial rollout.
In 2026, the migration is no longer ongoing. Every site Google indexes is being indexed mobile-first. The historical detail matters only for sites doing archaeology on their own historical performance data, where rankings may have shifted at the time their site transitioned.
What “mobile version” means in practice:
The way Google determines what counts as the mobile version depends on a site’s architecture. Three architectural patterns produce three different relationships to mobile-first indexing.
Responsive design. One set of HTML, one URL, CSS-driven layout adaptation. Googlebot fetches the same page mobile and desktop users get, just rendered through a mobile viewport. The content is identical across devices. Mobile-first indexing is functionally identical to any other indexing for these sites, since the mobile version is the only version that exists.
Dynamic serving. The same URL serves different HTML based on user-agent detection. A mobile user gets one version. A desktop user gets a different version. Googlebot crawls with a mobile user-agent and receives the mobile-targeted HTML. Sites using dynamic serving need the Vary: User-Agent HTTP header to signal that the content varies, which prevents intermediate caches from serving the wrong version. Content parity between the two versions matters more here, since Google only sees the mobile version directly.
Separate mobile URLs (m-dot pattern). The desktop version lives at example.com/page. The mobile version lives at m.example.com/page. Googlebot crawls the mobile URL via the <link rel="alternate"> declaration on the desktop page, paired with a canonical pointing back to the desktop URL from the mobile page. This pattern has been declining for years, since responsive design covers the same use case more simply.
For sites that started on m-dot architecture, mobile-first indexing exposed any content disparity between the two versions. A desktop page with extensive content and a mobile page with stripped-down content meant Google was now indexing the stripped-down version. The content that gave the desktop page its ranking strength wasn’t being read.
Content parity is the rule that matters:
The single most consequential rule of mobile-first indexing: the content on the mobile version is the content Google indexes. If something exists only on the desktop version, Google may not see it.
This breaks several patterns that were common in older mobile design:
Hidden content for mobile screen space. A common practice in older responsive design was to hide secondary content on mobile screens to reduce clutter. Sometimes this meant display: none on entire sections. Sometimes it meant accordion patterns where content was technically present but collapsed by default. Sometimes it meant separate mobile templates with less content than desktop equivalents.
Under mobile-first indexing, content hidden with display: none is still indexed if it’s in the HTML, but content removed from the mobile HTML entirely is not. The distinction matters for sites with separate mobile templates that genuinely strip content rather than just visually hide it.
Mobile-stripped navigation. Some sites collapse desktop navigation menus into mobile hamburger menus that contain a subset of the desktop links. The links inside hamburger menus get indexed, but links removed from mobile entirely don’t. A page only reachable from desktop navigation may have a harder time getting crawled if no mobile pathway exists.
Different headings and structured data. A site that uses different H1 tags, different schema markup, or different page titles between mobile and desktop versions confuses Google’s understanding of what each page is about. The mobile version’s headings and structured data are the ones Google reads, even if the desktop version’s are more comprehensive.
Different alt text. Mobile and desktop versions sometimes serve different image sets. If alt text is missing on the mobile version but present on desktop, the indexed page has no alt text. Image search results suffer accordingly.
The fix across all of these is content parity. The mobile version contains the same primary content, the same headings, the same structured data, the same alt text, the same internal linking structure as the desktop version. The visual presentation can differ. The substance shouldn’t.
Crawling and rendering, what Googlebot Mobile actually does:
Googlebot Mobile is the user-agent string Google uses when crawling pages for mobile-first indexing. The string identifies the crawler as a smartphone-class device and signals to the server which version of the page to serve.
The current Googlebot Mobile user-agent (subject to periodic updates):
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) 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)When Googlebot fetches a page, three stages happen. The initial fetch retrieves the HTML the server returns to a mobile user-agent. The render stage uses a headless Chrome environment to execute JavaScript and produce the final rendered DOM, the same way a real mobile browser would. The indexing stage extracts the content from the rendered page and adds it to Google’s index.
The rendering stage is the most consequential change from older indexing. Single-page applications, JavaScript-rendered content, and dynamic content that loads after initial HTML all get rendered before indexing. Content that depends on JavaScript execution is now indexable in a way it wasn’t a decade ago.
The trade-off is that rendering takes time. Pure HTML pages are crawled and indexed faster than JavaScript-heavy pages, since they skip the rendering step. For time-sensitive content, server-side rendering or static generation produces faster indexing than client-side rendering.
The mobile user-agent also affects which version of any user-agent-detected content Google receives. Cloaking (the practice of serving different content to crawlers than to users) gets detected when Googlebot’s mobile fetch returns different content than what a real mobile user would see. The protection against accidental cloaking is to serve the same content to both Googlebot and real mobile users, with no special handling for the crawler.
The signals Google uses to evaluate the mobile experience:
Beyond indexing what’s on the mobile version, Google evaluates whether the mobile experience itself is usable. Several signals contribute to this assessment.
Mobile-friendliness signals. Google’s algorithm continues to evaluate mobile-friendliness even though the dedicated Mobile Usability report in Search Console was retired in December 2023. Issues like content wider than screen, clickable elements too close together, viewport not configured, and text too small to read still affect ranking; the diagnostic just lives in Lighthouse and similar tools rather than in a Google-specific report. Sites with persistent mobile usability errors compete in mobile search results from a weaker position.
Core Web Vitals on mobile. Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint all get measured separately for mobile and desktop. The mobile measurements often differ from desktop measurements, since mobile devices have slower CPUs, smaller caches, and variable network conditions. Mobile-first indexing means the mobile Core Web Vitals are the ones that count for ranking. The Core Web Vitals piece covers the three metrics in depth.
Page experience signals broadly. HTTPS, no intrusive interstitials, mobile-friendly design, and Core Web Vitals together form the page experience ranking signal. Each component contributes, and the mobile measurements drive the signal.
Mobile-specific content quality. Content that renders correctly on mobile, loads quickly on cellular connections, and presents readably without zoom contributes to the page’s ranking strength. Mobile-friendly design that’s also mobile-poor in content quality (thin pages, missing context, stripped-down information) still ranks worse than mobile-friendly design with full content.
The chain of consequences. Mobile usability problems reduce ranking. Reduced ranking produces less traffic. Less traffic produces fewer user signals (clicks, dwell time, return visits) that contribute to further ranking. The cumulative effect compounds, which is why fixing mobile usability earlier produces stronger results than fixing it later.
The transition history, and what it left behind:
The mobile-first transition was largely uneventful for sites that had already migrated to responsive design. The mobile and desktop versions matched, so the change in indexing didn’t change what Google saw. Most modern sites fall into this category.
The transition was disruptive for sites that hadn’t migrated. Sites with separate mobile architecture often had content disparities the operators didn’t know about. Hidden mobile navigation, stripped mobile content, and missing mobile structured data all became visible problems once Google was indexing the mobile version directly. Some sites lost ranking position when the transition exposed gaps that desktop indexing had been masking.
The transition essentially failed for sites without a mobile version at all. Sites with no responsive design and no separate mobile site received Google’s lowest priority for migration, sometimes years after the initial rollout. Eventually, those sites were also moved to mobile-first indexing, with the desktop version serving as the substitute mobile version. The result for these sites was suboptimal: the desktop layout being evaluated as a mobile experience, with all the resulting mobile usability problems that follow.
What the transition left behind is a clearer landscape. Sites that survived and thrived have content parity between mobile and desktop, mobile-friendly design, and acceptable Core Web Vitals on mobile. Sites that survived without thriving have lingering mobile issues that limit their ranking ceiling. Sites that didn’t survive faced rankings collapse on whatever mobile-related weakness was hidden by the previous desktop-primary indexing.
Seven mobile-first indexing anti-patterns:
The trouble usually isn’t whether a site is mobile-friendly. It’s whether the mobile version carries the same content Google needs to index, and the same handful of gaps show up over and over.
- Content present on desktop but missing on mobile. Hidden sections, stripped templates, removed navigation links. Google indexes the mobile version, so the missing content isn’t indexed. Fix: establish content parity. The mobile version contains the same primary content as the desktop version, presented differently.
- Different structured data between mobile and desktop. Mobile pages have less detailed schema, or schema with different values, than desktop pages. Fix: generate structured data from the same source on both versions. Most CMS-driven sites already do this; sites with template forks need to audit.
- Mobile pages missing meta robots directives. Desktop pages have proper indexing controls; mobile pages lack them or have different ones. Fix: apply the same meta robots, canonical, and hreflang declarations on both versions.
- Slow mobile-specific resources. Mobile pages load extra scripts or stylesheets that desktop pages don’t, slowing the mobile version disproportionately. Fix: audit mobile resource loading. Remove or defer scripts that aren’t critical for mobile.
- Mobile rendering blocking on JavaScript. Content depends on JavaScript that takes longer to execute on mobile devices. Googlebot Mobile may time out before rendering completes. Fix: server-side render critical content. Defer non-essential JavaScript. Test rendering performance with the URL Inspection tool’s live test.
- Separate mobile URLs without correct alternate/canonical declarations. The m-dot site doesn’t properly declare its relationship to the desktop site, or canonicals point in the wrong direction. Fix: verify
<link rel="alternate">on desktop pages and<link rel="canonical">on mobile pages match the correct URLs. For new sites, migrate to responsive design.
- Mobile usability errors ignored in audits. Lighthouse and similar tools flag issues, but no one acts on them. With the dedicated Mobile Usability report retired, mobile diagnostic work has to be done deliberately rather than read off a single dashboard. Fix: include mobile-friendly audits in monthly site health reviews via Lighthouse. Fix flagged issues. Confirm fixes through revalidation.
An eighth pattern worth flagging: AMP pages without proper relationships. AMP pages exist alongside canonical mobile pages, but the relationship declarations are missing or wrong. Fix: with AMP’s reduced role in modern search, evaluate whether AMP is still worth maintaining for the site. If not, retire it. If yes, audit the declarations.
The page Google sees is the page the user sees:
Mobile-first indexing collapses what used to be two evaluations into one. The page Google reads, evaluates, ranks, and surfaces in search results is the same page the majority of users actually visit. Desktop and mobile aren’t competing for Google’s attention. The mobile version is the version, and the desktop view is a derivative experience for the minority of users who see it.
This perspective shift changes a lot about how to think about page work. The site’s strongest content, sharpest framing, and most useful structure all need to live on the mobile version, because that’s the version Google evaluates. The desktop version inherits the same content through responsive expansion, but it can’t add anything that affects ranking, since Google isn’t reading the desktop version directly.
The architectural implication is straightforward: design mobile-first, then expand. Write the mobile content first, then let larger screens spread it across columns or add secondary navigation. Choose responsive design over separate mobile architectures, since responsive guarantees content parity by structure. Use device emulation during development to confirm the mobile rendering matches what’s intended.
What’s left of the desktop-primary mental model is mostly residual habit. Site owners still sometimes think of the desktop layout as the “real” version of their site, with mobile as a constrained adaptation. Google’s indexing reversed that relationship years ago. The mobile rendering is the real version. The desktop rendering is the adaptation, optional and not directly indexed. Designing around that reversal produces sites that perform well across devices, since the constraint of mobile design forces clarity, while expanding for desktop is the easier addition. Designing around the older mental model produces sites that work on desktop and quietly fail on the version that actually counts.