Mobile-first indexing: what Google sees on your mobile site
·4 min read
Mobile first indexing means Google crawls your pages with its smartphone crawler and indexes and ranks the mobile version. If a paragraph, heading, link or block of structured data exists only on desktop, Google never sees it. The fix is parity, where the mobile page carries everything the desktop page does, even if it lays it out differently.
Responsive sites that serve one HTML document to every device are usually fine. The trouble shows up on sites that send phones different HTML, either through dynamic serving or a separate m. subdomain, and on sites where JavaScript builds different content per screen size.
What mobile-first indexing means today
Google finished the move on July 5, 2024. Its Search Central announcement said that after that date the last desktop-crawled sites would be crawled and indexed with only Googlebot Smartphone, and that a site whose content is not accessible at all with a mobile device would no longer be indexable. Googlebot Desktop still shows up in logs for a few specialized jobs, such as product listings and Google for Jobs.
So the desktop page is now a page for desktop visitors only. For ranking purposes, the mobile page is the page. If you want the background on how the crawler fetches and renders, read what Googlebot is and how it crawls.
Google's mobile-first indexing guide also says a mobile version is not required for inclusion in Search. A desktop-only layout that still loads on a phone gets indexed. It just serves phone users badly.
What parity means for mobile SEO
Parity means the mobile HTML gives Google the same signals as the desktop HTML. Google's guide lists what has to match.
| Signal | What Google asks for |
|---|---|
| Primary content | The same content on mobile as on desktop |
| Headings | The same clear, meaningful headings |
| Structured data | The same structured data on both versions |
| Title and meta description | Equivalent on both versions |
| Robots meta tags | The same tags, especially no stray noindex or nofollow |
| Images | The same alt text |
Design can differ. A mobile page can stack columns, shrink images and collapse sections. What it cannot do is drop the words, links and markup that the desktop page uses to rank.
Common mobile-first index mismatches
Most parity bugs come from a theme or template that treats phones as a place to trim.
Content in tabs is fine, removed content is not
Google's guide suggests moving content into accordions or tabs to save space on mobile. Collapsed content that is in the HTML counts. Content that a mobile template leaves out of the HTML does not exist as far as Google is concerned. "Read more" sections, comparison tables and FAQ blocks are the usual casualties.
Lazy loading that waits for a tap
Google's guide is direct about this. Do not lazy-load primary content upon user interaction, because Google won't load content that requires swiping, clicking or typing. A "Load more reviews" button that fetches text only after a tap hides that text from the index. Our post on JavaScript SEO covers rendering problems in more depth.
Separate m. sites with missing annotations
A separate mobile URL needs two links. The desktop page points to the mobile URL with rel="alternate", and the mobile page points back with rel="canonical". Google's guide says the desktop URL is always the canonical.
<!-- On https://example.com/page -->
<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/page">
<!-- On https://m.example.com/page -->
<link rel="canonical" href="https://example.com/page">Miss either one and Google may treat the pair as duplicates or index the wrong URL. If you are rebuilding anyway, move to responsive design and delete the problem.
A noindex that only phones get
This one is rare and painful. A mobile template, a plugin or an edge rule adds noindex to the mobile HTML while desktop stays indexable. Desktop checks look fine, Search Console shows "Excluded by noindex tag", and nobody can find the tag because they keep viewing source on a laptop.
How to check what Google sees on mobile
You check parity by fetching the page twice, once as a phone and once as a desktop browser, and comparing the HTML.
- Run the URL through Search Console's URL Inspection tool. It shows the crawled page as Googlebot Smartphone saw it.
- In Chrome DevTools, turn on device emulation, reload, and view the HTML. Compare word count, headings and the
<head>tags against the desktop load. - Diff the two responses with curl and two user agents if your server switches on them.
- Check whether the difference appears before or after JavaScript runs. Our guide to rendered source vs raw HTML shows how.
Check the template types that make money first. One product page, one article and one category page usually reveal a template-wide problem.
Compare your mobile and desktop pages
The Mobile Parity Checker fetches a URL with a mobile browser user agent and a desktop browser user agent and compares the HTML each returns. It checks main content word count, headings, structured data types, title, meta description, robots meta, canonical, internal links, images and their alt text, hreflang and the viewport tag. It also detects a separate mobile URL and tells you if the rel="alternate" or canonical annotation is missing, and flags dynamic serving that does not send Vary: User-Agent.
It does not render JavaScript, measure mobile speed or check visual layout and tap targets. It fetches with browser user agents, not as Googlebot, so it cannot see what Search Console reports. Each run costs 5 credits.