AVIF Images in Google Search: Serving Them From NGINX

Google Search has indexed AVIF images since Google’s announcement of AVIF support on August 30, 2024. NGINX can deliver them in two ways: under new file names with redirects, or under unchanged URLs through Accept-based negotiation. Which one should you pick? That depends on how much you care about stable image addresses and on how your caches behave. The goal here is modest: switch some pictures without breaking image URLs or caching.

What does AVIF support in Google Search actually change?

Short version: AVIF is now a supported file type in Google Images and in every other place Search uses images. Nothing special is required to get such files indexed. The format is open, built on the AV1 video compression standard, and all major browsers display it. Google’s image best practices list the formats accepted in the src attribute of img: BMP, GIF, JPEG, PNG, WebP, SVG and AVIF. So in practice, AVIF support in Google removes the last SEO argument against using it.

Should you convert every image? WebP vs AVIF and Google’s advice

No. Google advises against blind, sweeping changes across a website and recommends taking the time to evaluate which format works best for your needs. In my view, WebP vs AVIF is a per-image call among next-gen image formats, not a site-wide migration project. Here is where I would start, and what I would not touch:

• Convert first: large hero photos, product galleries, and images on high-traffic templates.
• Leave alone: SVG logos, tiny icons, and pictures already ranking in Google Images.

Encode a small batch. Compare visual quality and weight on your own files (not on somebody else’s benchmark). Widen the rollout only when the results justify it.

Teaching NGINX the image/avif MIME type

NGINX must send Content-Type: image/avif. For that it needs an avif entry in mime.types, or a types block on older installs. Skip this and the file goes out as application/octet-stream, and browsers may download it instead of rendering it. Not great. Add the mapping on your own origin server:

types {
    image/avif avif;
}

Then run curl -I https://example.com/img/hero.avif and read the response header. Google also notes that the extension should match the file type, so make sure your .avif files really carry AVIF data.

Option 1: new .avif file names with server-side redirects

Extension changes? Then the old image URL should redirect server-side to the new one, exactly as Google’s announcement advises. A single renamed file needs one exact-match location. A batch is easier to maintain in a map.

location = /img/hero.jpg {
    return 301 /img/hero.avif;
}

And don’t stop at the redirect. Update every img src and image sitemap entry to the new address, so crawlers do not depend on the redirect alone. The mechanics are the same as for pages, and permanent redirects for renamed files are the right choice here. The trade-off is simple: you get clean, cache-friendly URLs, but each renamed picture needs its own rule and a re-crawl.

Option 2: image content negotiation that keeps URLs unchanged

NGINX can read the Accept header and return an AVIF variant under the same URL. No image address changes at all. Image content negotiation takes five steps:

1. Generate .avif siblings next to the originals, for example hero.jpg.avif.
2. Add a map on $http_accept that sets a suffix.
3. Use try_files to serve the variant, falling back to the original.
4. Add Vary: Accept to the response.
5. Reload the server and test.

map $http_accept $avif_suffix {
    default        "";
    "~image/avif"  ".avif";
}

location ~* \.(jpe?g|png)$ {
    add_header Vary Accept;
    try_files $uri$avif_suffix $uri =404;
}

One caveat, and it is not a small one: the extension in the URL no longer matches the served type, which goes against Google’s hint that matching them is a good idea. Weigh this for pictures that matter in image SEO. Don’t want negotiation at all? There is the picture element, with a source type="image/avif" and an img fallback.

Keeping caches and hotlink rules correct after the switch

This is where things usually go wrong. Any cache in front of the origin must key on Accept through the Vary header, otherwise a browser without AVIF support can receive a cached AVIF file. Set the header on your own NGINX and verify that a proxy cache or CDN honors it - the same discipline that gives you proxy caching without stale pages. Referer-based protection needs attention too. Extend the valid_referers location blocks to cover the avif extension, so new files follow your existing hotlink rules and Google Images keeps fetching them. A reverse proxy such as Jalvo, with IP addresses in the EU and the USA, passes the origin’s response through, so format and headers are decided on the origin.

Checking that AVIF images still work for image SEO

Curl first, Search Console second. Send requests with different Accept headers, then confirm in Search Console that the image URLs are fetched without errors. Compare two requests:

curl -I -H 'Accept: image/avif' https://example.com/img/hero.jpg
curl -I https://example.com/img/hero.jpg

The first should return Content-Type: image/avif, the second the original type. Both should include Vary: Accept. And keep alt text, surrounding copy and the image sitemap intact, because Google’s guidelines say the content and metadata of the embedding page strongly influence how and where a picture appears in results.

Serving AVIF images safely is really just a gradual rollout. Start with a handful of heavy files. Put redirects or Vary in place before widening the change. Re-check headers after every configuration edit (yes, every one).

FAQ