Google Mobile-First Indexing in 2026: What It Means and How to Check Your Site

Google indexes the mobile version of your website. Not "prefers", not "also considers": the copy of each page that Googlebot Smartphone fetches and renders is the one that gets evaluated for ranking, and whatever exists only on the desktop version is, for ranking purposes, not there. That has been true for every site since Google finished the migration in 2023, and since July 2024 a site that cannot be loaded on a mobile device at all is no longer indexed.

This guide explains what mobile-first indexing is, how it got here, what it changes in practice, how to check exactly what Google sees, and the parity checklist that keeps a site safe.

What mobile-first indexing means

Google keeps one index. For each page it stores one version, and mobile-first indexing means that version is the one its smartphone crawler retrieved: the HTML as served to a mobile user agent, rendered with JavaScript on a simulated phone, with the images, structured data, links and meta tags present in that rendering.

Three consequences follow:

• Content parity is a ranking requirement. Text, headings, images, videos, structured data and internal links that appear only on desktop do not count. Content that is on the mobile page but collapsed behind a tab or accordion does count; hidden-by-default is fine, absent is not.
• Mobile performance is the performance Google measures. Core Web Vitals for the page-experience signal are assessed for mobile, and mobile is where Largest Contentful Paint and Interaction to Next Paint are hardest to keep in the green.
• Mobile crawlability is crawlability. If the mobile version blocks CSS or JavaScript, lazy-loads content that never renders without a scroll, or serves a different set of URLs, the crawler misses what a desktop crawl would have found.

For a responsive site that serves the same HTML to every device, mobile-first indexing changed nothing except which simulated device renders the page. For sites with a separate mobile site (m.example.com), dynamic serving (different HTML by user agent) or "mobile-lite" templates that trim content, it changed which version Google believes.

How it got here: the timeline

• November 2016. Google announces the mobile-first indexing experiment, after mobile searches overtook desktop.
• March 2018. The first sites are migrated, with notifications in Search Console.
• July 2019. Mobile-first indexing becomes the default for all new websites.
• 2020–2022. The remaining sites move in stages; Google delays the announced deadline twice for sites that were not ready.
• October 2023. Google announces that the rollout is complete and removes the "indexing crawler" indicator from Search Console: there is no longer a per-site status because every site is mobile-first.
• July 2024. Google states that after 5 July 2024 it will crawl and index with Googlebot Smartphone only, and that sites whose content is not accessible on a mobile device at all will not be indexed.

Along the way, Google retired the standalone Mobile-Friendly Test tool (December 2023) and the mobile usability report in Search Console; the guidance now points to Lighthouse, PageSpeed Insights and the Core Web Vitals report instead.

How Google evaluates the mobile version

Googlebot Smartphone fetches the page with a mobile user agent, renders it in a headless Chrome with a phone-sized viewport, and reads the rendered result. The evaluation is not a separate "mobile score"; it is the normal ranking process applied to that rendering. What it looks for:

Content. The primary content of the page in the rendered mobile HTML. Google has been explicit that reduced mobile content means reduced ranking inputs; the classic failure is a mobile template that drops the product description, the FAQ or the long-form article body to keep the page short.

Structured data. The same JSON-LD on both versions, with URLs in it pointing to the mobile-equivalent (for responsive sites, the same) URLs.

Meta and robots. Title, meta description, canonical, robots meta and hreflang must be present and equivalent on mobile. A mobile template with a generic title tag is a common regression.

Images and video. Same images, with alt text, on supported formats, at crawlable URLs (not data URIs or JavaScript-only carousels); the same video embeds with structured data if you rely on video results.

Links. Internal links in the mobile navigation and body. Mega-menus collapsed into a hamburger are fine as long as the links are in the HTML; menus injected only on tap are not.

Page experience. Mobile Core Web Vitals, HTTPS, and the absence of intrusive interstitials that cover the content on arrival.

Accessibility of the page itself. Not blocked by robots.txt for the mobile crawler, not requiring interaction to render, and returning the same status codes (a mobile version that 404s while desktop works is invisible).

How to check what Googlebot actually sees

Search Console, URL Inspection. Paste any URL. The result shows Crawled as: Googlebot smartphone, the last crawl date, and, under View crawled page, the rendered HTML, a screenshot and the resources that were blocked. Compare that HTML with your desktop page: if a section is missing, Google does not have it. This is the ground truth; everything else is an approximation.

Live test. The same tool's Test live URL renders the page now, which is how you confirm a fix before the next crawl.

Lighthouse or PageSpeed Insights, mobile. Both run on a simulated phone and show the rendered screenshot and the mobile Core Web Vitals. The Viewport and Tap targets audits catch the basics; the field data section shows what real mobile visitors experience.

Chrome DevTools device mode. Toggle the device toolbar, pick a phone, reload, and read the DOM. Anything you can only reveal by scrolling or tapping is something the crawler may not see.

A quick user-agent check shows whether the server itself serves different HTML to phones:

curl -s -A "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0 Mobile Safari/537.36" https://example.com/ | wc -c
curl -s -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0 Safari/537.36" https://example.com/ | wc -c

Very different sizes mean dynamic serving; then the mobile response is the one to audit.

The mobile parity checklist

1. Same primary content (text, headings, tables, FAQs) on mobile and desktop.
2. Same title tag, meta description, canonical, robots meta and hreflang.
3. Same structured data, validated on the mobile URL.
4. Same images and videos, with alt text, at crawlable URLs, in srcset or <picture> rather than JavaScript swapping.
5. Same internal links, present in the HTML even when the menu is collapsed.
6. No content that renders only after a scroll, tap or resize event.
7. CSS, JavaScript and image folders not blocked in robots.txt.
8. Same HTTP status codes for the same URLs across devices.
9. For separate mobile sites: rel="alternate" on desktop, rel="canonical" on mobile, matching URL pairs, and the mobile site verified in Search Console.
10. No intrusive interstitials that cover the content on arrival; cookie banners kept small.
11. Mobile Core Web Vitals in the green: LCP under 2.5 s, INP under 200 ms, CLS under 0.1 at the 75th percentile.
12. Viewport meta tag present; text readable and tap targets usable without zooming.

Common failures and their fixes

The trimmed mobile template. A CMS theme that hides the product description or the article body on small screens with display: none is still fine for Google (the text is in the HTML); one that omits it from the mobile markup is not. Fix: collapse, never remove.

Menus and content injected by JavaScript on interaction. Googlebot does not tap. Render the navigation and content in the HTML and use JavaScript to show or hide it.

Lazy loading that depends on scroll events. Native loading="lazy" on images is understood by the renderer; custom scripts that swap data-src only on scroll are not. Use the native attribute, or an IntersectionObserver implementation that Google's renderer triggers.

A "View desktop site" link as a substitute for content. Google evaluates the mobile page it was served, not the one the user could switch to.

Separate mobile site drifting from desktop. Different content, missing annotations, or redirects that send mobile users to the homepage instead of the equivalent page. The durable fix is one responsive site.

Blocking resources for mobile bots. A robots.txt rule left over from an old optimisation that disallows /assets/ or /wp-includes/ stops the renderer from producing the page as users see it.

Slow mobile pages. A page that passes on desktop and fails LCP on mobile is failing the version Google measures. The usual causes are a hero image sized for desktop, render-blocking scripts and a slow server; the Core Web Vitals guide walks through each.

Frequently asked questions

Does Google still use a desktop crawler? Googlebot Desktop still exists and is used for some verification crawls and specific cases, but indexing and ranking inputs come from the smartphone crawl. Serve the same content to both and it does not matter which one arrives.

Is there a mobile-first "penalty"? No. It is not a ranking factor that rewards or punishes; it is which version of your page gets evaluated. The penalty is self-inflicted when the mobile version is thinner than desktop.

How do I know if my site has moved to mobile-first indexing? Every site has, since October 2023. Search Console no longer shows a per-site status because there is nothing left to migrate.

Should I build a separate mobile site? No. One responsive site with the same HTML for every device is what Google recommends and what avoids every parity problem in this guide.

What about desktop-only web apps? Pages behind a login are not indexed anyway. The public marketing pages of that app should still work on mobile, because those are what Google indexes and what prospects open from a phone.

Does the Mobile-Friendly Test still exist? It was retired in December 2023. Use Lighthouse or PageSpeed Insights for the technical checks and Search Console's URL Inspection for what Googlebot actually rendered.

Run URL Inspection on your five most important pages, compare the crawled mobile HTML with what a desktop visitor sees, and fix any difference. A free audit then checks the mobile viewport, tap targets, text readability and mobile Core Web Vitals across your key pages in one run.