Image SEO for Blogs: Alt Text, Formats, and File Names That Rank

Sparktoro's well-known click study put Google Images at 22.6% of all search activity — more than YouTube, Bing, and Amazon combined. Yet most blogs treat images as decoration: camera filenames, empty alt attributes, 3 MB PNGs scaled down in CSS. That's traffic and ranking signal left on the table.

Image SEO is double-duty work. Done right, it earns you a second front of organic traffic through Google Images, and at the same time improves the page itself — faster loads, better Core Web Vitals, better accessibility — all of which feed your rankings on the main SERP. One set of habits, two payoffs.

TL;DR: Name files descriptively before upload, write alt text for screen-reader users (5-15 words), serve WebP with a JPEG fallback, keep content images under 200 KB, use srcset to match display size, lazy-load below the fold but never the LCP image, and expose images in your sitemap and BlogPosting schema.

Why Image SEO Pays Twice

Image SEO improves two separate surfaces at once. First, Google Images: a properly named, properly described image can rank on its own and pull visitors who never saw your blue link. Second, the main SERP: optimized images load faster, shift layout less, and describe themselves to assistive tech — all signals Google's page experience systems measure.

The second payoff is usually bigger. Images are the heaviest asset type on most blog pages, and the Largest Contentful Paint element is an image on the majority of content sites. Cut image weight in half and you've often fixed LCP, which is a direct ranking input. If you're working through site-wide fixes, image handling sits near the top of any CMS SEO checklist for exactly this reason.

There's a third, newer payoff: AI search. Pages that combine text with relevant, well-labeled images get cited more often in AI Overviews than text-only pages. The labeling is what matters — an AI system can't guess what IMG_4032.jpg shows any better than Google's crawler can.

File Names: Decide Before You Upload

A file name is the first thing a crawler reads about an image, before alt text, before surrounding copy. webp-vs-jpeg-file-size-comparison.jpg tells Google what the image is. IMG_4032.jpg tells it you took the photo on a phone.

Rules that hold up:

1. Lowercase, hyphen-separated words. Hyphens are word separators to Google; underscores are not. image-seo-checklist.webp, not image_seo_checklist.webp.
2. Describe the content, 3-6 words. What would someone type to find this image?
3. Keyword only when it's honest. If the image shows an alt text example, alt-text-example.webp is fine. Don't bolt your target keyword onto a stock photo of a laptop.
4. No dates, no version suffixes. hero-final-v3-FINAL.jpg leaks your process and says nothing about content.

The timing matters more than people think. Rename before you upload. Once an image URL is live and indexed, renaming it means a redirect — and image redirects are slow to re-process. Google Images can take weeks to pick up a moved image, and during that window the old URL 404s out of the index while the new one waits in the crawl queue. A 30-second rename before upload avoids all of it.

Alt Text Done Right

Write alt text for one audience: a screen-reader user who can't see the image. Get that right and the SEO value comes along for free, because what helps a blind reader understand the image is exactly what helps a crawler understand it.

The working rules:

• 5-15 words, describing what the image shows. Specific beats generic: "Line chart showing WebP files 30% smaller than JPEG" beats "chart".
• Include the keyword only when it's natural. If the image genuinely depicts your topic, the keyword will appear on its own. If you're forcing it in, the image probably doesn't belong in the post.
• No "image of" or "picture of" prefixes. The screen reader already announces it's an image.
• Never stuff. alt="image seo image optimization seo images alt text seo" is a spam signal, reads as garbage to assistive tech, and can drag down the page, not just the image.

When to Leave Alt Empty

Decorative images — section dividers, abstract background shapes, spacer graphics that carry no information — should get an explicitly empty attribute: alt="". That tells screen readers to skip the image entirely. Omitting the attribute is worse: many screen readers fall back to reading the file name aloud, so your user hears "div-blue-gradient-two-x dot webp" mid-article.

The test is simple: if the image vanished, would the reader lose information? Yes → write alt text. No → alt="".

Image Formats in 2026: What to Serve

The format question has settled. WebP is the default for photos and screenshots; AVIF is the upgrade where you can generate it; JPEG remains the universal fallback; SVG owns diagrams and logos.

The <picture> element handles the negotiation — browsers pick the first source they support:

<picture>
  <source srcset="chart.avif" type="image/avif">
  <source srcset="chart.webp" type="image/webp">
  <img src="chart.jpg" alt="Bar chart comparing image format file sizes">
</picture>

In practice, you want your CMS doing this conversion, not you. UnfoldCMS converts uploads to WebP automatically and generates responsive sizes in the media library, so authors drop in a JPEG or PNG and the published page serves the smaller format without anyone thinking about it. Whatever platform you run, automatic conversion on upload is the feature to look for — format discipline that depends on humans remembering doesn't survive the third guest post.

Compression and Sizing: Serve What the Screen Shows

The most common image mistake on blogs isn't format — it's serving a 2400px-wide original into a 740px content column. The browser downloads four times the pixels it paints.

Two fixes, both mechanical:

Compress to a budget. For content images — screenshots, charts, inline photos — aim for 100-200 KB each. Hero images can stretch to 250-300 KB. If a quality-80 WebP still blows the budget, the image dimensions are too large, not the compression too gentle.

Serve at display size with srcset. Generate 3-4 widths per image and let the browser pick based on viewport and device pixel ratio:

<img
  src="alt-text-example-800.webp"
  srcset="alt-text-example-400.webp 400w,
          alt-text-example-800.webp 800w,
          alt-text-example-1200.webp 1200w"
  sizes="(max-width: 768px) 100vw, 740px"
  width="800" height="450"
  alt="Code editor showing a descriptive alt attribute on an img tag">

Two details people skip: the sizes attribute (without it the browser assumes full viewport width and over-downloads), and explicit width/height (without them the layout shifts when the image loads, and CLS is a ranking input).

Lazy Loading: Below the Fold Only

Native lazy loading is one attribute: loading="lazy". The browser defers the download until the image approaches the viewport. For a long blog post with eight inline images, that's seven downloads that never happen for the median reader who bounces at 40% scroll.

But there's one image you must never lazy-load: the LCP image — usually your hero. Lazy-loading it tells the browser "this can wait," which delays the exact render event Google times. It's one of the most common self-inflicted LCP regressions. Do the opposite there:

<!-- Hero / LCP image: load eagerly, prioritized -->
<img src="hero.webp" fetchpriority="high" width="1200" height="630"
     alt="Workflow diagram of an image SEO pipeline from upload to publish">

<!-- Everything below the fold -->
<img src="diagram-3.webp" loading="lazy" width="800" height="500"
     alt="Decision tree for choosing between WebP, AVIF, and SVG">

fetchpriority="high" moves the hero ahead of scripts and stylesheets in the download queue. The pairing — eager-plus-priority above the fold, lazy below — is the whole strategy.

Captions and Surrounding Text Are Ranking Context

Google reads more than the image attributes. It reads the caption, the heading above the image, and the paragraphs around it to decide what the image depicts and which queries it should answer. An image of a srcset snippet placed under an H2 titled "Responsive Images" inherits that context.

Practical moves:

• Place images next to the text they illustrate, not batched at the top or bottom of the post.
• Use captions when they add information. Captions get read at a far higher rate than body text. Don't caption for the sake of it — "A laptop" under a laptop photo helps nobody.
• Keep one topic per section. If the surrounding text rambles across three subjects, the image's context signal blurs with it.

This is the same principle behind making your content legible to AI crawlers — clear, machine-readable context around every asset. The llms.txt proposal extends that idea to the site level, but it starts at the level of one image and the paragraph next to it.

Image Sitemaps and Structured Data

Two plumbing items most blogs miss, both of which expand how your images get discovered.

Image entries in the XML sitemap. Standard sitemaps list pages; the image extension lists the images on each page (<image:image> with <image:loc>). This matters most for images loaded via JavaScript or CSS that crawlers might not associate with the page otherwise.

The image property in BlogPosting schema. Your article's JSON-LD should declare its featured image:

{
  "@type": "BlogPosting",
  "headline": "Image SEO for Blogs",
  "image": {
    "@type": "ImageObject",
    "url": "https://example.com/media/image-seo-guide-hero.webp",
    "width": 1200,
    "height": 630
  }
}

That declaration feeds Discover, rich results, and AI answer engines — all of which surface a thumbnail next to your headline. Articles with a declared image get visual placement; articles without compete as plain text. This is a place where the platform should do the work: UnfoldCMS emits BlogPosting JSON-LD with image data and maintains the XML sitemap automatically, and since it's a self-hosted Laravel CMS, the markup ships with the page render rather than getting injected by a third-party script after load.

OG Images: The Social Layer

Open Graph images don't affect rankings, but they decide whether your link gets clicked when shared — and shares are how content earns the links that do affect rankings.

The spec is short:

• 1200×630 pixels (1.91:1) — the size every major platform renders without cropping
• Under 1 MB, ideally under 300 KB
• Readable at thumbnail size — title text at 60px+, high contrast, no fine detail
• Set per post via og:image, with a site-wide default as fallback

A blank or default OG image on a shared link reads as neglect. It's the favicon problem at ten times the size.

Hosting: Same Domain or CDN?

Where images live affects both speed and attribution. Three workable setups:

1. Same domain (example.com/media/...) — simplest, keeps all image authority on your domain, fine for most blogs behind a caching proxy like Cloudflare.
2. Subdomain or CDN with your hostname (cdn.example.com) — faster global delivery, still clearly yours.
3. Third-party CDN domain (images.somecdnprovider.net) — fastest to set up, but image search results credit the CDN's hostname, and migrating off later means redirecting every image URL.

For a typical self-hosted blog, option 1 with edge caching in front wins on simplicity: one domain to manage, no CORS quirks, no attribution leak. Where your images live is also tangled up with how your CMS stores them — the flat-file vs database CMS question shapes whether media is just files on disk or rows plus a storage layer.

Whatever you choose, choose once. Image URL migrations are the renaming problem from earlier, multiplied by your entire media library.

The Checklist

Image SEO is unglamorous and almost entirely mechanical, which is exactly why it works — most competitors won't do it. Before you publish your next post:

1. File names: descriptive, hyphenated, set before upload
2. Alt text: 5-15 words per informative image, alt="" for decorative ones
3. Format: WebP (AVIF where your pipeline supports it), JPEG fallback, SVG for diagrams
4. Weight: 100-200 KB per content image, served at display size via srcset
5. Loading: loading="lazy" below the fold, fetchpriority="high" on the LCP image
6. Context: captions and adjacent text that match the image
7. Plumbing: image in the sitemap, image in the BlogPosting JSON-LD, 1200×630 OG image

Half of these belong in your publishing platform, not your memory. The other half take thirty seconds per image. Both halves compound with every post you ship.