Mobile-first indexing: what must match between mobile and desktop, and how to check it

What mobile-first indexing means

Google's documentation defines it in two sentences: “Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking. This is called mobile-first indexing.”

That smartphone agent is Googlebot Smartphone, described by Google as “a mobile crawler that simulates a user on a mobile device.” Its counterpart, Googlebot Desktop, still exists, but Google says that “the majority of Googlebot crawl requests will be made using the mobile crawler, and a minority using the desktop crawler.”

The practical consequence is simple. The page Google reads, understands and ranks is the one a phone receives. If your desktop page has a specifications table and your mobile page does not, Google ranks a page without a specifications table, even for searches made on a desktop computer.

Current status

The switch is finished. In October 2023 Google announced: “We're delighted to announce that the trek to Mobile First Indexing is now complete.” The same post summed up what that means for site owners: “a mobile web page now needed to be as complete as the corresponding desktop version.”

A small group of sites that do not work on mobile at all are the exception. For them Google wrote: “We'll continue to try to crawl these sites with our legacy desktop Googlebot crawler for the time being, and will re-evaluate the list a few times a year.” This is a fallback for broken sites, not an option you can choose.

What Google officially says

The same page adds a warning that goes beyond matching text: “Even with the equivalent content, differences in DOM or layout between desktop and mobile page can result in Google understanding the content differently.” Other rules from the page, each quoted directly:

• “Use the same robots meta tags on the mobile and desktop site.”
• “Don't lazy-load primary content upon user interaction.”
• “Use the same clear and meaningful headings on the mobile site as you do on the desktop site.”
• “Make sure that your mobile and desktop sites have the same structured data.”
• “Make sure that the mobile site has the same alt text for images as the desktop site.”
• “Use the same video structured data on both your mobile site and desktop site.”

The three mobile configurations

Google names three ways to build a mobile-friendly site. Which one you use decides how much parity work you have.

Responsive design

Google describes it as a setup that “Serves the same HTML code on the same URL regardless of the users' device (for example, desktop, tablet, mobile, non-visual browser), but can display the content differently based on the screen size.” And it is the one Google prefers: “Google recommends Responsive Web Design because it's the easiest design pattern to implement and maintain.”

Google also notes that “In case of responsive design, the content and the metadata are the same on the mobile and desktop version of the pages.” The remaining risk is in the front end: CSS that hides whole blocks on small screens, or JavaScript that does not load some sections on mobile.

Dynamic serving

Dynamic serving “Uses the same URL regardless of device. This configuration relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.”

Send the header on every response that can differ by device:

# Response header for https://example.com/shoes/
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Vary: User-Agent

The header tells caches and CDNs that the response depends on the device. Without it, a cache can store the mobile HTML and serve it to desktop visitors, or the other way round. The real risk with dynamic serving is not the header, though. It is the mobile template that slowly drifts away from the desktop one as each is edited separately.

Separate URLs

This setup “Serves different HTML to each device, and on separate URLs.” Usually that means m.example.com. Google adds: “Like dynamic serving, this configuration relies on the user-agent and Vary HTTP headers to redirect users to the device-appropriate version of the site.” It needs the most care, and it has its own set of rules, covered below.

The parity checklist: what must match

With dynamic serving or separate URLs, every item below has to be checked on each template. With responsive design, check the items that CSS or JavaScript can change on small screens.

Primary content

Google's rule is “Make sure that your mobile site contains the same content as your desktop site.” Design can differ: “You can have a different design on mobile to maximize user experience (for example, moving content into accordions or tabs); just make sure that the content is equivalent to the desktop site, since indexing on your site comes from the mobile site.”

If a thinner mobile page is a deliberate choice, Google warns that “you can expect some traffic loss when your site is enabled mobile-first indexing, since Google can't get as much information from your page as before.” Its alternative: “Instead of removing content, consider moving content into accordions or tabs to save space.”

Headings

“Use the same clear and meaningful headings on the mobile site as you do on the desktop site.” A mobile template that turns H2s into plain bold text, or drops section headings to save space, changes how the page's structure is understood.

Structured data

“Make sure that your mobile and desktop sites have the same structured data.” If your mobile template cannot carry everything at once, Google gives an order: “If you have to prioritize which types you add to your mobile site, start with Breadcrumb, Product, and VideoObject structured data.” On separate mobile URLs there is one more rule: “Make sure that URLs in the structured data on the mobile versions are updated to the mobile URLs.”

Title and meta description

“Make sure that the title element and the meta description are equivalent across both versions of your site.” Mobile templates sometimes ship a generic title such as Product | Example while the desktop template builds a full one. Google lists both “Missing page title” and “Missing meta description” among its mobile-first troubleshooting errors.

Images and alt text

Check that the important images are on the mobile page at all, then check the details:

• “Make sure that the mobile site has the same alt text for images as the desktop site.”
• “Don't use URLs that change every time the page loads for images.”
• Do not serve images on mobile that are too small or low resolution. Google lists “Low quality image” as an error.
• Use the same image URLs where you can. With separate image URLs, Google says you may see a temporary drop in image traffic, and “To avoid a temporary image traffic loss, use the same image URLs across both versions of your site.”

Video

Put videos in supported tags such as <video>, <embed> or <object>, and “Use the same video structured data on both your mobile site and desktop site.” Placement matters on a small screen too: “For example, it might harm the video's ranking if users need to scroll down too much to find the video on mobile page.”

Internal links and navigation

Google's page does not have a separate rule for links, but it follows from everything above: links are part of the content, and the mobile version is the one that is crawled. If your mobile menu, footer or related-products block is shorter than on desktop, Google finds fewer of your pages through those links. Make sure every page that matters is reachable through links that exist in the mobile HTML, and that the mobile menu is in the HTML rather than built only after a tap.

Robots meta tags and robots.txt

“If you use a different robots meta tag on the mobile site (especially the noindex or nofollow tags), Google may fail to crawl and index your page when your site is enabled for mobile-first indexing.” For robots.txt: “In most cases, use the same robots.txt rules for both mobile and desktop versions of your site.” Remember that you cannot write separate rules for the two crawlers: they “obey the same product token (user agent token) in robots.txt, and so you cannot selectively target either Googlebot Smartphone or Googlebot Desktop using robots.txt.”

Lazy-loading, tabs and accordions

Two Google rules cover this: “Don't lazy-load primary content upon user interaction.” and “Google won't load content that requires user interactions (for example, swiping, clicking, or typing) to load.” Google's lazy-loading guide puts it in one line: “Google Search does not interact with your page.”

That leads to a clear split:

For lazy-loading, Google's instruction is to “make sure that your lazy-loading implementation loads all relevant content whenever it is visible in the viewport.” Native lazy-loading for images and iframes, IntersectionObserver, or a library that loads content when it enters the viewport all meet this rule. Lazy-loading that waits for a scroll event or a click does not.

Extra rules for separate mobile URLs

If your site uses m.example.com, the rules above apply, plus a few that exist only for this setup.

Canonical and alternate

“The desktop URL is always the canonical, and the mobile version is the alternate of that URL.” Google's own example:

<!-- m.example.com/shoes/ -->
<link rel="canonical"
      href="https://m.example.com/shoes/">

<!-- example.com/shoes/ -->
<link rel="canonical"
      href="https://example.com/shoes/">
<!-- no rel="alternate" -->

<!-- m.example.com/shoes/ -->
<link rel="canonical"
      href="https://example.com/shoes/">

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

The other m-dot rules

1. One-to-one mapping. Each desktop page needs an equivalent mobile page. “If different URLs redirect to the same URL (for example, to the home page on mobile devices) after your domain is enabled for mobile-first indexing, all these pages will be missing from the index.”
2. Same status codes. “If a page on your desktop site serves normal contents and your mobile site's version of that page serves an error page, this page will be missing from the index.”
3. No fragments. “Make sure that your mobile version doesn't have URL fragments.” A mobile URL such as m.example.com/#/shoes is, according to Google, not indexable most of the time.
4. hreflang per version. “Your mobile URLs' hreflang must point to mobile URLs, and similarly desktop URL hreflang must point to desktop URLs.”
5. Both versions in Search Console. Google recommends verifying both, so you see data and messages for each.
6. Server capacity. “Ensure that your mobile site has enough capacity to handle a potential increase in crawl rate on the mobile version of your site.”
7. robots.txt on both hosts. m.example.com has its own robots.txt. Check that it does not block pages, images, CSS or JavaScript that the desktop host allows.

If you are planning a redesign, moving from separate URLs to responsive design removes all of these rules at once. It is a migration in its own right: every m. URL needs a 301 to its equivalent main URL.

Sites without a mobile version

A mobile version is not mandatory: “While it's not required to have a mobile version of your pages to have your content included in Google's Search results, it is very strongly recommended.” A desktop-only page that loads on a phone is still crawled by Googlebot Smartphone and indexed from what it receives, which is the same HTML a desktop gets. You do not lose content; you lose usability for mobile visitors.

The real problem is a site that does not work on phones at all. Google described the error types it sees on such sites: “the page shows errors to all mobile users, that the mobile version of the site is blocked with robots.txt while the desktop version is allowed for crawling, or that all pages on the mobile site redirect to the homepage.” If any of these applies to you, fix it before anything else in this lesson.

Mobile usability basics

Indexing is about what Google can read. Usability is about whether people can use the page on a phone. A responsive page starts with the viewport meta tag; without it, phones render a shrunken desktop layout:

<meta name="viewport" content="width=device-width, initial-scale=1">

The other basics are standard practice: text readable without zooming, tap targets that are not crowded together, no horizontal scrolling, and no intrusive interstitials covering the content. Ads count too; Google advises following the Better Ads Standard on mobile, because large ads at the top of a small screen push the content out of view.

How to check your pages with URL Inspection

URL Inspection in Search Console shows the page the way Google fetched it. For a mobile-first check:

1. Inspect the URL and open the page indexing details. Under Crawled as you see the user agent type used for the crawl. For almost every site today it is Googlebot smartphone.
2. Click View crawled page to see the HTML Google has from the last crawl. Search it for the blocks you expect: the specs table, the reviews, the FAQ text, the structured data.
3. Run a live test to check the current version. “A screenshot of the rendered page is available only in a live test.” The screenshot shows what the smartphone crawler rendered, which quickly exposes missing sections or blocked CSS.
4. Check the rendered HTML in the live test for lazy-loaded content. If your images or video URLs appear in the src attribute of their elements, the lazy-loading works.
5. Compare with desktop. URL Inspection shows the mobile view, so open the desktop page yourself and compare headings, text, links, structured data, title, description and robots meta.

Outside Search Console, you can do the same comparison with any crawler or with Chrome DevTools device mode: fetch the same URL once with a smartphone user agent and once with a desktop one, then diff the results. With separate URLs, compare example.com/shoes/ with m.example.com/shoes/.

Common mistakes

Google's own troubleshooting list for mobile-first indexing is the best checklist of what goes wrong. Grouped:

• ✕Thinner mobile templateSpecs, reviews, FAQs or long descriptions removed on mobile. Google calls the result “Page quality issues” and “Missing image”.
• ✕Structured data only on desktop“Missing structured data”: the mobile page lacks markup the desktop page has.
• ✕Missing or generic titles and descriptions“Missing page title” and “Missing meta description” on the mobile template.
• ✕noindex or nofollow only on mobileA mobile template or plugin setting that adds robots rules the desktop page does not have.
• ✕Mobile pages or images blocked in robots.txtOften on a separate m. host with its own, forgotten robots.txt.
• ✕Images without alt text or in low resolution“Missing alt text” and “Low quality image” are separate errors in Google's list.
• ✕Content loaded on tapRead more buttons, tabs or carousels that fetch content only after an interaction.
• ✕Error pages on mobile only“Mobile URL is an error page” while the desktop URL returns normal content.
• ✕Many desktop pages, one mobile target“Duplicate mobile page target” and “Desktop site redirects to the mobile home page”: the affected pages drop out of the index.
• ✕Fragment URLs on mobile“Mobile URL has anchor fragment”, for example m.example.com/#/shoes.
• ✕Video hard to find or unsupported“Video issues”: unsupported format, placed far down the mobile page, or very slow to load.
• ✕Mobile host too weak“Hostload issues”: the mobile server cannot handle the crawl rate.

How to audit mobile parity step by step

1. Identify your configuration: responsive, dynamic serving or separate URLs. For dynamic serving, confirm the Vary: User-Agent header; for separate URLs, confirm canonical and alternate tags in both directions.
2. List your templates: home, category, product, article, search, landing pages. Pick a few URLs per template.
3. Fetch each URL as a smartphone and as a desktop with a crawler or Chrome DevTools device mode.
4. Diff the two versions: word count, headings, internal links, structured data, title, meta description, robots meta, images and alt text, video.
5. Check robots.txt on every host, and confirm mobile pages, images, CSS and JavaScript are crawlable.
6. Check redirects and status codes: each desktop URL maps to its own mobile equivalent, and both return the same status.
7. Test interaction-dependent content: open tabs, accordions and Read more blocks and confirm their text is in the HTML before any click.
8. Run URL Inspection live tests on sample URLs: check Crawled as, the screenshot and the rendered HTML.
9. Run Lighthouse or PageSpeed Insights on mobile for usability: viewport, font size, tap targets.
10. Fix, then re-test the same URLs before rolling the fix out to the template.

FAQ

Sources

• Google Search Central — Mobile site and mobile-first indexing best practices
• Google Search Central Blog — Mobile-first indexing has landed (October 2023)
• Google Search Central — Googlebot
• Google Search Central — Fix lazy-loaded content
• Google Search Central Blog — The role of page experience in creating helpful content (April 2023)
• Google Search Console Help — URL Inspection tool

Quotes checked against the official pages on 30 October 2026.