Mobile-First Indexing: What It Means for Your Site

Mobile-first indexing means Google uses the mobile version of your pages, crawled with its smartphone crawler, to index and rank your site. Since July 5, 2024, Google crawls every site for Search with Googlebot Smartphone, so content that can’t be reached on a phone can’t be indexed.

What is mobile-first indexing?

For most of Google’s history, its crawler behaved like a desktop browser. Mobile-first indexing flipped that. Google now fetches your pages as a smartphone, renders them as a smartphone, and uses what it finds there for indexing and ranking. In its best-practice guide (last updated December 10, 2025), Google describes this as using “the mobile version of a site’s content, crawled with the smartphone agent.”

Two clarifications help. First, Google says you don’t strictly need a mobile version to be included in Search, but it strongly recommends one. Second, mobile-first indexing is about which version of your content Google sees. Speed and usability on phones are related topics, covered in our Core Web Vitals guide, but they are not the same thing.

In practice, the question for any site is simple: does the mobile version contain everything you want Google to index? If a page, paragraph, link, image or piece of structured data exists only on desktop, assume Google doesn’t see it.

How did Google get here?

The shift took years. Google’s Search Central blog traces it from the 2015 mobile-friendly update through the start of mobile-first crawling in 2016, a gradual rollout from 2018, mobile-first indexing by default for new domains in 2019, and an announcement for the whole web in 2020.

On October 31, 2023, Google announced that “the trek to Mobile First Indexing is now complete.” It named the main problems on the small set of sites that still didn’t work on phones: pages that show errors to all mobile users, a mobile site blocked by robots.txt while desktop is allowed, and mobile pages that all redirect to the home page. At the same time, Search Console stopped showing which crawler indexed a site, because it no longer needed to.

The last step came in June 2024, when Google said the remaining desktop-crawled sites would be crawled with mobile Googlebot after July 5, 2024. Most sites didn’t need to do anything. For the rest, the consequence was simple: no mobile access, no indexing.

Which mobile setup should you use?

Google lists three ways to serve mobile users. Its recommendation is responsive web design, where every device gets the same HTML at the same URL and CSS adapts the layout. The other two still work, but they add places where mobile and desktop can drift apart.

Setup	How it works	What Google says	Extra work for SEO
Responsive design	Same URL, same HTML; layout adapts to screen size	Recommended. Content and metadata already match across devices	Lowest: one version to maintain
Dynamic serving	Same URL; server sends different HTML based on user agent	Supported; use the Vary: User-Agent header	Keep both HTML versions in step for content, metadata and structured data
Separate URLs (m-dot)	Different URLs per device, e.g. m.example.com	Supported, with extra rules for canonicals, alternates, hreflang and redirects	Highest: two sites to keep equivalent, verify and monitor

The web has largely made this decision already. In the HTTP Archive Web Almanac 2025 SEO chapter, the meta viewport tag (a basic marker of responsive design) appeared on 93.1% of desktop pages and 95.2% of mobile pages, and the authors describe the Vary: User-Agent header as “now nearly extinct”, used by only about 1% of pages.

What does “parity” mean in practice?

Parity means the mobile version carries the same things Google needs for indexing and ranking: the same primary content, headings, links, metadata, structured data and media. It doesn’t mean identical layout. Google explicitly says accordions and tabs are fine on mobile.

Across the web, the gaps are small but real. The Web Almanac found median home pages with 413 visible words on desktop and 378 on mobile, and JSON-LD on 39% of desktop inner pages against 37% on mobile. The authors suggest inner-page templates generated by a CMS can differ between desktop and mobile. On an individual site, a gap like that can mean a missing FAQ section, a hidden comparison table or product schema that only exists in the desktop template.

What to check	What Google asks for	Common failure
Primary content	The same primary content on mobile as on desktop	Shorter mobile copy; sections removed “to save space”
Headings	The same clear, meaningful headings	H2s replaced by unlabelled tabs or icons
Robots meta tags	The same tags on both versions	noindex or nofollow only on mobile templates
Lazy-loaded content	Don’t require swiping, clicking or typing to load primary content	Reviews or specs that load only after a tap
Resources	Don’t block CSS, JavaScript or images with disallow rules	Mobile asset paths blocked in robots.txt
Structured data	The same markup on both, with mobile URLs on mobile pages	Product, Breadcrumb or VideoObject missing on mobile
Titles and meta descriptions	Equivalent on both versions	Shortened or generic mobile titles
Images and video	Same alt text, captions and filenames; stable URLs; easy to find on mobile	Different image URLs on mobile, or video pushed far down the page

If your pages rely on JavaScript to build the mobile layout, check the rendered HTML, not the source. Our JavaScript SEO guide explains how Google renders pages, and our image SEO guide covers how to make images discoverable on any device.

Extra rules if you run separate mobile URLs

An m-dot site can still perform well, but Google’s guide adds a list of requirements that responsive sites never have to think about:

• Give every desktop page with distinct content an equivalent mobile page, rather than redirecting many URLs to one target.
• Return the same status for errors on both versions, and avoid URL fragments on mobile pages.
• Use rel="canonical" and rel="alternate" correctly: the desktop URL is the canonical, the desktop page points to the mobile alternate, and the mobile page points back to the desktop canonical.
• Keep hreflang separate for each version: mobile URLs point to mobile alternates and desktop URLs to desktop alternates (see our hreflang guide).
• Keep robots.txt rules consistent, verify both versions in Search Console, and make sure the mobile host can handle a higher crawl rate.

If you are planning a redesign anyway, moving from m-dot to responsive removes most of these failure points. Our technical SEO checklist before a redesign covers the checks to run before launch.

How to audit a site for mobile-first indexing

This seven-step process is how we check mobile parity during a technical audit. It works for any CMS.

1. Confirm your setup. Identify whether each template is responsive, dynamically served or on separate URLs. Mixed setups are common after partial redesigns.
2. Crawl twice and compare. Run a crawler with a smartphone user agent and again with a desktop user agent. Compare word counts, headings, internal links, titles, meta descriptions, canonicals and robots meta tags page by page.
3. Check what robots.txt blocks. Make sure no CSS, JavaScript, image or mobile-specific paths are disallowed.
4. Test interactive content. For tabs, accordions, carousels and “load more” buttons, confirm the content is in the rendered HTML without a tap or swipe.
5. Compare structured data. Validate the same markup types on mobile and desktop, and make sure mobile pages reference mobile URLs where they differ.
6. Check media. Confirm images and videos use the same URLs, alt text and captions across versions and aren’t buried at the bottom of mobile pages.
7. Watch how Google crawls. Google points to the Crawl stats report in Search Console to see how your site is currently being crawled. In server logs, expect Googlebot Smartphone to dominate, with occasional Googlebot Desktop requests.

Fix gaps in the mobile template rather than page by page. One template change usually closes hundreds of URL-level differences.

Frequently asked questions

Does Google still use Googlebot Desktop?

Rarely. Since July 5, 2024, Google crawls and indexes sites for Search with Googlebot Smartphone. Google says Googlebot Desktop may still appear in server logs, for example when crawling for product listings and Google for Jobs.

Do I need a separate mobile site?

No. Google recommends responsive web design, where every device gets the same HTML at the same URL. Dynamic serving and separate mobile URLs are still supported, but they need extra work to keep both versions equivalent.

Is it OK to put content in tabs or accordions on mobile?

Yes. Google’s best-practice guide says accordions and tabs are acceptable layouts on mobile. The content should be in the page when it loads, not fetched only after a user taps, swipes or types.

What happens if my site doesn’t work on mobile at all?

Google said in June 2024 that, after July 5, 2024, a site whose content is not accessible at all with a mobile device would no longer be indexable. Fixing mobile access is a precondition for appearing in Google Search.

Sources

1. Mobile site and mobile-first indexing best practices — Google Search Central, last updated Dec 10, 2025 — configurations, parity best practices, separate-URL rules, troubleshooting
2. Mobile-first indexing has landed — thanks for all your support — Google Search Central blog, John Mueller and Nir Kalush, Oct 31, 2023 — completion, remaining error types, Search Console change
3. Mobile-indexing vLast final final — Google Search Central blog, John Mueller, Jun 3, 2024 — July 5, 2024 switch to Googlebot Smartphone, Googlebot Desktop uses
4. Web Almanac 2025: SEO chapter — HTTP Archive, published Jan 15, 2026, last updated Jun 9, 2026 — viewport, Vary header, word count and structured data by device

Not sure whether Google sees the same site your desktop visitors do? Our technical SEO service includes a full mobile parity audit. Get in touch and we’ll tell you what we find.