Mobile-First Indexing

Since 2019, Googlebot has shown up to your site on a smartphone. Not a desktop. Not both - just mobile. When it crawls your pages to decide how to rank them, it's using a mobile user agent and a simulated phone viewport.

The implication is more significant than it sounds: if your mobile version is missing content, links, images, or structured data that exists on your desktop version, Google ranks based on the incomplete mobile view. Your beautifully polished desktop experience is invisible to the crawler that actually counts.

Is your site already mobile-first?#

Almost certainly yes - Google completed the transition for all crawled sites by 2024. To confirm:

Go to GSC → Settings → Crawling. It will tell you whether your site is being indexed as mobile-first. You can also use URL Inspection → "Test Live URL" to see a screenshot of how Googlebot renders any page on mobile.

The parity checklist#

Mobile-first indexing doesn't mean your site must look identical on mobile and desktop. It means the content and signals must be equivalent. Work through this list:

Content#

All body text, headings, lists, and tables must be present in the mobile DOM. Hiding large sections with CSS display: none on mobile can work fine for layout - but if significant content is hidden, Googlebot may not count it.

Expanding accordions ("read more" toggles) are fine. Google can execute JavaScript and access accordion content. Just make sure it's actually in the HTML and not conditionally not rendered at all.

Structured data#

Every <script type="application/ld+json"> block on your desktop template should exist identically on mobile. A common failure: schema added only to the desktop layout component. Check both views in the Google Rich Results Test.

Meta tags#

<title>, <meta name="description">, <link rel="canonical">, and <meta name="robots"> must be identical on both versions. Divergent meta on mobile vs. desktop is a signal conflict.

Internal links#

Navigation links, contextual links, and footer links present on desktop need to be accessible on mobile - even if collapsed into a hamburger menu. Google follows hamburger menu links. What it can't follow are links removed from the mobile DOM entirely.

Images#

alt attributes and title attributes should be present in the mobile HTML. If your responsive image component serves smaller images on mobile without alt text, Google gets none of the relevance signal from those images.

Responsive is the right answer#

There are three common patterns, in order of SEO friendliness:

Responsive is the universal recommendation. It eliminates the parity problem by definition - there is only one version of the page.

If you're stuck with an m. subdomain#

You need a bidirectional annotation:

• Every m.example.com/page needs <link rel="canonical" href="https://www.example.com/page">
• Every www.example.com/page needs <link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/page">
• Desktop pages need a Vary: User-Agent response header

If either side of this annotation breaks, the two versions split link equity and confuse the index. It's fragile to maintain at scale - responsive removes all of this complexity.

Mobile CWV: the numbers that actually matter for ranking#

Core Web Vitals scores are measured separately for mobile and desktop in GSC. Since Google ranks based on the mobile crawl, the mobile CWV figures are the ones affecting your rankings.

Mobile devices have slower processors and varying network conditions, so mobile CWV scores are almost always worse than desktop. Don't be lulled into a false sense of security by good desktop scores.

Check your mobile reality:

• GSC → Core Web Vitals → Mobile tab (real user data from CrUX)
• PageSpeed Insights with "Mobile" selected (lab data)
• Chrome DevTools with CPU throttling set to 4x slowdown and network at Fast 3G

Testing the mobile view#

Next: Duplicate Content - the closely related problem of multiple URLs serving the same content and how to resolve the signal conflict.