Image SEO: alt text, formats, responsive sizes and lazy loading

Where images show up in Google

Images reach searchers in more places than the Images tab. Google lists features “such as the text result images, Google Discover, and Google Images”, and adds: “While each feature and product looks different, the general recommendations for getting images to appear in them is the same.” One set of good habits covers all three.

Images also matter for the page itself. Google notes that “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” So image SEO has two halves that you cannot separate: helping Google understand the image, and keeping it from slowing the page down.

What Google officially says

Three more statements frame everything below:

• “The content and metadata of the pages where an image is embedded can have a great influence on how and where the image may appear in Google's search results.”
• “Wherever possible, make sure images are placed near relevant text and on pages that are relevant to the image subject matter.”
• “Avoid filling alt attributes with keywords (also known as keyword stuffing) as it results in a negative user experience and may cause your site to be seen as spam.”

Use real img elements, not CSS backgrounds

“Using standard HTML image elements helps crawlers find and process images.” Google reads the src attribute: “Google can find images in src attribute of <img> element (even when it's a child of other elements, such as the <picture> element).” An image set as a CSS background is invisible to Google Images, whatever it shows to users. Google's own pair of examples:

<!-- Good -->
<img src="puppy.jpg" alt="A golden retriever puppy" />

<!-- Bad -->
<div style="background-image:url(puppy.jpg)">A golden retriever puppy</div>

The rule of thumb: if the image carries meaning (a product photo, a chart, a screenshot, a hero photo of the subject), use <img>. If it is pure decoration (a texture, a pattern, a gradient), CSS is the right place for it.

Inline SVG, data URIs and repeated images

• Inline SVG. An <svg> has no alt attribute. Google's advice: “for inline <svg> elements, you can use the <title> element.” Reference it with aria-labelledby.
• Data URIs. You can inline an image as Base64 in src, but “While inlining images can reduce HTTP requests, carefully judge when to use them since it can considerably increase the size of the page.” Keep it for tiny icons.
• One URL per image. When the same image appears on many pages, “consistently reference the image with the same URL, so that Google can cache and reuse the image without needing to request it multiple times.” Avoid cache-busting parameters that change on every deploy.

Alt text that works

Alt text is read by screen readers, shown when the image fails to load, and used by Google to understand the image. Google's guidance: “When writing alt text, focus on creating useful, information-rich content that uses keywords appropriately and is in context of the content of the page.”

How to write it

1. Describe what the image shows, in the context of this page. The same photo of a kitchen might be alt="Oak kitchen with white quartz worktop" on a product page and alt="Kitchen after the renovation" in a case study.
2. Keep it to a short phrase or a sentence. Skip “image of” and “picture of”: screen readers already announce that it is an image.
3. Use the keyword only where it describes the image. A product photo naturally includes the product name, model and colour.
4. For linked images, describe the destination. Google notes that “alt text in images is useful as anchor text if you decide to use an image as a link.”
5. Do not copy the caption word for word. Screen reader users would hear the same text twice.

Decorative images: alt="" not a missing alt

For dividers, background flourishes and icons placed next to text that already says the same thing, use an empty alt. MDN explains that alt="" “indicates that this image is not a key part of the content (it's decoration or a tracking pixel)”. A missing alt is different: screen readers may read out the file name instead. If an image is purely decorative and never needs to be in Google Images, CSS is an even cleaner option.

File names, captions and placement

Google calls the file name a minor signal: “the filename can give Google very light clues about the subject matter of the image.” Its example: “my-new-black-kitten.jpg is better than IMG00023.JPG.” And: “Avoid using generic filenames like image1.jpg, pic.gif, 1.jpg when possible.”

• Use lowercase words separated by hyphens: https://example.com/images/red-trail-running-shoe-side.webp.
• On a multilingual site, “If you localize your images, remember to also translate the filenames”.
• Do not rename existing images just for SEO. A new image URL starts from scratch; if you must rename, redirect the old URL.

The text around the image matters more than the file name. “Google extracts information about the subject matter of the image from the content of the page, including captions and image titles.” Put the image next to the paragraph it illustrates, use a <figcaption> when the image needs explaining, and make sure the page title and headings are about the same subject. A photo of a red shoe on a page about red shoes is easy to understand; the same photo on a generic “Gallery 7” page is not.

Image formats: JPEG, PNG, WebP, AVIF, SVG, GIF

Google Search supports images in “BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF.” It adds: “It's also a good idea to have the extension of your filename match with the file type.” So a file called photo.jpg should really be a JPEG, not a renamed WebP.

WebP vs AVIF: the trade-offs

WebP supports lossy and lossless compression, transparency and animation, and usually produces smaller files than JPEG at similar visual quality. AVIF often goes smaller still, but it is slower to encode, and very aggressive settings can smear fine detail, gradients and text in screenshots, so check the output by eye. Support is the other catch. web.dev puts it this way: “AVIF is brand new, and while support for WebP is excellent across modern browsers, it isn't a given across the entire web.” Serve AVIF and WebP through <picture> with a JPEG or PNG fallback, or let your CDN choose the format based on what the browser accepts.

Compression basics

• Export at the largest size the image is displayed at, multiplied by the device pixel ratio you support (usually 2×). A 4000-pixel camera original in an 800-pixel slot wastes bandwidth.
• Pick the quality setting by eye, not by a fixed number, and compare on a real screen.
• Strip camera metadata you do not need, but keep IPTC rights fields if you rely on them for licensing (see below).
• For animations, a short muted video is usually far lighter than a GIF.

Responsive images: srcset, sizes and picture

A phone and a 4K monitor should not download the same file. “The srcset attribute allows specifying different versions of the same image, specifically for different screen sizes.” The browser then picks one based on the screen and the layout. Google adds one condition: “However, some browsers and crawlers don't understand these attributes. We recommend that you always specify a fallback URL using the src attribute.”

• srcset with w descriptors lists the files and their real widths: shoe-480.webp 480w, shoe-960.webp 960w.
• sizes tells the browser how wide the image will be in the layout, for example (max-width: 600px) 100vw, 50vw. Without it the browser assumes the full viewport width and often downloads too much.
• x descriptors (logo.png 1x, [email protected] 2x) suit images with a fixed display size, such as logos.
• <picture> gives explicit control: different crops for mobile and desktop (art direction) or different formats. “The picture element also comes in handy for using new image formats with built-in graceful degradation for clients that may not yet support the new formats.”

<img
  src="/images/red-trail-shoe-960.jpg"
  srcset="/images/red-trail-shoe-480.jpg 480w,
          /images/red-trail-shoe-960.jpg 960w,
          /images/red-trail-shoe-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  width="960" height="640"
  alt="Red trail running shoe, side view">

<picture>
  <source type="image/avif"
    srcset="/images/red-trail-shoe-960.avif">
  <source type="image/webp"
    srcset="/images/red-trail-shoe-960.webp">
  <img src="/images/red-trail-shoe-960.jpg"
    width="960" height="640"
    alt="Red trail running shoe, side view">
</picture>

Inside <picture>, the <img> is not optional: it carries the alt text, the dimensions and the fallback URL. The <source> elements only offer alternatives.

Width, height and layout shift

When the browser does not know an image's size, it lays the page out without it and then pushes the content down once the file arrives. That jump is measured by Cumulative Layout Shift (CLS). The fix is old and simple. web.dev: “As a rule, you should always use height and width attributes on <img>, with values matching the intrinsic size of your image source”, and “By using the width and height attributes on your <img> elements, you'll avoid a high CLS score due to images.”

/* lets the image scale down while keeping its aspect ratio */
img { max-width: 100%; height: auto; }

The attributes give the browser the aspect ratio; the CSS makes the image responsive. With both in place, the space is reserved before the first byte of the image arrives. For CSS-sized containers, aspect-ratio does the same job.

Lazy loading without hiding images

Lazy loading delays offscreen images until the user scrolls near them. It saves bandwidth, but Google warns: “if not implemented correctly, this technique can inadvertently hide content from Google.” Two rules keep it safe.

Rule 1: the image people see first is never lazy. Images matter most for two of the three Core Web Vitals: LCP, INP, CLS. Largest Contentful Paint (LCP) is very often a hero or product image, and lazy-loading it delays the moment the page looks ready. web.dev is blunt: “never specify loading="lazy" on an "above the fold" image”. It also recommends a hint for the main image: “using fetchpriority="high" can inform the browser that the transfer of this image should be prioritized above images elsewhere on the page.”

Rule 2: lazy images must load without user actions. Google needs the implementation to load content “whenever it is visible in the viewport”, and explains why scroll-triggered or click-triggered loading fails: “Google Search does not interact with your page.” Native loading="lazy" and IntersectionObserver both work. A script that only swaps data-src into src after a scroll event does not.

Two more practical points. Do not inject the LCP image with JavaScript: it cannot start downloading until the script runs. And test: Google's check is simple, “If your image or video URLs appear in the src attribute on the <img> or <video> elements in the rendered HTML, your setup works correctly.” Use URL Inspection in Search Console to see the rendered HTML. The lessons Core Web Vitals: LCP, INP, CLS and JavaScript SEO and rendering cover both topics in depth.

Image sitemaps

“Image sitemaps are a way of telling Google about other images on your site, especially those that we might not otherwise find (such as images your site reaches with JavaScript code).” They are optional. They help most for large image libraries, galleries loaded by JavaScript and images hosted on a CDN domain. Google is flexible about the setup: “You can create a separate image sitemap or add image sitemap tags to your existing sitemap; either approach is equally fine for Google.”

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://example.com/shoes/red-trail-shoe/</loc>
    <image:image>
      <image:loc>https://cdn.example.com/images/red-trail-shoe-side.webp</image:loc>
    </image:image>
    <image:image>
      <image:loc>https://cdn.example.com/images/red-trail-shoe-sole.webp</image:loc>
    </image:image>
  </url>
</urlset>

• Only two tags are required: <image:image> and <image:loc>. “Each <url> tag can contain up to 1,000 <image:image> tags.”
• Image URLs may sit on another domain, such as a CDN. Google says “This is fine, as long as you verify both domains in Search Console.” Also make sure robots.txt on that domain does not block the images.
• <image:caption>, <image:title>, <image:geo_location> and <image:license> were removed from Google's documentation. Drop them from generators that still output them; put captions on the page and licence data in structured data instead.

General sitemap rules still apply; see the lesson XML sitemaps.

Preferred image, structured data and licensing metadata

Telling Google which image represents the page

“Google's selection of an image preview is completely automated”, but you can state a preference in three ways: the schema.org primaryImageOfPage property, an image property on the page's main entity (for example a BlogPosting), or the og:image meta tag.

<meta property="og:image" content="https://example.com/images/red-trail-shoe-side.jpg">

Google's rules for that preferred image:

• “Choose an image that's relevant and representative of the page.”
• “Avoid using a generic image (for example, your site logo) or an image with text in the schema.org markup or og:image meta tag.”
• “Avoid using an image with an extreme aspect ratio (such as images that are too narrow or overly wide).”
• “Use a high resolution, if possible.”

Images in rich results

Structured data such as Product, Recipe or Video can earn a badge in Google Images, and “In each of these structured data types, the image attribute is a required field to be eligible for a badge and rich result in Google Images.” The lesson Structured data in 2026 covers the markup itself.

Licensing metadata and the Licensable badge

If you sell or license photos, Google can show who made an image and how to use it: “providing licensing information can make the image eligible for the Licensable badge”. You can supply this in two ways:

• Structured data with ImageObject, added on every page where the image appears. Besides contentUrl, Google says “you must include one of the following properties:” creator, creditText, copyrightNotice or license. Add acquireLicensePage to point to the page that explains how to license it.
• IPTC photo metadata embedded in the file. “You only need to embed IPTC photo metadata once per image.” This is why you should not strip rights fields during compression.

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "ImageObject",
  "contentUrl": "https://example.com/photos/red-trail-shoe-side.jpg",
  "license": "https://example.com/license",
  "acquireLicensePage": "https://example.com/how-to-use-our-photos",
  "creditText": "Example Studio"
}
</script>

If both sources exist and disagree, “Google will use the structured data information.”

Removing images from Google Images

Sometimes the goal is the opposite: keeping an image out of search. Google documents three routes for images hosted on your own site.

User-agent: Googlebot-Image
Disallow: /images/dogs.jpg
Disallow: /private-photos/

A noimageindex robots meta tag on a page stops the images on that page from being indexed through it, but if the same image is embedded on another page it can still be indexed there. The header method is the one that follows the image everywhere. The lesson Meta robots and X-Robots-Tag explains the syntax.

A softer option is to opt out of inline linking: when the image request comes from a Google domain, Google says to “reply with a 200 HTTP status code, or a 204 HTTP status code and no content.” Google then shows only a thumbnail instead of the full-size image, and “This behavior isn't considered image cloaking and won't result in manual actions.”

Common mistakes

• ✕Important images as CSS backgroundsHero and product photos set with background-image are not indexed.
• ✕Missing alt instead of empty altDecorative images need alt=""; content images need a real description.
• ✕Keyword-stuffed or templated alt textalt="red shoes buy red shoes cheap", or the same alt on every product photo.
• ✕Lazy-loading the hero imageOften the single biggest avoidable LCP delay on a template.
• ✕Lazy loading that needs a scrolldata-src swapped in on scroll; Google never scrolls, so src stays a placeholder.
• ✕No width and heightContent jumps as images arrive, which raises CLS.
• ✕Full-size originals everywhereA huge file squeezed into a thumbnail slot, with no srcset or sizes.
• ✕AVIF or WebP with no fallbackOr a WebP file saved with a .jpg extension.
• ✕Image URLs that change on every deployGoogle has to fetch and process them again and again.
• ✕robots.txt block plus noindex headerThe block stops Google from ever seeing the header.

Image SEO checklist

FAQ

Sources

• Google Search Central — Google image SEO best practices
• Google Search Central — Image sitemaps
• Google Search Central — Fix lazy-loaded content
• Google Search Central — Image metadata in Google Images
• Google Search Central — Remove images hosted on your site from search results
• web.dev — Learn Images: Key performance issues
• web.dev — Learn Images: Image formats: AVIF
• MDN — The img element

Quotes checked against the official pages on 30 October 2026.