Image SEO: How to Optimize Images for Google Search

Image SEO is often reduced to writing alt text, but an image only shows up in Google Images if it can be discovered, is served in a supported format, sits next to text that explains it, and does not slow the page down. This guide organizes those layers (discovery, files, placement and performance) into one checklist. Alt text and licensing are covered in depth in a separate article, so they only appear here at a high level.

What Image SEO Covers

Thinking about image SEO in four layers makes gaps easier to spot:

1. Discovery: can Google find the image at all? HTML image elements, rendering and image sitemaps belong here.
2. Files: is the image served in the right format, at a sensible size, with a meaningful name?
3. Placement: does the image sit next to the text, heading and caption that explain it?
4. Performance: does the image delay page load, especially as the largest element above the fold?

The layers depend on each other. Renaming a file achieves nothing if Google cannot discover the image, and a fast image on a page with no relevant content will struggle to appear for related searches. Google's Google Images SEO documentation (Opens in a new tab) touches on every layer and is the main source for the technical points in this article.

Audit order matters as well. Work through discovery first, then performance, then files and placement. Improving an image Google cannot see is wasted effort, while an image that delays Largest Contentful Paint hurts the whole page. File and placement fixes show clearer results once those two foundations are solid.

Alt text is an important part of the picture, but not the whole of it. For context-appropriate alt text and the terms that come with stock images, see our guide to article image alt text and stock image licensing. This article focuses on everything around it.

How Google Discovers Images

Google finds images through the src attribute of HTML img elements, including img elements nested inside a picture element. The documentation is direct on one point: Google doesn't index CSS images. A product photo shown only through a CSS background-image will not appear in Google Images, even though users see it on the page.

That distinction should shape design decisions. Decorative patterns, gradients and ornamental backgrounds can stay in CSS; they do not need to rank. Images that carry information, such as product photos, infographics, step-by-step screenshots and charts, should be delivered with an HTML image element.

JavaScript is the second discovery risk. Components that insert images on the client after the initial load can hide them until rendering completes. Google can process JavaScript, but rendering is an extra stage where things can go wrong. Use the URL Inspection tool in Search Console to confirm that image URLs appear in src attributes in the rendered HTML. The wider relationship between client-side rendering and indexing is covered in our guide to JavaScript SEO, rendering and indexing.

Finally, check robots.txt. If the directory or CDN hostname that serves your images is blocked, Google cannot fetch the files. These blocks are rarely intentional; they are usually left over from an old rule nobody revisited.

HTML Image Elements and Responsive Images

There are two ways to serve different images to different screen sizes: the srcset attribute on an img element, or a picture element with several source children. In both cases Google recommends specifying a fallback URL with the src attribute. When you use picture, include a final img element with src; some browsers and crawlers only read that fallback.

Points to get right with responsive images:

• srcset with sizes: the sizes attribute tells the browser how wide the image will display. Without it, the browser may download a much larger file than needed.
• Width and height: setting width and height that reflect the real aspect ratio reserves space before the image loads and reduces layout shift.
• Consistent content: every candidate in srcset should be the same image at a different size. If you want a different crop on mobile, picture with a media condition is the right tool.
• Preferred image: you can indicate the image that represents the page with og:image or structured data. Google recommends a relevant, representative, high-resolution image rather than a generic one like your site logo, and suggests avoiding extreme aspect ratios.

File Names, Formats and Compression

Google says short, descriptive file names give a light clue about an image's subject. Its own example contrasts a name like my-new-black-kitten.jpg with IMG00023.JPG. Avoid generic names such as image1.jpg, and consider translating file names on localized pages. Turning a file name into a keyword list adds nothing.

On formats, the documentation gives a clear list: BMP, GIF, JPEG, PNG, WebP, SVG and AVIF are supported when referenced in the src attribute of an img element. The file extension should also match the actual file type; serving WebP data under a .jpg extension breaks that rule.

WebP and AVIF can often produce smaller files at the same visual quality. Treat that as a page speed and user experience gain, not a ranking boost. A practical way to choose:

• Photos: WebP or AVIF, with a JPEG fallback if your audience needs it.
• Graphics with transparency: WebP or PNG.
• Logos, icons and simple illustrations: SVG.
• Animation: animated WebP or video instead of large GIFs.

Set compression levels by eye. Over-compression destroys product texture and makes text inside images hard to read. Google points out both sides: sharp, high-quality images attract more clicks, yet images are often the largest contributor to overall page size.

Surrounding Text and Captions

Google uses page content, captions and page titles to understand what an image is about. Whether an image appears for a query depends heavily on what the page around it says.

In practice, place images close to the paragraph that explains them; use them inside the relevant section rather than in a gallery dumped at the end of the article. Write a short caption that adds information instead of repeating the alt text. Keep the image's subject aligned with the page's subject; a random landscape photo in a coffee machine guide helps neither readers nor search.

The page title and meta description also shape what users see around your image in search. Someone who clicks an image in Google Images decides whether to visit the page based on that title and description. If the title contradicts the image, the click becomes less likely.

How images and video should work alongside copy in sponsored content is covered in our article on images and video in sponsored posts. The principle is the same: the image should support what the text is saying.

When an Image Sitemap Helps

An image sitemap tells Google about images it might not find otherwise. Google's image sitemap documentation (Opens in a new tab) gives images loaded through JavaScript as an example. Each url entry gets image:image tags, each containing the required image:loc tag, and a single url entry can hold up to 1,000 images.

One update is easy to miss: image:caption, image:title, image:geo_location and image:license have been removed from Google's documentation. Older templates may still include them; for new sitemaps, image:loc is all you need.

Images can live on a different hostname, such as a CDN. In that case the documentation asks you to verify the hosting site in Search Console and make sure robots.txt does not block the images.

Not every site needs an image sitemap. If your images are already served with HTML image elements and your pages are crawled properly, regular sitemaps and internal links are usually enough. Image sitemaps make the most sense for sites that load images with JavaScript, run large product catalogs, or host images on a separate domain. To check the sitemaps you already have, see our walkthrough on auditing XML sitemaps and fixing errors.

Lazy Loading and Above-the-Fold Images

Lazy loading delays offscreen images until the user scrolls near them. Done well, it speeds up the first load and avoids downloading data nobody sees. Done badly, it hurts both user experience and Google's ability to see your content.

Google's lazy-loading guidance sets two core rules. First, the implementation must load all relevant content when it enters the viewport. Browser built-in lazy loading, the IntersectionObserver API, or libraries that load content on viewport entry all fit. Second, loading must not depend on user actions such as scrolling or clicking, because Google does not interact with pages that way.

A third warning concerns the first screen: content that is visible immediately should not be lazy loaded. If the hero image, the main banner photo or the first product image carries loading="lazy", the browser discovers it late and it appears late. Load those images normally, and if needed, signal priority with fetchpriority="high".

To check your setup, open the rendered HTML in Search Console's URL Inspection tool and confirm image URLs sit in src attributes. Images that only ever live in custom attributes like data-src and never move into src are a red flag.

Images and Page Speed

On most pages an image is the largest content element, which means it directly drives Largest Contentful Paint. According to web.dev's LCP guide (Opens in a new tab), a good experience means LCP of 2.5 seconds or less; anything between 2.5 and 4 seconds needs improvement, and above 4 seconds is poor. The threshold is measured at the 75th percentile of page loads, segmented across mobile and desktop.

Elements that can be the LCP element include img elements, image elements inside SVG, video poster images, and background images loaded with url(). That last one matters: a CSS background image is not indexed in Google Images, but it can still be your LCP element and affect speed.

To speed up an LCP image, work in this order. Identify the LCP element first. If it is an image, make sure it is discoverable directly in the HTML source; images found only through JavaScript or CSS start late. Then size the file to what the screen actually needs, pick a suitable format, and remove lazy loading. Finally, check that server and cache settings deliver image files quickly.

On publisher pages that carry ads, images and ad slots compete for the same early screen space. We look at that trade-off in our article on balancing ads and Core Web Vitals for publishers.

Different Priorities for Product and Blog Images

Product pages and blog posts need different things from image optimization. On a product page, the image is part of the buying decision: shoppers want to see the item from several angles, in its true color and in detail. On a blog post, images usually support the explanation of a process, a screen or a comparison.

For product images, priorities include original photos for every product, separate images for color variants, a balance between zoom-ready resolution and a fast first load, and filling the image property in product structured data. How product imagery and copy should work together is covered in our product description writing guide; when the features in the description match what shoppers see in the photos, trust goes up.

For blog images, the question is whether the image carries information. The cover should represent the topic, and images in the body should explain the step or data being discussed. Unrelated photos added only to raise the image count just make the page heavier.

Imagine a hypothetical kitchenware store that shows product photos as CSS backgrounds and reuses the same stock photo across its blog posts. The team moves product photos into HTML image elements, renames files after the products, removes lazy loading from the first product image, and adds topic-specific process images to each article. The scenario is fictional; its purpose is to show which layer each change touches.

Image Licensing and Metadata

Google Images can display creator, usage rights and credit information for an image. You can provide it in two ways: structured data on the page, or IPTC photo metadata embedded in the image file. When the two conflict, Google uses the structured data.

With structured data, contentUrl is required, plus at least one of creator, creditText, copyrightNotice or license. The Licensable badge requires the license property; acquireLicensePage is recommended. On the IPTC side, the fields Google reads include Creator, Credit Line, Copyright Notice, Licensor URL and Web Statement of Rights.

This metadata is not documented as a ranking factor. It shapes how the image is presented and what information users see, and display is never certain. For images you create yourself, adding credit and rights information helps people trace the source when your images are reused elsewhere.

For stock and third-party images, verify usage rights at the level of the individual asset. A "free" label on a collection does not always cover every use.

Sample Template: Image SEO Checklist

This sample template lets you audit a page's images across all four layers; the status column holds example values for a fictional page.

Run the checklist per template rather than per page. Auditing the product, category and blog templates fixes the same mistake across hundreds of URLs at once. Pick one representative page for each template, fill in the table there, and recheck the same page after the fix to confirm the change reached the whole template.

Frequently Asked Questions

Do image file names matter for SEO?

Google says short, descriptive file names provide a light clue about an image's subject. They are not decisive, but replacing names like IMG00023.JPG with names that describe the content is an easy, worthwhile step. Avoid keyword stuffing.

Does using WebP improve rankings?

No, switching formats is not documented as a ranking advantage on its own. WebP and AVIF usually produce smaller files, which helps page speed and user experience. Google supports common formats including WebP and AVIF.

Are CSS background images shown in Google Images?

No. Google's image SEO documentation states plainly that CSS images are not indexed. Serve any image you want to appear in search with an HTML image element.

Does every site need an image sitemap?

No. If images are served with HTML image elements and pages are crawled properly, it is often unnecessary. It is most useful for images loaded with JavaScript, large catalogs, or images hosted on a separate domain.

Should the hero image be lazy loaded?

No. Content visible immediately should not be lazy loaded; the hero image is often the LCP element, and lazy loading delays it. Load it normally and reserve lazy loading for offscreen images.

Do stock photos weaken image SEO?

Using stock photos is not documented as a problem in itself, but because the same image appears on many sites, it adds little distinctive value. Original images that actually explain the topic give users more information. If you use stock photos, confirm the license for each image.

Conclusion and Next Step

Image SEO works when discovery, files, placement and performance support each other. Serve informative images with HTML elements, choose descriptive names and suitable formats, place images next to the text that explains them, and keep the first-screen image out of lazy loading. If you need in-depth copy that gives your images the context they deserve, take a look at our content writing service and weigh the options against the details on the product page.