Mobile first indexing is complete. Google uses the mobile version of a page as the primary basis for indexing and ranking for effectively all sites, and has for some time.
The practical implication most teams have not fully absorbed: if content exists on desktop and not on mobile, it may as well not exist. The desktop version is not a fallback. It is not consulted.
Responsive Design Solves Most of This Automatically
A responsive site serves the same HTML to every device and adjusts presentation with CSS. Same content, same markup, different layout.
That architecture makes mobile first indexing a non issue for content parity, because there is only one version. It is why responsive is the recommended approach and why most sites built in the last decade have fewer mobile problems than the topic's prominence suggests.
Separate mobile sites on an m dot subdomain are the legacy problem case, requiring bidirectional annotation between versions and creating exactly the split covered in the subdomain guide. If you still run one, migrating to responsive is worth the project.
Where Responsive Sites Still Lose Content
Responsive does not guarantee parity, because CSS can hide things and JavaScript can load different content by viewport.
Display none on mobile. Content hidden with CSS is generally still in the HTML and still indexed, though Google has indicated hidden content may carry less weight. The larger risk is hiding it so thoroughly that it is removed from the DOM entirely.
Conditional loading by viewport. Where JavaScript loads a different component set on mobile, content genuinely absent from the mobile DOM is absent from indexing. This is the pattern that causes real losses and it is invisible in desktop testing.
Tabbed and accordion content. Present in the HTML and collapsed is fine. Fetched via JavaScript when the user taps is not, which is the situation covered in the rendering guide.
The check is straightforward: view source on a mobile viewport and confirm the content you care about is in the HTML rather than trusting that it appears when you interact.
Metadata Parity Is Frequently Broken
Titles, meta descriptions, and structured data must be present on the mobile version. Where a mobile template omits schema for performance reasons, that schema does not exist for indexing purposes.
This happens more often than teams realise because performance optimisation frequently strips markup from mobile templates deliberately. The schema guide covers what should be present, and the mobile specific point is that stripping it to save bytes removes the signal entirely.
Images and video need to be present on mobile too, with the same alt text. A gallery hidden on mobile removes those images from image search consideration.
Mobile Performance Is Where Core Web Vitals Fail
Reported pass rates put mobile origins around 48 percent against desktop around 56 percent. The gap exists because phones run slower processors on worse connections, and it matters because mobile is the version being scored.
Checking a blended Core Web Vitals figure conceals this. Filter to mobile in Search Console and treat that as the number, per the Core Web Vitals guide.
The mobile specific causes are predictable. Images sized for desktop viewports downloading in full on a phone. JavaScript bundles that a desktop processor handles and a mid range phone does not. Third party scripts whose cost is invisible on fast hardware.
Tap Targets and Viewport Configuration
Two mechanical requirements that Search Console previously reported explicitly and that still matter for usability.
Tap targets need enough size and spacing that a finger can hit them without hitting a neighbour. Links in a dense paragraph and stacked navigation items are the usual failures.
The viewport meta tag needs to be present and configured to the device width. Without it, mobile browsers render at desktop width and scale down, producing text nobody can read without zooming.
Neither is difficult and both appear on sites where the mobile experience was an afterthought rather than the primary design target.
Interstitials That Block Content
Intrusive interstitials covering the main content immediately after arrival from search have been a documented negative signal for years.
What counts as intrusive: popups covering content on load, standalone interstitials requiring dismissal before reading, and layouts where above the fold content is an ad and the content sits below.
What does not: legally required notices like cookie consent and age verification, login walls on genuinely gated content, and reasonably sized banners that do not obscure the page.
Email capture popups firing on load from a search visit are the common self inflicted version, and delaying them past initial engagement resolves the issue without losing the capture entirely.
Mobile Intent Differs From Desktop Intent
Beyond the technical layer, the same query frequently means something different on a phone.
Local and immediate intent is disproportionately mobile. Near me searches, opening hours, phone numbers, directions. That is the behaviour underpinning the local guidance in the local SEO guide.
Which means mobile optimisation for a local business is not only technical. It is making the phone number tappable, the address linked to maps, and the opening hours visible without scrolling. Those are conversion elements and they are what mobile visitors arrived for.
Apps Do Not Replace a Mobile Site
Businesses with an app occasionally deprioritise mobile web on the reasoning that serious users are in the app. That reasoning fails at acquisition, because search visitors arrive on the web and most will not install anything to read a page.
Aggressive app install interstitials are the specific version of this that causes damage, since they are exactly the intrusive interstitial pattern described above and they intercept visitors at the moment of arrival.
A smart app banner that occupies a thin strip and does not obscure content achieves the same goal without the cost.
Migrating From a Separate Mobile Site
For anyone still running an m dot subdomain, the migration to responsive follows the same discipline as any URL change, per the migration guide.
The specifics: redirect mobile URLs to their desktop equivalents rather than to the homepage, remove the bidirectional annotation tags once redirects are live, and expect a temporary period where Google reconciles two previously separate URL sets into one.
The payoff is removing an entire category of parity problems permanently, which is why the project is usually worth it despite the short term disruption.
Testing Properly
Chrome DevTools device emulation is convenient and it simulates viewport rather than hardware. A page feeling responsive on a throttled desktop simulation can be slow on an actual mid range phone.
Test on real devices where possible, particularly older or mid range Android hardware rather than a current flagship. That is closer to what the 75th percentile of your visitors are using.
Search Console's URL Inspection shows the rendered mobile version Google produced, which is the closest available view of what is actually being indexed, per the Search Console guide.
What Crawlers Beyond Google See
Mobile first indexing is a Google concern. Other crawlers, including those feeding AI systems, generally fetch a single version and do not execute JavaScript, which means conditionally loaded mobile content is invisible to them regardless of viewport.
The NotionCue AI Crawler Audit reports what specific crawlers receive, which surfaces content that exists after rendering and not in the server response.
Start your free NotionCue trial and check a template where content loads conditionally. That pattern fails silently across every non rendering crawler and produces no error anywhere.
Quick parity test: open a key page on your phone, view source, and search for a paragraph you know appears on desktop. If it is missing from the mobile HTML, Google is not indexing it, because the mobile version is the version being indexed.
Common Questions
Should mobile and desktop content be identical?
The primary content, headings, structured data, and metadata should match. Presentation can differ freely. Removing content on mobile to simplify a layout removes it from indexing.
Does hidden content in accordions get indexed?
Content present in the HTML and hidden with CSS is generally indexed, though it may carry less weight than visible content. Content fetched only when a user expands the accordion is not indexed at all.
Is a separate mobile site ever the right choice now?
Rarely. Responsive is simpler to maintain, avoids parity problems entirely, and removes the annotation overhead. The main remaining case is a legacy platform where responsive is genuinely not achievable, and that is a reason to plan a migration rather than to keep the separate site indefinitely.