Does lazy loading doom your images to invisibility on Google?

Why does Googlebot miss some images loaded lazily?

Lazy loading defers the loading of an image until it is near the user's viewport. This technique boosts Core Web Vitals by reducing the initial page weight.

Googlebot doesn't always simulate infinite scrolling during crawling. When an image relies on a JavaScript scroll or intersection observe event, the bot may leave the page before the script triggers the loading. The result: the image URL never appears in the DOM analyzed by the crawler, and the image is never indexed.

What does the noscript tag really mean in this context?

A <noscript> tag contains a fallback version of the <img> that displays only if JavaScript is disabled. Googlebot, even if it executes JavaScript, can parse the raw HTML before JS execution.

By placing an image in <noscript>, you ensure that Googlebot sees the URL even if the JS lazy-load fails. But be careful: this creates a duplication in the client-side DOM, with the risk of loading the same resource twice if the implementation is sloppy. Some modern frameworks completely ignore <noscript> on the client side, complicating the implementation.

Are structured data a real alternative?

Mueller mentions structured data to reference images directly in JSON-LD. A schema.org type like Product, Article, or ImageObject can explicitly list image URLs in the image or contentUrl properties.

This approach works because Googlebot parses JSON-LD independently of the visual rendering of the page. Even if the image never appears in the visible DOM, Google knows it exists and can index it for Google Images. The problem? It requires maintaining a strict mapping between displayed images and those declared in the schema, with a risk of discrepancy during editorial updates.

• Googlebot does not always execute the scrolling necessary to trigger images lazily loaded via JavaScript.
• The <noscript> tag provides a parsable fallback URL in the raw HTML, but can create duplicates on the client side.
• JSON-LD structured data allows declaring images outside the visible DOM but requires rigorous maintenance.
• Native HTML lazy loading (loading="lazy") is better supported by Googlebot than third-party JS solutions.
• Highly visual sites (e-commerce, editorial, galleries) must balance LCP performance and Google Images indexing.

Is this recommendation consistent with on-the-ground observations?

Yes, partially. Tests show that Googlebot correctly indexes images with the HTML5 attribute loading="lazy" since late 2020. The issue focuses on legacy JS libraries (lozad.js, lazysizes, etc.) and custom implementations using IntersectionObserver.

Some Search Console audits reveal sharp drops in Google Images traffic after migrating to a poorly configured JS framework. Yet in other cases, thousands of JS lazy-loaded images are indexed without issue. The key variable? The JS execution timing during crawling. If your server responds slowly or if Googlebot allocates little rendering budget to your page, the lazy load may miss.

What nuances should be added to this statement?

[To be verified] Mueller's recommendation is several years old. Since then, Googlebot has improved in executing JS and natively supports loading="lazy". However, Mueller continues to advise <noscript>, suggesting that Google has not fully resolved the issue on the crawler side.

The real concern: Google guarantees nothing. Even with native loading="lazy", some images may never appear in Google Images if the crawl is interrupted too soon. Sites with thousands of product images cannot afford this risk. The result: many revert to eager loading for critical images (hero, initial product listings) and only lazy-load the bottom of the page.

When does this rule not really apply?

If you don’t care about Google Images as a traffic source, this statement is irrelevant. For a B2B SaaS site with little visual content, image indexing is not a priority. Lazy loading can be fully embraced without SEO concerns.

Another case: decorative, UI, or purely functional images (icons, buttons) carry no SEO value. They can be lazy-loaded without <noscript>. In contrast, for an editorial media that derives 30% of its traffic from Google Images, every photo must be indexable, requiring a much more conservative strategy.

What should be done concretely to secure indexing?

Start with an audit of critical images: products, editorial visuals, infographics. If they generate organic traffic, they need to be indexable without friction. Prefer loading="lazy" native HTML5 over a JS library unless advanced needs arise.

For images already lazy-loaded in JS, add a <noscript> tag with a complete <img src="..." />. Place it right after the lazy-loaded element. Test the client-side rendering to avoid having the image load twice (some browsers ignore <noscript> even with JS active, others do not).

Are structured data sufficient to replace noscript?

Yes, for key images you absolutely want indexed. A Product schema with "image": ["url1.jpg", "url2.jpg"] explicitly declares the product visuals. Google can index them even if they never appear in the visible DOM.

But this approach has its limits. If you have 50 images in a blog post, listing all of them in a Article schema burdens the JSON-LD without guaranteeing that all will be indexed. Reserve this method for high-value images: product thumbnails, featured images, category visuals.

How can I verify that my images are indexed?

Use a site:yourdomain.com search in Google Images and filter by specific page. If a critical image does not appear after several weeks, it's a red flag. Also, check the Performance report in Search Console with the filter "Search type: Image".

Crawl your site with Screaming Frog in JavaScript rendering mode enabled. Compare detected image URLs in JS mode vs. raw HTML mode. If images disappear in HTML mode, Googlebot may miss them too, especially if your crawl budget is limited.

• Use loading="lazy" natively for non-critical images (below the fold)
• Add a <noscript> tag with a complete <img> for SEO-high-value visuals
• Declare product/hero images in JSON-LD structured data (Product, Article, ImageObject)
• Check actual indexing via site: in Google Images, not just through the inspection tool
• Crawl your site in both JS enabled AND disabled modes to detect image detection discrepancies
• Prioritize eager loading for above-the-fold images or organic traffic generators