Image SEO Beyond Alt Text: File Names, Lazy Loading, and Google Images Ranking

Most teams treat images as an afterthought: upload, slap on an alt attribute, ship it. That leaves real traffic on the table, because Google Images is a search surface of its own with its own ranking signals. The fundamentals below are the parts almost nobody implements correctly, and they're where the gains actually live.

Why image SEO is a separate discipline

Google Images runs on the same index as web search but weights different signals. It cares heavily about the page the image lives on (its topical relevance, title, and surrounding text), the technical accessibility of the image file itself, and structured signals like sitemaps. Alt text matters, but it's one input among many. If you want image SEO that compounds, you have to think about how Googlebot discovers, crawls, renders, and contextualizes each file, not just whether the alt attribute is filled in.

A useful mental model: Google needs to find the image, fetch it, understand what it depicts, and decide which page deserves to rank for it. Each of those steps has a failure mode most sites quietly trigger.

File names are a ranking signal you control completely

The filename is one of the few image signals you set at creation time and never have to maintain. Google has confirmed it uses the URL path and filename to understand image content. A file called IMG_4837.jpg tells the crawler nothing; cast-iron-skillet-cornbread.jpg tells it the subject before it even analyzes pixels.

• Describe the image, not the page. Use words that match what's literally depicted, in lowercase, separated by hyphens (never underscores or spaces).
• Keep it short and specific. Three to five words is plenty. red-2024-trek-domane-road-bike.webp beats both bike.webp and a 12-word essay.
• Stop the CMS from mangling it. WordPress, Shopify, and most DAMs preserve the uploaded filename, so rename files before upload. Renaming after the fact changes the URL and you lose any equity the old URL accrued.
• Mirror filename, alt text, and caption without making them identical. They should reinforce the same subject from three angles: the file says what it is, alt describes it for accessibility, the caption adds context.

Directory paths count too. Serving from /images/products/road-bikes/ adds a relevance hint that a flat /uploads/ folder doesn't.

Responsive srcset: serve the right pixels, win Core Web Vitals

Oversized images are the single most common cause of poor Largest Contentful Paint, and LCP feeds into rankings. The fix is responsive images done properly with srcset and sizes, so a phone never downloads a 2000px desktop hero.

<img
 src="cast-iron-skillet-cornbread-800.webp"
 srcset="cast-iron-skillet-cornbread-400.webp 400w,
 cast-iron-skillet-cornbread-800.webp 800w,
 cast-iron-skillet-cornbread-1600.webp 1600w"
 sizes="(max-width: 600px) 100vw, 800px"
 width="800" height="600"
 alt="Golden cornbread baked in a cast iron skillet">

Three things separate this from what most sites ship:

• Always set explicit width and height. This reserves layout space and prevents Cumulative Layout Shift. It's a one-line fix that an alarming number of templates omit.
• Get sizes right. If sizes lies about how wide the image renders, the browser picks the wrong candidate and your effort is wasted. Match it to your actual CSS breakpoints.
• Serve modern formats. WebP is universally supported now; AVIF compresses even harder. Use <picture> with format fallbacks if you still need to support ancient clients.

Note that Google indexes the URL in src as the canonical image, so make sure your default src points at a sensible, well-named file rather than a tiny placeholder.

Lazy loading that doesn't hide images from Google

Lazy loading is essential for performance and dangerous for indexing if done wrong. The danger is simple: if an image only loads after a JavaScript scroll event that Googlebot never fires, Google may never see it.

• Prefer native lazy loading: loading="lazy" on the <img> tag. Googlebot supports it and it requires no JavaScript, so there's no indexing risk.
• Never lazy-load your LCP image. The above-the-fold hero should load eagerly (loading="eager" or no attribute) and ideally carry fetchpriority="high". Lazy-loading the hero actively hurts LCP, the opposite of the intent.
• If you use a JS lazy-load library, confirm the real image URL appears in the rendered HTML, not just in a data-src attribute that requires scrolling. Use Search Console's URL Inspection "View crawled page" / rendered HTML to verify Google actually sees the loaded src.
• Avoid background-image CSS for content images. Google does not index images referenced only in CSS. If it's content you want ranked, it belongs in an <img> or <picture> element.

The test is concrete: render the page as Googlebot would and check whether each image you care about has a crawlable URL present without user interaction. If it doesn't, it won't rank.

Image sitemaps: the unfair advantage almost nobody ships

Google discovers most images by crawling pages, but JavaScript-heavy sites, paginated galleries, and CDN-hosted assets routinely hide images from that process. An image sitemap is an explicit invitation that closes the gap, and the vast majority of sites never build one.

You can extend your existing sitemap with the image namespace rather than maintaining a separate file:

<url>
 <loc>https://example.com/recipes/cornbread</loc>
 <image:image>
 <image:loc>https://cdn.example.com/cast-iron-skillet-cornbread-1600.webp</image:loc>
 </image:image>
</url>

Practical guidance:

• List the image under the page URL where it appears, using the full absolute image URL, even when the image is served from a different CDN domain.
• If your CMS plugin generates these automatically (Yoast, RankMath, and similar do), verify it's actually including images and not silently excluding decorative or CDN-hosted ones.
• Submit the sitemap in Search Console and watch the indexed-image count. This is your single clearest signal that discovery is working.
• An image sitemap helps discovery; it does not override robots.txt. Make sure you aren't blocking the image directory or CDN path you're trying to get indexed, a stunningly common own-goal.

Two signals that quietly decide image rankings

Beyond the four pillars, two contextual signals do heavy lifting. First, surrounding text and the page's topical authority: an image of a skillet on a page that thoroughly covers cast-iron cooking ranks better than the identical file on a thin page. Place images near the relevant heading and body copy. Second, structured data: marking up images within Product, Recipe, or Article schema can earn richer treatment and badges in image results, which lifts click-through even at the same position.

Common mistakes

• Blocking image folders in robots.txt "to save crawl budget," then wondering why nothing indexes.
• Lazy-loading the LCP hero, tanking the very metric you optimized for.
• Identical alt text across an entire product gallery ("product photo") instead of describing each variant.
• Renaming files after upload and breaking the indexed URL instead of naming them correctly before.
• Hotlinking content images via CSS backgrounds, which Google won't index.
• Missing width/height, causing layout shift and CLS penalties.
• Stuffing keywords into filenames and alt text, describe accurately; the spammy version gets ignored at best.

The build order that works

1. Rename and compress images to modern formats (WebP/AVIF) before upload.
2. Implement srcset/sizes with explicit dimensions on every content image.
3. Add native loading="lazy" everywhere except the LCP image, which gets fetchpriority="high".
4. Write distinct, descriptive alt text per image.
5. Generate and submit an image sitemap, then monitor indexed-image counts in Search Console.

Do these in order and you've built a genuine image SEO program, not a checkbox. The sites that win Google Images traffic aren't using secret tactics; they're simply the ones that finished the work everyone else stops halfway through.