# Blog Image SEO: Alt Text, File Names, WebP, and What Actually Matters (2026)
Author: Sai Krishna
Author URL: https://superblog.ai/blog/author/sai-krishna/
Published: 2026-08-07
Meta Title: Blog Image SEO: What Actually Matters | Superblog
Meta Description: Blog image SEO in practice: alt text, descriptive file names, WebP, lazy loading rules, image sitemaps, and schema, ranked by what moves rankings.
URL: https://superblog.ai/blog/blog-image-seo/
Blog image SEO comes down to five things, in this order of impact: keep your hero image from wrecking Largest Contentful Paint, give every file a descriptive name and honest alt text, serve modern formats at the right size, surround images with relevant text and captions, and make sure search engines can discover them through standard HTML and an image sitemap. Everything else is refinement.
Most image SEO advice inverts that order. It opens with alt text keywords and treats page weight as a footnote. That is backwards. A 2 MB hero image costs you rankings across every query the page targets. A slightly weaker alt string costs you a sliver of image-search visibility on one image. Fix the expensive thing first.
## Blog image SEO: how images actually affect rankings
Images influence rankings through three separate channels, and they do not carry equal weight.
### Speed, because your hero image is usually the LCP element
Largest Contentful Paint measures when the biggest visible element finishes rendering. On a typical blog post, that element is the featured image sitting at the top of the article. Which means your image pipeline is not a side quest. It is the primary determinant of one of the three Core Web Vitals, and page experience signals apply to the whole URL, not just to the image.
This is the part of image work with the largest payoff, and the reason it belongs at the top of any [Core Web Vitals fix list](/blog/blog-core-web-vitals/). An unoptimized hero image is the single most common cause of a failing LCP on content sites.
### Image search as its own traffic channel
Google Images is a distinct surface with its own results. Google's image documentation is explicit that sharp, high-quality images perform better as result thumbnails and can increase the likelihood of drawing traffic. For blogs publishing original charts, screenshots, and product photography, this is real incremental traffic. For blogs illustrated entirely with stock photos that thousands of other sites also use, it is close to zero. Be honest about which one you are.
### Accessibility overlap
Alt text exists so screen readers can describe images to people who cannot see them. Search engines read the same attribute to understand image subject matter. The two goals almost always point the same way, which is why the correct instruction for alt text is an accessibility instruction, not an SEO one.
## Alt text done right
Write alt text as though you are describing the image out loud to someone who cannot see it, in one sentence, with enough specificity that they would not need to ask a follow-up question.
That single rule produces good SEO output as a byproduct. Compare:
- **Bad:** `alt="seo"`
- **Bad:** `alt="blog image seo, image seo tips, seo images, optimize images for seo"`
- **Weak:** `alt="chart"`
- **Good:** `alt="Line chart showing organic sessions rising from 4,000 to 19,000 over twelve months"`
The second example is the one Google's image documentation warns against by name. Filling alt attributes with keywords is called out as keyword stuffing, described as a negative user experience, and flagged as something that can get a site treated as spam.
### When the keyword belongs in alt text
When it is the honest description. A screenshot of an image sitemap in Search Console legitimately gets `alt="Image sitemap submitted in Google Search Console"`, because those are the words that describe the picture. A stock photo of a laptop on a desk does not, and forcing your target keyword in is both dishonest and useless.
Practical guidance: aim for 8 to 16 words. Do not start with "Image of" or "Picture of," since assistive technology already announces that it is an image. Do not repeat the same alt string across multiple images on one page.
### Decorative images get empty alt
If an image carries no information, such as a background texture, a divider flourish, or an icon sitting next to a text label that already says the same thing, give it `alt=""`. An empty alt attribute tells screen readers to skip the image. Omitting the attribute entirely is different and worse, because some screen readers then fall back to reading the file name aloud. Empty alt is a deliberate signal. A missing alt is an accident.
## File names and structure
Google's documentation is unusually direct here: use short, descriptive file names, and its own example is that `my-new-black-kitten.jpg` beats `IMG00023.JPG`. That is the entire rule.
In practice:
- Lowercase, hyphen-separated words. Not underscores, not spaces, not camelCase.
- Describe the content, not the workflow. `blog-image-seo-checklist.webp`, not `final-v3-approved.webp`.
- Three to six words is plenty. A twelve-word file name is not more descriptive, only longer.
- Strip camera defaults at upload. `IMG_4032.JPG` and `Screenshot 2026-08-04 at 11.42.17.png` both carry zero information, and the second contains spaces that get percent-encoded into an ugly URL.
Keep image URLs stable once published. Google notes that consistent image URLs improve caching efficiency, and on top of that, an image that has accumulated ranking history in image search loses it when the URL changes. If you must move images, redirect the old URLs rather than letting them 404.
One structural rule that catches people out: embed images with HTML `![]()
` elements. Google's guidance is that HTML image elements are what gets discovered and indexed. Images loaded purely as CSS backgrounds are decorative as far as image search is concerned, so if a picture matters, it belongs in the markup.
## Format and compression
Google supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF. Format choice is about file size at acceptable quality, not about a ranking bonus for any particular extension.
- **WebP** is the sensible default for photographs, screenshots, and most blog imagery in 2026. Browser support is effectively universal and it produces smaller files than JPEG at equivalent visual quality.
- **AVIF** compresses better still, with WebP or JPEG as a fallback.
- **JPEG** remains a valid fallback for photographic content in older pipelines.
- **PNG** only when you need lossless output. Transparency alone is not a reason, since WebP supports it.
- **SVG** for logos, icons, and line diagrams. Resolution independent and usually tiny.
Target under 100 KB for a hero image and under 50 KB for inline images. Those are working targets, not laws, but if your featured image is over 300 KB you have a problem worth an afternoon. The compression mechanics and the wider speed stack are covered in more depth in the [Core Web Vitals guide](/blog/blog-core-web-vitals/) and in the breakdown of [why WordPress blogs run slow](/blog/wordpress-speed/).
### Lazy loading, and the one image you must never lazy-load
Lazy loading defers offscreen images until the reader scrolls toward them. Below the fold, it is straightforwardly good: fewer bytes, faster initial render.
Applied to your hero image, it is actively harmful. `loading="lazy"` on the LCP element delays the exact paint LCP measures, because the browser must run layout before deciding to fetch. Google's own web.dev analysis of WordPress found that lazy-loading images inside the initial viewport regressed LCP, and that exempting above-the-fold images reversed it while keeping the byte savings everywhere else.
So the rule is two-sided:
- Above the fold: no `loading="lazy"`. Consider `fetchpriority="high"` on the LCP image so the browser fetches it before lower-priority assets.
- Below the fold: `loading="lazy"` on everything.
This is one of the most common self-inflicted SEO wounds on blogs, because plugins and themes often apply lazy loading globally without exempting the first image.
### Explicit width and height
Set `width` and `height` attributes (or an equivalent CSS aspect ratio) on every image. Without them the browser cannot reserve space, so text renders and then jumps down when the image arrives. That jump is Cumulative Layout Shift, and images without dimensions are its leading cause on blogs.
## Responsive images
A single 1600px image served to a 390px phone screen wastes most of the bytes it downloads. Responsive images fix that by offering the browser a set of sizes and letting it pick.
```html html
```
The `srcset` lists candidate files with their widths, `sizes` tells the browser how much space the image will occupy, and the browser downloads exactly one. Google asks you to keep a plain `src` fallback when using `srcset` or ``, so crawlers and older clients always have something to resolve.
You should not be hand-writing this per post. If you are, that is a signal about your platform, not about your diligence.
## Image sitemaps and structured data
Google's position on image sitemaps is that they surface images it might not otherwise discover. For a blog where every image sits in an `![]()
` tag inside crawlable HTML, an image sitemap is a safety net rather than a necessity. It earns its place when images are served from a separate CDN hostname or loaded through JavaScript, which is exactly when discovery gets unreliable.
For structured data, two things are worth knowing:
**Article and BlogPosting schema carry an `image` property.** This is the one that matters for most blogs, because it feeds rich result eligibility for the post itself. The [blog schema markup guide](/blog/blog-schema-markup-guide/) covers the full set.
**Standalone `ImageObject` markup with licensing metadata.** Google supports this for the Licensable badge in Google Images. It requires `contentUrl` plus at least one of `creator`, `creditText`, `copyrightNotice`, or `license`, and a `license` URL is what earns the badge. Worth implementing if you publish original photography others might want to license. For a SaaS blog running screenshots and charts, it is not a priority.
You can also nominate the image Google should prefer for a page using the schema.org `primaryImageOfPage` property or an `og:image` meta tag.
## Captions and surrounding context
Google extracts information about an image's subject matter from the content of the page around it, explicitly including captions and image titles. This is the most underused part of image SEO, because it costs nothing.
Three things follow:
- **Place images next to the text they illustrate.** An image dumped between two unrelated paragraphs has no context to inherit. Google's guidance asks you to place images near relevant text on topic-appropriate pages.
- **Write real captions.** Unlike alt text, a caption is visible, so it earns its keep with readers and crawlers both. Use it to state what the reader should notice, not to restate the alt text.
- **Reference the image in body copy.** A sentence like "the chart below breaks traffic out by source" gives the image a textual anchor.
This is the same discipline that wins [featured snippets](/blog/featured-snippets-for-blogs/): make the relationship between question, answer, and supporting visual unambiguous on the page.
## The manual checklist vs. what a platform handles
Here is the honest accounting of what the above costs you per image on a plugin-assembled stack: rename the file, compress it, convert to WebP, generate three or four sizes, write `srcset` and `sizes`, exempt the hero from lazy loading, set width and height, write alt text, write a caption, confirm the sitemap picked it up.
Nine steps, most of them mechanical, repeated on every image in every post by whoever is writing that day. It does not survive contact with a real publishing schedule, and it degrades the moment a new writer joins or a plugin updates.
Superblog handles the mechanical layer at upload. Images are automatically converted to WebP with a JPEG or PNG fallback, compressed, lazy-loaded below the fold with the first image prioritized, and delivered from a CDN with 200+ edge locations. XML sitemaps and JSON-LD schema, including Article and FAQ, are generated on every deploy. That is why Superblog blogs hold 90+ Lighthouse performance scores without anyone running an image pipeline.
What stays with you is the part requiring judgment: choosing an image worth including, describing it accurately, and writing a caption that tells the reader something. Software should not be guessing what your chart shows, and you should not be hand-converting PNGs at 11pm.
If you need original featured images to work with, the free [featured image creator](/featured-image-creator) generates blog and social sharing images from templates. For the wider on-page picture, the [blog SEO checklist](/blog/blog-seo-checklist/) covers where image work sits relative to everything else you do before hitting publish.
Superblog starts at $49/month with a 7-day free trial, no credit card required.
## Frequently asked questions
### How do I optimize images for SEO?
Work in impact order. Compress and convert the image to WebP or AVIF and keep the hero under 100 KB, since it is usually your LCP element. Give it a descriptive hyphenated file name. Set explicit width and height to prevent layout shift. Never apply `loading="lazy"` to the above-the-fold image, and apply it to everything below. Write alt text that accurately describes the image. Add a caption and place the image beside the text it illustrates. Serve responsive sizes with `srcset`.
### Does alt text help SEO?
Yes, but narrowly and indirectly. Alt text is the primary way search engines understand what an image depicts, which affects image search visibility and contributes to the page's topical context. It is not a ranking lever for the page's main keyword. Google's documentation warns directly against stuffing alt attributes with keywords, noting it can cause a site to be seen as spam. Describe the image accurately and the SEO benefit follows.
### What image format should I use on a blog in 2026?
WebP for photographs and screenshots, AVIF where your pipeline supports it, SVG for logos and line diagrams, and PNG only when you need lossless output. Google supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF, so the choice is purely about file size at acceptable quality.
### Should every image have alt text?
Every image needs an `alt` attribute, but not every image needs words in it. Informative images get a description. Purely decorative images, such as background textures and dividers, get `alt=""`, which tells screen readers to skip them. Leaving the attribute off entirely is the one option to avoid, because some screen readers then read the file name aloud.
### Do I need an image sitemap?
Usually not, if your images are embedded as standard `![]()
` elements in crawlable HTML. Google describes image sitemaps as a way to surface images it might not otherwise find. They earn their place when images live on a separate CDN hostname or are injected by JavaScript, since that is where discovery gets unreliable.
### Does lazy loading hurt SEO?
Only when it is applied to the wrong image. Lazy-loading offscreen images reduces page weight and helps performance. Lazy-loading the above-the-fold hero image delays the paint that Largest Contentful Paint measures. Google's web.dev analysis of WordPress found that lazy loading images inside the initial viewport regressed LCP, and that exempting above-the-fold images fixed it.
### How many images should a blog post have?
There is no ranking threshold to hit. Add an image when it explains something words handle poorly, such as a process, a comparison, a data set, or an interface. Stock photos added to break up text carry no informational value, is unlikely to rank in image search because the same file appears on hundreds of other sites, and still cost you bytes.
---
This blog is powered by Superblog. Visit https://superblog.ai to know more.
---