Why hasn't your site been migrated to mobile-first indexing yet?

What is mobile-first indexing and why are some sites still not migrated?

Mobile-first indexing means that Google now uses the mobile version of a site as the primary basis for indexing and ranking. This shift has been gradual since 2018, and Google has officially migrated the majority of sites.

But a minority still resists. Two categories emerge: orphan sites without maintenance (often abandoned and never updated) and very large sites with technically complex architectures where mobile-desktop parity is a structural puzzle. In the latter case, it's not about abandonment but real technical blockages that Google struggles to pinpoint accurately in its notifications.

Why does Google send notifications before migration?

Google has implemented a notification system in Search Console to alert webmasters about detected issues that could harm mobile-first indexing. The idea is to provide time to correct issues before switching, thus avoiding drastic visibility losses.

The problem is that these notifications often remain vague or generic. For a complex site, receiving a message saying “your mobile content differs from desktop” without specific details about the affected pages or elements is barely actionable. Hence, Google's commitment to improve the granularity of these alerts — but with no timeline or concrete guarantee.

What are the most common technical blockages on large sites?

On complex structures, several recurring issues hinder mobile-desktop parity: truncated or hidden content in mobile (accordion, tabs, poorly configured lazy loading), different URLs between mobile and desktop (m.site.com vs www.site.com), or divergent robots.txt files and meta robots tags.

Issues with missing or incomplete structured data in mobile, differences in internal linking, and assets (images, CSS, JS) blocked only on mobile are also common. For a technical SEO, these discrepancies often result from chaotic development histories where mobile and desktop have evolved separately.

• Sites without maintenance: generally abandoned platforms, with little real business stakes.
• Complex large sites: legacy architectures, fragmented technical teams, difficulties in precisely identifying mobile-desktop discrepancies.
• Google notifications: often too vague to allow for quick and targeted corrections on sites with thousands of pages.
• Promise of improvement: Google commits to refining alerts, but without specifics or a public timeline.
• SEO risk: remaining stuck in desktop-first indexing can lead to visibility losses if mobile content is incomplete or different.

Is this statement consistent with field observations?

Yes, and it's quite honest on Mueller's part. In the field, it is indeed observed that the majority of unmigrated sites fall into two distinct camps: dead projects (often forgotten subdomains, test sites, archived platforms) and technical behemoths where the mobile-first migration involves heavy redesign work.

What is less clear is the actual effectiveness of the current notifications. Many SEOs report that Search Console alerts are still too generic to be helpful on sites with tens of thousands of pages. Receiving an alert stating “content differs” without a list of affected URLs is of little use. [To be verified]: Google has never published statistics on the correction rate following these notifications — making it impossible to know if they have genuinely helped or if they merely served as a cover before a brutal switch.

What nuances should we consider about “very large sites”?

Be careful not to generalize. Not all large sites are stuck in mobile-first. Major e-commerce platforms, high-traffic media outlets, and complex SaaS have migrated without issue. The criterion is less about size and more about historical technical debt.

Sites that struggle are often those that built their mobile version alongside the desktop (separate versions m.site.com, poorly implemented responsive design, or worse: native apps with different content). These architectures create structural gaps that are difficult to detect and correct at scale. To say “large complex site” is vague — the real indicator is rather “site with a history of divergent mobile/desktop versions”.

Should we wait for “improved notifications” before taking action?

No. Relying on Google to identify all your problems is a strategic mistake. Search Console notifications are just a starting point, never an exhaustive map. If your site is still unmigrated and has business stakes, you need to proactively audit mobile-desktop parity.

Specifically: crawl the site with a mobile and desktop user-agent, compare rendered HTML content, check internal linking, structured data, and meta tags. Don’t wait for Google to tell you where it’s stuck — especially since these so-called “improved notifications” have no deployment date or guarantee of adequate granularity. [To be verified]: Mueller does not specify what “improve” means — more details? More context? Specific URLs? Nothing concrete.

How to check if my site is properly migrated to mobile-first indexing?

The first step: Search Console. Go to the site settings and check the indexing status. If you see “Mobile-first indexing enabled,” you're good. If not, look for notifications in the Messages tab — Google usually lists detected issues prior to migration there.

The second step: manual parity testing. Crawl your site with a Googlebot smartphone user-agent (Screaming Frog, OnCrawl, Botify, etc.) and compare it with a desktop crawl. Look for discrepancies in textual content, internal linking, canonical tags, structured data. If entire sections disappear on mobile or are hidden by default, that's a red flag.

What to do if my site is stuck in desktop-first indexing?

First, identify the real cause of the blockage. Is it a content issue (truncated text, missing images, incomplete linking)? A technical configuration issue (robots.txt, meta robots)? Missing structured data in mobile? Or a URL gap between mobile and desktop versions?

Next, prioritize. If you have thousands of pages, start with the most critical templates (product pages, categories, blog posts). Correct structural discrepancies, test with the URL Inspection tool in Search Console (mobile mode), and ensure Googlebot has access to all assets (CSS, JS, images). Once corrections are deployed, request a new indexing via Search Console and monitor positions on mobile.

What mistakes to avoid during the mobile-first migration?

Don’t fall into the trap of “lightweight mobile”. Hiding content to speed up loading or simplify the interface risks losing relevance signals for Google. If content is important for desktop, it should be for mobile — even if it’s in an accordion or a tab (as long as it is accessible to crawl).

Avoid inconsistent hybrid configurations: a responsive site with canonical tags pointing to a m.site.com version, or desktop alternate tags that no longer exist. This type of inconsistency muddles signals and delays migration. Finally, don’t neglect server logs: check that Googlebot smartphone is properly crawling your key pages and that there are no hidden blocks (rate limiting, 403, looping redirects).

• Check the mobile-first status in Search Console and read all notifications.
• Crawl the site with mobile and desktop user-agent, compare content, linking, structured data.
• Correct content, meta tags, robots.txt discrepancies between mobile and desktop.
• Test key pages with the URL Inspection tool (mobile mode) to validate Googlebot access.
• Monitor server logs for any potential blocks or crawl errors in mobile.
• Prioritize critical templates (products, categories) rather than tackling all pages at once.