Google now crawls and indexes the web with its smartphone crawler, so the mobile version of each page is the version Google uses for ranking. Since July 2024, Google has said that sites not accessible on mobile devices will no longer be indexed. The practical requirement is parity: the mobile page must have the same main content, headings, structured data, metadata, images with alt text and internal links as the desktop page, loaded without requiring user interaction. This checklist covers what to verify.
Where things stand
- Google moved to mobile-first indexing over several years and completed the transition for the whole web.
- Google announced that from 5 July 2024 it would crawl with Googlebot Smartphone only, and that content not accessible on mobile would not be indexed.
- Search Console’s URL Inspection tool uses the smartphone crawler, so it shows what Google sees.
The parity checklist
| Check | Why it matters |
|---|---|
| Same main text on mobile and desktop | Content missing on mobile is not indexed |
| Same headings | Structure is read from the mobile version |
| Same structured data | Rich results depend on mobile markup |
| Same title and meta description | Used from the mobile page |
| Same images, with alt text | Image understanding comes from mobile |
| Same internal links, including navigation | Discovery and structure depend on them |
| Same robots meta tags | A noindex on mobile removes the page |
Common mobile problems
Content cut for mobile
Some themes hide sections, tables or long descriptions on small screens by not rendering them. Hiding with CSS for layout is fine if the content is in the HTML; removing it from the mobile HTML is not.
Content loaded only on tap or scroll
Googlebot does not tap buttons or scroll like a person. Content fetched only after a tap, such as “load more” or “read more” that requests new content, may not be seen. Put it in the HTML and show or hide it with CSS. See making tabs and accordions crawlable.
Lazy loading that needs interaction
Use native lazy loading (loading=”lazy”) or libraries that load images as they enter the viewport. Avoid lazy loading that waits for a click or a scroll event.
Separate mobile sites
Sites on a separate m-dot domain need full parity with the desktop site and correct rel=”alternate” and rel=”canonical” annotations. Many sites find a single responsive design simpler and safer.
Blocked resources
If robots.txt blocks CSS, JavaScript or images, Google may render the mobile page incorrectly.
How to test
- Run URL Inspection on key templates and view the tested page’s HTML and screenshot.
- Compare word counts, headings and links between mobile and desktop versions with a crawler that can switch user agents.
- Check the page on a real, mid-range Android phone. See mobile performance on low-end Android.
Mobile and AI crawlers
AI crawlers usually fetch pages without rendering and without a mobile layout, so they receive your server HTML. A responsive site that sends the same HTML to every device avoids differences between what Google, AI crawlers and users see.
Frequently asked questions
Is a responsive design required?
Not required, but Google recommends it as the easiest pattern to maintain, since there is one URL and one HTML for all devices.
Can we show less content on mobile for user experience?
You can collapse content into tabs or accordions, as long as it is in the HTML. Removing it means it will not be indexed.
Does mobile speed affect rankings?
Page experience, including Core Web Vitals measured on real devices, is one of many signals. Speed also directly affects whether mobile visitors stay.
Sources
- Google Search Central, “Mobile-first indexing best practices”
- Google Search Central blog, mobile-first indexing completion and the July 2024 announcement
- Google Search Central, “Lazy-loading content”