Does Googlebot really index images with native lazy-loading?

Why is Google clarifying its stance on lazy-loading?

Lazy-loading allows images to load only when they enter the viewport. For years, this technique required JavaScript, which posed a problem: Googlebot had to execute the JS to discover image URLs, causing variable delays and risks of non-indexation.

Since 2019, HTML5 has included the loading='lazy' attribute directly in the <img> tag. Google announces here that its bot understands this native attribute without needing to render the JavaScript. The image is discovered right away during the crawl of the raw HTML.

What does this change for crawling and indexing?

Prior to this native support, images lazy-loaded via JavaScript might be invisible on Googlebot's first pass. The bot had to return, execute the JS, and then discover the resources — a process that consumes crawl budget.

With loading='lazy', the image URL is directly in the HTML src attribute. Googlebot sees it immediately, adds it to its crawl queue, and can index it without JavaScript rendering phase. This theoretically accelerates discovery and reduces load on high-volume image sites.

Does this statement cover all types of lazy-loading?

No. Google specifically refers to the native HTML attribute. JavaScript implementations that dynamically manipulate the DOM — for example, replacing data-src with src via a script — are not covered by this guarantee.

If your CMS or framework uses a custom JS library for lazy-loading, you remain dependent on Googlebot's ability to execute that code. Google's statement does not simplify anything for these cases.

• Native attribute loading='lazy': crawled and indexed without JS, according to Google
• Custom JavaScript lazy-loading: still requires JS rendering, possible delays
• Crawl budget: native saves resources, especially on media-intensive sites
• Browser compatibility: the attribute has been supported by Chrome, Firefox, Edge, and Safari since 2020
• Use case: particularly useful for e-commerce product pages, blogs with galleries, editorial sites

Is this statement consistent with real-world observations?

In the majority of tested cases, yes. Images with loading='lazy' appear in Google Images and get indexed. But the speed of discovery varies depending on crawl depth and bot visitation frequency.

On sites with low authority or a limited crawl budget, some real-world reports indicate that lazy-loaded images at the bottom of long pages may take several days to be indexed — even with the native attribute. Google does not specify whether Googlebot scrolls virtually or simply reads the raw HTML. [To verify]

What nuances should be added to this claim?

Google speaks of support, not a guarantee of immediate indexing. The attribute loading='lazy' does not change the crawl prioritization rules: an image below the fold on a rarely crawled page will still be discovered late.

Furthermore, some frameworks (Next.js, Nuxt, WordPress with plugins) add JavaScript layers on top of the native attribute to optimize loading. In these cases, it’s difficult to know whether Googlebot relies solely on the HTML attribute or also executes the JS. Server logs sometimes show delayed image requests hours after the HTML crawl — suggesting a late JS rendering.

In what cases does this rule not apply completely?

If you use loading='lazy' on an image above the fold — visible without scrolling — you artificially degrade Core Web Vitals. The browser delays loading a critical resource, which penalizes LCP. Google recommends lazy-loading only images below the fold.

Another limitation: sites with infinite scroll or SPA (Single Page Application) navigation. If content is displayed via JavaScript after a user event, Googlebot may not simulate this scroll. The native attribute is not enough: server-side rendering architecture or pre-rendering is required to ensure indexing.

What should you concretely do on an existing site?

First, audit your current implementation. If you’re using a JavaScript library like Lazy Sizes or a custom WordPress plugin, ensure it does not override the native attribute. Some scripts replace src with data-src, negating the SEO benefits of Google's statement.

Transitioning to native loading='lazy' is simple: add the attribute to your <img> tags while keeping src intact. No need for external scripts, no third-party dependencies. The browser handles everything. From an SEO perspective, this ensures that Googlebot sees the URL on the first HTML crawl.

What mistakes should be avoided during implementation?

The most common mistake: applying loading='lazy' to all images, including those in the header, logo, or hero banner. The result: the LCP (Largest Contentful Paint) spikes, and Google Search Console signals Core Web Vitals issues.

Another pitfall: forgetting to test on mobile. Some frameworks apply lazy-loading conditionally based on screen size. If your CMS disables the native attribute on mobile but keeps the JS, you lose the SEO benefits that Google promised for the majority of traffic.

How to check that the implementation is compliant?

Inspect the raw HTML (cURL or "View Source" in Chrome). If src contains the complete image URL AND loading='lazy' is present, you’re good. If you see data-src or data-lazy, your implementation relies on custom JS — not covered by this statement.

Use Google Search Console, under the "Coverage" section, to monitor the indexing of image-rich pages. Compare the delays before/after migrating to the native attribute. A shift from 7 days to 48 hours for indexing a gallery page is a good indication of success.

• Audit all <img> tags to identify custom JS implementations
• Migrate to native loading='lazy' while keeping src intact
• Exclude above-the-fold images and critical resources (logo, hero)
• Test the raw HTML rendering with cURL or "View Source" to confirm the presence of src
• Monitor Core Web Vitals (especially LCP) before/after deployment
• Check indexing in Google Images via Search Console, under the Performance section