Image SEO: Alt Text, File Names, Formats, and Speed

On-Page SEO

Image SEO: Alt Text, File Names, Formats, and Speed

Images are the most neglected ranking asset on most websites. Google can’t see a picture the way you do — it reads the file name, the alt text, the surrounding copy, and the file size. This is the checklist I run on every single image before it goes live.

Updated August 2026 · 14 min read

A few years ago I audited a photography blog that published gorgeous original shots three times a week — and got almost zero traffic from Google Images. The reason took about thirty seconds to spot: every file was still called IMG_2047.jpg, straight off the camera, with empty alt attributes and uncompressed files weighing 6 to 9 megabytes each. The photos were excellent. Everything around the photos was invisible.

That pattern repeats on most sites I look at, from hobby blogs to small business pages. People spend real effort on the headline and the body copy, then drag a stock photo into the page and call it done. Meanwhile, Google Images drives a meaningful slice of search traffic in visual niches — recipes, DIY, travel, products, tutorials — and the page-speed penalty from bloated images drags down rankings in regular search too, through Core Web Vitals.

The good news: image SEO is the most checklist-friendly part of on-page optimization. There are no judgment calls about intent or content depth. It’s a fixed set of mechanical steps that take about ninety seconds per image once you’ve done them a few times. This guide walks through each step in the order I actually do them, with the specific numbers and settings I use.

Why image SEO is worth the ninety seconds

Three separate benefits stack up from properly optimized images, and people usually only think about the first one.

First, image search itself. Google Images is a real discovery channel, and for some topics it’s the dominant one. Someone planning a kitchen remodel or looking for a specific plant pest is searching visually. If your images rank there, they click through to your page — and image search visitors who find exactly the visual they wanted tend to stay.

Second, page speed. Images are almost always the heaviest thing on a page. On a typical blog post the hero image alone outweighs all the HTML, CSS, and fonts combined. Oversized images are the number one cause of a poor Largest Contentful Paint score, which is one of the Core Web Vitals Google uses as a ranking input. Fix your images and you’ve usually fixed the worst of your speed problems — there’s a full walkthrough in my Core Web Vitals fix guide if you want the broader picture.

Third, accessibility. Alt text exists primarily for screen readers. Sites that take it seriously serve visually impaired visitors better, and accessibility practices correlate strongly with the technical quality signals Google rewards. Doing right by readers and doing right by rankings are the same action here.

Google doesn’t rank your image. It ranks the text around your image — the file name, the alt attribute, the caption, the page itself. Your job is to make that text honest and descriptive.

Step 1: Pick the right format before anything else

Format choice happens before you write a word of alt text, because it determines your file size. Here’s the short version of a long debate:

Format Use it for Avoid it for
WebP Almost everything — photos, illustrations, screenshots. 25-35% smaller than JPEG at the same quality. Nothing, unless your tooling is ancient. Browser support is universal now.
JPEG Photos when your CMS or workflow can’t produce WebP. Screenshots, logos, anything with sharp text or flat color — it smears the edges.
PNG Screenshots, diagrams, images needing transparency, anything with crisp text. Photographs — a PNG photo is often 5-10x the size of the same image as JPEG/WebP.
AVIF Maximum compression (often 50% smaller than JPEG) when you control the pipeline. Situations where you need dead-simple compatibility or quick manual edits.
SVG Logos, icons, simple illustrations — infinitely scalable, tiny files. Anything photographic or complex; also, only upload SVGs you trust (they can contain scripts).

The single most common mistake I see is saving photographs as PNG. Someone takes a screenshot of a chart (correctly saved as PNG), then saves a stock photo the same way out of habit. That 400 KB photo just became 3.2 MB for zero visual benefit. Photos go in WebP or JPEG. Screenshots and text-heavy graphics go in PNG or WebP. Logos and icons go in SVG. Commit that to memory and you’re ahead of most of the web.

Step 2: Resize to display dimensions

This is the step almost everyone skips, and it’s the biggest file-size win available. If your content column displays images at 780 pixels wide, there is no reason to upload a 4000-pixel-wide original. The browser downloads all 4000 pixels’ worth of data and then squishes it down. The visitor pays the loading cost and gets nothing for it.

My rule: find the maximum width at which an image will ever appear on your site, and export at exactly 2x that width (the 2x covers retina/high-DPI screens, which need double the pixel density to look sharp). For most blog layouts that’s 1,560 to 1,920 pixels wide. A full-width hero might justify 2,560. Anything beyond that is waste.

You don’t need Photoshop for this. On a Mac, Preview resizes fine (Tools → Adjust Size). On Windows, the Photos app or Paint.NET does it. Or use a free web tool like Squoosh, which also converts to WebP in the same step and shows you a live before/after quality comparison. The whole operation takes twenty seconds.

Step 3: Compress to a sane file size

Even after resizing, an exported image is usually carrying 30-60% more data than it needs to. Compression strips that out. Run every image through a compressor — Squoosh, TinyPNG, ImageOptim, or a build-tool plugin if you’re technical — and use these targets as your ceiling:

  • Hero/featured images: under 150 KB, ideally under 100 KB. This is usually your LCP element, so it matters most.
  • In-article photos: under 100 KB each.
  • Screenshots: under 80 KB (PNG compresses beautifully when there’s lots of flat color).
  • Thumbnails and logos: under 30 KB.
  • Total image weight per page: under 500 KB if you can manage it, under 1 MB as a hard ceiling for a normal article.

Quality settings: for JPEG and WebP, quality 75-85 is the sweet spot. Below 70 you’ll start seeing artifacts in gradients and skin tones; above 90 you’re paying a lot of bytes for differences nobody can see. When in doubt, export at 80 and look at it at full size. If you can’t tell it apart from the original, ship it.

Quick tipCheck your current pages right now: open a post in Chrome, right-click an image, “Open image in new tab,” and look at the file size in the dev tools network panel. If your photos are over 300 KB, compression alone will probably cut your page weight in half.

Step 4: Write a real file name before you upload

The file name is the first piece of text Google reads about your image, and it’s set in stone the moment you upload — changing it later usually means re-uploading and breaking the old URL. Get it right on your computer, before the file ever touches your CMS.

The rules are simple:

  • Describe what’s in the image. golden-retriever-puppy-sleeping-on-rug.webp tells Google something. IMG_2047.jpg tells it nothing.
  • Use hyphens between words, never underscores or spaces. Google treats hyphens as word separators; underscores join words together into one unreadable blob. Spaces get encoded as %20 and look broken.
  • Keep it short — three to six words. white-ceramic-coffee-mug-wooden-table.webp is fine. A fifteen-word keyword list as a file name looks spammy because it is.
  • Include your target keyword once if it’s genuinely the subject of the image. If your article targets “pour over coffee ratio” and the photo shows your pour-over setup, pour-over-coffee-ratio-scale.webp is legitimate. If it’s a generic stock photo of beans, forcing the keyword in is a mismatch.
  • Lowercase everything. Some servers treat Photo.JPG and photo.jpg as different files, which creates duplicate URLs and broken links when you migrate.

Rename the file on your desktop, then upload. Every CMS I know of takes the uploaded file name as the permanent slug, so this thirty-second habit pays off forever.

Step 5: Alt text that actually describes the image

Alt text is the heart of image SEO, and it’s also the most misunderstood. It serves two audiences at once: screen reader users who hear it read aloud, and search engines that use it to understand the image content. Write for the human first and the ranking takes care of itself.

The formula

Describe the image as if you’re explaining it to someone over the phone. Be specific, be brief, and stop. The sweet spot is roughly 5 to 15 words, under 125 characters.

Here’s the difference in practice. Bad: alt="coffee". Better: alt="coffee cup". Good: alt="White ceramic mug of pour-over coffee on a wooden desk next to a gooseneck kettle". The good version tells a screen reader user exactly what they’d see, and it happens to contain a natural mention of the article’s topic.

What to avoid

  • Don’t start with “image of” or “picture of.” Screen readers already announce it’s an image. You’re wasting the two most valuable words.
  • Don’t stuff keywords. alt="coffee coffee beans best coffee coffee maker buy coffee" is an old trick that hasn’t worked in over a decade and can actively hurt you.
  • Don’t duplicate the caption word-for-word. If you have both, they should complement each other — a screen reader will hear them back to back.
  • Don’t leave it empty unless the image is purely decorative. A flourish divider or background texture gets an empty alt="" (which tells screen readers to skip it). Anything with content gets real alt text.

If you’re on WordPress, alt text is a field in the media library — fill it in at upload and it applies everywhere the image appears. Google’s own SEO starter guide explicitly calls out descriptive alt text as a best practice, and their image guidelines repeat the same advice: write for users, be specific, keep it short.

Step 6: Captions, placement, and surrounding text

Google reads the text immediately around an image as context — the paragraph above it, the caption below it, the heading of the section it lives in. This is why placement is an SEO decision, not just a design one.

Put each image next to the text it illustrates. If the photo shows step 3 of your process, it belongs under the step 3 heading, not floated to the top of the article because that’s where the template wants a picture. The surrounding words are how Google disambiguates what your image depicts, and mismatch — a keyword-stuffed file name next to unrelated body copy — reads as manipulation.

Captions are optional but underrated. They’re among the most-read text on any page (eyes jump from headline to image to caption), and they give you one more honest, descriptive sentence tied directly to the image. I use them whenever the image benefits from explanation and skip them for purely illustrative filler. One caveat: a caption is not a substitute for alt text. They serve different functions and you often want both.

Step 7: Let the browser do the heavy lifting — responsive images and lazy loading

Two technical settings finish the job, and if you’re on WordPress both are handled for you automatically — but you should know they exist, because they break.

Responsive images (srcset)

Modern HTML lets you serve different file sizes to different screens via the srcset attribute: a phone gets the 480-pixel version, a laptop gets the 1,200-pixel version. WordPress has generated these sizes automatically since version 4.4, and any decent static-site setup does too. If you hand-code your pages, the MDN documentation for the img element covers srcset and sizes syntax thoroughly. The SEO-relevant point: never defeat this by hardcoding a huge image URL into a small display slot.

Lazy loading — with one big exception

Lazy loading (loading="lazy") defers off-screen images until the visitor scrolls to them. It’s free speed, and WordPress enables it by default. The exception: your above-the-fold hero image should NOT be lazy loaded. Lazy-loading the largest element on the page delays exactly the thing Google measures for LCP. WordPress stopped lazy-loading the first image by default a few versions back, but if you use a performance plugin, check that it excludes the first image — many of them get this wrong.

Watch outPage builders and slider plugins are notorious for loading full-size originals instead of the generated responsive sizes, and for wrapping images in JavaScript that delays rendering. If your scores are bad despite optimized files, inspect the actual <img> tag in dev tools — the culprit is usually the theme, not your images.

Step 8: Get your images indexed properly

Optimized images still need to be discoverable. Three things handle this:

  • Don’t block your uploads folder. An ancient robots.txt rule blocking /wp-content/uploads/ keeps Google Images out entirely. I’ve seen this survive on sites for years.
  • Use an image sitemap (or let your SEO plugin handle it). Image entries in your XML sitemap help Google find images it might miss, especially ones loaded via galleries or lazy loading. Yoast and Rank Math include image data in their sitemaps automatically. If you’re new to sitemaps, my guide to XML sitemaps and robots.txt covers the setup.
  • Host images on your own domain. Images hotlinked from a CDN subdomain or third-party host split their value. Keep them on your domain or a properly configured CDN that serves them under your URL structure.

Then verify in Google Search Console: the Pages report shows whether your posts are indexed, and you can filter Performance data by Search type → Image to see exactly how many impressions and clicks your images earn. Most site owners have never looked at this report. It’s usually a pleasant surprise — or a useful kick in the pants.

Stock photos vs. original images: the honest trade-off

Google has said repeatedly that original images can outperform stock photos, and it matches what I see in practice. A page using the same Shutterstock handshake photo as ten thousand other pages gives Google nothing new to rank. Original screenshots, your own photos, and custom diagrams are indexable assets nobody else has.

Practical middle ground, because not everyone can shoot original photography for every post: screenshots you captured yourself (perfect for tutorials and software how-tos), simple diagrams made in Canva or Figma, and at minimum, stock photos you’ve cropped, edited, or combined into something distinct. Even light customization — a branded overlay, a unique crop — differentiates the file. Whatever you use, never hotlink images from other sites. It steals their bandwidth, it can break without warning, and it can create copyright exposure. Download, rename, compress, upload to your own media library, every time.

The 90-second checklist for every image

Here’s the whole guide compressed into the checklist I actually run, in order, before any image goes live:

  • Right format picked. Photo → WebP or JPEG. Screenshot/text → PNG or WebP. Logo/icon → SVG.
  • Resized to 2x display width. Usually 1,560-1,920 px for article images. Never upload the camera original.
  • Compressed under target. Hero under 150 KB, body images under 100 KB, page total under 1 MB.
  • Descriptive hyphenated file name. Three to six words, lowercase, keyword included only if it’s truly the subject.
  • Alt text written. 5-15 words describing the image, no “image of,” no keyword stuffing.
  • Placed next to relevant text. The section it illustrates, with a caption if explanation helps.
  • Srcset working, lazy load on — except the hero. First image loads eagerly; everything below the fold waits.
  • Uploaded to your own domain. No hotlinks, no third-party hosting, uploads folder crawlable.

Run this eight times and it becomes muscle memory. The compounding effect is real: a site with two hundred properly optimized images has faster pages, better accessibility, and a Google Images presence its competitors — still uploading IMG_2047.jpg — can’t see from where they’re standing.

Sources: Google Search Central’s SEO starter guide and image best practices documentation (developers.google.com/search); MDN Web Docs for HTML img/srcset syntax. Related reading on this site: Core Web Vitals Fix Guide, XML Sitemaps and robots.txt. This article is reviewed and updated when Google’s image guidance changes.

Leave a Comment