An image can be sharp, well shot, and exactly on topic, and still never show up anywhere Google's generative search touches. That's not because the picture is bad. It's usually because Google can't find it, can't tell what it's a picture of, or can't connect it to the page it sits on with any confidence. This guide walks through the steps that fix that: making the image itself crawlable, describing it consistently, delivering it at the right quality, and adding the metadata that lets Google trust what it's looking at. If you want to optimize images for AI Overviews and ordinary visual search at the same time, these are the same steps, because Google has said its generative features build on the same image practices it has always recommended.
One thing worth saying up front: none of this guarantees images in Google AI Overviews or a spot in ordinary image results. Google doesn't publish a special AI image score, a minimum resolution, or a required alt text length. What you can do is remove the reasons an image gets skipped, and give Google every signal it needs to understand the image correctly. That's a real, achievable outcome, even if "guaranteed inclusion" isn't.
Pick the image that actually represents the page
Start with the image itself, before any of the technical work. If a page has more than one image, work out which one best represents what the page is actually about. That's the image Google is most likely to treat as the page's preview, and it's the one worth spending your optimization time on.
Choose a picture that shows the real subject, not a logo, not a decorative stock photo, and not whatever happened to fill the layout slot. A generic brand mark tells Google almost nothing about what the page covers. A picture that actually demonstrates the product, the process, or the concept does the opposite: it gives Google (and the reader) something concrete to match against the query.
Aspect ratio matters more than people expect. An image that's extremely narrow or extremely wide is hard to use as a preview or a thumbnail, so it's more likely to be passed over even when the content is otherwise fine. Aim for something closer to a standard ratio, at a resolution that still looks sharp when scaled down.
You can tell Google which image you'd prefer it use, through page metadata like og:image or a primaryImageOfPage property tied to the page's main entity. That's a signal, not an instruction. Google's selection process is automated, and it can still choose a different image, or none at all, if it decides that's the better answer for a given query. Treat the preferred-image signal as a strong hint you're giving Google, not a lock on the outcome.
A quick way to check your choice: look at the image on its own, then look at the page on its own, and see if a stranger could tell they're about the same subject without reading any hidden metadata. If yes, you've picked the right image.
Make the image easy for Google to find
None of the description or metadata work matters if Google can't actually reach the image in the first place. This step is about crawlability, and it's where a lot of otherwise well-optimized pages quietly lose images without anyone noticing.
Use a real img element with the actual image URL in the src attribute. Google can find an image nested inside a picture element too, as long as the fallback img and its src are still there. That last part trips people up: adding srcset or a picture wrapper for responsive delivery doesn't excuse you from keeping a working src. If the fallback is missing, you've built an image the browser can render but Google may never index.
CSS background images are the other common trap. Google does not index images that only exist as CSS backgrounds, so if a product photo, a diagram, or anything else you want found is set purely through background-image, it's effectively invisible to image search and to how Google AI Overviews reads your site when it renders the page. Anything that matters should live in the HTML as a genuine img element.
If images live on a CDN or otherwise might not get discovered through normal crawling, submit an image sitemap. Image sitemaps can list URLs hosted on a different domain than the page itself, which is exactly the CDN case, and verifying the CDN domain in Search Console lets you see crawl errors for those assets instead of guessing. It also helps to keep the same image at a consistent URL rather than generating a new one every time it's referenced, since that lets Google cache and reuse what it already has.
Common mistake: treating a media library upload as automatically discoverable. Uploading an image to your CMS doesn't put it in front of Googlebot. It has to appear in crawlable HTML on a page Google actually visits.
Write alt text and context that agree with the image
This is the step people either skip or do badly, and it's the one that does the most to help Google (and a screen reader, and a human skimming the page) actually understand what an image shows. Get the image alt text AI search systems combine with computer vision and page content, and you've given Google its clearest read on the picture.
Use four things together, and keep them consistent with each other:
- A short, descriptive filename.
dalmatian-puppy-playing-fetch.jpgtells Google something.IMG00023.JPGtells it nothing. This is a light signal on its own, not a replacement for the rest. - Useful alt text. Describe the subject and what it's doing, the way you'd describe it to someone who can't see it. Google's own example contrasts a weak alt of "puppy" against a stronger one, "Dalmatian puppy playing fetch." The difference isn't length for its own sake, it's specificity: name the subject and the action, not just a category.
- A caption or title, when it actually adds something. A caption that repeats the alt text word for word isn't helping. Use it to add context the alt text can't carry, like why the image is on the page at all.
- Text near the image, and a page that's genuinely about the same subject. Google reads images in context. An on-topic image sitting in an off-topic section, with no supporting text nearby, is harder to interpret correctly no matter how good the alt text is.
Keep every one of those four in agreement about what the image shows. Don't write alt text that contradicts the picture, and don't stuff it with keyword variations hoping one of them sticks. Google is explicit that keyword-stuffed alt text is a poor experience for the people who rely on it, and it doesn't help your visibility either. Write it for the person who can't see the image first, and it will do the SEO job on its own.
This is also where pages tend to get quietly excluded rather than obviously rejected. A picture that's technically fine but surrounded by generic or unrelated copy gives Google very little to work with, which is part of why content gets excluded from AI Overviews even when nothing looks broken on the surface.
Pro tip: use the same description of the subject across the filename, the alt text, the caption, and the surrounding copy, but don't copy the exact same sentence into all four. Consistency helps Google connect the dots. Repetition just looks like stuffing.
For the technical side of alt text, Google's own guidance on writing helpful alt text is worth reading directly, since it covers cases like decorative images and complex diagrams that a short guide like this one can only summarize.
Deliver a sharp image without slowing the page down
Quality and speed pull against each other, and this step is about not sacrificing one for the other more than you have to.
Google has said plainly that high-quality, sharp images appeal to users more than blurry or unclear ones, and that sharper images can increase the odds someone clicks through from a search result. So don't undercut a good photo by compressing it until the detail is gone. At the same time, images are usually the single biggest contributor to a page's total weight, so serving an unnecessarily huge original to every device is its own problem.
Google's image SEO documentation lists the formats Search supports in src: BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF, as long as the file extension matches the actual file type. WebP is broadly supported across modern browsers and usually compresses better than older formats. AVIF can compress even further but has less universal support, so pair it with a fallback if you use it.
Use srcset and sizes to serve appropriately sized versions to different devices, or a picture element when you need to swap the source entirely. Whichever you use, the alt, width, and height attributes belong on the actual nested img, and they apply no matter which source ends up loading. There's no single compression setting that works for every image type: lossy compression is usually fine for photos, but it can visibly damage line art, sharp edges, or text, so check each image type rather than applying one setting everywhere.
Lazy-loading images below the fold is a reasonable way to cut initial page weight, but it's a delivery decision, not a way to hide an image from Google. Keep the crawlable markup and fallback URL in place even on a lazy-loaded image.
If a cover image or diagram is the bottleneck in your production process rather than the technical delivery, that's a different problem than the one this section solves. DeepSmith's Content Studio Writer can generate a cover image and publish-ready metadata as part of turning a planned article into a finished one, which removes a step that otherwise eats twenty minutes per article in a design tool or a wait on someone else's queue. It doesn't replace the checks in this guide. Whatever image comes out of that process still needs a real src, honest alt text, relevant surrounding copy, and working responsive markup before it's ready to publish, the same as an image from any other source.
Add image metadata without overpromising what it does
Structured data can help Google understand an image and, in some cases, make it eligible for specific rich results. It does not force Google to show anything, and it's worth being precise about what it actually does before you invest time in it.
Google says there's no special AI-only schema you need to add for generative search. Established image SEO, the practices covered in the earlier steps, is what Google itself points to as the right foundation. Structured data explained for AI search is a useful primer if you're setting this up from scratch, since the same core structured-data rules apply here as anywhere else on the site.
Two uses of image metadata are worth separating:
- Preferred-image metadata helps indicate which image on a page you'd like treated as the representative one, covered in the first step above.
- Licensing metadata helps Google understand who owns an image and under what terms, and can make it eligible for a Licensable badge in image results.
For the licensing feature specifically, Google's image metadata requirements call for contentUrl (the actual image URL) plus at least one of creator, creditText, copyrightNotice, or license. The license property specifically is required for Licensable-badge eligibility. Recommended fields on top of that include acquireLicensePage, creator.name, and copyrightNotice, so a user who wants to license the image has somewhere to go.
If you're deciding between JSON-LD, Microdata, or RDFa for the markup itself, Google supports all three under its general structured-data guidelines, and the choice usually comes down to what your CMS makes easiest to maintain. If your team doesn't have a developer on hand for this, adding schema markup without a developer covers the no-code path for the common platforms.
Whatever markup you add, the image URL inside it has to be crawlable and indexable, and the image it describes has to actually be visible and relevant on that page. Marking up a generic logo as your representative image, or adding structured data for an image that isn't actually there, doesn't work around the underlying content problem, it just adds a validation failure on top of it.
If the same image appears on more than one page, add the structured data separately on each page instance. That's different from IPTC metadata, covered next, which lives inside the image file itself and travels with it automatically.
Protect your licensing and provenance signals
This step is easy to skip because it feels like paperwork, but it's the piece that determines whether Google can say anything trustworthy about who made an image and how it can be used.
You have two ways to supply licensing information: structured data on the page, or IPTC metadata embedded in the image file. You only need one, but they solve different problems. Structured data is tied to the specific page it's declared on. IPTC metadata is embedded in the file itself, so it travels with the image wherever it's used, which matters if the same photo ends up syndicated or reused across pages you don't control as tightly. If the two ever disagree, Google uses the structured-data version.
Google documents support for several IPTC fields: Copyright Notice, Creator, Credit Line, Digital Source Type, Licensor URL, and Web Statement of Rights. The Web Statement of Rights field specifically is what's required for Licensable-badge eligibility through the IPTC route, and adding a Licensor URL gives anyone interested a place to find licensing terms.
Digital Source Type is worth knowing about even if it sounds obscure: Google supports values like trainedAlgorithmicMedia and compositeSynthetic that flag an image as AI-generated or AI-assisted rather than a straight photograph. If an image carries C2PA provenance metadata, from a signer using C2PA version 2.1 or later with a certificate on the C2PA Trust List, Google can surface that in an "About this image" panel showing how the image was made or edited. Treat this as a transparency signal for the reader, not a ranking lever. Google doesn't describe it as one, and claiming otherwise would be getting ahead of what's actually documented.
One practical warning: compressing an image to shrink file size sometimes strips its embedded metadata along with it. That can improve load time, but it can also remove the rights information you were relying on, which creates a real problem if the image's licensing terms mattered in the first place. Check what your compression pipeline actually preserves before you assume the metadata survived.
If any of this markup goes wrong in ways that quietly hurt visibility across your whole site, not just one image, it's worth reviewing common schema markup mistakes that keep pages out of AI answers, since several of the same failure patterns, like markup describing something that isn't actually on the page, show up in image metadata too. For placement questions once you're past the basics, where to add schema markup for AI visibility covers the site-wide version of this decision.
Check what actually got indexed, then measure the right thing
Before you publish, walk through the image the same way Google will encounter it. Confirm it appears in real img src markup, not only as a CSS background. Check that the URL loads and isn't blocked. Confirm the responsive markup still has a working fallback. Read the filename, alt text, caption, and nearby text together and check they describe the same subject. Look at the image itself and confirm it's sharp, representative, and not distorted by an extreme crop. If you're using structured data, validate it, and use URL Inspection to confirm Google can actually access both the page and the image.
Once it's live, measure the two things this guide covers separately, because they answer different questions and mixing them up will give you a false read on what's working.
Search Console's Performance report has an Image search type you can filter to, showing clicks, impressions, click-through rate, and average position specifically for image results. Establish a baseline there before you change filenames, alt text, or delivery, then compare over a consistent window rather than reacting to a single day's numbers. This is genuine visual search optimization measurement: it tells you whether your images are performing as images, separate from how the page performs in ordinary web results. Validating schema markup for AI engines is the companion check for the structured-data side of this, worth running alongside the image-level validation above.
Measuring AI Overview inclusion specifically is harder, and it's worth being honest about the limits. Google's generative-AI performance report shows impressions tied to links surfaced in AI Overviews and AI Mode, but that's a page-level or link-level signal, not a confirmed "this exact image was shown" report. If you want to know whether images in Google AI Overviews actually include your pictures, you'll need to track representative prompts by hand or through a monitoring workflow, note the date, query wording, device, and region each time, and resist drawing a conclusion from a single appearance. Tracking whether your pages appear in Google AI Overviews covers the page-level version of that tracking discipline, which pairs naturally with the image-level checks in this guide.
Common mistake: treating a rise in page clicks as proof an image showed up in an AI Overview. It might mean that. It might mean nothing to do with the image at all. Keep the two data sources, and the two claims, separate.
What to do next
Work through these steps on the pages where you most want to optimize images for AI Overviews, not your whole site at once. A handful of product pages or key guides done properly will teach you more about what Google actually rewards than a site-wide sweep done quickly. Once you've got a baseline in Search Console's Image search view, revisit the pages that aren't showing up and check them against this list one at a time.
If image production, alt text, and metadata are eating time you'd rather spend on strategy, DeepSmith's Content Studio can take a planned article through to a publish-ready piece, cover image included, so the manual parts of this checklist stop being a bottleneck on every single post. You can start a free trial and see what a produced draft looks like against your own brand context.
For more on the broader picture beyond image-level work, how to optimize content for AI Overviews covers the writing and source-signal side of the same problem.
