Mobile-first indexing: parity checks that catch real problems

Mobile-first indexing means Google uses the mobile version of a page, as fetched by its smartphone crawler, for indexing and ranking. The desktop version is no longer the reference. For a fully responsive site that serves identical HTML to every device, nothing changes. For sites that serve different HTML, trim content on small screens, or load parts of the page only on desktop, anything missing from the mobile version is effectively invisible to Google.

The rollout finished years ago, so this is not news. What is still common is the gap: a mobile template quietly dropping a block of text, a set of internal links, or the structured data, often because a developer optimised for screen space without knowing the SEO consequence. This guide is a set of checks to find those gaps.

Which setup do you have?

Parity risk depends almost entirely on how the site serves mobile users.

Setup	How it works	Parity risk
Responsive design	Same URL, same HTML; CSS adapts the layout	Low. Only content removed or loaded conditionally by JavaScript can differ
Dynamic serving	Same URL; the server sends different HTML depending on the user agent	Medium to high. Two templates to keep in sync; needs the Vary: User-Agent header
Separate mobile URLs (m-dot)	Different URLs such as m.example.com, linked with rel=alternate and rel=canonical	High. Two sites, two sets of templates, annotations to maintain

If you are on dynamic serving or an m-dot site and have the chance to move to responsive design, that removes most of the problems below in one step. Moving off an m-dot site is a migration in its own right; the site migration checklist applies.

Check 1: main content

The most damaging gap is text that exists on desktop but not on mobile. Typical examples:

• Category descriptions shown on desktop and removed on mobile "to get to products faster".
• Long product specifications or reviews omitted from the mobile template.
• Article sections, FAQs or comparison tables replaced with a "view on desktop" link.

To check, fetch the page with a smartphone user agent and a desktop user agent and compare the visible text. A quick way with curl:

UA_M='Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)'
curl -s -A "$UA_M" https://example.com/page | sed 's/<[^>]*>//g' | wc -w
curl -s https://example.com/page | sed 's/<[^>]*>//g' | wc -w

This counts words in the raw HTML only, so treat a large difference as a prompt to look, not as proof. For JavaScript-heavy pages, use URL Inspection's live test in Search Console, which shows the rendered HTML Googlebot Smartphone sees.

Content hidden behind tabs, accordions or "read more" toggles is fine as long as it is in the page on load. Google has said such content is given full weight on mobile, where collapsing is a normal design choice. The problem is content that is not loaded at all until a user taps.

Check 2: internal links

Mobile navigation is often simplified: a hamburger menu with top-level sections only, no footer link blocks, fewer "related" links. Since Google discovers and weighs pages through the links on the mobile version, a link that exists only on desktop does not count. Crawl your site twice, once with a smartphone user agent and once with a desktop one, and compare the number of internal links per page and the set of pages reachable. Pages that are only reachable on desktop are effectively orphaned. The internal linking guide explains why that matters.

Also check that menu links are real anchor elements in the HTML. Mobile menus built entirely in JavaScript, which create the links only when the menu is opened, may hide the whole navigation from crawlers.

Check 3: metadata and structured data

Titles, meta descriptions, meta robots, canonicals and hreflang must be the same on both versions, or set up correctly for separate URLs. Mismatches are common on dynamic serving and m-dot sites:

• A noindex left on the mobile template, which removes the page entirely.
• Structured data (Product, Article, Breadcrumb, FAQ) present only in the desktop template. If the mobile version lacks it, the page loses rich result eligibility. See structured data and Open Graph.
• On m-dot sites, hreflang annotations that point mobile pages to desktop alternates in other languages, instead of mobile to mobile.

Check 4: images and video

Mobile templates sometimes swap images for smaller placeholders, use different URLs that change on every deploy, or lazy-load images in a way crawlers do not trigger. Make sure:

• Images use stable URLs and the same alt text on mobile.
• Lazy loading uses the native loading="lazy" attribute or a pattern that puts the real image URL in the HTML, not one that waits for a scroll event.
• Videos are embedded with supported markup on the mobile page, not replaced with a link.

The image SEO guide covers lazy loading and image formats in more detail.

Check 5: the mobile experience itself

Parity is about what Google sees. Rankings also depend on whether mobile users can actually use the page. A few things to check by hand on a real phone:

• The viewport tag. Without <meta name="viewport" content="width=device-width, initial-scale=1"> in the head, phones render the page at desktop width and shrink it, so text is tiny and every tap needs a zoom. It is one line, and its absence is the clearest sign that a template was never built for mobile. Do not disable zooming with maximum-scale=1 or user-scalable=no; it hurts accessibility.
• Intrusive interstitials. Full-screen pop-ups that cover the main content right after arriving from search are something Google has said can affect rankings. Cookie consent and age verification are treated differently from promotional overlays, but keep them compact.
• Tap targets and font size. Text that needs zooming and buttons too close together frustrate users, and that frustration shows up in engagement and conversions even if it is not a direct ranking signal.
• Layout shifts and responsiveness. Mobile Core Web Vitals are usually worse than desktop. The guides on CLS and INP cover the usual causes.

Server capacity and crawl

With dynamic serving or m-dot sites, the mobile version may run on different infrastructure. If it is slower or less reliable than desktop, crawling suffers, because Googlebot Smartphone does most of the fetching. Check response times in the Crawl Stats report and your logs filtered to the smartphone crawler, and make sure that rate limits and bot protection do not treat mobile user agents differently.

Confirming what Google actually sees

Your own comparisons tell you what the server sends. Search Console tells you what Google stored. Three places are worth checking for a handful of important pages:

• URL Inspection shows which crawler fetched the indexed version (it should say Googlebot smartphone) and lets you view the crawled HTML. Search the HTML for a sentence that only appears in the desktop version; if it is missing, so is that content in the index. The URL Inspection guide explains the fields.
• The live test renders the page as Googlebot Smartphone right now, including a screenshot. Use it after a fix to confirm the change, before waiting for a recrawl.
• Enhancement reports for structured data types. If the number of valid items dropped when a new mobile template went live, the markup was probably left out of it.

Do this for one page of each template type, not just the home page. Parity problems usually live in a single template, such as product pages or blog posts, while everything else is fine.

A quick parity checklist

Item	Same on mobile?
Main body text, headings, product details, reviews	Present in HTML on load
Internal links in navigation, breadcrumbs, related blocks	Same set, real anchors
Title, meta description, meta robots, canonical	Identical (or correctly paired for m-dot)
Structured data	Same types and values
hreflang	Present, pointing to equivalent versions
Images and alt text	Same images, crawlable lazy loading
robots.txt rules	Do not block resources the mobile page needs

The DeskSEO checker fetches pages the way a crawler does and reports title, canonical, robots directives and structured data from the HTML it receives, which is a fast way to spot a template that serves something different from what you see in the browser.