Mobile-First Indexing Best Practices: A 2026 Checklist

Mobile-first indexing means Google uses the mobile version of your pages for indexing and ranking. The core mobile-first indexing best practices are simple: the mobile version must carry the same main content, titles, meta descriptions, robots tags, structured data, images and links as desktop, and Googlebot Smartphone must be able to fetch every resource it needs.

Most problems don't come from a missing mobile site. They come from a mobile version that quietly shows less: a collapsed product description that never loads, a "lite" template without breadcrumbs, or a noindex left on an m-dot subdomain. This guide covers what to check, how to test it and what to fix first.

What is mobile-first indexing, and does it still matter in 2026?

Yes. Mobile-first indexing is now the default way Google works: the smartphone crawler fetches your pages and the mobile content is what gets indexed. If something exists only on desktop, assume Google doesn't see it.

Google's Googlebot documentation states that "for most sites Google Search primarily indexes the mobile version of the content," and that the majority of crawl requests use the mobile crawler, with a minority from the desktop crawler. Both crawlers follow the same robots.txt rules, so you can't allow one and block the other there.

What this means in practice:

• Responsive sites (same HTML for every device) usually have little to fix, unless the theme hides or removes content at small widths.
• Dynamic serving (same URL, different HTML by user agent) needs a parity check, because the mobile HTML can drift from desktop over time.
• Separate mobile URLs (m.example.com) carry the most risk and have extra requirements, covered below.

Google's mobile-first indexing best practices page recommends responsive design as the easiest setup to maintain.

Mobile-first indexing best practices: the checklist

The checklist below summarizes Google's guidance, ordered by how badly each mistake can hurt you.

Keep the main content the same on mobile

Google's guidance is direct: make sure your mobile site contains the same content as your desktop site. You can reorganize it for small screens with accordions, tabs or a different order, but you shouldn't cut it, because indexing relies on the mobile content.

Watch for these common cuts:

• Long category descriptions or FAQ blocks removed "to save space"
• Breadcrumbs, related-product blocks or footer links dropped from the mobile template
• Shorter headings or a different H1 on mobile
• Reviews loaded only on desktop

Removing internal links on mobile is especially costly, because those links are part of how Google discovers and weighs your other pages.

Don't hide content behind interactions

Google says it won't load content that needs user interaction, such as swiping, clicking or typing, to appear. Content that is already in the HTML but visually collapsed in an accordion is fine. Content that is fetched from the server only after someone taps "Read more" is not.

If your mobile pages build content with JavaScript, test what Googlebot actually renders. Our guide to JavaScript SEO rendering problems explains how to compare raw HTML with rendered output.

Use the same robots meta tags

A different robots meta tag on mobile is one of the few mistakes that can remove a page from Google outright. Google warns that a noindex or nofollow on the mobile version means Google may fail to crawl and index the page. This happens most often on m-dot sites, staging copies of mobile templates and AMP leftovers.

Don't block resources Google needs

If your robots.txt blocks the CSS, JavaScript or image folders a page needs, Google can't render it the way a phone does. Keep Disallow rules away from assets that are essential to understanding the page. The robots.txt guide covers safe patterns and the mistakes we see most.

Match metadata and structured data

Titles and meta descriptions should be equivalent on both versions. Structured data should be the same too, and Google highlights Breadcrumb, Product and VideoObject markup as priorities. On separate mobile URLs, update the URLs inside the markup so they point to the mobile pages rather than desktop ones.

Treat images and video as content

Google's checklist for images on the mobile version:

• High-quality images at a sensible size, in supported formats
• The same alt text as desktop
• Stable image URLs that don't change on every page load
• Descriptive file names, titles and captions

Google also notes that if your mobile pages use different image URLs from desktop, you may see a temporary loss of image traffic while the new URLs are processed. For video, use supported formats in standard tags (<video>, <embed>, <object>), keep the same structured data and place the video where users don't have to scroll far to find it.

How do you test what Googlebot Smartphone sees?

Use the URL Inspection tool in Search Console, run a live test and check the screenshot and rendered HTML. Then compare the mobile version against desktop for content, links, meta tags and structured data.

A practical workflow:

1. Check the crawler. In URL Inspection, the user agent appears under Page availability > Crawled > Crawled as. For almost every site, it should say smartphone.
2. Run a live test. Click View tested page to see the screenshot and the rendered HTML. Search the HTML for a sentence from the bottom of your desktop page. If it's missing, Google doesn't index it.
3. Compare templates. Pick one URL per template (home, category, product, article, location page) and compare word count, headings, internal links and the number of structured data items between mobile and desktop.
4. Crawl as a smartphone. Set your crawler's user agent to a mobile one and look for noindex, missing titles, blocked resources and thinner pages across the whole site.
5. Check the logs. Server logs confirm that the smartphone crawler is getting 200 responses, not redirects or errors.

Lighthouse is useful here too: Google's page experience documentation points to it as a way to find improvements related to page experience, including mobile usability. If you'd rather not run these comparisons by hand, the free SEORecheck audit at /request renders your pages in a real browser and flags noindex tags, blocked resources, missing titles and text that appears only after JavaScript runs, with example URLs.

Separate mobile URLs (m-dot): what extra rules apply?

M-dot sites must keep a one-to-one mapping between desktop and mobile pages, use matching status codes and robots.txt rules, and point the mobile canonical to desktop. Hreflang must link mobile to mobile and desktop to desktop.

Google lists these extra requirements for separate URL setups:

• One mobile page for each desktop page. Don't redirect many desktop URLs to the mobile homepage.
• Same error status. If a desktop page returns 404, the mobile one should too, and the reverse.
• No fragment URLs. Mobile URLs that rely on # can't be indexed as separate pages.
• Both versions verified in Search Console.
• Matching robots.txt on both hosts.
• Server capacity for the extra crawling the mobile host will receive.
• Canonical and alternate tags: the mobile page points rel="canonical" to the desktop URL; the desktop page lists the mobile URL as an alternate.

<!-- On https://example.com/page (desktop) -->
<link rel="alternate" media="only screen and (max-width: 640px)"
      href="https://m.example.com/page">

<!-- On https://m.example.com/page (mobile) -->
<link rel="canonical" href="https://example.com/page">

If you also run several languages, the hreflang set on m-dot pages must point to the other mobile language versions, not to desktop ones. See the canonical tag guide for how canonicals interact with other signals.

If you're planning a redesign anyway, moving from m-dot to a responsive site removes this entire category of errors.

Do speed and mobile UX count for mobile-first indexing?

They're separate from indexing but still matter for ranking and users. Google says Core Web Vitals are used by its ranking systems, while other page experience aspects don't directly help a site rank higher.

From Google's page experience guidance:

• Core Web Vitals (LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 at the 75th percentile) are used by ranking systems, but good scores don't guarantee top rankings.
• There is no single page experience signal. Core ranking systems look at a variety of signals.

Mobile field data is usually worse than desktop, so check the mobile numbers first. Our Core Web Vitals guide explains how to read and fix them.

Avoid intrusive interstitials on mobile

Google describes intrusive interstitials and dialogs as elements that block the user's view of content, usually for promotion: full-page overlays, app install prompts and newsletter pop-ups that cover the main content. Small banners are the recommended alternative. Legally required interstitials, such as age gates, are an exception.

The mobile-first guidance also asks that ads follow the Better Ads Standard and don't take up too much of the top of the mobile page.

Keep pages within crawl limits

Google's Googlebot documentation currently says Googlebot processes up to 2 MB of a supported file type (uncompressed), and indexes only what it downloaded before the limit. Typical HTML pages are far below that. But pages with huge inline scripts or embedded data can push key content past the cutoff, so keep the main content high up in the HTML.

What should you fix first?

Fix issues that remove pages or content from the index first, then the ones that remove signals, then experience problems:

1. Mobile noindex, robots.txt blocks and error pages that only appear on mobile
2. Content, links or reviews missing from the mobile HTML, and content loaded only on interaction
3. Missing or different titles, meta descriptions and structured data
4. Image alt text, image URLs and video placement
5. Interstitials, ad density and Core Web Vitals

For a worked example of how findings are grouped by severity, with affected URLs, see the sample report.

Key takeaways

• Google indexes the mobile version of your pages, and most of its crawling uses the smartphone crawler.
• Content, links, metadata, robots tags and structured data must match desktop. Reorganizing is fine, removing is not.
• Content that loads only after a tap, swipe or typing isn't indexed.
• Never block CSS, JS or images that pages need to render.
• M-dot sites need one-to-one URL mapping, matching status codes, canonicals to desktop and mobile-to-mobile hreflang. Responsive design avoids all of this.
• Test with URL Inspection live tests and a smartphone crawl, then fix index-removing issues first.