Mobile-First Indexing — What It Means and How to Comply

Key Takeaways

All sites are now on mobile-first indexing — there is no opt-out; if you have a separate mobile site (m.dot), the mobile version is what Google primarily indexes and ranks; if your site is responsive (one URL, same content on all devices), you're compliant by default
The most common mobile-first indexing issue is content parity — the desktop page has full text content, structured data, and internal links, while the mobile version has truncated content in expandable tabs, missing schema, or fewer internal links; Google only sees the mobile version
Google's mobile Googlebot crawls all sites now but still renders JavaScript — SPA sites that rely on JavaScript for content rendering must ensure the mobile render delivers the same content as the desktop render; check the Rendered HTML in GSC URL Inspection
<meta name="viewport" content="width=device-width, initial-scale=1"> is a prerequisite — without a viewport meta tag, Google's mobile Googlebot may render your page at desktop width and misassess mobile usability
Lazy-loaded content (images and text that load only on scroll) is crawled by Googlebot if it uses standard lazy-loading (loading="lazy" or Intersection Observer); JavaScript-based content hidden in tabs or accordions IS indexed if it exists in the DOM — but content behind a non-progressive render (requires a user interaction to insert into DOM) may not be

How mobile-first indexing works

Google switched to mobile-first indexing because the majority of search queries now come from mobile devices. Showing desktop-optimised results to mobile searchers produced mismatched experiences — Google chose to index the version of the page that most searchers would actually see.

The switch means:

Googlebot Smartphone is Google's primary crawler (not Googlebot Desktop)
The mobile HTML is the source of truth for content, links, and structured data
Rankings are based on the mobile version of the page
Desktop pages are still indexed, but as a secondary signal

If you have a responsive site (one URL, adapts via CSS media queries) with the same content on all viewports: you're compliant. The same HTML is delivered regardless of viewport size.

If you have a separate mobile site (m.dot or dynamic serving): you need to verify that your mobile version has full content parity with the desktop version — same text, same structured data, same internal links, correct rel="alternate"/rel="canonical" annotations.

Checking your mobile indexing status

Three ways to verify:

1. GSC → Settings → Crawl stats. Shows which Googlebot type made the most crawl requests. A healthy site shows predominantly Googlebot Smartphone.

2. GSC → URL Inspection. For any URL, the "Crawled as" field shows whether Googlebot crawled the page as desktop or smartphone. Also shows the "Rendered page" — the HTML Googlebot actually processed. Compare this rendered HTML against your desktop HTML for content parity.

3. Google Mobile-Friendly Test (search.google.com/test/mobile-friendly): Tests a URL for mobile usability and shows the rendered screenshot from Googlebot's perspective.

Common mobile-first indexing issues

Issue 1: Content parity gaps. Desktop page has full article text; mobile version hides sections in collapsed accordions. On mobile, the accordion content exists in the DOM but may not be rendered in the initial view. Google crawls and indexes content in collapsed tabs and accordions IF it exists in the source HTML — but if it's loaded dynamically via JavaScript on interaction, it may be missed.

Fix: Ensure all primary content exists in the initial HTML response on mobile. Use CSS to collapse/expand, not JavaScript DOM insertion.

Issue 2: Missing structured data on mobile. Some CMS themes serve different templates for mobile, accidentally omitting the JSON-LD blocks that are present on desktop.

Fix: Validate structured data on the mobile URL using the Schema Markup Tester — confirm JSON-LD blocks are present in the mobile-rendered HTML.

Issue 3: Different metadata. Mobile version has a shorter title tag or different meta description (legacy mobile templates sometimes had truncated metadata).

Fix: Ensure title and meta description are identical across all responsive breakpoints — if using a single responsive template, this is automatic.

Issue 4: Missing viewport meta tag. Pages without <meta name="viewport"> are flagged as mobile-unfriendly; Googlebot renders them at desktop width.

Fix: Add <meta name="viewport" content="width=device-width, initial-scale=1"> to <head>.

Issue 5: Slow mobile TTFB. Mobile connections have higher latency than wired desktop connections. A server that responds in 200ms on desktop may deliver 800ms TTFB on a mobile connection due to latency.

Fix: Implement a CDN with edge caching to reduce origin-to-device roundtrip time. Check mobile-specific TTFB with the Page Speed Inspector (tests server response directly).

Images and lazy loading on mobile

Images that are lazy-loaded with loading="lazy" are crawled by Googlebot — it scrolls the page during rendering. This means lazy images in the body are indexed.

However:

Images that require user interaction (swipe, click) to appear may not be indexed
Images inside CSS background-image properties are not indexed (Google doesn't follow CSS background images as content images)
The LCP image should have loading="eager" — even on mobile, this is the most important image and should load immediately

LCP and lazy loading: Never apply loading="lazy" to your above-the-fold hero or LCP candidate image. Google's own guidance flags this as a Core Web Vitals anti-pattern — it delays the largest contentful paint, which directly impacts your CWV score.

AMP and mobile-first indexing

AMP pages are still indexed, but Google no longer requires AMP for the Top Stories carousel (as of 2021). If your site uses AMP, ensure the canonical AMP page and the standard page have content parity — Google uses the canonical page (not the AMP page) as the indexed version for most sites.

If you're running AMP solely for mobile speed, consider migrating to standard responsive HTML with a CDN and Core Web Vitals optimisation instead. AMP's maintenance overhead rarely justifies the benefit now that non-AMP pages can rank in Top Stories.

JavaScript-rendered content and mobile crawling

Googlebot renders JavaScript, but it does so in a second wave — typically hours or days after the initial crawl. Content that is only available after JavaScript executes may be indexed eventually, but it won't be as consistently crawled as server-rendered HTML.

For mobile-first indexing specifically:

Server-side rendered (SSR) or static HTML — fully crawled in the first pass, both desktop and mobile
Client-side rendered (CSR) single-page apps — content requires JavaScript execution; relies on Googlebot's rendering queue
Hybrid (SSR + hydration) — server HTML is indexed immediately; client-side enhancements picked up in rendering pass

If you use a JavaScript framework, check the "Rendered HTML" section in GSC URL Inspection. If the rendered HTML is significantly different from the source HTML, your content is being rendered client-side and depends on Googlebot's render queue for indexing.

Check your mobile render, not just your desktop render. GSC URL Inspection shows the rendered page as Googlebot saw it — but by default it uses the user agent that last crawled the page. If you want to specifically test the mobile render, use the Google Mobile-Friendly Test or trigger a new crawl request in GSC with Googlebot Smartphone.

Content parity checklist

For any page where mobile and desktop may differ — particularly m.dot sites, AMP pages, or CMS themes with separate mobile templates — run through this checklist:

Element	Must match on mobile	How to verify
Body text	Full article/page text, not truncated	GSC URL Inspection → Rendered HTML
Title tag	Identical to desktop	View Source on mobile UA
Meta description	Identical to desktop	View Source on mobile UA
JSON-LD structured data	All blocks present (BlogPosting, BreadcrumbList, etc.)	Schema Markup Tester on mobile URL
Internal links	Same links as desktop (navigation + body links)	Link Checker crawl with mobile UA
Canonical tag	Points to the canonical URL (www, HTTPS)	View Source on mobile UA
Images	Present with width/height attributes	Page Speed Inspector HTML audit
Viewport meta tag	`width=device-width, initial-scale=1`	View Source / Mobile-Friendly Test

Check Your Page's Mobile Performance and TTFB

Free, no signup. The Page Speed Inspector measures TTFB, DNS, TCP, TLS, and compression from the server — the same metrics that affect mobile Core Web Vitals scores — without requiring a browser or device.

Inspect Page Speed Free →

Sunny Pal Singh

Fellow · Technical Director — AI Infrastructure, Cloud Orchestration & Network Automation

Sunny is a Fellow and Technical Director specialising in AI infrastructure, cloud orchestration, and network automation. With hands-on depth across AWS, Azure, GCP, Red Hat OpenStack, and OpenShift, he leads high-performing teams of architects and engineers building transformative solutions at scale. He built ByteWaveNetwork to bring the same engineering rigour to everyday web tooling.

Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.