Image SEO and Alt Attributes

Image SEO and alt attributes are three different questions that are usually blended: will Google find the picture, will it understand what is on it, and will the picture slow the page down. Google has a guide for the first two, while speed is covered by web.dev. This lesson covers what is documented, what is only practice, and which checklist rules — including "Latin only in the file name" and "alt up to 125 characters" — do not appear in Google's documentation.

It rests on Google's image SEO best practices guide.

First: so the picture gets found

• The img element. Google can find images in the src attribute of the img element, even when it is a child of other elements such as picture; Google doesn't index CSS images. A picture set through background-image does not exist for search.
• A fallback src. Some browsers and crawlers don't understand picture and srcset, so always specify a fallback URL using the src attribute.
• Formats. BMP, GIF, JPEG, PNG, WebP, SVG and AVIF are supported; it is also a good idea to have the file extension match the file type.
• An image sitemap. You can provide the URL of images Google might not otherwise have discovered by submitting an image sitemap, and unlike regular sitemaps it may include URLs from other domains, which suits CDNs; verifying the CDN's domain in Search Console is encouraged. The extension is covered in the lesson on XML sitemaps, and each page URL can carry up to 1,000 images.
• One address. If an image is referenced on multiple pages, consistently reference it with the same URL, so that Google can cache and reuse it.
• Not blocked. The image folders must not be blocked in robots.txt; what a crawl actually finds is shown by the site crawler.

An example with a fallback:

<picture>
  <source type="image/avif" srcset="sofa.avif">
  <source type="image/webp" srcset="sofa.webp">
  <img src="sofa.jpg" alt="A grey corner sofa" width="800" height="600">
</picture>

Second: so it is understood what is on the picture

Alt — the key attribute, but not the only source

Google's wording is exact: the most important attribute when it comes to providing more metadata for an image is the alt text, which also improves accessibility for people who can't see images. But Google uses alt text along with computer vision algorithms and the contents of the page to understand the subject matter of the image. When an image is a link, alt text is useful as anchor text.

How to write it: focus on useful, information-rich content that uses keywords appropriately and is in context of the page; avoid filling alt attributes with keywords, as it results in a negative user experience and may cause your site to be seen as spam. The documentation's own examples: missing alt is bad; a string of dozens of words is bad; "puppy" is better; "Dalmatian puppy playing fetch" is best.

Image types: these are W3C rules, not Google's

Note the last row: the old rule "repeat the image's text word for word" does not fit, per the W3C, when the text is already present nearby.

File names: a light clue, and the audience's language

On the file name the guide is restrained: it can give Google very light clues about the subject; when possible use short but descriptive names — my-new-black-kitten.jpg is better than IMG00023.JPG; generic names such as image1.jpg are best avoided. The rule "Latin only", though, the guide contradicts: if you localize your images, remember to also translate the filenames, keeping in mind the URL encoding guidelines if you're using non-Latin or special characters. For a Russian- or Ukrainian-language site that means a Russian or Ukrainian file name is acceptable, and in a link it is encoded — see the lesson on URL structure.

The context around an image

Google extracts information about the subject matter of an image from the content of the page, including captions and image titles; wherever possible make sure images are placed near relevant text and on pages relevant to the image subject matter. The words around a picture work for it just as its alt does. On aligning the words on a page see the lesson on keyword targeting.

Third: what makes a picture noticeable

• The preferred image. Selection of the preview is completely automated and takes several sources into account; you can influence it with metadata such as the primaryImageOfPage property or the image of the page's main entity.
• Structured data. For rich results and a badge in Google Images, the image attribute is a required field in the structured data types that support it. For articles the recommendation is multiple high-resolution images (a minimum of 50K pixels when multiplying width and height) with 16x9, 4x3 and 1x1 aspect ratios.
• Licences. Licence metadata can make an image eligible for the Licensable badge, which links to the licence; for that, pages containing images must be accessible without needing an account or logging in.
• The page title and description. Google automatically generates a title link and snippet from several sources, including the title and meta tags of each page.

Fourth: speed and lazy loading

Google's guide reminds us that images are often the largest contributor to overall page size, so modern optimisation and responsive techniques matter. The specific techniques are described on web.dev:

• Dimensions. Per the CLS guide, always include width and height attributes on images and video, or reserve the space with CSS aspect-ratio: the browser allocates space in advance and the layout does not jump.
• The main image. Per the LCP guide, never lazy-load your LCP image, as that always leads to unnecessary resource load delay and a negative impact on LCP. A priority hint to the browser is the fetchpriority attribute.
• The remaining images. Lazy loading suits pictures below the first screen. Google has a condition of its own for it: the implementation must load content when it becomes visible in the viewport, without relying on user actions such as scrolling or clicking, because Google Search does not interact with your page. And separately: don't add lazy-loading to content that is likely to be immediately visible when a user opens a page. The browser's built-in lazy loading and IntersectionObserver both fit.

Do not expect guarantees from speed: good results in Core Web Vitals reports don't guarantee a top ranking. More on the metrics in the lesson on Core Web Vitals.

Seeing the result

In the performance report the search type filter separates the traffic: "Image" is traffic from results shown in the Google Images tab, and "Web: multimodal" is search by image, including through Google Lens. That shows whether a site has a flow from images at all before you invest in optimisation. The pages with the most traffic, a place to start, are shown by the pages report, and a page's overall state by page analysis and the site audit.

What is not in Google's documentation

These widespread claims do not appear in the documentation, so they cannot be presented as rules:

• "Latin only in the file name, three to five words": Google advises translating file names when localising;
• "alt of 80–125 characters, screen readers cut off anything longer": Google gives no length;
• "accessibility is a direct ranking factor" and "Google penalises a bad LCP";
• "images in markup at least 1200 px": for articles the figure named is 50K pixels, width times height;
• "Google Lens requires a sharp image and structured data";
• "10–30% of traffic comes from Google Images", target weights (hero up to 100 KB, an icon under 5 KB), AVIF saving 50% and browser support percentages are guidelines and measurements from third-party sources; check them on your own images;
• the case "LCP from 3.8 to 1.4 s, Images traffic +340%" as proof.

That does not mean the opposite is true. It means the figures are observations, and the reliable basis is what the guide describes.

Checklist

1. Images embedded as img elements with a src; CSS backgrounds not used for content.
2. A fallback src for picture and srcset; a format from the supported list.
3. One address per image across pages; folders not blocked in robots.txt.
4. Informative alt, in context, with no keyword stuffing; empty for decorative ones.
5. File names short and descriptive, in the audience's language, with encoding in mind.
6. The picture placed near relevant text.
7. Width and height set on every image; the LCP image not lazy-loaded.
8. For the right page types, structured data with image; for articles, several aspect ratios.
9. Image traffic read in the performance report by search type.

Mistakes

• Content images in a CSS background.
• Alt that is a string of keywords, or identical on every picture.
• Lazy loading on the main image of the first screen.
• Images without width and height.
• Treating Cyrillic in a file name as an error and not translating names when localising.
• Blocking the image folder in robots.txt.

What comes next

The next lesson is about headings and page content: headings and content.