Google Lens i multimodalne AI search: jak optymalizować zdjęcia w WordPressie i WooCommerce

Współczesna rekonfiguracja wyszukiwarek internetowych przesuwa punkt ciężkości z tradycyjnych zapytań tekstowych na interakcje multimodalne. Użytkownicy urządzeń mobilnych coraz częściej kierują aparat telefonu na fizyczny produkt, element maszyny przemysłowej lub próbkę tkaniny, aby za pomocą Google Lens, ChatGPT Vision czy Bing Visual Search natychmiast zidentyfikować towar, porównać ceny i zlokalizować dostawcę. Równolegle autonomiczne systemy sztucznej inteligencji analizują zasoby graficzne sklepów internetowych nie tylko jako elementy dekoracyjne, lecz jako podstawowe źródło danych faktograficznych o wymiarach, specyfikacjach technicznych i certyfikatach jakości.

Dla inżynierów i właścicieli serwisów opartych na WordPressie oraz WooCommerce oznacza to konieczność wdrożenia nowoczesnej architektury przetwarzania i serwowania multimediów. Przestarzałe podejście polegające na wgrywaniu plików JPEG i wypełnianiu podstawowego atrybutu alt nie wystarcza, aby zdobyć widoczność w zintegrowanych interfejsach zakupowych nowej generacji.

#Rosnąca rola wyszukiwania wizualnego i multimodalnych modeli AI

Ewolucja modeli takich jak Google Gemini i OpenAI GPT-4o diametralnie zmieniła sposób, w jaki boty indeksujące postrzegają treść witryn internetowych. Dawniej robot wyszukiwarki polegał wyłącznie na tekście otaczającym grafikę, nazwie pliku i znacznikach meta. Dzisiaj silniki wizualne przeprowadzają wielowarstwową analizę pikseli w czasie rzeczywistym:

• Wektorowa identyfikacja obiektów (Visual Embeddings): Algorytm przekształca kształt, proporcje i detale produktu na wielowymiarowe wektory cech, porównując je bezpośrednio z bazą miliardów zarejestrowanych wzorców handlowych.
• Optyczne rozpoznawanie znaków (OCR): Tekst umieszczony na etykiecie produktu, tabliczce znamionowej silnika elektrycznego czy składzie surowcowym jest automatycznie ekstrahowany i przetwarzany jako pełnoprawny kontekst indeksacyjny.
• Spójność obrazu i tekstu: Wytyczne Google dla informacji o produktach sprzedawcy wymagają, by obrazy przedstawiały oznaczoną treść, więc zdjęcie sprzeczne z danymi produktu to problem z zasadami, a do tego problem z dopasowaniem.

Jeżeli sklep internetowy sprzedaje specjalistyczne części zamienne lub produkty konsumenckie bez czytelnych, poprawnie przygotowanych fotografii o wysokiej ostrości detali, agenci zakupowi nie będą w stanie dopasować oferty do zapytań użytkowników posługujących się zdjęciami referencyjnymi.

#Co Google Lens robi ze zdjęciem produktu

Google opisuje Lens jako sposób wyszukiwania aparatem, obrazem albo zrzutem ekranu, gdy czegoś trudno opisać słowami (Google Lens). W zakupach, jak podaje ta sama strona, Lens ustala, kto produkuje dany przedmiot, ile kosztuje i gdzie go kupić, a strona wymienia około 35 krajów, w których te wyniki zakupowe są dostępne. Lens tłumaczy też tekst z aparatu na ponad 100 języków, czyli korzysta z tego samego odczytu tekstu, który wyłapuje etykiety i tabliczki znamionowe na zdjęciach produktów.

W październiku 2024 Google poinformował, że Lens obsługuje prawie 20 miliardów wyszukiwań wizualnych miesięcznie, i pokazał stronę wyników produktu z opiniami, cenami kilku sprzedawców i miejscami zakupu (Google, 3 października 2024). Według wpisu Lens rozpoznaje sfotografowany przedmiot za pomocą modeli AI i Shopping Graph, który obejmuje ponad 45 miliardów produktów. Sklep nie zgłasza niczego osobno do Lens: produkt trafia na tę stronę wyników przez dane, które Google już o nim ma, czyli feed Merchant Center i samą kartę produktu. Google nie publikuje przewodnika po Lens dla właścicieli witryn, więc praktyczne dźwignie to te udokumentowane: wytyczne Grafiki Google, dane strukturalne produktu i wymagania Merchant Center dotyczące zdjęć, opisane niżej.

#Jak Google odczytuje obraz na stronie WordPressa

Przewodnik Google po SEO obrazów wymienia sygnały, które Google pobiera ze strony (Google Search Central, sprawdzone metody SEO dla obrazów). Obsługiwane formaty to BMP, GIF, JPEG, PNG, WebP, SVG i AVIF, a rozszerzenie pliku powinno odpowiadać jego typowi. Tekst alternatywny jest wskazany jako najważniejszy atrybut metadanych obrazu, a przewodnik odradza upychanie w nim słów kluczowych. Przykład Google przechodzi od braku alt, przez alt="puppy", do alt="Dalmatian puppy playing fetch". Nazwy plików powinny być krótkie i opisowe, więc my-new-black-kitten.jpg jest lepsze niż IMG00023.JPG. Reguła zmiany nazw w procesie wgrywania się opłaca, bo pliki z aparatów i od dostawców rzadko mają użyteczne nazwy.

Kontekst liczy się tak samo jak plik. Google wyciąga informacje o temacie obrazu z treści strony, w tym z podpisów i tytułów obrazów, i zaleca umieszczanie grafik blisko powiązanego tekstu. Obrazy osadzone przez CSS nie są indeksowane, co wyklucza zdjęcia produktów wstawiane jako background-image przez page buildery i wtyczki sliderów. Przy znacznikach responsywnych Google zaleca zawsze zostawić zapasowy adres w atrybucie src obok srcset lub <picture>; WordPress już dodaje srcset i sizes do obrazów w treści, nie usuwając src (wp_image_add_srcset_and_sizes). Mapy witryny dla obrazów mogą zawierać adresy <image:loc> z innych domen, co ma znaczenie, gdy biblioteka mediów jest serwowana z hosta CDN. Aby wskazać, który obraz reprezentuje stronę, przewodnik odsyła do primaryImageOfPage, mainEntityOfPage albo meta tagu og:image.

#Architektura przetwarzania multimediów w WordPressie: libvips i format AVIF

Standardowe środowisko WordPressa przez lata opierało się na bibliotece GD (Graphics Draw) do tworzenia miniatur i przeskalowywania wgrywanych plików graficznych. W przypadku sklepów WooCommerce z tysiącami produktów biblioteka GD generuje ogromne zużycie pamięci RAM i powolne przetwarzanie wsadowe, co wymuszało stosowanie starszych formatów JPEG i PNG o niskiej kompresji.

Nowoczesny stos technologiczny może korzystać z biblioteki libvips (np. przez binding php-vips lub procesy w tle oparte na silniku Sharp). Autorzy opisują libvips jako bibliotekę przetwarzającą obrazy na żądanie i wielowątkowo, która działa szybko i zużywa mało pamięci w porównaniu z podobnymi bibliotekami (libvips). Dzięki temu masowa konwersja dużego katalogu do AVIF jest wykonalna:

<?php
/**
 * Integracja strumieniowej konwersji do formatu AVIF z uzyciem libvips w WordPressie
 */
declare(strict_types=1);

namespace WPPoland\MediaArchitecture;

use Jcupitt\Vips\Image;
use WP_Error;

class ModernImageProcessor
{
    private const QUALITY_AVIF = 68; // Zoptymalizowany balans jakosci do rozmiaru pliku

    public function generateAvifVariant(string $sourcePath, string $destinationPath): bool
    {
        if (!file_exists($sourcePath)) {
            return false;
        }

        try {
            // Wczytanie obrazu strumieniowo bez alokacji calej bitmapy w pamieci RAM
            $image = Image::newFromFile($sourcePath, ['access' => 'sequential']);

            // Zapis do formatu AVIF z uzyciem libheif/libvips
            $image->writeToFile($destinationPath, [
                'Q'           => self::QUALITY_AVIF,
                'compression' => 'av1',
                'strip'       => false, // Zachowanie kluczowych metadanych IPTC
            ]);

            return true;
        } catch (\Throwable $e) {
            error_log(sprintf('Blad generowania pliku AVIF dla %s: %s', $sourcePath, $e->getMessage()));
            return false;
        }
    }
}

AVIF zwykle daje mniejsze pliki niż JPEG przy porównywalnej jakości obrazu i przy umiarkowanej kompresji zachowuje czyste krawędzie i drukowany tekst. Zmierz oszczędność na własnym katalogu, zanim podejmiesz decyzję: packshoty na białym tle kompresują się zupełnie inaczej niż zdjęcia aranżacyjne, a etykiety, które mają pozostać czytelne, wymagają wyższej jakości niż gładkie tło.

#Jak WordPress 6.5 obsługuje wgrywanie plików AVIF

Obsługa AVIF trafiła do rdzenia WordPressa w wersji 6.5 i zależy od biblioteki graficznej serwera: Imagick albo GD muszą obsługiwać ten format (ogłoszenie zespołu rdzenia WordPressa). Ogłoszenie wyjaśnia, jak sprawdzić w kokpicie WordPressa, czy serwer wymienia AVIF wśród obsługiwanych formatów. Jeśli tak, pliki AVIF da się wgrać i generują rozmiary pośrednie tak jak JPEG czy PNG. Konwersja innych formatów jest opcjonalna i odbywa się przez filtr image_editor_output_format; przykład z ogłoszenia mapuje image/jpeg na image/avif.

Jedno ograniczenie powinno trafić do każdego planu AVIF w sklepie. Atrybut obrazu w Merchant Center przyjmuje JPEG, WebP, PNG, GIF, BMP i TIFF (Merchant Center, link do obrazu), a AVIF nie ma na tej liście. Sklep, który konwertuje każdy wgrany plik do AVIF i kasuje oryginały, nie ma już czego podać w feedzie. Zachowaj oryginał JPEG lub WebP każdego zdjęcia produktu albo generuj go dla feedu, a AVIF serwuj przeglądarkom przez <picture>.

Więcej informacji o wydajnych połączeniach magazynów mediów z systemami nadrzędnymi znajdziesz w naszym opracowaniu dotyczącym zagadnienia, jakim są integracje woocommerce erp.

#Semantyczne opisywanie zdjęć ze Schema.org i typem ImageObject

Aby roboty Google i autonomiczne systemy AI prawidłowo skojarzyły fotografię z konkretną ofertą handlową, kod HTML strony musi zawierać ustrukturyzowane metadane w formacie JSON-LD. Zamiast ograniczać się do prostego ciągu adresów URL w schemacie Product, należy zdefiniować pełne obiekty ImageObject:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Product",
      "@id": "https://sklep-przemyslowy.pl/produkt/zawor-kulowy-dn50/#product",
      "name": "Zawor kulowy ze stali nierdzewnej DN50 PN40",
      "sku": "VALV-SS-DN50",
      "image": [
        {
          "@type": "ImageObject",
          "@id": "https://sklep-przemyslowy.pl/media/zawor-kulowy-dn50-glowny.avif",
          "contentUrl": "https://sklep-przemyslowy.pl/media/zawor-kulowy-dn50-glowny.avif",
          "url": "https://sklep-przemyslowy.pl/media/zawor-kulowy-dn50-glowny.avif",
          "width": "2400",
          "height": "2400",
          "encodingFormat": "image/avif",
          "caption": "Zawor kulowy przemyslowy DN50 widok z boku z widoczna dzwignia sterujaca",
          "representativeOfPage": true,
          "creditText": "Laboratorium Produktowe WPPoland",
          "copyrightNotice": "Wszelkie prawa zastrzezone 2026",
          "license": "https://sklep-przemyslowy.pl/warunki-licencji-zdjec"
        },
        {
          "@type": "ImageObject",
          "@id": "https://sklep-przemyslowy.pl/media/zawor-kulowy-dn50-tabliczka.avif",
          "contentUrl": "https://sklep-przemyslowy.pl/media/zawor-kulowy-dn50-tabliczka.avif",
          "url": "https://sklep-przemyslowy.pl/media/zawor-kulowy-dn50-tabliczka.avif",
          "width": "2000",
          "height": "1500",
          "encodingFormat": "image/avif",
          "caption": "Tabliczka znamionowa z numerem seryjnym i normami cisnieniowymi PN40",
          "representativeOfPage": false
        }
      ]
    }
  ]
}

representativeOfPage to właściwość schema.org oznaczająca główne zdjęcie produktu. Przewodnik Google po obrazach wymienia primaryImageOfPage, mainEntityOfPage i og:image jako sposoby wskazania preferowanego obrazu, a dla informacji o produktach sprzedawcy Google wymaga image i zaleca kilka plików wysokiej rozdzielczości (co najmniej 50 000 pikseli, szerokość razy wysokość) w proporcjach 16x9, 4x3 i 1x1 (Google Search Central, informacje o produktach sprzedawcy). Google nie dokumentuje, by Lens przykładał większą wagę do którejś z tych właściwości, więc traktuj je jako czytelne oznaczenie. Ujęcie tabliczki znamionowej z precyzyjnym opisem caption daje czytelnikom i systemom odczytu tekstu specyfikację zwykłym tekstem obok zdjęcia.

W celu weryfikacji integralności danych oraz ochrony struktur serwera przed nieautoryzowanymi modyfikacjami warto zaplanować regularny audyt bezpieczeństwa wordpress.

#Techniki optymalizacji elementu picture i skracanie LCP

Największym wyzwaniem w sklepach e-commerce jest pogodzenie wysokiej rozdzielczości zdjęć (niezbędnej do sprawnego działania Google Lens i powiększania detali w galerii) ze ścisłymi wymaganiami Google Core Web Vitals dotyczącymi wskaźnika Largest Contentful Paint (LCP do 2,5 sekundy).

Prawidłowa implementacja wymaga zastosowania semantycznego znacznika <picture> z progresywną negocjacją formatów oraz atrybutami srcset i sizes:

<!-- Zoptymalizowany znacznik picture dla glownego zdjecia produktu -->
<picture class="woocommerce-product-hero-picture">
  <!-- Nowoczesny format AVIF o najwyzszej kompresji -->
  <source
    type="image/avif"
    srcset="/media/zawor-dn50-600.avif 600w,
            /media/zawor-dn50-1200.avif 1200w,
            /media/zawor-dn50-2400.avif 2400w"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px"
  />
  <!-- Format rezerwowy WebP dla starszych przegladarek -->
  <source
    type="image/webp"
    srcset="/media/zawor-dn50-600.webp 600w,
            /media/zawor-dn50-1200.webp 1200w,
            /media/zawor-dn50-2400.webp 2400w"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px"
  />
  <!-- Standardowy plik JPEG jako ostateczny fallback -->
  <img
    src="/media/zawor-dn50-1200.jpg"
    alt="Zawor kulowy DN50 ze stali kwasoodpornej w rzucie bocznym"
    width="1200"
    height="1200"
    loading="eager"
    fetchpriority="high"
    decoding="async"
    class="object-cover w-full h-auto"
  />
</picture>

Kluczowe reguły inżynieryjne obejmują:

1. fetchpriority="high" oraz loading="eager" na głównym zdjęciu produktu: Zapobiega to opóźnieniom w harmonogramie renderowania przeglądarki, gwarantując pobranie pliku przed wykonaniem skryptów JavaScript.
2. Wstępne ładowanie (Preload) w sekcji <head>: Wstrzyknięcie nagłówka <link rel="preload" as="image" type="image/avif" href="..." imagesrcset="..." imagesizes="..."> pozwala przeglądarce zażądać głównego zdjęcia, zanim przetworzy arkusze stylów.
3. Obowiązkowe atrybuty width i height: Ustalenie proporcji eliminuje skoki układu strony (Cumulative Layout Shift, CLS) podczas asynchronicznego ładowania pliku.

#Metadane IPTC, EXIF i bezpieczeństwo biblioteki mediów

Automatyczne wtyczki optymalizujące grafikę w WordPressie często bezkrytycznie usuwają wszystkie metadane z nagłówków plików graficznych w celu zaoszczędzenia kilku kilobajtów. Razem z danymi prywatnymi znikają wtedy pola autora i praw autorskich.

Należy precyzyjnie rozróżnić kategorie metadanych:

• Metadane do usunięcia (Prywatność i bezpieczeństwo): Współrzędne GPS, numery seryjne aparatów fotograficznych oraz profile konfiguracyjne oprogramowania graficznego powinny być bezwzględnie czyszczone.
• Metadane do zachowania (autorstwo i prawa autorskie): Pola IPTC takie jak By-line (twórca), Copyright Notice (prawa autorskie), Headline (tytuł) oraz Object Name (unikalny identyfikator produktu/SKU).

Grafika Google może pokazywać twórcę, autora zdjęcia i dane licencji z tych pól, jak opisuje następna sekcja. Google nie twierdzi, że dane IPTC wpływają na pozycje, więc powodem ich zachowania są autorstwo i prawa.

#Które pola licencji obrazu odczytuje Grafika Google

Google dokumentuje dwa sposoby dołączania informacji o prawach do obrazu: metadane IPTC osadzone w pliku albo dane strukturalne ImageObject na stronie (Google Search Central, metadane licencji obrazów). Z pliku Google odczytuje pola Web Statement of Rights, Licensor URL, Creator, Credit Line i Copyright Notice. Web Statement of Rights jest wymagane do oznaczenia licencji w Grafice Google, pozostałe cztery są zalecane.

W danych strukturalnych wymagane jest contentUrl, bo na jego podstawie Google ustala, którego obrazu dotyczą metadane. Obok musi się znaleźć co najmniej jedna z właściwości creator, creditText, copyrightNotice lub license, a gdy jedna jest ustawiona, test wyników z elementami rozszerzonymi zaleca pozostałe trzy. license jest potrzebne do oznaczenia licencji, a acquireLicensePage wskazuje stronę, która wyjaśnia, jak uzyskać licencję na obraz. Google dodaje, że nie gwarantuje wyświetlenia tych metadanych w wynikach wyszukiwania, a strona nie mówi nic o pozycjach. Wypełniaj te pola dla własnych zdjęć produktów jako element ochrony praw i oznaczania autorstwa. W starszym kodowaniu IIM pole Credit Line ma numer 2:110, a Copyright Notice 2:116.

#Co rdzeń WordPressa robi z IPTC i EXIF podczas wgrywania

WordPress sam odczytuje pola IPTC przy wgrywaniu obrazu. wp_read_image_metadata() pobiera autora zdjęcia z IPTC Credit (2#110), a w razie braku z Creator (2#080), prawa autorskie z 2#116, podpis z Description (2#120), tytuł z Headline (2#105) lub Title (2#005) oraz datę wykonania z 2#055 i 2#060 (dokumentacja dla deweloperów WordPressa). Od wersji 4.4 filtr wp_read_image_metadata dostaje surową tablicę IPTC, a od 5.0 także tablicę EXIF, więc wtyczka może przejąć dodatkowe pole, na przykład numer katalogowy producenta, bez ponownego parsowania pliku.

To, co zostaje w wygenerowanych rozmiarach, zależy od edytora obrazów. Przy Imagick metoda thumbnail_image() wywołuje strip_meta(), która usuwa wszystkie profile poza icc, icm, iptc, exif i xmp (WP_Image_Editor_Imagick::strip_meta). EXIF jest na tej chronionej liście, więc współrzędne GPS ze zdjęcia zrobionego telefonem mogą zostać w przeskalowanych kopiach. Jeśli dane lokalizacji muszą zniknąć, usuń je przed wgraniem albo w osobnym kroku, a potem sprawdź wygenerowany rozmiar narzędziem exiftool, zamiast ufać przełącznikowi we wtyczce.

#Feedy produktowe z obrazami o wysokiej rozdzielczości dla Google Shopping

Google Merchant Center pobiera główne zdjęcie z image_link i do 10 dodatkowych ujęć z additional_image_link (link do obrazu, link do dodatkowego obrazu). Udokumentowane wymagania:

1. Rozmiar: Google zaleca obrazy około 1500 x 1500 pikseli lub większe i zapowiedział minimum 500 x 500 pikseli dla wszystkich produktów od 31 stycznia 2027. Pliki nie mogą przekraczać 16 MB ani 64 megapikseli.
2. Formaty: JPEG, WebP, PNG, GIF, BMP i TIFF, z rozszerzeniem zgodnym z formatem. AVIF nie ma na liście.
3. Kompozycja: produkt powinien zajmować nie mniej niż 75% i nie więcej niż 90% obrazu, bez ramek, elementów promocyjnych, znaków wodnych i nałożonych logo.
4. Obrazy generowane: obrazy utworzone przez generatywną AI muszą mieć metadane, które to wskazują, a osadzonych tagów takich jak IPTC DigitalSourceType nie wolno usuwać.
5. Dostęp: robots.txt musi wpuszczać Googlebota i Googlebot-Image, a adresy obrazów nie powinny mieć parametrów zmieniających się przy każdym wysłaniu feedu.

Dodatkowe linki do obrazów to miejsce na inne ujęcia i zdjęcia w użyciu, które pokazują skalę produktu.

Serwowanie plików wysokiej rozdzielczości z hosta CDN zoptymalizowanego pod cache odsuwa zapytania robotów o duże katalogi od serwera PHP.

#Asynchroniczne przetwarzanie grafik na poziomie CDN i headless WordPress

W wielkoskalowych wdrożeniach e-commerce przetwarzanie tysięcy wariantów graficznych bezpośrednio na serwerze aplikacji WordPress obciąża procesor i pamięć, i konkuruje z obsługą zamówień. Częstym wzorcem jest przeniesienie logiki transformacji na poziom globalnej sieci brzegowej (Edge Network) z wykorzystaniem Cloudflare Images, Fastly Image Optimizer lub dedykowanego klastra Sharp w środowisku Node.js/Bun.

Zalety rozdzielenia warstwy mediów w architekturze bezgłowej:

• Kompresja w locie (On-the-fly transformations): Oryginalny plik źródłowy w pełnej rozdzielczości przechowywany jest w bezpiecznym magazynie S3/R2, a serwery brzegowe generują formaty AVIF i dopasowane rozmiary w ułamku sekundy na podstawie parametrów w adresie URL.
• Ochrona serwera głównego: Zapytania robotów o pliki graficzne obsługuje cache brzegowy, więc statyczne obrazy nie uruchamiają procesu PHP.
• Zastrzeżenie dotyczące metadanych: opcja metadata w Cloudflare działa tylko dla wyjścia JPEG. copyright (domyślnie) zostawia wyłącznie tag EXIF z prawami autorskimi, keep zachowuje większość EXIF łącznie z lokalizacją GPS, a przy każdym innym formacie wyjściowym, także WebP i PNG, wszystkie metadane są odrzucane (Cloudflare Images). Wariant AVIF wygenerowany na brzegu nie niesie autora IPTC, dlatego dane licencji muszą być także w danych strukturalnych strony.
• Zgodność z architekturami decoupled: Frontend zbudowany w Astro lub Next.js dynamicznie renderuje zoptymalizowane komponenty wizualne z zachowaniem błyskawicznego czasu TTFB.

Poznaj nasze doświadczenia w projektowaniu niezawodnych platform cyfrowych w ramach usług headless wordpress.

#Automatyczna kontrola jakości i zarządzanie profilem kolorów

Często pomijanym elementem obsługi zdjęć w e-commerce są profile kolorów (profile ICC). Jeśli dostawca wgrywa zdjęcia w przestrzeni Adobe RGB lub ProPhoto RGB, a serwer odrzuca profil bez przeliczenia wartości kolorów, barwy w przeglądarce wychodzą wyblakłe albo przesunięte i przestają odpowiadać fizycznemu produktowi.

Żeby tego uniknąć, cały katalog trzeba znormalizować do standardowej przestrzeni sRGB. Potok ciągłej integracji może dodatkowo uruchamiać automatyczne testy kontrastu tła i ostrości obiektu, zanim zdjęcia trafią na produkcję.

<?php
/**
 * Obowiazkowa normalizacja do sRGB przy wgrywaniu mediow
 */
declare(strict_types=1);

namespace WPPoland\ColorGovernance;

final class ProfileNormalizationFilter
{
    public function ensureStandardSrgbProfile(string $imagePath): void
    {
        if (!extension_loaded('imagick')) {
            return;
        }

        try {
            $imagick = new \Imagick($imagePath);
            $colorspace = $imagick->getImageColorspace();

            if ($colorspace === \Imagick::COLORSPACE_CMYK) {
                // Konwersja plikow drukarskich CMYK do cyfrowego RGB
                $srgbProfile = file_get_contents(__DIR__ . '/profiles/sRGB.icc');
                $imagick->profileImage('icc', $srgbProfile);
                $imagick->transformImageColorspace(\Imagick::COLORSPACE_SRGB);
            } elseif ($colorspace !== \Imagick::COLORSPACE_SRGB) {
                $imagick->transformImageColorspace(\Imagick::COLORSPACE_SRGB);
            }

            $imagick->writeImage($imagePath);
            $imagick->clear();
        } catch (\Throwable $e) {
            error_log('[Color Governance] Blad normalizacji profilu kolorow: ' . $e->getMessage());
        }
    }
}

#Checklista techniczna dla audytu zdjęć pod kątem Google Lens i AI

Przed wdrożeniem strategii wizualnego SEO w WordPressie i WooCommerce należy przeprowadzić szczegółowy audyt techniczny infrastruktury:

1. Weryfikacja formatu AVIF: Sprawdź, czy serwer prawidłowo generuje pliki AVIF z poprawnym nagłówkiem HTTP Content-Type: image/avif.
2. Poprawność znaczników picture: Upewnij się, że kod HTML zawiera odpowiednie źródła alternatywne z atrybutami srcset oraz poprawnym formatem zapasowym JPEG/WebP.
3. Priorytetyzacja LCP: Zweryfikuj w narzędziu PageSpeed Insights, czy główne zdjęcie katalogowe ładuje się z parametrami fetchpriority="high" i nie podlega opóźnionemu ładowaniu (brak atrybutu loading="lazy" na pierwszym widocznym ekranie).
4. Kontrola schematów JSON-LD: Sprawdź w teście wyników z elementami rozszerzonymi, czy obiekt Product ma image, a węzły ImageObject z danymi licencji zawierają contentUrl.
5. Przegląd metadanych IPTC: Upewnij się, że procesy optymalizacyjne nie usuwają informacji o prawach autorskich i identyfikatorach handlowych.
6. Obrazy w feedzie Merchant Center: Potwierdź, że adresy w image_link kierują do plików JPEG, WebP lub PNG o rozmiarze około 1500 x 1500 pikseli, a przed wymogiem z 31 stycznia 2027 co najmniej 500 x 500 pikseli.
7. Optyczna czytelność etykiet: Upewnij się, że teksty na tabliczkach znamionowych i opakowaniach są ostre i możliwe do odczytania przez algorytmy OCR.
8. Buforowanie na poziomie CDN: Skonfiguruj długie nagłówki pamięci podręcznej (Cache-Control: public, max-age=31536000, immutable) dla wszystkich zoptymalizowanych zasobów wizualnych.
9. Bezpieczeństwo magazynu mediów: Zablokuj bezpośredni dostęp do katalogów systemowych i wyłącz wykonywanie skryptów PHP w katalogu /wp-content/uploads/.

Wyszukiwanie wizualne nagradza tę samą pracę u podstaw co SEO obrazów: indeksowalne pliki w obsługiwanych formatach, czytelne znaczniki i czysty feed. W celu omówienia modernizacji Twojego sklepu internetowego zapraszamy do kontaktu z naszym zespołem.