What Actually Ranks an Image in 2026

Image SEO has two payoffs: visibility inside Google Images, and a healthier ranking for the page that hosts the image. This guide separates the signals that move rankings from the ones that do not, and shows where AVIF fits.

The two outcomes image SEO buys you

Optimising an image targets two distinct results:

A spot in Google Images — the image appears as a direct result, linked to your page.
A stronger parent page — image context (alt text, captions, nearby copy) helps Google read the page topic.

Most teams chase the second and forget the first. Image-search clicks convert well for visual and product queries, so the first is worth deliberate effort.

Ranking signals vs myths: the short answer

Alt text, nearby copy, file names, resolution, and page speed move rankings. Format choice and image count do not.

Factor	Affects ranking?	Why
Alt text quality	Yes	Primary text signal Google reads for an image
Surrounding copy	Yes	Strongest context signal, stronger than alt alone
Descriptive file name	Yes (minor)	Used in Google Images and the URL preview
Page load speed	Yes (indirect)	Core Web Vitals are a confirmed ranking input
Resolution available	Yes	Google prefers a large variant for results
Format (AVIF vs JPEG)	No	No format ranks higher; speed is the real lever
Number of images	No	More images earns nothing on its own
`title` attribute	No	Not used for image search

Google states it reads alt text together with computer vision and page content to understand an image, per Google's image SEO documentation. Alt text leads; vision assists.

Writing alt text that serves screen readers and crawlers

Alt text does three jobs: it is read aloud by screen readers, shown when an image fails to load, and treated as content by search engines.

Aim for a complete, specific phrase of roughly 50 to 125 characters. Describe what the image shows, and include a keyword only when it is genuinely part of that description.

Strong examples:

alt="Brown leather messenger bag on an oak desk"
alt="Quarterly revenue chart, up 30 percent year over year"

Weak examples:

alt="" on a meaningful image — an accessibility and SEO miss.
alt="IMG_0234.avif" — a file name carries no meaning.
alt="bag leather brown bags messenger mens bag" — keyword stuffing is flagged as spam.
The same alt text repeated across many images — Google discounts duplicates.

Skip the "image of" or "photo of" prefix; the element already announces itself as an image. For purely decorative graphics (dividers, background textures), use alt="" so screen readers ignore them.

Naming files so they carry meaning

Use short, hyphenated, lower-case names that describe the subject: brown-leather-messenger-bag.avif beats IMG_20260524_134522.avif.

Two practical notes:

If your CMS auto-renames uploads to hashes, point the renamer at the content slug instead.
Keep the descriptive name when you convert. A JPG to AVIF or PNG to AVIF conversion should preserve the meaningful stem, not reset it to a GUID.

Placing images near the text that explains them

Google leans heavily on the copy surrounding an image — captions, the paragraph above and below, nearby headings, and anchor text. This context can outweigh alt text for understanding what an image means.

Three habits that help:

Put a product photo beside its name and description, not in an isolated gallery.
Wrap meaningful images in <figure> with a <figcaption> when a caption adds value.
Avoid dumping every image into one carousel stripped of explanatory text.

<figure>
  <img
    src="/img/messenger.avif"
    alt="Brown leather messenger bag on an oak desk"
    width="800"
    height="600"
  />
  <figcaption>The Hartford messenger bag, hand-stitched in Italian leather.</figcaption>
</figure>

The <figure> and <figcaption> pairing creates an explicit, machine-readable link between image and caption.

Serving the right size with srcset and sizes

Responsive markup lets a phone download a small variant while Google still sees a high-resolution version. Use srcset with several widths plus a sizes hint.

<img
  src="/img/messenger-1200.avif"
  srcset="
    /img/messenger-480.avif 480w,
    /img/messenger-800.avif 800w,
    /img/messenger-1200.avif 1200w
  "
  sizes="(max-width: 600px) 100vw, 800px"
  alt="Brown leather messenger bag on an oak desk"
  width="1200"
  height="800"
/>

Two reasons this matters for ranking:

Fast mobile loads feed Core Web Vitals, which Google measures on real users.
Google Images favours a large variant — keep at least one edge at 1200px or more, and never ship only thumbnails.

Setting dimensions to stop layout shift

Always set width and height (or a CSS aspect-ratio) on every image. The browser then reserves space before the image loads, which prevents the jump that inflates Cumulative Layout Shift.

CLS is one of the three Core Web Vitals. A missing dimension on a hero image is a common, avoidable cause of a poor score. The Core Web Vitals & Images guide covers the full metric set.

How AVIF feeds the page-experience signals

Format is not a ranking signal, but the bytes a format saves are. AVIF stores a photo in roughly half the size of an equivalent JPEG, and 20 to 25 percent smaller than WebP — see the AVIF format overview.

Smaller image bytes improve the metrics Google actually scores:

Largest Contentful Paint drops when the hero image is a small AVIF instead of a large JPEG.
Total transfer falls, helping users on slow mobile connections that Google's field data captures.

Ship AVIF first with fallbacks so the savings reach the ~94% of users who support it, while older browsers still get an image:

<picture>
  <source type="image/avif" srcset="/photo.avif" />
  <source type="image/webp" srcset="/photo.webp" />
  <img src="/photo.jpg" alt="…" width="1200" height="675" />
</picture>

The AVIF vs WebP comparison covers the trade-off, and AVIF Browser Support details the fallback patterns. For the encoder settings behind the byte savings, see AVIF Optimisation and Lossy vs Lossless Compression.

Lazy loading without hiding images from crawlers

Native loading="lazy" is crawl-safe and saves bandwidth by deferring off-screen images. Two rules keep it from backfiring:

Never lazy-load the LCP image. Deferring the hero pushes LCP later and can drop the score from good to needs-improvement.
Keep the final src in the server-rendered HTML. Google's renderer runs JavaScript, but custom JS lazy-loaders that swap src only after interaction risk hiding the image from indexing.

The AVIF Lazy Loading guide shows the loading priority pattern in full.

Structured data and og:image for rich results

For images central to a page, schema markup and social tags sharpen discovery. Reserve ImageObject for the images that represent the page entity — product shots, article heroes — not every decorative graphic.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Hartford Messenger Bag",
  "image": [
    "https://example.com/img/messenger-1200.avif",
    "https://example.com/img/messenger-1200-side.avif"
  ]
}

Provide multiple absolute high-resolution URLs; Google Shopping and image search both use them. For social previews, set og:image (and twitter:image) to a large, absolute URL so Facebook, LinkedIn, and X render a rich card. Note that most social crawlers do not yet decode AVIF, so point og:image at a JPEG or PNG variant.

When an image sitemap is worth it

An image sitemap helps Google find images that normal crawling might miss — assets loaded by unusual JavaScript or buried behind tabs.

<url>
  <loc>https://example.com/products/messenger-bag</loc>
  <image:image>
    <image:loc>https://example.com/img/messenger-1200.avif</image:loc>
  </image:image>
</url>

It complements, rather than replaces, your regular sitemap. The payoff is largest for image-heavy catalogues with thousands of assets; a small blog rarely needs one.

A pre-publish image checklist

Run this before shipping a content page:

Every meaningful image has specific alt text; decorative ones use alt="".
File names are descriptive, not hashes.
width and height are set on every image.
The LCP image is eager-loaded and ideally preloaded; the rest are lazy.
srcset and sizes cover the device range you serve.
At least one variant is 1200px or larger on the long edge.
AVIF is served first with a WebP or JPEG fallback.
Product or article schema lists high-resolution image URLs.
og:image points to a JPEG or PNG for social previews.

FAQ

Does using AVIF directly improve my Google ranking?

No — no format ranks higher. AVIF helps indirectly by cutting bytes, which improves the Core Web Vitals that Google does score.

How long should alt text be?

Around 50 to 125 characters. Write a complete, specific phrase; go longer only when the image content genuinely needs it.

Should I lazy-load every image?

No. Lazy-load off-screen images, but eager-load the LCP hero, or you delay it and hurt your LCP score.

Usually not yet. Most social crawlers do not decode AVIF, so set og:image to a JPEG or PNG variant.

Do I need an image sitemap?

Only for image-heavy sites. It mainly helps when assets are hard to crawl; small sites are fine without one.

Where to go next

AVIF Optimisation — the encoder side of byte savings
Core Web Vitals & Images — the metrics Google scores
AVIF Lazy Loading — loading priority done right
AVIF Browser Support — fallback patterns
Convert now: JPG to AVIF, PNG to AVIF

Get alt text, file names, dimensions, and modern formats right on every image, and the gains compound — one stronger page and one more image search result at a time.