Image SEO

I start with a crawl. Screaming Frog or Sitebulb on a full site scan, filtering for images. I'm looking for three things: files over 100 KB, missing alt text, and filenames that are just numbers. In one audit of an ecommerce site I found 1,200 product shots averaging 800 KB each, all named 'IMG_XXXX.JPG'. The cumulative cost was about 450 MB of unnecessary page weight.

Once I have the crawl data I prioritise by volume. Batch-rename first: a script or a tool like Adobe Bridge can turn 'IMG_4521.jpg' into 'blue-suede-loafers.jpg' in minutes. Then I write alt text. I aim for one accurate sentence per image — 'Blue suede loafers on a white marble surface' not 'loafers shoes blue suede footwear'. Google uses the surrounding page content too, so I check that the [SEO Copywriting](/seo-copywriting/) on the page reinforces the image's topic. If the page is about 'blue suede loafers' and the alt text says the same thing, you're reinforcing relevance.

Next comes compression and format. I use Squoosh or ImageOptim to convert to WebP while keeping a JPEG fallback for older browsers. I always set explicit width and height attributes — without them the browser waits for the image to load before knowing its dimensions, which causes Cumulative Layout Shift (CLS). On a recent project that alone cut CLS from 0.38 to 0.09. I also add loading="lazy" to images below the fold, but never to the hero image or anything above the fold because that can delay Largest Contentful Paint (LCP).

The final step is the [Internal Links SEO](/internal-links-seo/) context. If an image is important — a product shot, a chart, a screenshot that explains a concept — I make sure it sits inside a relevant paragraph with descriptive text around it. Google uses the surrounding text to understand image context, so a caption or adjacent heading matters. I also add itemprop="image" or ImageObject structured data for pages where the image is the main content, like a recipe photo or a gallery. That helps the image appear in rich results and get indexed faster.

I don't worry about image sitemaps unless the site has hundreds of images that are hard to discover. On a blog with 100 articles, the normal crawl covers them. But for a large ecommerce site with 10,000 product shots, a dedicated image sitemap saves resources. I use the same format Google specifies — <image:image> inside the existing sitemap — and submit it via Search Console. One client saw 12% more images indexed within two weeks after adding it.

Don't hide important images in CSS backgrounds. Google can't crawl background-image — use an <img> tag for anything you want indexed. I've fixed several sites where the hero banner was a CSS background and Google had no idea what the banner showed. The fix is simple: swap to <img> and style with object-fit.

Avoid lazy loading above the fold. It sounds efficient but it can push LCP past the 2.5-second threshold. I test with Lighthouse: if the image is in the initial viewport, I remove loading="lazy" and let it load normally. One client's home page had lazy-load on the hero image, LCP was 4.1s. Removing it dropped LCP to 1.8s.

Don't block image paths in robots.txt. I've seen disallow rules for /images/ that prevented Google from ever seeing the image files. Check your robots.txt — if you disallow the image directory, those images won't appear in Google Images or get the page's context boosted.

Don't keyword-stuff alt text. Alt text is first for accessibility. Screen reader users rely on it to understand what an image shows. If the alt text says 'blue suede loafer shoes for men buy cheap discount', it's useless for a blind user and Google may treat it as spam. I keep alt text to 5–15 words describing exactly what is visible. If the image contains text, I write the text out in the alt attribute.

Beware of huge SVG files. SVGs can be small, but I once saw an SVG infographic that was 3 MB because it contained embedded base64 images. Always check SVG file size and simplify paths where possible. Use tools like SVGO to strip unnecessary metadata.

Don't overlook responsive image syntax. Serving a 2400px-wide image to a mobile phone wastes data and slows the page. I use srcset with width descriptors — 1200w, 800w, 400w — and <picture> for format switching. This is a [Meta Tags SEO](/meta-tags-seo/) consideration because the <picture> element sits in the HTML head or body. If you're unsure about the technique, test with Chrome DevTools network tab to see which image version loads at different viewport sizes.

Finally, don't assume WebP is supported everywhere. Safari on older macOS and iOS does not support WebP. Always provide a JPEG or PNG fallback. I use <picture><source srcset="img.webp" type="image/webp"><img src="img.jpg" alt="..."></picture> and set width/height on the fallback <img> to avoid layout shifts.

I used to upload images at full resolution and let CSS scale them down. On a travel blog I ran, each photo was 5 MB straight from the camera, rendered at 800px wide. Visitors were downloading 5 MB for a 300 KB visible image. Bounce rate on article pages was 78%. When I finally resized before uploading — 1920px max for hero, 800px for inline — total page weight dropped from 8 MB to 1.2 MB, and bounce rate fell to 52%. That was four years ago. Now resizing is step one.

I also thought alt text was purely for keywords. My early alt text looked like 'cheap flights to Bangkok Thailand book now'. It didn't describe the image at all — it was a landing page photo of a beach. Google ignored it, screen readers got nothing, and accessibility audits failed. I changed my approach after watching a blind user test my site with a screen reader. Now I write alt text as if the person can't see the screen: 'White sand beach on Koh Samui, clear blue water, two palm trees in the foreground.' That's useful for everyone.

Another mistake: I ignored image dimension attributes. I assumed responsive CSS would handle it, but missing width and height caused layout shifts that made pages jump. Core Web Vitals reports flagged CLS on every page. Adding width="800" height="600" to every <img> tag fixed it almost overnight. It's one of those trivial changes that has an outsized impact.

I also used to rely on JPEG alone because 'WebP is not worth the effort'. Then I ran a comparison on a client's product page: the WebP version of the same image was 40% smaller with no visible quality loss. The effort to add <picture> was maybe 10 minutes per template. The client's overall page speed score improved from 62 to 84. I've converted all new images to WebP ever since.

Finally, I thought image sitemaps were unnecessary for small sites. When I did a [Content Audit](/content-audit/) for a blog with 200 articles, I discovered that 30% of its images had never been indexed. The reason? They were embedded in JavaScript galleries that Google couldn't render. Adding an image sitemap got those images indexed within two weeks and increased organic traffic from Google Images by 15%. Now I include image sitemaps for any site with more than 50 images, regardless of size.