Dlaczego zacząłem na poważnie traktować ruch z grafik?

Jakoś nigdy nie brałem Google Images na serio. W raportach widziałem pojedyncze kliknięcia, czasem coś drgnęło, ale nigdy nie miałem poczucia, że to kanał, którym warto się zajmować. Aż do chwili, gdy odpaliłem GSC dla jednego klienta i z ciekawości przełączyłem typ wyszukiwania na grafikę. Zobaczyłem setki kliknięć miesięcznie i ruch, którego nikt nie raportował ani nie optymalizował. Wtedy do mnie dotarło, że chyba trzeba będzie się zaprzyjaźnić z obrazkami.

Spis treści:

1. Dlaczego ruch z grafik jest naprawdę ważny?
2. Jakie elementy biorę pod uwagę, optymalizując grafikę pod Google?
3. Jak wdrażam Schema.org ImageObject – i po co to robię?
4. Jak analizuję ruch z grafik?
5. Sprzeczne dane z Google Images – co naprawdę oznaczają wzrosty i spadki?
6. Jak dobieram formaty zdjęć, żeby nie tracić ani jakości, ani pozycji?
7. Lazy loading: gdzie pomaga, a gdzie szkodzi?
8. Czy sitemapa dla grafik ma sens i kiedy ją robię?
9. Czy grafiki mogą uratować ruch, który zabierają AIO?
10. Podsumowanie w punktach

Dlaczego ruch z grafik jest naprawdę ważny?

Im dłużej się temu przyglądałem, tym bardziej zaczęło mi się to układać w logiczną całość. Wyszukiwanie się zmienia – i to nie jest żadna odkrywcza teza, ale skala tej zmiany robi robotę.

Dziś mniej więcej co czwarte zapytanie ma komponent wizualny. Ludzie klikają w zakładkę grafika, korzystają z modułów obrazów w SERP-ach, wrzucają zdjęcia do Google Lens i oczekują odpowiedzi wizualnej, a nie w formie ściany tekstu.

No i mamy jeszcze drugą stronę medalu – klasyczne wyniki organiczne są systematycznie podgryzane:

• Zero-clicki kradną ogromną część ruchu – według danych to ok. 58-62% wszystkich wyszukiwań (DigitalK / Amra & Elma).
• AI Overviews dokładają swoje – zabierają około 19-20% kliknięć z wyników organicznych (Senuto).

Efekt jest taki, że nawet jeśli robisz dobrą robotę z pozycjonowaniem, niekoniecznie zobaczysz to w liczbie kliknięć – ale to właśnie grafiki są jednym z niewielu miejsc, gdzie ten ruch jest jeszcze kierowany na strony internetowe.

Dlatego jeśli masz serwis z obrazami i nie wiesz, co się z nimi dzieje w Google, to trochę tak, jakbyś prowadził sklep i nie zaglądał do jednego z pomieszczeń. Może nic tam nie ma… a może stoi tam pół magazynu.

Jakie elementy biorę pod uwagę, optymalizując grafikę pod Google?

Z grafikami jest jeden podstawowy problem: Google nie widzi ich tak jak człowiek. Dla nas zdjęcie to kontekst, detale i emocje. Dla Google to plik, który trzeba „zrozumieć” na podstawie tego, co go otacza.

Dlatego kiedy optymalizuję obrazy, nie skupiam się na jednym elemencie, tylko na całym zestawie sygnałów:

• Atrybut alt – to jest w praktyce najważniejszy sygnał tekstowy dla pojedynczego obrazu. Ma opisywać to co, jest na zdjęciu, a przy okazji powinien zawierać najważniejsze słowo kluczowe.
• Nazwa pliku – jest czytana przez Google przed załadowaniem strony. „DSC_4821.jpg” mówi Googlebotowi tyle co nic, ale „czarne-buty-skorzane-meskie.jpg” mówi już całkiem sporo.
• Tytuł obrazu – w WordPressie to pole "Tytuł" w bibliotece mediów. Ma mniejsze znaczenie niż alt, ale uzupełniam go dla porządku.
• Tekst otaczający grafikę – nagłówek sekcji, w której jest osadzony obraz, akapit tuż przed i tuż po, podpis pod zdjęciem (caption). To ważne sygnały kontekstowe.
• Dane strukturalne Schema.org ImageObject – o nich więcej poniżej.

Jak wdrażam Schema.org ImageObject – i po co to robię?

W pewnym momencie doszedłem do wniosku, że skoro i tak przekazuję Google kontekst „dookoła” obrazu, to równie dobrze mogę mu go podać wprost.

Tu wchodzą dane strukturalne i ich konkretny typ: ImageObject.

W WordPressie najłatwiej wdrożyć ImageObject przez wtyczkę Yoast SEO lub Rank Math – obie automatycznie generują podstawowy markup dla obrazów. Wystarczy je odpowiednio skonfigurować.

Dla większej kontroli można użyć ręcznego JSON-LD, który da się wkleić przez wtyczkę WPCode lub bezpośrednio w szablonie.

Przykład najprostszego ImageObject w JSON-LD:

{  "@context": "https://schema.org",  "@type": "ImageObject",  "contentUrl": "https://twojastrona.pl/wp-content/uploads/buty-skorzane.jpg",  "name": "Czarne buty skórzane męskie — widok z przodu",  "description": "Klasyczne czarne buty skórzane na skórzanej podeszwie, rozmiary 40–46.",  "author": {    "@type": "Organization",    "name": "Nazwa firmy"  },  "license": "https://creativecommons.org/licenses/by/4.0/"}

Krótkie wyjaśnienie wybranych elementów:

• contentUrl (adres pliku),
• name (krótki opis, to samo co alt, ale może być nieco dłuższe),
• license (jeśli obraz jest na licencji CC lub własnej strony z warunkami użytkowania).

Jeśli chcę się upewnić, że wszystko działa ok, wchodzę w Rich Results Test od Google, wklejam adres strony i widzę, czy markup jest poprawnie odczytany.

Drugi sposób to Google Search Console → Ulepszenia. Jeśli Google wykryje ImageObject na większej liczbie stron, pojawi się tam osobny raport z błędami i ostrzeżeniami.

Jak analizuję ruch z grafik?

Domyślny widok raportu Skuteczność w GSC miesza razem ruch tekstowy, graficzny i z Google Discover.

Sposób wejścia w dane graficzne jest zawsze taki sam:

1. GSC → Skuteczność → Wyniki wyszukiwania.
2. Nad wykresem klikam + Nowy → Typ wyszukiwania → zaznaczam Grafika.
3. Ustawiam zakres dat na ostatnie 3 miesiące – krócej nie ma sensu, bo ruch graficzny jest bardziej sezonowy i zmienny niż tekstowy.
4. Włączam wszystkie cztery metryki naraz: Łączna liczba kliknięć, Łączna liczba wyświetleń, Średni CTR, Średnia pozycja.
5. W tabeli poniżej przełączam widok na Strony.

Kilka chwil i mam przed sobą pełny obraz: kliknięcia, wyświetlenia, CTR i średnią pozycję – ale już tylko dla obrazów.

Możecie zapytać, dlaczego zaczynam akurat od stron, nie od zapytań? Bo zapytania w Google Images są często kompletnie generyczne, np. „krzesło”, „sukienka”, „tatuaż”. Fajnie, ale co z tego wynika? Niewiele.

Strony pokazują już coś konkretnego. Który artykuł, która karta produktu lub sekcja serwisu generuje ruch graficzny. Mogę tam wejść i sprawdzić, czy to efekt świadomej optymalizacji, czy przypadek.

I dopiero na tym poziomie zaczyna się sensowna analiza.

Sprzeczne dane z Google Images – co naprawdę oznaczają wzrosty i spadki?

Najwięcej błędów widzę przy interpretacji danych, nie przy samej optymalizacji.

Klasyczny przykład: wyświetlenia rosną, kliknięcia stoją. Wiele osób zaczyna wtedy panikować, a to często oznacza po prostu pojawianie się na bardziej ogólne zapytania. Więcej ludzi widzi obraz, ale mniej klika – i to jest całkowicie normalne.

W takich sytuacjach sprawdzam zakładkę Zapytania, sortuję po wyświetleniach i patrzę, które frazy urosły. Jeśli to frazy dalekie od moich treści, to nie reaguję.

Z drugiej strony, spadek kliknięć przy stabilnych wyświetleniach to już coś, co weryfikuję dokładniej. Patrzę po kolei na te trzy rzeczy:

1. Czy nie zmieniły się adresy URL zdjęć (co skutkuje utratą historii indeksowania)?
2. Czy grafiki na tych stronach ładują się prawidłowo?
3. Czy Google nie zaczęło wyświetlać obrazów w podglądzie bez konieczności wchodzenia na stronę?

Zawsze też staram się porównać ruch graficzny z tekstowym. Robię to, zestawiając dwa widoki w GSC na tym samym zakresie dat: jeden z filtrem Grafika, drugi z filtrem Sieć. To daje bardzo ciekawy obraz.

I tutaj zdarza się, że SEO „tekstowe” leży, ale grafiki radzą sobie bardzo dobrze. Czyli tracę pozycje w wynikach webowych, a zdjęcia ratują widoczność.

Czasem jest odwrotnie – tekst rośnie, a grafiki stoją w miejscu. To sygnał, że nowe treści są dobrze zoptymalizowane, a obrazy są w jakiś sposób zaniedbane.

Jak dobieram formaty zdjęć, żeby nie tracić ani jakości, ani pozycji?

Format pliku decyduje o tym, ile miejsca zajmie obraz po kompresji i jak będzie wyglądał na ekranie.

W większości przypadków celuję w WebP. Daje dobry balans między jakością a wagą i jest wspierany praktycznie wszędzie.

Druga opcja to format AVIF. Traktuję go jako rozwiązanie „dla ambitnych”, kiedy naprawdę liczy się każdy kilobajt wielkości. AVIF daje jeszcze lepszą kompresję niż WebP, ale czas kodowania jest znacznie dłuższy – no i nie każdy CMS go akceptuje (nie da się go wgrać).

PNG zostawiam tylko dla grafik z przezroczystością, np. dla logotypów czy ikon. W każdym innym zastosowaniu PNG jest po prostu za ciężki.

Do kompresji często używam Squoosh od Google, bo daje szybki podgląd i kontrolę nad tym, co się dzieje z obrazem. Ale nic nie stoi na przeszkodzie, żeby sięgnąć po inne darmowe narzedzia webowe.

Lazy loading: gdzie pomaga, a gdzie szkodzi?

Lazy loading to atrybut loading="lazy" na znaczniku <img>, który każe przeglądarce wstrzymać pobieranie obrazu do momentu, gdy użytkownik zbliży się do niego podczas scrollowania.

To dobra technika dla obrazów osadzonych nisko na stronie, ale jeśli ktoś stosuje ją dla wszystkich grafik jak leci, to bardzo łatwo rozwalić LCP (Largest Contentful Paint). A LCP często jest liczony właśnie na głównym obrazie – np. na grafice hero lub pierwszym zdjęciu w artykule.

Moja zasada jest prosta: pierwszy obraz na stronie nigdy nie dostaje loading="lazy". Zamiast tego daję:

• loading="eager" (lub po prostu nie umieszczam żadnego atrybutu – eager jest domyślne),
• fetchpriority="high", który mówi przeglądarce, żeby potraktowała ten zasób priorytetowo.

<!-- Obraz LCP — hero, pierwszy w artykule --><img  src="zdjecie-glowne.webp"  alt="Opis obrazu"  width="1200"  height="630"  fetchpriority="high"><!-- Wszystkie pozostałe obrazy na stronie --><img  src="zdjecie-dodatkowe.webp"  alt="Opis obrazu"  width="800"  height="500"  loading="lazy">

function remove_lazy_loading_from_first_image( $attr, $attachment, $context ) {    static $image_count = 0;    $image_count++;    if ( $image_count === 1 ) {        $attr['loading']       = false;        $attr['fetchpriority'] = 'high';    }    return $attr;}add_filter( 'wp_get_attachment_image_attributes', 'remove_lazy_loading_from_first_image', 10, 3 );

Niby jest to detal, ale może zrobić sporą różnicę w Core Web Vitals.

Czy sitemapa dla grafik ma sens i kiedy ją robię?

Jeśli mogę pomóc Google jeszcze szybciej znaleźć i zrozumieć obrazy, to czemu by tego nie zrobić? Do tego wykorzystuję sitemapę.

Standardowa sitemapa XML informuje Google o stronach w serwisie, ale może nie zawierać informacji o grafikach. Jeśli chcemy, żeby Google wiedziało, które obrazy ma zaindeksować i powiązać z konkretnymi podstronami, warto użyć rozszerzenia sitemapowego dla grafik.

Wpis w sitemapie dla strony z grafikami wygląda tak:

<?xml version="1.0" encoding="UTF-8"?><urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">  <url>    <loc>https://twojastrona.pl/produkty/czarne-buty-skorzane/</loc>    <image:image>      <image:loc>https://twojastrona.pl/wp-content/uploads/czarne-buty-skorzane-front.webp</image:loc>      <image:title>Czarne buty skórzane męskie — widok z przodu</image:title>      <image:caption>Klasyczne buty skórzane na skórzanej podeszwie, dostępne w rozmiarach 40–46</image:caption>    </image:image>    <image:image>      <image:loc>https://twojastrona.pl/wp-content/uploads/czarne-buty-skorzane-bok.webp</image:loc>      <image:title>Czarne buty skórzane — widok z boku</image:title>    </image:image>  </url></urlset>

W WordPressie do wygenerowania takiej sitemapy można użyć Yoast SEO. W ustawieniach wtyczki włączam opcję dołączania grafik do sitemapy i wtedy Yoast automatycznie dodaje wpisy <image:image> dla obrazów przypisanych do stron i wpisów.

Czy grafiki mogą uratować ruch, który zabierają AIO?

Podsumowania AI od Google pojawiły się w polskich wynikach wyszukiwania stopniowo – i co istotne, ich wpływ na ruch graficzny jest inny niż na ruch tekstowy.

Zacznijmy od tego, że AI Overviews generują odpowiedź tekstową po lewej, a po prawej cytują źródła razem z grafikami. Użytkownik widzi nazwę domeny pod każdym obrazem.

W klasycznych wynikach tekstowych AI Overviews „kradną” kliknięcia – odpowiedź jest generowana bezpośrednio w SERP-ach i część użytkowników nie przechodzi dalej. Mimo, ze widoczność strony rośnie, to ruch (wejścia) spadają.

Grafiki działają trochę inaczej – z dwóch powodów:

1. Zdjęcia często pojawiają się jako element odpowiedzi AIO. Jeśli moja strona jest źródłem, obraz może zostać użyty jako ilustracja. To generuje wyświetlenia i czasem kliknięcia, których wcześniej by nie było.
2. Zapytania o charakterze wizualnym (jak coś wygląda, jak coś zrobić krok po kroku, produkty do kupienia) rzadziej wyzwalają AI Overviews w formie tekstowej, a częściej trafiają bezpośrednio do Google Images.

Co to zmienia w mojej pracy? Przestałem traktować ruch tekstowy i graficzny jako jeden kanał organiczny. Śledzę je osobno w GSC i mam dla nich osobne cele.

Zaczynam też patrzeć na ruch graficzny trochę jak na zabezpieczenie. Nie zastąpi w pełni ruchu tekstowego, ale może go częściowo kompensować – oczywiście jeśli zdjęcia są odpowiednio zoptymalizowane.

Można więc spokojnie powiedzieć, że jest to realny poligon walki o widoczność. Zwłaszcza teraz, gdy AI Overviews i zero-click search agresywnie wycinają kliknięcia z tradycyjnych wyników tekstowych.

Dziś widzę grafiki jako osobny kawałek SEO, który – jeśli jest dobrze ogarnięty – jest w stanie dowieźć bardzo konkretne wyniki.

Podsumowanie w punktach

1. Ruch wizualny to już standard: Grafika odpowiada za ok. 22-26% zapytan w Google, a popularność Google Lens (20 mld zapytań miesięcznie) sprawia, że ignorowanie tego kanału to realna strata ruchu.
2. Odpowiedź na AI Overviews: Podczas gdy tradycyjne wyniki tekstowe tracą kliknięcia na rzecz AI, sekcja Google Images pozostaje stabilnym źródłem wejść, często zasilając odpowiedzi generatywne jako źródło obrazów.
3. Analityka w 30 sekund: Śledzę skuteczność tego kanału w Google Search Console poprzez filtr Typ wyszukiwania: Grafika, co pozwala odkryć mi setki „niewidzialnych” wcześniej kliknięć.
4. Techniczna optymalizacja: Skupiam się na 5 rzeczach: unikalnych atrybutach alt, opisowych nazwach plików, kontekście tekstowym wokół grafiki, wdrożeniu danych strukturalnych ImageObject oraz sitemapie XML dla obrazów.
5. Wydajność bez strat dla SEO: Dzięki zastosowaniu lekkich formatów takich jak WebP/AVIF oraz inteligentnej konfiguracji lazy loadingu mogę pogodzić szybkość ładowania strony z wysokimi pozycjami.