Obrazy AVIF w wyszukiwarce Google: jak serwować je z NGINX

Wyszukiwarka Google indeksuje obrazy AVIF od ogłoszenia Google o obsłudze AVIF z 30 sierpnia 2024 r. NGINX może je dostarczać na dwa sposoby: pod nowymi nazwami plików z przekierowaniami albo pod niezmienionymi adresami URL dzięki negocjacji opartej na nagłówku Accept. Który wybrać? To zależy od tego, jak bardzo zależy Ci na stabilnych adresach obrazów i jak zachowują się Twoje cache. Cel jest tu skromny: przestawić część grafik bez psucia adresów URL obrazów i cache’owania.

Co właściwie zmienia obsługa AVIF w wyszukiwarce Google?

W skrócie: AVIF jest teraz obsługiwanym typem pliku w Grafice Google i w każdym innym miejscu, w którym wyszukiwarka korzysta z obrazów. Żeby takie pliki zostały zaindeksowane, nie trzeba robić nic szczególnego. Format jest otwarty, oparty na standardzie kompresji wideo AV1 i wyświetlają go wszystkie główne przeglądarki. Sprawdzone metody Google dotyczące obrazów wymieniają formaty akceptowane w atrybucie src elementu img: BMP, GIF, JPEG, PNG, WebP, SVG i AVIF. W praktyce więc obsługa AVIF w Google usuwa ostatni argument SEO przeciwko jego stosowaniu.

Czy konwertować każdy obraz? WebP vs AVIF i rada Google

Nie. Google odradza ślepe, hurtowe zmiany w całej witrynie i zaleca poświęcić czas na ocenę, który format najlepiej odpowiada Twoim potrzebom. Moim zdaniem WebP vs AVIF to decyzja podejmowana dla każdego obrazu osobno w ramach formatów nowej generacji, a nie projekt migracji całego serwisu. Oto od czego bym zaczął i czego bym nie ruszał:

• Konwertuj w pierwszej kolejności: duże zdjęcia hero, galerie produktów i obrazy w szablonach o dużym ruchu.
• Zostaw w spokoju: logotypy SVG, malutkie ikony i grafiki, które już mają pozycje w Grafice Google.

Zakoduj małą partię. Porównaj jakość wizualną i wagę na własnych plikach (a nie na cudzym benchmarku). Rozszerzaj wdrożenie dopiero wtedy, gdy wyniki to uzasadniają.

Jak nauczyć NGINX typu MIME image/avif

NGINX musi wysyłać Content-Type: image/avif. Potrzebuje do tego wpisu avif w mime.types albo bloku types w starszych instalacjach. Jeśli to pominiesz, plik wyjdzie jako application/octet-stream, a przeglądarki mogą go pobrać zamiast wyświetlić. Słabo. Dodaj mapowanie na własnym serwerze źródłowym:

types {
    image/avif avif;
}

Następnie uruchom curl -I https://example.com/img/hero.avif i odczytaj nagłówek odpowiedzi. Google zaznacza też, że rozszerzenie powinno odpowiadać typowi pliku, więc upewnij się, że Twoje pliki .avif naprawdę zawierają dane AVIF.

Opcja 1: nowe nazwy plików .avif z przekierowaniami po stronie serwera

Zmienia się rozszerzenie? Wtedy stary adres URL obrazu powinien przekierowywać po stronie serwera na nowy, dokładnie tak, jak radzi ogłoszenie Google. Pojedynczy plik ze zmienioną nazwą wymaga jednego bloku location z dokładnym dopasowaniem. Większą partię łatwiej utrzymać w map.

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

I nie poprzestawaj na przekierowaniu. Zaktualizuj każdy img src i każdy wpis w mapie witryny obrazów na nowy adres, żeby roboty nie polegały wyłącznie na przekierowaniu. Mechanika jest taka sama jak w przypadku stron, a trwałe przekierowania dla przemianowanych plików są tu właściwym wyborem. Kompromis jest prosty: dostajesz czyste, przyjazne dla cache adresy URL, ale każda przemianowana grafika wymaga własnej reguły i ponownego zaindeksowania.

Opcja 2: negocjacja treści obrazów, która nie zmienia adresów URL

NGINX może odczytać nagłówek Accept i zwrócić wariant AVIF pod tym samym adresem URL. Żaden adres obrazu się nie zmienia. Negocjacja treści obrazów to pięć kroków:

1. Wygeneruj bliźniacze pliki .avif obok oryginałów, na przykład hero.jpg.avif.
2. Dodaj map na $http_accept, która ustawia sufiks.
3. Użyj try_files, aby serwować wariant, a w razie jego braku oryginał.
4. Dodaj Vary: Accept do odpowiedzi.
5. Przeładuj serwer i przetestuj.

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

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

Jedno zastrzeżenie, i to niemałe: rozszerzenie w adresie URL nie odpowiada już serwowanemu typowi, co jest sprzeczne ze wskazówką Google, że warto, by były zgodne. Rozważ to w przypadku grafik, które mają znaczenie dla SEO obrazów. Nie chcesz negocjacji w ogóle? Jest jeszcze element picture z source type="image/avif" i zapasowym img.

Jak utrzymać poprawne cache i reguły hotlinkowania po zmianie

To tutaj zwykle coś idzie nie tak. Każdy cache stojący przed serwerem źródłowym musi uwzględniać Accept w kluczu za pośrednictwem nagłówka Vary, w przeciwnym razie przeglądarka bez obsługi AVIF może dostać plik AVIF z cache. Ustaw ten nagłówek na własnym NGINX i sprawdź, czy cache proxy albo CDN go respektuje - to ta sama dyscyplina, która daje Ci cache proxy bez nieaktualnych stron. Uwagi wymaga też ochrona oparta na nagłówku Referer. Rozszerz bloki location z valid_referers tak, aby obejmowały rozszerzenie avif, dzięki czemu nowe pliki będą podlegać Twoim dotychczasowym regułom hotlinkowania, a Grafika Google nadal będzie je pobierać. Reverse proxy takie jak Jalvo, z adresami IP w UE i USA, przekazuje odpowiedź serwera źródłowego dalej, więc o formacie i nagłówkach decyduje serwer źródłowy.

Jak sprawdzić, czy obrazy AVIF nadal działają w SEO obrazów

Najpierw curl, potem Search Console. Wyślij żądania z różnymi nagłówkami Accept, a następnie potwierdź w Search Console, że adresy URL obrazów są pobierane bez błędów. Porównaj dwa żądania:

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

Pierwsze powinno zwrócić Content-Type: image/avif, drugie oryginalny typ. Oba powinny zawierać Vary: Accept. Zachowaj też bez zmian tekst alt, otaczającą treść i mapę witryny obrazów, bo wytyczne Google mówią, że treść i metadane strony, na której osadzono grafikę, mocno wpływają na to, jak i gdzie pojawia się ona w wynikach.

Bezpieczne serwowanie obrazów AVIF to tak naprawdę po prostu stopniowe wdrożenie. Zacznij od garstki ciężkich plików. Wprowadź przekierowania albo Vary, zanim rozszerzysz zmianę. Sprawdzaj nagłówki ponownie po każdej edycji konfiguracji (tak, po każdej).

FAQ