Is your website still not switched to mobile-first indexing?

What exactly is mobile-first indexing?

Mobile-first indexing means that Google now uses the mobile version of your site as the primary reference for indexing and ranking. Previously, it was the opposite: the bot first crawled the desktop version, and the mobile version was considered secondary.

This change is not cosmetic. If your mobile version is less complete than your desktop—hidden content, missing images, absent structured data—that's the stripped-down version Google indexes. And that determines your ranking, including on desktop.

Why are some sites still not migrated?

Google states that an automated assessment determines if a site is ready. But what does 'ready' mean in this context? The systems analyze the parity between the two versions: textual content, media, meta tags, structured data, loading speed.

If the gap is deemed too significant, Google holds off. The site remains indexed via its desktop version, waiting for the issues to be resolved. This is not a permanent blockage—it's a stay of execution.

What signals trigger this migration refusal?

We lack precise official data here. However, field observations point to several recurring culprits: hidden content via accordions not accessible to the mobile bot, incorrect canonical tags, server response times exceeding 3 seconds on mobile, or structured data present on desktop but missing on mobile.

A classic case: e-commerce sites that display 30 products per page on desktop but only 10 on mobile, without clear pagination. Google detects the difference and slows down the migration.

• Content parity: text, images, videos must be identical on mobile and desktop
• Consistent structured data: same Schema.org on both versions
• Meta tags and titles: no truncation or variation between desktop and mobile
• Mobile loading speed: a non-negotiable criterion since Core Web Vitals
• Content accessibility: nothing hidden behind interactions not detectable by the bot

Is this statement consistent with field observations?

Yes and no. Google has indeed migrated the majority of sites—we're talking about over 70% of the indexed web being mobile-first according to the latest estimates. However, the notion of 'automated assessment' remains vague. No specific threshold is communicated. [To be verified]: which KPIs exactly trigger the green or red light?

In the field, we see that some sites with minor differences (a desktop carousel absent on mobile, for example) have been migrated without issue, while others with similar gaps remain stuck. This suggests that the algorithm incorporates other variables—traffic, domain authority, crawling history—without Google admitting this openly.

What nuances should be added to this statement?

Mueller speaks of a 'significant part,' but does not quantify it. Yet, 30% of non-migrated sites is still colossal. This often involves legacy sites, outdated CMS, or architectures where desktop and mobile are managed via two separate code bases (m.example.com vs www.example.com).

Another point: Google says the site 'is not yet ready,' but does not always clearly notify webmasters. The Search Console shows a migration status, yes, but without detailing the specific blockages. You discover the problem by manually inspecting the URL via the inspection tool, comparing the desktop vs mobile rendering.

In what cases does this rule not apply?

If your site is 100% responsive—a single HTML version served to all devices, adapted via CSS—you are already mobile-first by default. No content difference = no risk. Google has nothing to assess.

The real concerns? Sites using dynamic serving (different HTML based on user-agent) or distinct URLs (m.example.com). Here, parity becomes critical. And often it's on these architectures that bugs linger: partial duplicated content, incorrect cross-canonical tags, 302 redirects instead of 301.

How can I check if my site has been migrated?

The first step: Google Search Console, section 'Settings' > 'Indexing'. A banner will tell you if your site is mobile-first or not. If you see 'Mobile-first indexing enabled,' you're good to go. Otherwise, dig deeper.

Use the URL inspection tool on several key pages: homepage, product page, blog post. Compare the HTML rendering retrieved by Googlebot smartphone vs desktop. If you see content differences, meta tags, or structured data, you’ve found your culprits.

What concrete corrections are needed to unblock migration?

Start by aligning the content. If you hide text on mobile via tabs or accordions, make sure the complete HTML is present in the DOM—even if visually hidden. Google must be able to parse it.

Next, structured data. Use Google’s rich results test on both versions. If you have Schema.org Product on desktop but not on mobile, you lose rich snippets—and delay migration.

Finally, Core Web Vitals mobile. A LCP beyond 4 seconds, a CLS that jumps everywhere, a catastrophic FID: all negative signals for the automated assessment. Optimize images (WebP, lazy loading), reduce blocking JavaScript, move to at least HTTP/2.

What mistakes should you absolutely avoid?

Never block resources (CSS, JS, images) via robots.txt for the mobile version. Google needs to load everything to assess the real rendering. A blocked CSS file = broken layout = negative evaluation.

Avoid intrusive popups on mobile that obscure the main content. Google detects them and penalizes. If you use interstitials, ensure they comply with guidelines (easily dismissible, do not cover the entire screen).

Last classic pitfall: improperly implemented lazy loading images. If Googlebot can't load critical images because they rely on a JS scroll event, they are invisible for indexing. Use the loading="lazy" attribute native to HTML5, not some exotic custom script.

• Check the mobile-first status in Search Console
• Compare HTML rendering between Googlebot mobile vs desktop using the inspection tool
• Audit content parity: text, images, videos, structured data
• Measure mobile Core Web Vitals via PageSpeed Insights and fix discrepancies
• Test canonical and hreflang tags on both versions
• Ensure no critical CSS/JS files are blocked on mobile