Mobile-first indexing means Google crawls your pages with its smartphone crawler, indexes what that crawler sees, and ranks pages on that basis. The desktop version is not used. Since Google finished the switch between 2023 and 2024, this applies to every site, including sites that have no mobile design at all. The practical consequence is simple: anything that exists only in your desktop layout, whether text, links, images or structured data, does not exist for Google.
What changed and when
Before mobile-first indexing, Google crawled with a desktop user agent and ranked pages on the desktop version, then adjusted for mobile users. Google announced the change in 2016, started moving sites over in 2018, made it the default for new sites in 2019, and declared the migration essentially complete in late 2023. In 2024 it announced that the small set of remaining sites would also be crawled with Googlebot Smartphone, and that content which cannot be accessed on a mobile device at all would no longer be indexable.
There is still one index. "Mobile-first" describes which version of a page is used to populate it, not a second index for phones. Desktop searchers see results built from the mobile version too.
The crawler itself identifies as Googlebot Smartphone. Its user agent string contains an Android device name, "Mobile Safari" and the usual (compatible; Googlebot/2.1; +http://www.google.com/bot.html) token, so you can tell it apart from the desktop Googlebot in server logs.
What it changes in practice
| Area | What Google uses | What goes wrong |
|---|---|---|
| Main content | The mobile HTML, after rendering | Shortened or removed text on mobile means a thinner page in the index |
| Internal links | Links in the mobile version | Mobile menus that drop sections leave pages with no internal links |
| Images | Images in the mobile HTML, with their src and alt |
Lazy loading that only sets src on scroll leaves images invisible |
| Structured data | Markup in the mobile HTML | Schema added only to the desktop template is missing |
| Meta tags | Title, description, robots, canonical from the mobile version | A mobile template with a different canonical or a stray noindex |
| hreflang | Annotations in the mobile version | Separate m. sites that point to desktop alternates only |
| Videos | Video markup and placement on mobile | Videos pushed far down or removed on small screens |
For a responsive site where one HTML document serves every screen, most rows are a non-issue by construction. The HTML is the same; CSS just lays it out differently. Content that is hidden by CSS on small screens is still in the page and still indexed. Problems arrive when the mobile version is built from different HTML: separate m. URLs, dynamic serving that returns different markup by user agent, or JavaScript that renders a reduced version on narrow viewports.
How to check how Google crawls your site
Three places:
URL Inspection. Open Search Console, inspect any URL and expand Page indexing. The Crawled as line reads "Googlebot smartphone" (the normal case today) or "Googlebot desktop". A live test uses the same crawler type as the last indexed crawl.
The URL Inspection API. The response contains crawledAs with the value MOBILE or DESKTOP, next to lastCrawlTime, pageFetchState and the rest. Useful when you want the answer for a list of URLs rather than one at a time; the URL Inspection tool guide covers both the UI and the API.
The Crawl stats report. Under Settings > Crawl stats > Open report, the By Googlebot type breakdown shows how many requests came from Smartphone, Desktop, Image, Video and other agent types over the last 90 days. A healthy site shows the large majority under Smartphone, with Desktop requests for a small sample that Google keeps for comparison.
Your own server logs tell the same story if you filter on the user agent strings and verify the IP addresses against Google's published ranges.
The failures that come up most often
Links that exist only in the desktop menu
A desktop header shows twelve top-level sections with dropdowns; the mobile hamburger menu shows five. Every page reachable only through the missing seven loses its internal links in Google's eyes and drifts towards "Discovered - currently not indexed" or drops out. Check with a crawler set to a mobile user agent, or simply open the mobile menu and count. Links in a collapsed menu are fine as long as they are in the HTML.
Content loaded on click
Tabs, accordions and "read more" sections that fetch their content with a request when tapped are empty at crawl time. Google renders pages, but it does not tap. Put the content in the HTML and hide it with CSS, or render it on the server. Collapsed content in the HTML is indexed normally. The rendering side of this is covered in JavaScript SEO: rendering and indexing.
Lazy loading that never fires
Image lazy loading triggered by scroll events does not fire for a crawler that does not scroll. Use the native loading="lazy" attribute, or an IntersectionObserver implementation, and keep a real src or a <noscript> fallback. The same applies to infinite scroll: Google needs paginated URLs it can request.
Resources blocked for the mobile crawler
A robots.txt rule or a firewall rule that blocks CSS, JavaScript or an API endpoint for Googlebot Smartphone leaves the rendered mobile page incomplete. Run Test live URL, then View tested page > More info > Page resources and look for anything marked blocked or failed.
Separate mobile sites with broken annotations
Sites with m.yoursite.com need two things on every page pair: the desktop page carries <link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.yoursite.com/page"> and the mobile page carries <link rel="canonical" href="https://www.yoursite.com/page">. Missing pairs, mobile pages that are missing altogether, or user agent redirects that send Googlebot Smartphone to the mobile home page instead of the equivalent page all cause the wrong content to be indexed, or none.
Structured data and meta tags that differ
The mobile template was built later and never got the product schema, or carries a different canonical, or a noindex from a staging setup. Compare the two versions with the structured data viewer and the indexability checker, requesting each with a mobile and a desktop user agent where your setup serves different HTML. For responsive sites one pass is enough.
Slower responses on mobile pages
Dynamic serving stacks sometimes do extra work for mobile requests. If the mobile version times out or returns 5xx under load, those errors now affect indexing directly, where before they affected only mobile visitors. Watch the Crawl stats report's response breakdown and your logs. Speed itself is a ranking consideration through Core Web Vitals rather than an indexing one; Core Web Vitals and indexing separates the two.
What mobile-first indexing does not mean
- It does not mean desktop users get a different page. They get the same page; only the crawl and index are based on the mobile version.
- It is not a ranking boost for mobile-friendly sites by itself. Page experience signals are separate.
- It does not require AMP or a mobile app.
- It does not change how Google treats a responsive site that already serves identical HTML to every device, apart from which user agent appears in your logs.
A short check for your own site
- Inspect three pages of different types and confirm Crawled as says Googlebot smartphone.
- On a phone, or in a browser with a narrow viewport, open the navigation and confirm every section is reachable.
- Run a live test on a content-heavy page and search the rendered HTML for a sentence from deep in the body.
- Check that images in the rendered HTML have real
srcattributes. - Compare structured data and meta tags between mobile and desktop if your server varies the HTML by user agent.
- If you run separate m. URLs, sample ten page pairs and confirm the alternate and canonical links both exist.
If every item passes, mobile-first indexing is already working for you and there is nothing to change. If you want the per-URL results from step 1 for a whole sitemap rather than three pages, TurboIndex checks every sitemap URL through the URL Inspection API after submission and keeps Google's answer next to each one.
Frequently asked questions
- What does mobile-first indexing mean?
- Google crawls and indexes the mobile version of a page, using its smartphone crawler, and uses that version for ranking. What the desktop version shows does not matter unless the same content is also present on mobile. There is one index, not a separate mobile index.
- Is mobile-first indexing finished?
- Yes. Google finished moving sites between 2023 and 2024 and announced that the few remaining sites would also be crawled with Googlebot Smartphone, and that content which cannot be accessed on a mobile device would no longer be indexable.
- How do I check if Google crawls my site as mobile?
- Inspect a URL in Search Console and look at Crawled as in the Page indexing section: it says Googlebot smartphone or Googlebot desktop. The URL Inspection API returns the same thing in the crawledAs field, and the Crawl stats report breaks requests down by Googlebot type.
- Does my desktop content still count?
- Only if it is also in the mobile version. Text, links, images and structured data that exist only in the desktop layout are not seen by Google. Content that is in the mobile HTML but visually collapsed behind a tab or accordion is fine, because it is in the page.
- Do I need a separate mobile site?
- No. Google recommends responsive design, where one URL serves every screen. Separate m. URLs still work if the alternate and canonical annotations are correct, but they double the maintenance and are the most common source of mobile-first problems.