Mobile-First Indexing: Why Google Only Sees Your Mobile Page

Google indexes and ranks using the mobile version of your site, and only content present on the mobile page is used. That is the whole rule, and its consequence is blunt: anything you show desktop visitors but hide from mobile — a paragraph, a set of internal links, structured data, a meta description — is invisible to Google's index. Mobile-first indexing has been the default for all sites since Google completed the migration, so there is no desktop-first fallback to rely on. The task is not to build a mobile site; it is to guarantee your mobile page is a full peer of your desktop page.

What mobile-first indexing actually is

Mobile-first indexing means Googlebot crawls, renders, and indexes the version of a page it would fetch as a smartphone user agent, and that rendered mobile HTML is what enters the index. It does not mean mobile pages get a ranking boost, and it is separate from the mobile-friendly and Core Web Vitals signals that feed page experience. It is purely about which version Google reads. If your mobile and desktop pages differ, the mobile one wins by definition, and the desktop content you assumed was indexed may never have been.

The parity requirements

Google's guidance is that the mobile page must carry the same substance as the desktop page. Parity applies across six areas (handbook Ch.4):

• Primary content. The same main text, in full. Collapsing content into accordions or tabs to save screen space is fine — it is still in the HTML. Deleting content from the mobile page is not.
• Internal links. The same crawlable <a href> links. If your mobile navigation drops links that only appear in a desktop mega-menu, Google loses those discovery paths and the PageRank that flows through them.
• Metadata. The same <title> and meta description on both versions.
• Structured data. The same schema markup on mobile as desktop, with URLs in the markup pointing to mobile-accessible resources.
• Images and video. The same media, with the same alt text, and URLs Google can crawl on the mobile page.
• Robots directives. The same meta robots / X-Robots-Tag on both versions. A noindex that exists only on the mobile page will deindex the page.

Alongside parity, two technical requirements make the mobile page usable at all.

A viewport meta tag. Without <meta name="viewport" content="width=device-width, initial-scale=1">, the page renders at a desktop width on a phone, and Google may not treat it as mobile-ready.

Crawlable resources. Do not block the CSS and JavaScript the mobile page needs in robots.txt. Google's Web Rendering Service fetches every HTML-referenced resource to render the page; blocking them produces a broken render and can hide the very content you need indexed.

Responsive versus separate m-dot

There are three ways to serve mobile, and Google recommends the first.

Responsive design (recommended). One URL and one HTML document that adapts with CSS. The desktop and mobile content are the same document, so parity is automatic — there is nothing to keep in sync. This is why it is the lowest-risk configuration and the default advice.

Dynamic serving. The same URL returns different HTML depending on the user agent. This works, but you must send the Vary: User-Agent HTTP header so caches and Google know the response varies by device. Missing that header is a common, silent failure.

Separate mobile URLs (m-dot). A distinct m.example.com for mobile. This is the most fragile setup: it requires correct rel="canonical" from the mobile URL to the desktop URL and rel="alternate" from desktop to mobile, and every parity requirement must be maintained across two separate codebases. Most parity failures happen here. If you are on m-dot and can migrate to responsive, do so.

Common mobile-parity failures

These are the patterns that quietly remove content from Google's index:

• Content dropped on mobile. A "read more" that never loads the rest, or sections stripped from the mobile template. Google indexes only what is on mobile.
• Fewer links on mobile. A reduced mobile menu or footer cuts internal links, hurting discovery and link equity.
• Different title or meta description between versions, so the indexed snippet is not the one you optimized.
• Structured data present on desktop, missing on mobile — the rich-result eligibility silently disappears.
• A noindex or a conflicting robots directive on the mobile version that does not exist on desktop.
• A missing viewport tag, so the page is not treated as mobile-ready.
• Dynamic serving without Vary: User-Agent, so caching serves the wrong version.
• A broken mobile canonical on an m-dot setup, pointing to the wrong page or itself instead of the desktop equivalent.

How Crawlinx helps

Crawlinx fetches pages with both a desktop and a mobile user agent and compares the two, so parity gaps surface as specific findings rather than a vague warning.

• Missing viewport flags pages with no mobile viewport meta tag.
• Content mismatch and links mismatch catch primary content and internal links that differ between mobile and desktop.
• Meta mismatch and title mismatch flag metadata that diverges across versions.
• Robots mismatch surfaces a noindex/nofollow difference that would deindex the mobile page Google actually reads.
• Canonical mismatch detects a mobile canonical that disagrees with the desktop version — the classic m-dot trap.
• Structured data missing on mobile flags schema that exists on desktop but not mobile.
• No Vary header catches dynamic serving without Vary: User-Agent.

Takeaway

Because Google indexes the mobile version, your mobile page must be a full peer of the desktop page: same content, links, metadata, structured data, media, and robots directives, plus a viewport tag and crawlable resources. Responsive design removes the risk by keeping one document. If you serve mobile separately, every parity gap is a chance to hide content from the index — so audit both versions side by side and close the mismatches. For the surrounding page-experience signals, see the Core Web Vitals guide; for how rendering affects what Google sees, see JavaScript SEO and rendering.