Mobile-first indexing is done. What still breaks

What survives to the mobile render is what gets indexed — everything else is invisible.

What is mobile-first indexing, and is it still happening?

Mobile-first indexing is Google using the mobile version of a page as the version it crawls, indexes and ranks. That is the whole definition, and it is one chapter of our wider SEO guide.

It is finished. Google announced in October 2023 that the move was complete for every site. There is no switch left to wait for, no migration date to plan around, and no "are we on mobile-first yet?" question to answer.

Google's Googlebot documentation, last updated in February 2026, says Search "primarily indexes the mobile version" of content for most sites, and that the mobile crawler makes most of Googlebot's requests. Google also still publishes guidance under this exact name — its mobile-first indexing best practices page was last updated in December 2025 — so the topic is maintained, just settled.

One boundary before we go on: the marketing side of mobile lives in mobile marketing. This page is strictly about what gets indexed.

The one rule that still matters: content parity

Content parity means the mobile version of a page carries the same primary content, headings, links, metadata and structured data as the desktop version. It matters for one reason: Google indexes the mobile page. If the desktop page has something the mobile page does not, Google works from the version without it.

Google's own wording in the mobile-first indexing best practices is blunt: "Make sure that your mobile site contains the same content as your desktop site."

Responsive design mostly gives you parity for free, because there is one HTML document for both. The breakages come from three setups:

• Separate mobile URLs (an m. subdomain) — two templates that drift apart over time.
• Dynamic serving — the server sends different HTML based on the device.
• Responsive templates that conditionally render less on small screens. This is the common one in 2026, and the easiest to miss, because the page looks fine on a phone.

Where mobile parity breaks on real sites

Every row below is a gap we have seen cause real indexing loss, mapped to what Google's documentation says about it.

Three of those rows have their own deeper pages on this site: schema markup for structured data, image SEO for alt text and image files, and writing meta descriptions for the metadata. The missing-links row is the one people underrate — see internal linking and orphan pages.

Are tabs and accordions a problem?

No — as long as the content sits in the HTML. Google's mobile guidance actively suggests "moving content into accordions or tabs to save space" on small screens. Collapsed is not hidden, in indexing terms.

The line that matters is a different one. Google's same page says: "Don't lazy-load primary content upon user interaction," because Google will not swipe, click or type to make content appear.

So the distinction is collapsed versus not yet loaded:

• Collapsed and present: an accordion whose answer text is already in the HTML and just styled shut. Indexed normally.
• Absent until interaction: a tab that fires a request when tapped, or a "read more" that injects text on click. Not indexed, because the tap never happens.

You can tell the two apart in thirty seconds. Copy a sentence from inside the accordion, open the page's crawled HTML, and search for it. If the sentence is there, you are fine. If it is not, Google never saw it.

The mobile parity checklist to run this week

From our own audits: when we run a technical audit at Digital Hangover, the mobile parity check is a side-by-side comparison of two things — the HTML Google actually crawled (Search Console → URL Inspection → View crawled page) and the desktop render of the same URL. We compare four lists: headings, in-body links, structured data types, and the title plus meta description. The two gaps we find most often are internal links that exist in the desktop footer or sidebar but not in the mobile template, and FAQ or specification blocks that the theme loads on tap. Neither one shows up in a visual check on a phone — because on a phone, you tap.

Run this on your five most important pages:

1. Confirm the crawl device. In Search Console, inspect the URL and check that the crawl was done by the smartphone crawler.
2. Search the crawled HTML for three sentences — one from the intro, one from mid-page, one from inside a tab or accordion. All three should be present.
3. Count the in-body links in the mobile version against the desktop version. A large drop means lost crawl paths.
4. Compare structured data types on both versions. Google names Breadcrumb, Product and VideoObject as the ones to fix first.
5. Check the title element and meta description match across versions, character for character.
6. Spot-check alt text on the main images. Mobile-specific image components often ship without it.
7. Check robots.txt is not blocking the CSS, JS or image paths the mobile template needs to render.
8. If you serve separate mobile URLs, confirm the status codes match and that no group of desktop pages redirects to one mobile URL.

This is also the check to run before a relaunch goes live, not after. Mobile parity is one of the most common things a redesign quietly breaks — more on that in website redesign SEO.

What is not a mobile indexing problem

Plenty of worry on this topic is misplaced. These are fine:

• Responsive design that reflows or stacks content. One HTML document means parity by default.
• Content inside tabs, accordions or a hamburger menu — provided it is in the HTML.
• Not having been "switched" to mobile-first. Every site already has been. There is no queue.
• Failing the old mobile-friendly test. That tool no longer exists.
• Desktop pages still ranking. Google indexes the mobile version and serves it to everyone; desktop searchers are not excluded.
• Mobile and desktop positions differing for the same query. That is normal result variation, not an indexing fault.

Which tools to use now the mobile reports are gone

Google retired the Mobile-Friendly Test, the Mobile-Friendly Test API and the Search Console Mobile Usability report in December 2023, pointing people to Lighthouse in Chrome instead. Google's own announcement page for the old tool now carries a one-line retirement note. If an agency still sends you a mobile-friendly test screenshot, that is a dated deliverable.

Note what is not on this page: speed metrics. Mobile indexing and mobile speed are different jobs. The thresholds and diagnosis live in our Core Web Vitals guide, and the fixes in page speed optimisation. For the wider technical checklist this sits inside, see technical SEO, and for the page-level work, on-page SEO.

What getting mobile parity right gives you

A parity fix is unusually cheap compared with most SEO work. You are not creating content. You are making content Google already crawls visible to it.

That means the pages you already have start competing on everything they contain, rather than on the subset your mobile template chose to render. Deep pages get crawl paths back. Rich results that were silently missing become eligible again.

Expect organic movement on the normal timeline — meaningful change in roughly three to six months, compounding after that. The parity audit itself takes an afternoon.