Mobile-First Indexing: What Google Requires

Mobile-first indexing means that Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking. A mobile version is not required to appear in Search, but it is very strongly recommended. The main practical point: if the mobile version has less content than the desktop one, Google gets less information about the page. Below: what exactly the Google guide for mobile sites requires, which checks to run and which popular claims (“only the mobile version since 2023”, “display:none weighs less”, “Mobile-Friendly Test”) are not confirmed by the guide or no longer work.

Three ways to build a mobile site

• Responsive design — the same HTML on the same URL for all devices; display depends on screen size. Google recommends it as the easiest to implement and maintain. Content and metadata are then the same.
• Dynamic serving — one URL but different HTML for different devices; it relies on user-agent sniffing and the Vary: user-agent header.
• Separate URLs — different HTML on different URLs (for example m.example.com); it also relies on user agents and redirects.

The recommendations below mostly concern dynamic serving and separate URLs: with responsive design the content and metadata are the same anyway.

What to check

Access and rendering

• The mobile and desktop versions should have the same robots meta tags: if the mobile one has noindex or nofollow, Google may fail to crawl and index the page (robots.txt and meta robots).
• Don’t load primary content upon user interaction. Google does not perform actions (swiping, clicking, typing), so such content will not load (lazy loading, JavaScript SEO).
• Resources with different URLs on the mobile version must not be blocked by a robots.txt disallow rule.

Content

• The mobile version should have the same primary content. Even with equivalent content, differences in DOM or layout can lead to a different understanding of the page; equivalent content lets the two versions rank for the same queries.
• A different design is fine: for example, moving text into accordions or tabs. The guide advises moving content there rather than removing it; but it must stay equivalent. If you deliberately shorten the mobile page, expect some traffic loss.
• Headings on the mobile version are as clear and meaningful as on the desktop one.

Markup and metadata

• The same structured data on both versions. If you must prioritize, start with Breadcrumb, Product and VideoObject (structured data). URLs in the mobile version’s markup must be mobile URLs.
• The same title and meta description on both versions.

Images, videos, ads

• Images — high quality, in a supported format, with stable URLs and the same alt text, captions and file names (image search). Different image URLs on the mobile version can cause a temporary loss of image traffic.
• Videos — with stable URLs, in supported tags, with the same markup (video in search).
• Ads must not harm the mobile page: follow the Better Ads Standard and don’t fill the top of the screen with ads.

If you have separate URLs

1. The error status is the same on both versions: if the desktop page serves content and the mobile one an error, the page will be missing from the index.
2. Mobile URLs have no fragments (#).
3. Every desktop page has an equivalent mobile page; if different URLs redirect to one (for example the home page), they will be missing from the index.
4. Both versions are verified in Search Console; a data shift is possible at the switch.
5. Hreflang: mobile URLs link to mobile URLs, desktop ones to desktop ones.
6. The mobile server can cope with a possible increase in crawl rate; robots.txt rules work as intended on both versions.
7. The desktop URL is always the canonical, and the mobile one is its alternate (rel="alternate" with media on the desktop page, rel="canonical" on the mobile one; the canonical tag).

How to check now

The old Mobile-Friendly Test no longer works: its address now leads to the Lighthouse documentation (checked 03.10.2026). To check rendering and quality use Lighthouse and the browser’s developer tools, and to see how Google sees the page, the URL Inspection in Search Console. The speed of the mobile version is a separate topic (Core Web Vitals).

What is not in the guide

• “Only the mobile version since 2023” — the guide describes the principle without such a date.
• “Content hidden with CSS display:none counts with less weight” — the guide says nothing of the kind.
• A mobile version being mandatory: it says it is not required but very strongly recommended.

Checklist

1. Responsive design is chosen; with another option the rules for separate URLs or dynamic serving are met.
2. The mobile version has the same primary content, headings, title and meta description.
3. The same robots meta tags; primary content does not depend on user actions.
4. Structured data and alt text match on both versions.
5. Images and videos have stable URLs.
6. Both versions are verified in Search Console (if the URLs differ).

Mistakes

• Removing text, tables and markup from the mobile version “for compactness”.
• Setting noindex or nofollow only on the mobile version.
• Hiding primary content behind a user action.
• Redirecting different mobile URLs to one page.
• Checking a site only with a tool that no longer exists.

What next

Next comes voice search: it is also built on the same pages and data, so a complete mobile version is the foundation for it too.