Your Image Srcset Is Serving Googlebot the Smallest Version
On this page
If Google Images shows a small, soft version of an image your page serves sharply on desktop, check the src attribute before blaming srcset. Google’s image SEO best practices say Google can find images in the src attribute of an <img> element, even when it sits inside a <picture> element, and recommend always specifying a fallback URL in src. When a responsive setup puts its smallest variant in src, the small file is the one Google’s documentation says it can find. Point src at a good, reasonably sized version and keep srcset for your visitors. How you write srcset decides whether that change costs your users anything.
What Google documents, and what it doesn’t
Google’s image guidance describes srcset as a way to specify different versions of the same image for different screen sizes, and <picture> as a way to use new image formats with graceful degradation. It names src as the place Google can find images and asks for a fallback there because, in its words, “some browsers and crawlers don’t understand these attributes.”
It doesn’t describe Googlebot picking a srcset candidate by viewport width and indexing that candidate. So “Googlebot renders on a phone, therefore it indexes the smallest breakpoint” is a guess this guidance doesn’t support. What you can check is concrete: which file your src names, and which file Google Images shows.
Diagnose it
- Read the markup. In the page source, find the
<img>and note the file insrc. A template or image plugin can write the smallest generated size there, with the larger sizes only insrcset. - Check what Google fetches. Run a live test in the URL Inspection tool and read the
<img>in the tested page’s HTML, so you see the markup the live test fetched rather than your template. - Compare with Google Images. Open your image’s result and check which file it points to. If it matches the small file in
src, start the fix there.
Fix src without slowing mobile
Point src at a version that looks good as a search thumbnail and on a large screen. Whether that costs your visitors anything depends on how srcset is written. MDN’s reference for the img element spells out the two cases:
| <!–INLINECODE23–> descriptors | How browsers use <!–INLINECODE24–> | Effect of a larger <!–INLINECODE25–> |
|---|---|---|
| Width (<!–INLINECODE26–>, <!–INLINECODE27–>) | Browsers pick from <!–INLINECODE28–> using <!–INLINECODE29–>; <!–INLINECODE30–> is the fallback for browsers that don't support <!–INLINECODE31–> | Browsers that support <!–INLINECODE32–> don't pick it, so phones keep their smaller files |
| Density (<!–INLINECODE33–>, <!–INLINECODE34–>) | <!–INLINECODE35–> counts as the <!–INLINECODE36–> source, used on low-density screens | Low-density screens download it, so size it for that role |
With width descriptors, you can set src to a large, high-quality file and keep the small variants for phones. With density descriptors, the src file does real work for real visitors, so choose it with that in mind.
Don’t drop srcset to fix a thumbnail. It exists so phones download files sized for them, and Google’s image guidance itself says “images are often the largest contributor to overall page size.”
Make the small variants good too
Visitors on phones may still get the small variants, so they should look sharp. Google’s guidance says high-quality photos appeal to users more than blurry, unclear images, and that sharp images are more appealing in the result thumbnail.
- Use efficient formats through
<picture>, which Google describes as handy for new image formats with graceful degradation for clients that don’t support them. - Don’t crush the compression on the smallest files to shave kilobytes. Tune quality by eye.
- Set a sensible smallest width. A variant sized for the narrowest phones is the one a template may put in
src. A reasonable mobile width as the smallest step trades a larger file for a sharper fallback and phone image.
Help Google find the version you want
Google’s image guidance says you can provide the URL of images it might not have otherwise discovered by submitting an image sitemap, which lists each image URL in an <image:loc> element, as the image sitemaps guide shows. Listing the high-quality file helps discovery; it doesn’t replace a correct src.
One shortcut to avoid
Don’t serve Googlebot a high-resolution image that visitors never get. Google’s spam policies define cloaking as presenting different content to users and search engines with the intent to manipulate search rankings and mislead users. If you want a large version indexed, make it part of the page for everyone: in src, or behind a “view full size” link any visitor can open.
After the change, Google has to recrawl the page and the image before the result updates, so judge the fix once that has happened, not on the day it ships.
Frequently asked questions
Does Googlebot pick the smallest image in my srcset?
Google’s image SEO guidance doesn’t describe that. It documents finding images in the src attribute and recommends a fallback URL there. Check which file your src names first.
Will a larger src slow down my mobile pages?
Not if your srcset uses width descriptors: browsers that support srcset choose from it and use src only as a fallback. With density descriptors, src is the 1x image for low-density screens, so size it accordingly.
Should I remove srcset so Google sees one large image?
No. srcset keeps phone downloads small. Fix src, keep srcset, and make the small variants look good.