Is it true that Google delays mobile-first migration for some sites?

What exactly does Google mean by 'poorly marked headings'?

A poorly marked heading is text that visually resembles a title (large, bold, spaced font) but does not use HTML semantic tags like <h1>, <h2>, etc. Instead, the developer has applied CSS to a <div> or a <p> to simulate the appearance of a title.

Google cannot guess that a <div class="big-title"> is a structural heading. To the crawler, it is just text. If this practice is common on the desktop version but corrected (or worse, absent) on mobile, Google detects a structural inconsistency between the two versions and suspends the mobile-first migration.

Why does the number of images between desktop and mobile pose a problem?

Many sites hide thumbnails or image galleries on mobile to lighten the page or speed up loading. The problem is: if Google indexes only the mobile version, those images disappear from the index. The result? Loss of visibility in Google Images, loss of semantic context for certain content (e-commerce products, portfolios, illustrated articles).

Google considers that if the mobile version is too stripped down compared to desktop, it does not faithfully represent the site's content. The migration is therefore postponed until the gap is closed. This is not a definitive block, but a warning signal.

Does this check concern all sites or only those pending migration?

Mueller clearly states: 'For a site not yet migrated to mobile-first indexing'. In practice, the majority of sites have already switched since 2019-2021. But some projects — ongoing redesigns, legacy CMS, high traffic desktop sites — remain in desktop-first indexing.

For these, Google applies a manual or algorithmic review before switching. If the criteria (headings, images, text content) are not met, migration is postponed. Once migrated, the site remains in mobile-first: there is no going back, even if mobile quality deteriorates later on.

• Mandatory semantic HTML tags: <h1> to <h6> must be present in the DOM, not simulated with CSS.
• Image parity desktop/mobile: the number and type of images (especially thumbnails, galleries, product visuals) must be equivalent.
• Deferred migration, not rejected: Google does not permanently block but waits for the site to correct the detected gaps.
• Essential technical audit: compare both versions with a crawler (Screaming Frog, OnCrawl) using desktop and then mobile User-Agent.
• No going back: once migrated to mobile-first, the site stays there — hence the importance of properly preparing the mobile version before the switch.

Is this statement consistent with observed practices in the field?

Yes, and it confirms what many of us have observed for years. Sites that hide content on mobile — through display:none, aggressive lazy-loading, or outright removal of entire sections — see their visibility drop after mobile-first migration. This is not a penalty: it is the logical consequence of a stripped-down index.

But the nuance is that Google never details the tolerance threshold. How many fewer images are acceptable? 10%? 30%? No public metrics. [To be verified] on each project with a phased test: compare performance before/after adjusting the number of mobile images.

Is the issue of styled headings still common in practice?

Less than before, but it still happens — especially on legacy sites or no-code builders that generate atypical HTML. The real danger is the invisible heading: a <h2> present on desktop, hidden in CSS (display:none), or replaced by an image on mobile.

Google treats these cases as structural inconsistencies. If the heading is only hidden on mobile, it disappears from the mobile-first index. If it is a strategic <h1> or <h2>, the SEO impact can be brutal. Always check that semantic tags are present in the mobile DOM, not just visible on screen.

Do we really need to have as many images on mobile as on desktop?

To be honest: no, it is not always relevant. An e-commerce site with 12 product photos on desktop can legitimately display only 4-5 on mobile for UX and performance reasons. But — and here’s the catch — those images must still exist in the mobile HTML, even if they are in lazy-loading or in a collapsed carousel.

Google indexes what is in the DOM, not what is immediately visible. If thumbnails are loaded in JavaScript after a user click, they may be invisible to Googlebot. The result: loss of indexing in Google Images, loss of semantic context. [To be verified] with a JavaScript render via Search Console or a crawler configured for JS mode.

What should be checked concretely before a mobile-first migration?

First reflex: crawl the site using mobile User-Agent (Googlebot Smartphone) and compare with a desktop crawl. Screaming Frog, OnCrawl, Botify — all allow you to change the User-Agent. Then, export the headings (<h1> to <h6>) and images from each version, and cross-reference the data in a spreadsheet.

If headings disappear or change levels (an <h2> becomes <h3>), it’s a warning signal. If the number of mobile images is more than 20-30% lower than on desktop, it needs investigation: overly aggressive lazy-loading? Images hidden in CSS? Non-crawlable carousels?

How to correct a site that hides content on mobile?

If images or headings are hidden via display:none or visibility:hidden, replace them with native lazy-loading (loading="lazy") or an HTML-accessible carousel. The idea: content must be present in the DOM, even if it is not immediately visible on screen.

For headings styled with CSS, it is necessary to refactor the HTML: replace <div class="heading"> with <h2>, then adjust the CSS. This is a technical project, but it is the only way to ensure that Google recognizes the semantic structure of the content.

What tools to use to detect these issues in advance?

Search Console remains the reference tool: 'Page Experience' section → check if Google reports differences between desktop and mobile. But be careful, Search Console doesn’t always detail the precise gaps. It should be supplemented with a crawler configured in mobile mode and a JavaScript render test (via Puppeteer, for example).

Another approach: compare server logs to see if Googlebot Smartphone crawls as many resources (images, CSS, JS) as Googlebot Desktop. If the number of server requests on mobile is significantly lower, it’s a sign that content is inaccessible or hidden.

• Crawl the site using Googlebot Smartphone User-Agent and compare with a desktop crawl.
• Ensure all headings (<h1> to <h6>) are present in the mobile DOM, not simulated in CSS.
• Verify that the number of images (especially thumbnails, galleries, product visuals) is equivalent between desktop and mobile.
• Replace display:none with native lazy-loading or carousels accessible in HTML.
• Test the JavaScript render to check that lazy-loaded images are visible to Googlebot.
• Consult server logs to detect any uncrawled resources on mobile.