An image SEO checklist is only useful if you can hand it to someone else and get the same answer back every time. This one covers the file-level and markup side of image optimization: names, formats, compression, dimensions, loading, and the metadata that tells search and AI systems what an image is and where it lives. It is built to run once per important image and to repeat cleanly across a whole client roster, which is the part most checklists skip.
There is one thing this checklist cannot promise you. Google says there are no extra technical requirements or special schema for AI Overviews or AI Mode. For an image's page to even be considered as a supporting link, the page itself has to be indexed and eligible to appear in a regular search result with a snippet. That is a page-level condition, not a rule that guarantees Google will pick a particular image once the page qualifies. What this checklist gets you is a clean, correctly built image that has removed every technical reason it could be skipped. Whether it gets picked is still Google's call.
The checklist
Run one row per important image on a page, not every decorative asset on the site. Record Pass, Fix, or Not applicable, note which image and page it covers, and who owns the fix.
| Check | Pass criterion | How to verify |
|---|---|---|
| Page eligibility | The landing page is accessible and indexable, and nothing is quietly keeping it out of a search snippet. | Inspect the live page in Search Console and compare its indexed status with the live-test result. |
| Image accessibility | The image can actually be fetched, and neither the page nor the image is blocked from crawling, including on a CDN. | Request the image directly and check for crawl restrictions on both the page and the asset host. |
| Discoverable HTML | The image sits in a real <img> element with a working src, including as the fallback inside a <picture> element. | Inspect the rendered HTML. A CSS background image alone will not show up here. |
| File name | The file has a short, descriptive name, and the extension matches the actual format being served. | Compare the published file name against the image's real subject and file type. |
| Format | The delivered format is one Google supports and fits what the image actually shows. | Check the format that is really being served, not just the one exported. |
| Compression | The encoding cuts transfer size without making the image visibly blurry or artifact-heavy. | Compare a few encoding settings at the size users actually see, and look at the delivered bytes. |
| Responsive delivery | The page offers sized versions of the image, with an accurate sizes attribute alongside srcset, and src still present as a fallback. | Test at a few viewport widths and see which file each one downloads. |
| Space reservation | The image carries correct width and height attributes, or an equivalent reserved aspect ratio. | Load the page at a few sizes and watch whether content jumps around it. |
| Loading priority | The visible hero image, or whatever is likely the Largest Contentful Paint element, is not lazy loaded. Images below the fold can be. | Check the rendered loading attribute and the load timeline on mobile and desktop. |
| Preferred page image | Where one image best represents the page, it is named through applicable metadata, such as og:image or primaryImageOfPage. | Compare what the metadata points to against what actually shows on the page. |
| Structured data | Where the page qualifies for a supported rich result, the image property follows that type's rules and points to a real, relevant file. | Run the page through the Rich Results Test and check against the relevant documentation. |
| Image sitemap | If discovery needs help, the important images are listed under their landing page's entry in an image sitemap. | Check the submitted sitemap for correct page-to-image pairing and working URLs. |
| Outcome check | The page, the image, and any relevant Search Console reports get a second look after publishing. | Keep a dated pass or fix record rather than checking once and closing the ticket. |
Make the image discoverable in the first place
Everything else on this list assumes the image can actually be found, so start there. Google reads an image from the src attribute of an <img> element, including the fallback <img> inside a <picture> element. It does not index images that only exist as a CSS background. A background image can still do its design job, but if you need the image to be searchable, it has to live in an HTML image element with a working src, not just in a stylesheet.
If a CMS or a JavaScript framework builds the page dynamically, check what actually renders rather than trusting the source template. When images are served off a CDN, check both the landing page and the image host, since a broken or blocked asset on either side breaks the chain. Google also recommends referencing an image with the same URL consistently, so it can cache and reuse the reference instead of re-requesting it every time.
Get the image file names right
Google's own guidance contrasts a name like my-new-black-kitten.jpg with a generic export name like IMG00023.JPG, and it discourages placeholder names such as image1.jpg. The goal is identification, not keyword stuffing. There is no published length limit or keyword-density rule for image file names, so the useful test is simpler: does the name describe what is actually in the file. For an agency client, monthly-visibility-chart.webp tells you what you are looking at before you open it. IMG0042.webp does not.
Renaming makes sense when you publish a new asset, not as a reason to keep moving an image that already has links and cached references pointing at it. Keep the extension honest too: a file saved as WebP but named .jpg still confuses tools further down the pipeline. Writing the words inside the alt attribute is a separate, descriptive-copy job, not this checklist.
Choose the right format and compress it properly
Google supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF for images referenced in an <img> element. Supported is not the same as best for every case, so pick by what the image actually is.
For photos and similar raster imagery, an efficiently encoded JPEG, lossy WebP, or AVIF usually gives you the smallest file at acceptable quality, with WebP and AVIF generally compressing better than older formats. For fine-edged graphics, screenshots with text, or anything where a hard line matters, PNG or lossless WebP holds up better, since lossy settings built for photos tend to smear sharp edges. For simple geometric artwork, logos, or icons, SVG stays crisp at every size and is not a good substitute for a complex photo. If you offer a <picture> element with modern formats, keep a working <img> fallback inside it and confirm that fallback actually renders, since discovery should never depend on a <source> tag alone.
Good image compression SEO practice is a visual tradeoff you test, not a single setting you apply everywhere. There is no universal file-size ceiling or quality-slider number published by Google, so treat any internal page-weight budget your agency sets as your own standard, not a search requirement. Run a few encoding settings against the real asset, especially charts and screenshots where blur shows up fast, and look at the actual bytes being delivered rather than trusting the export dialog.
Dimensions follow the same logic. Offer width variants through srcset with an accurate sizes attribute so a phone does not download a desktop-sized file, and keep src present as the baseline. Set accurate width and height attributes even when CSS scales the image, since that is what lets the browser reserve the right amount of space before the file even downloads.
Load images without slowing the page down
Lazy loading is not a setting you flip on for every image. Apply loading="lazy" to images that are genuinely below the initial viewport. Leave the visible hero image, or whatever is likely to be the page's Largest Contentful Paint element, on normal eager loading, and consider fetchpriority="high" only for a genuinely vital image, since overusing high priority just makes other resources compete for the same bandwidth.
Research from web.dev found that deferring below-the-fold images does cut downloaded bytes, but lazy loading an image that is actually in the initial viewport can make Largest Contentful Paint worse. Treat that as a real tradeoff to test on the page in question, not as a fixed ranking effect you can promise a client. Check the rendered output directly too, since some CMS platforms add lazy-loading attributes automatically and quietly apply them to a hero image nobody meant to defer.
Add the markup that tells search and AI what the image is
A preferred-image signal influences what gets shown, it does not command it. Google's own documentation says image-preview selection is automated, but you can indicate a relevant preferred image through og:image or the schema.org primaryImageOfPage property. Pick an image that actually represents the page, and skip anything generic, oddly cropped, or carrying text that makes it a poor thumbnail.
Rich-result markup depends entirely on the page type the image sits on, so validate against the specific type that page qualifies for rather than adding every schema property you can find. A Rich Results Test pass tells you the markup is structurally valid, not that Google will choose to display it.
Rights metadata is a separate, conditional layer that only matters if you actually need it. Google's ImageObject implementation uses contentUrl for the real image file, plus at least one of creator, creditText, copyrightNotice, or license. Licensable badge eligibility needs the license property specifically, with acquireLicensePage as an optional add-on. If structured data and embedded IPTC metadata disagree, Google goes with the structured data. None of this is special AI Overview markup, just standard image metadata that matters more once an image gets reused.
Use image sitemaps for discovery, not repair
An image sitemap describes which images belong to which page. Each page entry can hold up to 1,000 image locations, and an image location can point to another domain, such as a CDN, as long as you verify both domains in Search Console and confirm crawling is not blocked. Image sitemaps earn their place when an image might otherwise go unnoticed, including some served through JavaScript.
What an image sitemap will not do is fix a broken or blocked resource. Listing an image there does not make it discoverable if the underlying src is missing or returns an error. Treat it as an extra discovery route on top of a working image, not a substitute for one.
Worked example: an agency client's report article
Picture a client publishing an article that explains their quarterly visibility reporting. The prominent image is a results chart near the top, and the second image, further down, is a supporting workflow diagram. The values below are implementation choices for this example, not Google requirements or measured results.
| Field | Prominent chart | Supporting diagram |
|---|---|---|
| File name | quarterly-visibility-chart.webp | reporting-workflow.svg |
| Discoverability | Standard <img> with a working src, present in rendered HTML | Standard <img> with a working src |
| Format | Compare WebP against a lossless option if labels or fine lines degrade | SVG, checked for clean rendering |
| Dimensions | Record the chart's real intrinsic size, and offer smaller raster variants | Reserve the diagram's display space with correct width and height |
| Loading | Eager load, since it is visible immediately and likely the LCP element | Lazy load only if it sits below the initial viewport |
| Metadata | Consider as the preferred page image if it genuinely represents the article | No preferred-image metadata needed |
| Sitemap | Associate with the article's landing-page entry if using an image sitemap | Include only if it helps discovery |
| Checks | Page indexing, rendered image, mobile download size, visual quality, layout shift | Fetchability and whether deferral actually hides it |
If the chart looks blurry after compression, do not mark that row as passed just because the transfer size dropped. If the CMS adds loading="lazy" to the hero by default, fix what actually renders, not just the setting in the editor. And nothing about this example predicts that either image will show up in Google Images or an AI Overview. It just removes the technical reasons either one could be skipped.
Adapt the checklist across a portfolio of clients
For a single small site, audit the homepage plus a representative set of article or product templates and their hero images. Fix template-wide mistakes first, like a missing src, an oversized default variant, or lazy loading applied without exception, before you move on to polishing individual file names.
Across a portfolio, keep the same checklist and pass criteria for every client, but record results separately by client, template, and image role. Assign clear owners: one person for CMS templates, one for image export settings, one for CDN delivery, one for search validation. Save examples of the actual published markup, so a fix that worked on one client's WordPress setup is not assumed to carry over to another client's Webflow build without checking. Recheck a representative page on mobile and desktop after any template release or CDN change, since that is when a passing row quietly breaks.
Use each tool for what it actually tells you. Search Console's URL Inspection shows Google's indexed version of a page, and its live test can show a rendered screenshot, but a passing live test is not proof the image is indexed. The Rich Results Test checks what rich results the structured data could support, and it is not an AI Overview simulator. For file and performance checks, look at the real network responses and the rendered result, not the export settings you meant to apply.
How to know the checklist is working
Track fewer template-wide errors over time: images that fetch cleanly in the rendered page, appropriate mobile variants, acceptable visual quality, no needless lazy loading on prominent images, and structured data that validates where it applies. That is what a working image SEO checklist actually gives you: fewer repeat errors, not a promised ranking. Search appearance itself, whether that is an image search result or an AI Overview citation, stays an outcome to watch, not something a passing row can guarantee.
If you are running this across many client sites at once, the manual bookkeeping is usually the part that breaks first, not the checklist itself. DeepSmith's Content Map keeps a live picture of every page across a workspace, useful for spotting which templates a fix needs to touch. A free trial is enough to see if it fits.
