How to Do Image SEO: The Accessibility-First Guide

Here’s how to do image SEO in one honest sentence: write alt text that genuinely describes each image for the people who can’t see it, make your images as light as they can be without looking worse, and give them descriptive file names on pages that clearly cover the topic — in that order. Image SEO is really three disciplines wearing one trench coat: accessibility, performance, and discoverability. And the lovely secret is that when you do the accessibility work first, the other two layers mostly fall into place behind it.

Okay, let’s be honest with each other for a second. Most image SEO advice is written backwards. It starts with “stuff your keyword into the alt attribute,” wanders through a list of plugins, and never once mentions the actual human being using a screen reader who has to listen to “best-crm-software-2026-top-crm-tools-crm” read aloud. That version of image SEO fails blind users and reads as spam to search engines. We’re going to do the version that works for everyone — and I promise it’s less work, not more.

What is image SEO, really?

Image SEO is everything you do so that the images on your site help rather than hurt — help the people reading (and listening to) your pages, help the page load fast, and help search engines understand and surface your content. Those are three different jobs, and most guides smush them into one checklist without telling you which items serve which job.

So let’s un-smush them. The three layers, in the order you should care about them:

• The accessibility layer. Alt text, decorative-image handling, and captions. This is about people first — and it happens to be the layer search engines lean on most to understand what an image shows.
• The performance layer. File formats, dimensions, compression, and loading behavior. On most pages, images are the single heaviest category of bytes, which makes them the biggest lever you have on page speed.
• The discoverability layer. File names, surrounding context, image sitemaps, and structured data. This is the part that helps your images show up in image search and rich results — and it only works when the first two layers are solid.

Why this order? Because the accessibility layer forces you to actually think about what each image is and whether it earns its place. Once you’ve done that thinking, performance decisions get easier (that decorative flourish probably doesn’t need to be a 900 KB PNG) and discoverability gets honest (the file name describes the image because you just wrote a description of it). Accessibility-first isn’t a moral flourish bolted onto an SEO tactic. It’s the workflow that makes the whole thing coherent.

One more framing note before we dive in: image SEO sits inside your larger content strategy, not beside it. Images rank in the context of pages, and pages rank in the context of a site that demonstrably knows its subject. If you’re building that larger structure, my guide on how to build topical authority is the pillar this piece hangs from — images are one of the signals that make a deep page feel genuinely deep.

Why does accessibility come first in image SEO?

Because alt text has a primary audience, and it isn’t Google. It’s a person using a screen reader, a person on a connection so slow the images never loaded, or a person whose browser choked on your CDN. For them, the alt text is the image. Write it for them, and you’ve automatically written something a search engine can understand too. Write it for the algorithm, and you’ve often ruined it for both.

Write alt text for people, honestly and usefully

Good alt text describes what the image shows and why it’s there, in roughly a sentence. Not a keyword list. Not “image of.” Just the honest answer to: if I were reading this aloud to a friend over the phone, what would I say when I hit this picture?

A few contrasts to make it concrete:

• Weak: alt="coffee shop marketing social media marketing small business" — that’s a keyword pileup. A screen reader user hears gibberish; a search engine sees a spam pattern.
• Strong: alt="Barista writing the day's latte special on a chalkboard easel outside a café" — descriptive, specific, naturally includes relevant words because the image is actually relevant.
• Weak: alt="chart" — technically present, practically useless.
• Strong: alt="Line chart showing website visits rising steadily from January to June, with a sharp spike in April" — someone who can’t see the chart now knows what it says.

Here’s the part nobody tells you: keyword-stuffed alt text is one of the rare tactics that fails on every axis at once. It fails blind users, who have to sit through it. It fails sighted users when the image breaks and the gibberish renders on screen. And it fails as SEO, because keyword-crammed attributes are an old, well-known spam signal. There is no trade-off here. People-first alt text is simply the correct move, full stop. I’ve written a much deeper companion piece on how to write alt text for images — if alt text is your weak spot, start there, because it’s the single highest-leverage skill in this entire article.

Give decorative images an empty alt — that’s the honest exception

Not every image carries information. The abstract gradient behind your heading, the swooshy divider, the purely atmospheric stock texture — these are decoration, and the accessible, correct markup is an empty alt attribute: alt="". That tells screen readers to skip the image entirely, which is exactly what a sighted user’s brain does with decoration.

This trips people up because it feels like leaving SEO value on the table. It isn’t. An empty alt on a decorative image is honest markup; a keyword jammed into a decorative image’s alt is noise at best and spam at worst. The skill is deciding which bucket an image belongs in: ask “would someone who can’t see this miss anything that matters?” If the answer is no, empty alt. If yes, describe it.

Use captions when they add real information

Captions are visible to everyone, so they’re not an alt-text substitute — they’re a bonus layer. Use one when there’s context worth giving every reader: who’s in the photo, where it was taken, what the diagram’s takeaway is. Skip the caption when it would just restate the obvious. And please don’t duplicate your alt text word-for-word into a caption; screen reader users get it read twice, and nobody enjoys déjà vu they didn’t order.

How do you fix the performance layer?

Now the layer your visitors feel in their thumbs. On a typical page, images account for more of the transferred bytes than any other resource type — more than your scripts, more than your fonts, more than the HTML itself. That makes images the first place to look when a page is slow, and page speed feeds directly into Core Web Vitals, which is its own rabbit hole. (I’ve got a full walkthrough on how to improve Core Web Vitals if you want the whole picture — this section is the images-only slice of it.)

Serve modern formats, pragmatically

WebP and AVIF compress dramatically better than old-school JPEG and PNG at comparable visual quality. Browser support for WebP has been effectively universal for a while now, and AVIF support has become broad across modern browsers — though I’d gently suggest you verify the current support picture for your actual audience before going AVIF-only, because audiences with older devices and browsers still exist. The pragmatic play most sites land on:

• Serve WebP as your workhorse format — the compatibility risk is minimal for most audiences.
• Layer in AVIF via the <picture> element or your CDN’s automatic format negotiation, so browsers that support it get the smaller file and everyone else gets a fallback.
• Keep PNG for the few things that need it (sharp-edged UI screenshots, transparency where WebP isn’t an option in your pipeline) and SVG for logos, icons, and simple diagrams — vectors stay crisp at any size and are usually tiny.

If your CMS, CDN, or image service can convert formats automatically, let it. This is a solved problem you should configure once, not a craft you should practice nightly.

Serve the size the screen actually needs

The classic crime scene: a 4000-pixel-wide photo, straight off a phone camera, squeezed into a 300-pixel-wide column. The browser downloads megabytes it will never show. Nobody notices on office Wi-Fi; everybody suffers on a train.

The fix is responsive images: export or generate multiple sizes of each image and use srcset (or your CMS’s built-in equivalent — WordPress does this automatically for uploaded images) so the browser picks the size that fits the slot and the screen. Your part of the job is mostly upstream: don’t upload a 6 MB original and trust the system to cope. Resize to a sensible maximum — for most blog layouts, something in the 1200–2000 pixel width range covers even large displays — and let the responsive machinery generate the smaller variants.

Compress honestly — down to the visible-quality floor, not through it

Compression has a floor, and the floor is visible quality. Squeeze a lifestyle photo from 400 KB to 120 KB and nobody can tell; squeeze it to 25 KB and your product shots look like they were faxed. The honest rule: compress until just before you can see the difference at the size the image is actually displayed, then stop. For product photography especially, resist the urge to chase the smallest possible number — a mangled product photo costs you trust that no page-speed gain buys back. Images of text, fine patterns, and detailed charts degrade fastest, so give those a lighter touch or use SVG/PNG where appropriate.

Lazy-load below the fold — never the hero

Native lazy loading (loading="lazy") tells the browser to defer images until the reader scrolls near them. Use it on everything below the first screenful — it’s free performance. But never lazy-load the hero image or anything visible on first paint. Your hero is very often the Largest Contentful Paint element, and lazy-loading it tells the browser to delay the exact thing your LCP score is waiting for. It’s the single most common self-inflicted vitals wound I see: a well-meaning plugin set to “lazy-load all images” quietly throttling every page’s hero. Exempt the hero, eagerly load it, and let everything downstream be lazy.

How to do image SEO for discoverability?

With people served and pages fast, now we get to the layer most guides start with: helping search engines find, understand, and surface your images. This layer matters — but it only compounds on top of the first two. A perfectly named, structured-data-wrapped image that’s 3 MB with no alt text is still a liability.

Give files descriptive names

Somewhere on your server is a graveyard of IMG_4032.jpg, Screenshot-2024-11-03-at-9.41.17-AM.png, and final-final-v2.png. File names are a small but genuine context signal, and they’re also the URL your image lives at in image search results. The habit is easy going forward: name the file for what it shows, in a few lowercase hyphenated words, before you upload. barista-chalkboard-latte-special.jpg beats IMG_4032.jpg for the crawler, for your own media library search, and for the human who sees the URL.

Notice I said going forward. What you should not do with the existing graveyard is mass-rename old files — we’ll get to that trap in the audit section, because it breaks things in ways that are genuinely annoying to undo.

Let the surrounding page do the heavy lifting

Here’s a quietly important truth: images mostly rank for what the page is about. The headline near the image, the paragraph around it, the page’s overall topic — that context tells search engines what the image means far more reliably than any single attribute. Which is why a relevant image embedded in a genuinely useful article outranks the same image on a thin page, every time. If your pages deeply cover their topics, your images inherit that clarity. If your pages are thin, no amount of image metadata rescues them. Image SEO, it turns out, is mostly just SEO.

Use image sitemaps and structured data where they genuinely apply

Two mechanical helpers, both situational:

• Image sitemaps (or image entries in your regular sitemap) help crawlers find images they might otherwise miss — most useful on image-heavy sites or where images load via JavaScript. Most WordPress SEO plugins handle this automatically; check yours before adding anything.
• Structured data matters most where images feed rich results: product markup with product images, recipe markup with dish photos, article markup with featured images. If you sell things or publish recipes, this is worth real attention. If you write B2B service pages, it’s a smaller win. Since eligibility rules and supported result types change over time, verify the current requirements in Google’s documentation for your content type rather than trusting any article’s snapshot — including mine.

The honest ceiling: image search traffic varies wildly by niche

I need you to hear this before you invest a weekend: the payoff from image search is dramatically uneven. Recipes, products, home décor, fashion, travel, crafts, charts people love to cite — visual niches can see image search become a real acquisition channel. B2B services, local plumbing, consulting? People simply don’t shop for those through image search much, and image SEO there mostly pays off through the accessibility and performance layers instead.

So no, I won’t promise that image SEO will transform your traffic, and you should squint at anyone who does. The method to find your answer: open Google Search Console, switch the performance report’s search type to “Image,” and look at what image search already sends you. If it’s meaningful, invest more. If it’s a rounding error, do the accessibility and performance layers anyway — they pay regardless — and keep the discoverability layer to good habits rather than heroic efforts.

Do your own images really beat stock photos?

Yes — and the gap is widening. The same smiling-team-at-whiteboard stock photo appears on thousands of sites. It adds no information, it’s invisible to image search in any way that benefits you specifically, and readers’ eyes have learned to slide right past it. Your real photos, your actual product shots, your own screenshots and diagrams do the opposite: they carry information nobody else has, they’re unique by definition, and they signal that a real person with a real camera (or a real screen) stands behind the page.

That trust signal matters more now than ever. As AI-generated content floods the web — words and pictures alike — genuine imagery is becoming one of the clearest ways to show readers there’s a real operation behind the site. A slightly imperfect photo of your actual workspace outperforms a flawless synthetic render precisely because it’s verifiably real. Original visuals are also the images other sites actually link to and cite: nobody ever earned a backlink with a stock photo of a handshake, but a clear original diagram explaining a tricky concept gets referenced for years.

On AI-generated imagery, since you’ll be tempted: used openly for illustration and concept art, it’s a legitimate tool. But where an AI image is photorealistic — where a reader could mistake it for a photograph of something real — disclosure norms are tightening, and quietly passing synthetic images off as photography is the kind of trust debt that compounds. If it looks like a photo but isn’t, say so. Your credibility is worth more than the illusion.

What about image licensing?

The unglamorous corner that keeps you out of trouble. Three rules cover almost everything:

• Use what you have rights to. Stock licenses are real contracts — know whether yours covers commercial use, and keep records of where each licensed image came from. “I found it on Google Images” is not a license; it’s how small businesses end up with startling invoices from image-rights enforcement firms.
• Do Creative Commons properly. CC-licensed images are a gift, but most CC licenses require attribution — typically the title, creator, source, and license, linked. A caption or credits line handles it gracefully. Attribution done right costs you thirty seconds; attribution skipped converts a free image into an infringement.
• Never hotlink other people’s images. Embedding an image directly from someone else’s server steals their bandwidth, breaks your page the moment they move or delete the file (or swap it for something you really don’t want on your site — a classic retaliation), and gives you zero control. Host your own copies of anything you have the right to use.

What does image SEO look like in WordPress?

WordPress already does more than people realize: it generates multiple sizes of every upload, builds srcset automatically, and (in current versions) lazy-loads images natively. Your job is to fill the gaps with one image-optimization approach, configured properly — either a single reputable optimization plugin (handling compression, WebP/AVIF conversion, and sensible lazy-loading exemptions) or an image CDN that does the same at the edge. Pick one. Configure the hero-image exemption. Done.

The failure mode I see constantly is the plugin pileup: an optimizer from 2021, a second one added when the first “stopped working,” a caching plugin that also touches images, and a page builder with its own lazy-loader — all fighting over the same files. The result is double-compressed murky images, heroes that lazy-load twice, and a site that’s somehow slower than before anyone optimized anything. If that’s you, the fix is subtraction: choose the one tool that covers your needs, configure it deliberately, and remove the rest. One approach, configured properly, beats four approaches fighting.

How do you audit the images you already have?

New habits fix new uploads; the audit fixes the backlog. Work it in this order so effort lands where it matters:

1. Find the heaviest pages first. Run your most-visited pages (analytics tells you which) through PageSpeed Insights or your preferred auditing tool and sort by image weight. A 2 MB hero on your top landing page matters more than fifty mediocre images on posts nobody reads. Fix the top offenders — resize, recompress, convert format — and you’ll bank most of the available win in an afternoon.
2. Run the missing-alt sweep. Most SEO crawlers and accessibility checkers (and several WordPress plugins) will list every image missing alt text. Work through the list people-first: write honest descriptions for informative images, set empty alt on decorative ones. Prioritize your highest-traffic pages, then templates (logos, shared headers), since fixing a template fixes every page at once.
3. Fix file-name hygiene going forward — and mind the rename trap. Adopt descriptive names for everything new, starting today. But do not mass-rename your existing library: renaming a file changes its URL, which breaks every existing embed, kills any image-search rankings those files earned, and 404s any external sites linking to them — unless you set up redirects for every single rename, which is almost never worth it for ordinary images. Old mediocre names on images that work are fine. Reserve renames for images you’re replacing anyway, and redirect when a renamed image had real traffic or links.

What’s the complete image SEO system, on one card?

Everything above, condensed into the three artifacts you’ll actually use.

The three-layer checklist

Layer	What to do	Who it serves
1. Accessibility	Honest, specific alt text for informative images; alt="" for decorative ones; captions only when they add information	People first — and search engines understand the image through the same words
2. Performance	WebP/AVIF with fallbacks; sized for the slot (srcset); compressed to the visible-quality floor; lazy-load below the fold, eager hero	Every visitor, every connection — and your Core Web Vitals
3. Discoverability	Descriptive file names on new uploads; images embedded in genuinely relevant content; sitemaps/structured data where your niche earns rich results	Image search and rich results — payoff varies by niche, so check Search Console before investing heavily

The image pre-publish card

Pin this next to your publish button and run it on every image, every post:

• Does this image earn its place — information, evidence, or genuine visual relief?
• Alt text written for a person, or alt="" if it’s decoration?
• File named descriptively before upload (lowercase, hyphens, says what it shows)?
• Resized to a sensible maximum width and compressed — still looks good at display size?
• Modern format (or auto-conversion confirmed working)?
• Hero eager, everything below the fold lazy?
• Rights confirmed — licensed, attributed if CC, hosted on your own server?
• Caption only if it adds something the reader needs?

The worst-offenders audit workflow

• Monthly (30 minutes): run your top ten pages through PageSpeed Insights; fix any image flagged as oversized or slowing LCP.
• Quarterly (half a day): full missing-alt crawl; write or empty-alt everything on high-traffic pages and shared templates. Check Search Console’s Image search type to see whether discoverability investment is paying off in your niche.
• Ongoing: new uploads follow the pre-publish card, no exceptions. Never mass-rename old files; rename only on replacement, with redirects when the old URL earned traffic or links.

One honest aside before the FAQ, because it trips people up: the images you optimize for your website and the images you attach to social posts are different animals — social networks ignore your alt-text-and-srcset craftsmanship and want their own dimensions, crops, and per-platform specs. That’s its own discipline with its own checklist.

FAQ: how to do image SEO

Should I put my keyword in every image’s alt text?

No. Write alt text that honestly describes the image; include the keyword only when it’s a natural part of that description. Keyword-stuffed alt text fails screen reader users and reads as spam to search engines — it loses on both fronts at once.

Which image format should I use in 2026?

WebP is the safe workhorse with near-universal support, with AVIF layered in via the picture element or CDN negotiation for browsers that support it. Keep SVG for logos and diagrams, and PNG for the rare case that needs it. Verify current browser support for your actual audience before going all-in on any single format.

Does image SEO really bring traffic?

It depends heavily on your niche. Visual categories like recipes, products, and travel can earn real image search traffic; B2B services usually see modest direct gains. Check the Image search type in Google Search Console to see what image search already sends you, and let that guide how much you invest in the discoverability layer. The accessibility and performance layers pay off regardless.

Should I rename all my old image files to be more descriptive?

No — mass-renaming changes every image URL, which breaks existing embeds and loses any rankings or links those files earned. Use descriptive names for everything new going forward, and only rename old images when you’re replacing them anyway, adding redirects if the old URL had real traffic.

Is lazy loading good or bad for SEO?

Both, depending on where you apply it. Lazy-loading images below the fold is nearly free performance. Lazy-loading your hero image is actively harmful, because the hero is usually the Largest Contentful Paint element and deferring it delays the exact milestone your Core Web Vitals score measures. Lazy-load everything except what’s visible on first paint.