Google crawls and indexes your site with a smartphone user agent and a phone-sized viewport. Not a desktop, and not both: the mobile version of each page is the version Google indexes and ranks.
The implication is bigger than it sounds. If your mobile version is missing content, links, images or structured data that exist on desktop, Google works from the incomplete mobile view. A polished desktop experience is invisible to the crawler that counts.
Is your site already mobile-first?#
Yes. Google started mobile-first indexing in 2016, made it the default for new sites in July 2019, declared the switch complete in October 2023, and from 2024-07-05 stopped indexing sites that don't work on mobile devices at all. Search Console's old "Indexing crawler" line in Settings was removed in November 2023 because it no longer told you anything.
To see what Googlebot Smartphone sees, use URL Inspection → Test live URL → View tested page: it shows the rendered HTML, a screenshot and the crawler used.
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 primary text, headings, lists and tables must be present in the mobile HTML. Content collapsed into accordions or tabs for usability is fine: Google indexes it as long as it is in the DOM. The real failure is content that is never rendered on mobile, or loaded only after a tap or swipe.
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 a desktop layout component. Run the Rich Results Test with the smartphone crawler.
Meta tags#
<title>, meta description, <link rel="canonical"> and meta robots must match on both versions. Divergent meta between mobile and desktop is a signal conflict.
Internal links#
Navigation, contextual and footer links present on desktop must also be in the mobile DOM, even if collapsed into a hamburger menu. Google extracts links from the HTML whether or not CSS shows them; what it cannot follow are links that are removed from the mobile markup.
Images and video#
Use the same descriptive alt text on mobile, crawlable image URLs (not ones that change per session), and supported formats. Lazy-loaded media must load without user interaction, as covered in Image & Video SEO.
Responsive is the right answer#
There are three common patterns, in order of SEO friendliness:
| Pattern | What it means | Risk level |
|---|---|---|
| Responsive design | One URL, CSS adapts the layout | Lowest: same content, same signals, same URL |
| Dynamic serving | Same URL, server returns different HTML by user agent | Medium: requires a correct Vary: User-Agent header |
Separate m. URLs | Different URL for mobile visitors | Highest: bidirectional annotations required |
Responsive design is Google's 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/pageneeds<link rel="canonical" href="https://www.example.com/page">. - Every
www.example.com/pageneeds<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/page">. - If you redirect visitors between versions based on user agent, send
Vary: User-Agent.
Both versions also need the same content, structured data and hreflang (each pointing to its own version). If either side breaks, the two versions split signals and confuse the index. It is fragile at scale, which is why responsive is worth the migration.
AMP#
If you still run AMP pages: since 2026-07-01 Google Search sends users directly to the AMP pages on your own host, and Google removed its AMP Cache, viewer and signed-exchange guidance. Google says AMP content "will continue to rank just like any other web page", so AMP is neither a requirement nor a ranking advantage.
Mobile results look different too#
Since 2025-01-23 Google no longer shows breadcrumb trails in mobile results: the URL line shows just the domain. Desktop still shows breadcrumbs. Your title and the domain name carry more weight on a phone, so preview titles with the SERP preview tool.
Mobile Core Web Vitals#
Core Web Vitals are measured separately for mobile and desktop, and the mobile field data is what applies to mobile searches, which is where most traffic usually is. Phones have slower processors and less reliable networks, so mobile numbers are almost always worse than desktop. Don't be reassured by a good desktop report.
Check your mobile reality:
- Search Console → Core Web Vitals → Mobile (real-user data from CrUX)
- PageSpeed Insights, Mobile tab (field data plus a lab run)
- Chrome DevTools with a mobile CPU throttling preset and the Slow 4G network preset
Details and fixes are in Core Web Vitals.
Testing the mobile view#
| Tool | What to check |
|---|---|
| Search Console URL Inspection | Live render as Googlebot Smartphone, indexing status, detected canonical |
| Rich Results Test (smartphone) | Structured data on the mobile version |
| PageSpeed Insights (Mobile) | Field and lab performance on mobile |
| Chrome DevTools device emulation | Content and link visibility at a 375 to 390px viewport |
| Screaming Frog or Sitebulb with a smartphone user agent | Full crawl as Googlebot Smartphone, diffed against a desktop crawl |
Next: Duplicate Content, the closely related problem of multiple URLs serving the same content and how to resolve the signal conflict.