Why does Google ignore your images if they're in data-src instead of src?

What is the technical difference between src and data-src for Google?

The src attribute is the HTML standard that tells the browser — and Googlebot — where to load an image resource. It's what the crawler reads directly in the DOM. The data-src attribute, on the other hand, is a custom attribute (data-* attribute) commonly used in lazy loading solutions: the image is not loaded immediately, but only when it becomes visible in the viewport.

The problem? Google does not natively read data-src. If your JavaScript never switches the URL from data-src to src, or if the JavaScript rendering fails, Googlebot sees an <img data-src="..." src=""> element with an empty or missing src. The result: no indexed image, no chance to appear in Google Images, and a substantial loss of SEO traffic.

Why do so many sites still fail on this point?

Because lazy loading libraries (LazyLoad, Lozad, etc.) and some CMS (WordPress with misconfigured plugins, Shopify with third-party themes) inject data-src by default without always ensuring a switch to src. Developers test in desktop mode with JavaScript enabled, everything works visually, but they never check the rendering on Googlebot.

However, Googlebot does indeed execute JavaScript, but with limitations: a 5-second timeout for rendering, no simulated scrolling (thus no triggering of IntersectionObserver events for certain images), and blocked resources that can prevent the JS from executing correctly. If your script doesn't pass data-src to src within this timeframe, the image is lost.

Does Google Search Console help in detecting this issue?

Yes, but not directly. The URL Inspection tool displays the final HTML rendering as seen by Google. If you inspect a page and the <img> tags don’t have a specified src, that's the signal. You can also cross-reference with the Coverage > Images report: if pages with a lot of images show 0 or very few indexed images, it's probably data-src that's stuck.

The issue is that GSC does not do automatic detection or specific alerts for 'images in data-src not indexed’. You must manually audit, URL by URL, or use a third-party crawler (Screaming Frog, OnCrawl, Botify) that simulates JavaScript rendering and compares src/data-src attributes.

• src is the standard attribute that Google tracks to index images
• data-src is invisible to Googlebot if no JavaScript switches it to src
• The native lazy loading (loading="lazy") works with src, not with data-src
• Google Search Console allows you to check the final rendering, but does not automatically detect this problem
• A technical audit with a JS crawler is essential to map lost images

Is this statement consistent with practices observed in the field?

Absolutely. It has been observed for years that sites implementing lazy loading via data-src without fallback lose image indexing. Production testing confirms this: an e-commerce site with 10,000 product listings and poorly configured lazy loading can have 80% of its images missing from Google Images. This is not a theoretical nuance, it's a traffic sinkhole.

What is less discussed is that native lazy loading (loading attribute loading="lazy") resolves this issue: it works with src, Google interprets it correctly, and no JavaScript manipulation is necessary. Since 2019, it is supported by Chrome, Firefox, Edge, Safari — and most importantly, by Googlebot. If you're still using third-party scripts for lazy loading, now is the time to migrate to the HTML standard.

What nuances should be added to this Google assertion?

First nuance: Google can index an image whose URL appears elsewhere in the code (CSS background, JSON-LD script, <link rel="preload"> tag), but this is marginal and not guaranteed. The only reliable method remains src in <img>. Don't count on detours.

Second nuance: even if your JavaScript correctly switches data-src to src, if this script is blocked by robots.txt, loaded late after the rendering timeout, or depends on an external library that fails, Google will see the initial DOM with data-src. In other words, [To be verified] ensure that your JavaScript rendering chain is robust and that all critical files are crawlable.

In what cases does this rule not apply or become secondary?

If your images have no SEO value (decorative icons, CSS sprites, purely UX illustrations without search value), then data-src or even the complete absence of an <img> tag has no impact. Google will not seek to index PNGs of arrows or buttons.

Conversely, for any content that can generate traffic through Google Images — product photos, infographics, editorial visuals, portfolios, recipes, before/after images — the rule is absolute: src required, data-src forbidden without guaranteed switching. And here, it's critical.

What should you concretely do to ensure Google indexes your images?

First, audit the existing setup. Crawl your site with Screaming Frog in JavaScript mode enabled (or OnCrawl, Botify, Sitebulb) and extract all <img> tags. Filter those that have a data-src specified but an empty or missing src. This is your blacklist.

Next, check the actual rendering on Google: use the URL Inspection tool in Search Console on some typical pages (product listing, blog article, gallery page). Look at the rendered HTML and search for <img> tags: if src is empty, you have a problem. Cross-reference with the Indexed Images report: if the number of indexed images is abnormally low, it's confirmed.

What errors should be avoided when complying?

Error #1: adding an empty src="" thinking it’s better than nothing. No. An empty src triggers an HTTP request to the page itself, which pollutes your logs, increases wasted crawl budget, and does not index anything. If you cannot specify src immediately, use a low-weight placeholder (inline SVG data:image, or 1x1 px image) while waiting for lazy load.

Error #2: blocking lazy loading scripts in robots.txt. If your JS is blocked, Google cannot execute it, so data-src never switches to src. Check that all critical .js files for image rendering are crawlable.

How to verify that your implementation works after correction?

Use the Mobile-Friendly Test tool or PageSpeed Insights, which run JavaScript and display the final DOM. Inspect the <img> tags in the screenshot and rendered HTML: src should be populated with the final image URL. If it's good, trigger another URL inspection in GSC and request re-indexing.

Then, monitor the Indexed Images report in GSC over 4-6 weeks. You should see a rising curve in the number of discovered and indexed images. If it stagnates, there may be uncorrected pages or your image sitemap is not submitted. Cross-reference with Google Analytics / GA4: traffic from Google Images (source/medium = google/organic, landing page = /images or image search) should increase.

• Crawl the site in JavaScript mode to detect <img> tags with data-src but no src
• Check Google's rendering via URL Inspection (Search Console) on typical pages
• Migrate to native lazy loading loading="lazy" with populated src
• Remove or correct third-party scripts that inject data-src without fallback
• Ensure critical JavaScript files are not blocked by robots.txt
• Submit an image sitemap with the correct URLs (referring to src, not data-src)