Image SEO: file names, alt text, formats, sizes and lazy loading

Images do two very different things for SEO. They can bring traffic of their own, through Google Images, image packs in regular results, Discover and visual search. And they decide a large part of how fast a page feels, since on most pages the largest element on screen is an image and images make up most of the bytes. Get them wrong and you lose on both counts: invisible in image search and slow everywhere else.

This guide covers the HTML, the files and the delivery, in that order, with the details that matter in practice.

Use real img elements

Search engines index images they find in <img> elements (and <picture> with an <img> fallback). Images set as CSS backgrounds are not indexed as content images. That is fine for decorative backgrounds and patterns, but a product photo, a chart or a diagram that is part of the content should be an img.

A well-formed content image looks like this:

<img src="/images/trail-shoe-side-view.webp"
     alt="Grey trail running shoe with a deep lugged sole, side view"
     width="1200" height="800" loading="lazy" decoding="async">

Each attribute does a specific job. src must be a crawlable URL, not a placeholder swapped by script. alt describes the image. width and height let the browser reserve space before the image loads, which prevents layout shift; see fixing CLS. loading="lazy" defers off-screen images, with an important exception covered below.

Alt text that helps people and search engines

Alt text exists for people who cannot see the image: screen reader users, and anyone whose connection failed to load it. Search engines use it as one of their main clues about what an image shows. Writing for the first audience almost always serves the second.

Image	Weak alt	Better alt
Product photo	"shoe"	"Grey trail running shoe with a deep lugged sole, side view"
Team photo on an about page	"team"	"Five members of the support team at a long table in the Lisbon office"
Chart in an article	"chart"	"Bar chart: organic clicks rose each month from January to June" (and explain the data in the text too)
Decorative divider	"decorative line"	Empty: alt=""
Logo linking to home	(missing)	The brand name

Avoid stuffing keywords ("running shoes trail running shoes best trail shoes") and avoid starting with "image of" or "picture of", which screen readers already announce. When the same image appears on many pages, such as a product thumbnail in listings, the alt can be shorter there than on the product page itself.

File names, captions and surrounding text

Search engines understand an image mostly from its context: the page title, the heading above it, the caption below, the paragraph next to it. A product photo on a page about that product, with a descriptive caption, is easy to understand. The same photo dropped into a generic gallery with no text is not.

• File names: trail-shoe-side-view.webp beats IMG_4031.webp. Use hyphens, lowercase and a few descriptive words. Do not rename existing images in bulk unless you also redirect the old URLs, because image URLs that change are treated as new images.
• Captions: text inside a <figcaption> is read by users far more than body text, and gives search engines a strong clue.
• Placement: put important images near the text that discusses them, not in a separate carousel at the bottom.

Formats: what to serve

Modern formats deliver the same visual quality at a fraction of the size of older ones.

Format	Use for	Notes
AVIF	Photos, complex images	Usually the smallest; slower to encode; supported by current major browsers
WebP	Photos and graphics	Widely supported, much smaller than JPEG and PNG; a safe default
JPEG	Fallback for photos	Use progressive encoding and quality around 75–85
PNG	Screenshots needing exact pixels, transparency	Often much larger than WebP; convert where possible
SVG	Logos, icons, simple illustrations	Tiny and sharp at any size; not suitable for photos

Serve modern formats with the <picture> element or through an image CDN that negotiates formats based on the browser's Accept header. Both work for search engines, as long as the img fallback has a real URL.

Sizes: stop sending 4000-pixel photos to phones

The most common waste is not the format but the dimensions. A product photo uploaded straight from a camera at 4000 pixels wide, displayed at 400 pixels on a phone, costs ten times the bytes it needs. Two fixes:

1. Resize on upload to the largest size you actually display, typically 1200 to 2000 pixels wide for full-width images.
2. Use responsive images with srcset and sizes, so phones download a smaller file than desktops:

<img src="/img/boot-1200.webp"
     srcset="/img/boot-480.webp 480w, /img/boot-800.webp 800w, /img/boot-1200.webp 1200w"
     sizes="(max-width: 600px) 100vw, 600px"
     alt="Brown leather hiking boot, three-quarter view" width="1200" height="800">

Most CMSs and e-commerce platforms generate several sizes automatically. Check that the generated sizes attribute matches your layout; a default of 100vw on an image that only fills a third of the screen makes desktops download far larger files than needed.

Lazy loading, and the image you must not lazy-load

Native lazy loading (loading="lazy") tells the browser to fetch an image only when it is about to scroll into view. It saves bandwidth and is understood by Google, which renders pages with a tall viewport and loads lazy images it finds. Use it for images below the fold.

Never use it on the main image at the top of the page: the hero image, the main product photo, the featured image of an article. That image is very often the Largest Contentful Paint element, and lazy-loading it delays it. For that one image, do the opposite: load it eagerly and consider fetchpriority="high". The LCP guide explains how to find the LCP element.

Avoid script-based lazy loading that puts the real URL in a data-src attribute and swaps it on scroll. Crawlers that do not scroll may never see the real image, and the delay often hurts LCP. Native lazy loading is supported by all current major browsers and needs no script.

Image sitemaps and structured data

Google discovers most images by crawling pages. An image sitemap, or image:image entries inside your normal XML sitemap, helps for images that are hard to find, for example images loaded by JavaScript or hosted on a CDN domain. It is optional for most sites; see XML sitemaps.

For products, recipes and articles, the image property in structured data tells search engines which image represents the page, and is required for some rich results. Use large images (Google recommends high resolution, with several aspect ratios for some result types) and make sure the URLs are crawlable and not blocked by robots.txt. The product page guide covers Product markup in more detail.

Hosting and delivery

• Do not block image directories in robots.txt if you want images indexed. Older configurations sometimes disallow /wp-content/ or /images/.
• Watch hotlink protection. Rules that refuse image requests without your domain as the referrer can also refuse crawlers, which send no referrer.
• Serve long cache headers and change the file name when the image changes, so browsers and CDNs can cache aggressively without serving stale images.
• Keep image URLs stable. CDNs or plugins that add a changing token to image URLs on every deploy make search engines see new images each time.

A ten-minute image audit

1. Open a typical product or article page, find the largest image above the fold, and check it is not lazy-loaded.
2. Check its file size and dimensions against how large it is displayed.
3. Look for img elements without alt, and without width/height.
4. Confirm modern formats are served (look at the response Content-Type in the network panel).
5. Check robots.txt does not block image folders, and that one image URL returns 200 to a crawler user agent.
6. Run the page through the SEO checker, which counts home page images without alt text along with the other technical basics.