Why does Googlebot ignore your lazy-loaded images that are below the fold?

Does Googlebot scroll to index your images?

The answer is no, categorically. Googlebot loads the page, analyzes the initial DOM, and stops there. It does not simulate user scrolling to trigger the lazy loading of images located below the first viewport.

This technical limitation directly impacts indexing in Google Images. If an image does not appear at the first load, it simply does not exist for the crawler. Native lazy loading (loading="lazy") or JavaScript produces the same effect: invisibility.

Why does this technical restriction exist?

Crawl budget explains part of the problem. Simulating user interactions (scroll, click, hover) would multiply the time and resources required to crawl each page. Google made a technical trade-off: to index massively rather than deeply.

Modern JavaScript rendering further complicates matters. Googlebot executes JavaScript, but within a limited time window. The onscroll events or Intersection Observer do not trigger without real interaction, so conditional images remain in perpetual waiting.

How does Google differentiate priority images?

For Google, only actual presence in the initial HTML or immediate post-render DOM matters. An IMG tag with a filled src attribute = indexable. A data-src awaiting scroll = ignored.

This binary logic does not consider the semantic or editorial importance of the image. A key illustration placed 1200px of scroll away is treated the same as a decorative image: no indexing.

• Googlebot does not scroll: lazy-loaded images outside the first viewport remain invisible
• Only the initial DOM matters: src attribute present at load = guaranteed indexing
• No semantic distinction: Google ignores editorial importance, only technical position matters
• Alternative landing page: create dedicated pages for strategic images like Wikipedia
• Trade-off performance vs visibility: lazy loading improves LCP but destroys image indexing

Does this statement really reflect the observed real-world behavior?

Yes, and tests have confirmed this for years. Audits on e-commerce sites show that 60 to 80% of lazy-loaded product images below the fold never appear in Google Images. This statement simply formalizes what practitioners observe daily.

The important nuance: Googlebot executes the initial JavaScript, so an image loaded via JS at the first render (without requiring a scroll) will be indexed. The problem specifically concerns conditional triggers related to user interaction.

What contradictions arise with the Core Web Vitals recommendations?

Google officially recommends lazy loading to optimize LCP and reduce initial weight. But this same optimization sacrifices image indexing. The paradox is harsh: improving your Core Web Vitals can destroy your visibility in Google Images.

For sites where Image traffic represents 15-30% of the total (fashion, decoration, travel), this conflict becomes strategic. No clear guidance from Google on the trade-offs to make. [To be verified]: Google claims that the overall ranking impact compensates for the loss in Images, but no public data supports this.

In what cases does this rule apply differently?

Sites with client-side JavaScript architecture (React, Vue, Angular) suffer a double effect. If the framework loads images after hydration, even at the top of the page, indexing remains random. The timing of rendering becomes critical.

Special case of AMP and mobile pages: AMP imposes its own lazy loading system (amp-img). Googlebot AMP applies the same rules, but since the initial mobile viewport is smaller, even fewer images pass the filter. A mobile product gallery can lose 90% of its indexable images.

What should you do concretely to preserve image indexing?

Disabling lazy loading on strategic images remains the most straightforward solution. Identify the 3-5 key images per page (hero, main product, priority editorial visuals) and enforce loading="eager" or remove the loading attribute. These images should have a standard src, no data-src.

For e-commerce sites with hundreds of references, create dedicated image landing pages like Wikipedia. A lightweight page per product, optimized for image indexing, with structured metadata (ImageObject schema). This approach doubles your indexable surface without penalizing the performance of transactional pages.

How can you check that your images pass the Googlebot filter?

Use the URL Inspection tool in Search Console and look at the rendered screenshot. Any image absent from this capture will not be indexed. Compare it with your actual scrolled page: the gap reveals losses.

Also test with Mobile-Friendly Test in mobile mode. Since the initial mobile viewport is smaller (generally 375-414px wide), you'll see how many images disappear. A product slider that shows 4 desktop images may show only one mobile to Googlebot.

What critical errors should you absolutely avoid?

Do not rely on JavaScript to "bypass" this limitation. Developers try to load all images via JS and then visually hide them with CSS. Googlebot detects these manipulations and may impose penalties for cloaking if the DOM/visual rendering gap is too significant.

Avoid the trap of "conditional lazy loading" based on User-Agent. Disabling lazy loading for Googlebot only creates a divergence between user experience and crawler that Google classifies as deceptive practice. Sanctions can go beyond simple non-indexation of images.

• Audit images currently indexed via Google Images with site:yourdomain.com
• Identify strategic images (conversions, traffic, potential backlinks) and their viewport position
• Disable loading="lazy" on any image above 800px of scroll
• Implement dedicated landing pages for high-SEO potential images
• Consistently test with Search Console Inspection before deployment
• Monitor changes in Google Images traffic after modifications (wait 4-6 weeks)