Image SEO: A Practical Guide to Alt Text, Formats and Fast Images

Images do more work on a page than almost any other element. They explain products and processes, they are often the largest thing on screen, and they can bring visitors through Google Images, Discover and the thumbnails next to text results. They are also the most common reason a page is heavy, slow and jumpy while it loads.

Good image SEO is therefore three jobs at once: help Google find and understand each image, describe images properly for people who cannot see them, and deliver them quickly without pushing content around. This guide covers all three using Google's image documentation, the W3C's accessibility tutorials and web.dev's performance guidance, with copy-ready markup and a checklist you can apply page by page.

How Google finds and understands images

Google's image SEO best practices start with discovery. Google finds images in the src attribute of <img> elements, including an <img> inside <picture>, and it states plainly that it "doesn't index CSS images". For images Google might not find otherwise, such as images your site inserts with JavaScript, you can add an image sitemap. It may list image files hosted on other domains, such as a CDN, with up to 1,000 <image:image> entries per page; Google has deprecated the caption, geo location, title and license tags. Our guide to XML sitemap best practices covers the sitemap basics.

To understand an image, Google uses alt text together with computer vision and the content of the page: captions, image titles, surrounding text and, lightly, the file name. The landing page matters as well, because its title, description and structured data influence how and where an image can appear.

Alt text: write it for people first

Alt text is first an accessibility feature: screen readers read it aloud, and Google notes it also helps people on low-bandwidth connections. Google also calls it the most important attribute for describing an image, and warns that filling alt attributes with keywords "results in a negative user experience and may cause your site to be seen as spam". Its own examples run from bad to best: no alt at all, a list of keywords, "puppy", and finally "Dalmatian puppy playing fetch".

For deciding what to write, the W3C's alt decision tree covers most images in four questions:

1. Does the image contain text? If the same text also appears as real text nearby, or the text is only decoration, use alt="". If it is an icon with a function, describe the function. Otherwise put the image's text in the alt attribute.

2. Is it the content of a link or button? If the link or button would be unclear without it, describe the destination or the action, not the picture.

3. Does it add meaning to the page? For a simple photo or graphic, write a brief description that conveys that meaning. For a chart or diagram, give the information elsewhere on the page as well, for example in a caption or a table. If it only repeats nearby text, use alt="".

4. Is it purely decorative? Use alt="". The W3C's decorative images tutorial explains why omitting the attribute is not an option: some screen readers then announce the file name instead.

File names, captions and surrounding text

Google's documentation is specific about file names: they give "very light clues" about the subject, so use short, descriptive names such as my-new-black-kitten.jpg rather than IMG00023.JPG or image1.jpg. If you have thousands of images, automate the naming; if you localize pages, translate the file names too.

The page around the image carries more weight. Google says it extracts information about an image's subject from the page content, including captions and image titles, and recommends placing images near relevant text on pages that are relevant to the image's subject. A product photo in a product description says more than the same photo in a generic gallery.

Avoid putting important text inside images. web.dev's image format guide notes that text in images is not selectable, searchable or zoomable; use real text or a web font for anything people need to read.

Choose the right format and file size

Google notes that images are often the largest contributor to page size. The format decides much of that weight. web.dev's guidance, summarized:

All six formats in the table are on Google Search's list of supported image formats. Where you serve AVIF or WebP, web.dev suggests keeping a JPEG or PNG fallback, which the <picture> element in the next section handles.

Neither Google nor web.dev sets a byte limit per image. As a working rule, resize every image to the largest size it is actually displayed at and compress it. Backlnk's Image SEO Audit uses disclosed heuristics of its own: it flags files over 200 KB for review and over 500 KB as oversized.

Responsive images: srcset, sizes and picture

Sending a 2,000-pixel photo to a 400-pixel phone screen wastes data. Responsive markup lets the browser choose. According to web.dev's responsive images guide, srcset lists the available files with width descriptors (480w means 480 pixels wide), and sizes tells the browser how wide the image will be displayed so it can pick the right file before layout. sizes does not set the display size, so you still need CSS, and it does not accept percentages. Serving three to five sizes is common.

Google adds one requirement for crawlers: some browsers and crawlers don't understand srcset or <picture>, so always include a fallback src, and inside <picture> always end with an <img> element that has one.

<picture>
  <source type="image/avif"
          srcset="/img/boot-480.avif 480w, /img/boot-960.avif 960w, /img/boot-1440.avif 1440w"
          sizes="(max-width: 600px) 100vw, 600px">
  <source type="image/webp"
          srcset="/img/boot-480.webp 480w, /img/boot-960.webp 960w, /img/boot-1440.webp 1440w"
          sizes="(max-width: 600px) 100vw, 600px">
  <img src="/img/boot-960.jpg"
       srcset="/img/boot-480.jpg 480w, /img/boot-960.jpg 960w, /img/boot-1440.jpg 1440w"
       sizes="(max-width: 600px) 100vw, 600px"
       width="960" height="720"
       alt="Brown leather hiking boot with a lugged rubber sole, side view">
</picture>

Keep every file in a srcset at the same aspect ratio, as web.dev recommends, so a single width and height pair stays correct whichever file the browser picks.

Width, height and layout shift

Until an image file arrives, the browser does not know how tall it is. Without dimensions it starts at zero height, and everything below jumps down when the image appears. That jump counts toward Cumulative Layout Shift, one of the Core Web Vitals.

web.dev's CLS guide gives the fix: always set width and height attributes on images and videos, or reserve space with CSS aspect-ratio. Modern browsers derive an aspect ratio from the two attributes before the file loads, so with img { width: 100%; height: auto; } in your stylesheet the image stays responsive and its space is reserved. With art direction in <picture>, each <source> can carry its own width and height.

Dimensions matter even more with lazy loading. web.dev's lazy-loading guide notes that images without dimensions default to 0 × 0 pixels, so in a gallery the browser may decide they all fit in the viewport and load every one of them at once.

Lazy loading and fetchpriority: load the right image first

Native lazy loading defers images that are far from the viewport until the user scrolls near them: add loading="lazy". Browsers that don't support it ignore it, and the default (eager) loads images as usual. The rule from web.dev is equally simple: use loading="lazy" only for images outside the initial viewport, because the browser cannot start a lazy image until layout tells it where the image sits.

Google Search adds its own condition in its guide to fixing lazy-loaded content: content must load when it becomes visible in the viewport, because Google Search does not interact with the page by scrolling or clicking. Browser-level lazy loading, IntersectionObserver and libraries that load on entering the viewport all meet that condition; loading images only after a click does not.

For the main image, do the opposite. In Chrome, images start at a low fetch priority and are only raised once layout shows they are in the viewport. web.dev's Fetch Priority guide recommends fetchpriority="high" on the image likely to be the Largest Contentful Paint element so it starts loading immediately, and its LCP guide adds that setting high priority on more than one or two images makes the hint unhelpful.

<!-- Visible without scrolling: load early, never lazy -->
<img src="/img/trail-hero-1200.webp" width="1200" height="600"
     fetchpriority="high"
     alt="Hikers crossing a rocky ridge above a valley at sunrise">

<!-- Further down the page: lazy -->
<img src="/img/boot-sole-800.webp" width="800" height="600"
     loading="lazy"
     alt="Close-up of a lugged rubber boot sole">

Audit every image on a page with Backlnk

The Image SEO Audit lists every <img> on a page with its source line, alt text, dimensions, loading attributes and responsive sources, then requests up to 60 image files to measure their size, format and status. It reports:

• Missing alt attributes, decorative images (alt="") to double-check, and alt text that repeats the file name, uses a generic word, runs over 125 characters or is reused for different images.
• Images without width and height, the most common source of image-related layout shift.
• Broken images, files served through redirects or with the wrong content type, and formats Google Search does not list as supported.
• Files over 200 KB or 500 KB, large JPEG, PNG or GIF files that could be AVIF or WebP, and large images without srcset.
• loading="lazy" on the first images in the page, and whether the first image uses fetchpriority="high".

It is upfront about its limits. It checks that alt text exists and flags obvious problems, but it cannot judge whether a description is accurate. "Above the fold" is estimated from the first two content images in document order, not from a measured layout, and CSS background images, images inside iframes and inline SVG are not part of the inventory. Choose Rendered mode if your images are added by JavaScript. The Page Speed Test then shows which image is really the LCP element, and the free full audit runs both alongside Backlnk's other checks and e-mails you the report.

Next step

Pick your most important page type, such as a product, article or service template, run the audit on one example, and work through this checklist:

• Every content image is an <img> with descriptive alt text; decorative images have alt="".
• File names are short and descriptive, and images sit next to the text they illustrate.
• Photos are served as AVIF or WebP with a fallback, resized to their display size.
• Large images offer several sizes through srcset and sizes, with a fallback src.
• Every image has width and height.
• The main image loads eagerly with fetchpriority="high"; only images further down use loading="lazy".