The Image SEO Checklist: 12 Things to Fix Before You Publish
A practical pre-publish checklist for image SEO — filenames, alt text, dimensions, compression, lazy loading, structured data and metadata — with the reasoning behind each item.

Image SEO has a reputation problem. It is treated as a tidy-up task, the thing you do after the copy is signed off and the schema is in, if there is time. There is never time. So images ship as Screenshot-2026-07-14-at-3.42.11-PM.png with an empty alt attribute, and a genuine ranking input gets thrown away on every single page.
This is the checklist we actually run before publishing. Twelve items, ordered roughly by how much they matter relative to how long they take. As of July 2026, all of it reflects current Google Search Central guidance on Google Images.
1. Give the file a descriptive name
Google states plainly that the filename gives it clues about the subject of the image. IMG_4471.jpg communicates nothing. arlington-tx-locksmith-rekeying-deadbolt.jpg communicates the subject, the service and the location.
The rules are boring and worth following:
- Lowercase throughout.
- Hyphens between words, never underscores. Google treats hyphens as word separators and underscores as joiners, so
car_key_replacementcan read as one token. - Three to six meaningful words. Beyond that you are keyword stuffing a filename, which does nothing.
- No stop words padding it out, no dates unless the date is genuinely part of the subject.
We wrote a longer piece on the mechanics of this in SEO image filenames, including how to handle variants and near-duplicate files across a large site.
2. Write alt text for a human first
Alt text exists for people who cannot see the image. That it also helps search engines is a happy side effect, and treating it the other way round produces the keyword-stuffed garbage that helps nobody.
Describe what is in the frame and why it is on the page. "Technician programming a transponder key with a diagnostic tool in a car's driver seat" is useful. "car key locksmith key programming car key replacement near me" is not, and it makes the page actively worse for the person using a screen reader.
The W3C alt decision tree is the reference worth bookmarking — it walks you through the specific case you are looking at, including the cases where the right answer is an empty alt attribute. Our full treatment is in how to write alt text.
3. Use an empty alt for decorative images
alt="" tells assistive technology to skip the image. Omitting the attribute entirely tells it to guess, which usually means reading out the filename. For a background gradient or a divider flourish, an empty alt is the correct, deliberate answer.
4. Serve the right dimensions
Shipping a 4000px-wide original into a 800px-wide container wastes bandwidth on every visit and is one of the most common Largest Contentful Paint failures. Resize to the largest size the layout will actually display, then let srcset handle the rest.
5. Choose the right format
| Format | Best for | Typical saving vs JPEG | Watch out for |
|---|---|---|---|
| WebP | Almost everything — photos and graphics | 25–35% | Nothing significant; support is universal in 2026 |
| AVIF | Large hero photos where every KB counts | 40–50% | Slower to encode; check your build times |
| JPEG | Fallback, legacy pipelines | — | No transparency |
| PNG | Screenshots, line art, anything needing transparency | Often larger | Terrible for photographs |
| SVG | Logos, icons, diagrams | Resolution-independent | Sanitise user-uploaded SVGs — they can carry script |
The short version: default to WebP, reach for AVIF on the hero image, and stop shipping PNG photographs.
6. Compress with intent
Aim for visually lossless. For most photographic content that lands around quality 80–85 in WebP. Run the result past your own eyes on a good screen — automated quality metrics do not notice the specific artefact that ruins a face or a logo.
7. Set explicit width and height
Every <img> should carry width and height attributes (or a CSS aspect-ratio). This lets the browser reserve the correct space before the file arrives, which is what stops the page jumping around and wrecking your Cumulative Layout Shift score.
8. Lazy load below the fold — and only below the fold
loading="lazy" on images below the fold is free performance. Putting it on your LCP hero image is a self-inflicted wound: it delays the single most important paint on the page. Mark the hero fetchpriority="high" instead and leave lazy loading to everything else.
9. Put the image near the content it belongs to
Google uses the surrounding text, the caption and the nearest heading to understand what an image depicts. An image dropped in a sidebar, far from the paragraph it illustrates, loses that context. Captions in particular get read by humans at a much higher rate than body copy, so a caption is rarely wasted effort.
10. Make images crawlable
Standard <img src> markup gets crawled. CSS background images generally do not get indexed as images. If an image matters for search, it belongs in the HTML — and it must not be blocked by robots.txt. It is genuinely common to find a site blocking /assets/ or /uploads/ and quietly excluding every image it owns from Google Images.
11. Add structured data where it applies
For product, recipe, article and video content, the image field in your structured data is what feeds rich results. Google's requirements are specific — high resolution, correct aspect ratios, crawlable URLs — and worth reading directly on schema.org plus Google's per-type documentation. If your images are core to the offering rather than illustrative, consider whether an image sitemap earns its keep.
12. Write the file's own metadata
This is the item nobody does, which is exactly why it is interesting. An image file carries its own metadata block — EXIF and IPTC — with fields for description, creator, copyright, keywords and GPS coordinates. Google has said it reads IPTC fields for image credits and rights, and the IPTC Photo Metadata Standard is the governing spec.
Two honest caveats. First, embedded metadata is a weaker signal than filename, alt text and surrounding copy — treat it as reinforcement, not a shortcut. Second, many CDNs and CMS pipelines strip EXIF on resize, so verify your processed output rather than your source file. We go through what survives, what does not, and what each field is actually good for in what EXIF metadata does for SEO, and the location-specific case in geotagging images for local SEO.
Measuring whether any of it worked
Image SEO has a feedback problem: you do the work, and nothing visibly happens. Three places to look, none of which require new tooling.
Search Console, Performance, Search type = Image. This filter is the single most underused report in the product. It isolates impressions and clicks coming from Google Images, which is the surface most of this checklist affects. Set a baseline before you change anything, then check monthly — not weekly, because image indexing is slow.
URL Inspection on a page you just fixed. Confirms Google can actually fetch the images and shows you the rendered HTML it used. If an image is missing here, nothing else on this list matters until that is resolved.
A coverage count of your own. What percentage of images on your top twenty pages have a descriptive filename and non-empty, non-junk alt text? It is a two-minute audit and it is the only number here entirely within your control — useful precisely because it moves the month you do the work rather than three months later.
Set expectations accordingly. Filename and alt-text improvements tend to surface over weeks, not days, and they compound with everything else on the page rather than producing an isolated spike. Anyone promising otherwise is selling something.
One trap in the reporting
Image impressions can rise sharply for reasons unrelated to your work — a seasonal query spike, a competitor deindexing, Google changing how many results a surface shows. Before attributing a jump to the checklist, check whether clicks moved with impressions. Impressions up and clicks flat usually means you are appearing for something irrelevant, which is not a win.
The realistic version of this checklist
Twelve items per image is not a workflow anyone sustains across fifty pages. In practice the list splits cleanly in two.
Items 4 through 11 are delivery concerns. They are solved once, in your build pipeline or your CMS, and then they apply to everything automatically. If you are on a modern framework, most of them are already handled by the image component you are using.
Items 1, 2, 3 and 12 are per-file concerns. Every single image needs its own filename, its own alt text and its own metadata, and no framework can guess them for you — it does not know your business name, your city or what the picture is meant to convey. This is precisely the part that gets skipped, and it is the part Google's own documentation puts first.
That gap is why SEOpix writes the filename, alt text, EXIF block and optional GPS coordinates at generation time rather than leaving them as a post-processing chore. When the metadata is produced with the image, there is no end-of-project cleanup to run out of time for. If you are doing this at volume across clients or locations, the bulk workflow guide covers how that plays out at a few hundred images a month.
Start with the two free items: fix your filenames and write real alt text on your next batch. Those cost nothing but attention, and they are the two things the documentation actually names.
Ready to stop doing it by hand? Ten images a month are free — no credit card — and the pricing page has the tiers if you need volume.
Frequently asked questions
Does image SEO still matter in 2026?+
Yes, but for broader reasons than a decade ago. Google Images remains a significant discovery surface, and image files now feed AI overviews, shopping surfaces and multimodal search. On top of that, several image SEO items — dimensions, compression, lazy loading — are really page-speed items that affect the ranking of the whole page, not just the image.
What is the single highest-impact image SEO fix?+
Descriptive filenames and alt text, in that order of neglect. They are the two things Google Search Central explicitly names as signals it uses to understand an image, and they are the two things most teams skip entirely. A file called IMG_4471.jpg with an empty alt attribute gives a crawler nothing to work with.
How many words should alt text be?+
There is no official limit, but roughly 8 to 16 words is a good working range. Long enough to describe the subject and its context, short enough that a screen reader user is not stuck listening to a paragraph. Never pad it with keywords.
Should every image on a page have alt text?+
Every meaningful image should. Purely decorative images — background flourishes, spacer graphics, icons that repeat adjacent link text — should carry an empty alt attribute (alt="") so screen readers skip them. An empty alt is a deliberate choice; a missing alt attribute is a defect.
Does compressing an image hurt its ranking?+
No. Sensible compression helps, because Core Web Vitals are a ranking factor and images are usually the heaviest thing on a page. What hurts is over-compression that leaves visible artefacts, since image quality affects engagement and, for product images, conversion.
Do I need an image sitemap?+
Most sites do not. It is worth adding when images are loaded by JavaScript, served from a separate CDN domain, or are a core part of the offering — a gallery, a marketplace, a real estate portal. For a standard site with images in the HTML, the regular sitemap plus clean markup is enough.
Can SEOpix do all of this automatically?+
It handles the metadata layer: filename, alt text, EXIF fields and GPS coordinates are written as the image is generated. The delivery items — compression, responsive sizes, lazy loading, CDN — remain your site's job, because they depend on your stack rather than the file.
Let SEOpix handle the metadata
Filenames, alt text, EXIF fields and GPS coordinates written automatically as each image is generated. Start with 10 free images a month — no credit card required.


