Open any page you own on a phone. That rendered view, not the desktop layout you designed on a large monitor, is the version Google reads, evaluates, and ranks. Mobile-first indexing is Google’s policy of treating the mobile version of a page as the primary source for indexing and ranking. Despite the name, it isn’t about preferring mobile over desktop; it’s about Google standardizing on one version, the mobile one, as the canonical representation of every page.
The policy tracks how the web is actually used, since most searches and most page visits happen on mobile. A site that performs poorly on mobile performs poorly for most of its visitors, even if the desktop experience is polished. For most sites, though, mobile-first indexing is invisible: responsive design means the mobile and desktop versions are the same HTML rendered differently, so Google reads either one and gets the same content. The policy matters most for sites with structural differences between the two, where one version carries content or signals the other doesn’t.
The transition is finished, not ongoing #
This is the detail most older articles get wrong, so it’s worth stating plainly. Mobile-first indexing is complete for every site Google indexes. There is no site still being indexed desktop-first.
The shift began as a pilot in 2016 and rolled out in waves for years, with sites notified in Google Search Console as their indexing transitioned. In October 2023 Google published a Search Central blog post declaring the migration substantially complete, and the small remainder of sites still crawled by desktop Googlebot were moved to the mobile crawler after July 5, 2024 (Google Search Central, “Mobile-first indexing has landed,” 2023, and the follow-up July 2024 completion notice). At that point the crawler-selection setting was removed from Search Console, since there was nothing left to select.
The transition was never a single switch flipped on one date. Responsive sites went first, since mobile and desktop were already aligned. Sites with separate mobile architectures moved later, after Google verified the mobile site held the right content, and sites with no usable mobile version were last, eventually moved with the desktop layout standing in as the mobile version. If you’re auditing your own historical data, a ranking shift years ago may line up with the date your site transitioned. Going forward, none of that timing matters, because everything is now mobile-first.
What “mobile version” means for your architecture #
How Google decides what counts as the mobile version depends on how the site is built, and three patterns produce three relationships to mobile-first indexing.
Responsive design uses one set of HTML, one URL, and CSS-driven layout. Googlebot fetches the same page users get, rendered through a mobile viewport. Content is identical across devices, so mobile-first indexing is functionally the same as any other indexing here, and the mobile version is the only version that exists.
Dynamic serving uses the same URL but returns different HTML based on user-agent detection. Googlebot crawls with a mobile user-agent and receives the mobile-targeted HTML. Sites doing this need the Vary: User-Agent HTTP header to signal that content varies by device, which stops intermediate caches from serving the wrong version. Content parity matters more here, since Google sees only the mobile version directly.
Separate mobile URLs (the m-dot pattern) put desktop at example.com/page and mobile at m.example.com/page. Googlebot reaches the mobile URL through the <link rel="alternate"> declaration on the desktop page, paired with a canonical on the mobile page pointing back to desktop. The pattern has been declining for years, since responsive design covers the same need more simply, and for sites that started on m-dot, mobile-first indexing exposed every content gap: a rich desktop page paired with a stripped-down mobile page meant Google was now reading the stripped-down one.
Content parity is the rule that governs everything #
The single most consequential rule of mobile-first indexing is this: the content on the mobile version is the content Google indexes. If something exists only on desktop, Google may not see it.
That breaks several habits from older mobile design. Hiding secondary content on small screens was common practice, done through display: none, collapsed accordions, or thinner mobile templates. The distinction that matters now is where the content lives. Content hidden with display: none but still present in the HTML is indexed; content genuinely removed from the mobile HTML is not. Google’s own guidance adds a limit: don’t lazy-load primary content behind a user interaction such as a tap, swipe, or click, because Googlebot won’t perform that interaction and won’t see what it reveals. Content collapsed in a tab or accordion is safe only when it’s already in the rendered DOM.
The same logic applies to navigation. Sites that collapse desktop menus into mobile hamburger menus keep the links Google can crawl only if those links are in the mobile markup; a page reachable only from desktop navigation is harder to crawl. Headings, structured data, page titles, and alt text follow the rule too. If mobile uses different H1 tags, thinner schema, or omits alt text that desktop carries, the mobile version is what Google reads, and the fuller desktop version doesn’t count. The fix in every case is parity: the mobile version carries the same primary content, headings, structured data, alt text, and internal links as desktop. The visual presentation can differ. The substance shouldn’t.
What Googlebot Mobile actually does #
Googlebot Mobile is the user-agent Google uses when crawling for mobile-first indexing, identifying the crawler as a smartphone-class device so the server knows which version to serve. Its work runs in three stages: an initial fetch of the HTML the server returns to a mobile user-agent, a render stage that uses a headless Chrome environment to execute JavaScript and build the final DOM the way a real mobile browser would, and an indexing stage that extracts content from the rendered page.
Rendering is the consequential change from older indexing. Single-page applications, JavaScript-rendered content, and content that loads after the initial HTML all get rendered before indexing, so JavaScript-dependent content is now indexable in a way it wasn’t a decade ago. The trade-off is time: pure HTML pages are indexed faster than JavaScript-heavy pages because they skip rendering, so for time-sensitive content, server-side rendering or static generation indexes faster than client-side rendering. Serving the same content to Googlebot and to real mobile users is also the protection against accidental cloaking, since a gap between the crawler’s mobile fetch and what a real user sees can be flagged.
The mobile signals Google evaluates #
Beyond indexing what’s on the mobile version, Google assesses whether the mobile experience is usable. Mobile-friendliness still feeds ranking even though the dedicated Mobile Usability report in Search Console was retired in December 2023. Content wider than the screen, tap targets too close together, an unconfigured viewport, and text too small to read still matter; the diagnosis now lives in Lighthouse and similar tools rather than a Google-specific report.
Core Web Vitals are measured separately for mobile and desktop, and mobile figures often lag because phones have slower processors and variable networks. Under mobile-first indexing, the mobile Core Web Vitals are the ones that count. That metric set (Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint) is a separate topic covered elsewhere; here it’s enough to know the mobile measurement drives the signal, alongside HTTPS, the absence of intrusive interstitials, and mobile-friendly design.
How to check and fix your mobile version #
Work through the gaps that show up most often. Confirm content parity first: view the rendered mobile HTML and check that primary content, headings, structured data, and alt text match desktop, with nothing stripped from the mobile template. Apply the same meta robots, canonical, and hreflang declarations on both versions, since desktop indexing controls don’t carry over. Defer non-critical scripts so mobile isn’t slowed by resources desktop doesn’t load, and server-side render content that depends on heavy JavaScript, using the URL Inspection tool’s live test to confirm Googlebot renders it before timing out. Fold mobile-friendly checks into routine site health reviews through Lighthouse, then revalidate after fixing. If the site still runs separate mobile URLs, verify the <link rel="alternate"> on desktop and the canonical on mobile point at the correct URLs; for new builds, responsive design guarantees parity by structure.
The chain behind all of this is worth keeping in mind: mobile usability problems reduce ranking, reduced ranking cuts traffic, and less traffic means fewer engagement signals that feed back into ranking. The effect compounds, which is why fixing mobile issues earlier produces stronger results than fixing them later.
FAQ #
Is mobile-first indexing still rolling out?
No. Google completed the transition. The October 2023 announcement declared it substantially done, and the last desktop-crawled sites were moved to the mobile crawler after July 5, 2024. Every indexed site is now indexed mobile-first, and the crawler-selection setting has been removed from Search Console.
Does my desktop content still matter?
Only insofar as it appears on the mobile version. Google reads the mobile rendering, so content that lives only on desktop can go unread. Anything you need indexed has to be present in the mobile HTML.
Is content hidden in tabs or accordions indexed?
Yes, if it’s in the rendered DOM on load. Content collapsed visually but present in the HTML is indexed. Content that only loads after a tap, swipe, or click is not, because Googlebot won’t trigger that interaction.
Where did the Mobile Usability report go?
It was retired in December 2023. Mobile usability still affects ranking; the diagnostics moved to Lighthouse and similar tools rather than a dedicated Search Console report.
The mental shift is the real takeaway. The page Google reads, ranks, and surfaces is the same page most of your users visit. Design mobile-first, then expand: write the mobile content, then let larger screens spread it into columns or add secondary navigation. Choose responsive over separate mobile architectures, and use device emulation during development to confirm the mobile rendering matches your intent. The desktop layout is the derivative now, optional and not directly indexed, so start with the mobile version, because that’s the version that counts.