Google Lens und multimodale KI-Suche: Bilder in WordPress und WooCommerce optimieren

Die Art und Weise, wie Nutzer im Internet nach Produkten suchen, verändert sich grundlegend von reinen Textanfragen hin zu multimodalen Erlebnissen. Smartphone-Nutzer richten ihre Kamera immer häufiger direkt auf technische Bauteile, Ersatzteile oder Konsumgüter, um über Google Lens, ChatGPT Vision oder Bing Visual Search sofort das passende Produkt zu finden, Preise zu vergleichen und Händler ausfindig zu machen. Gleichzeitig greifen autonome KI-Systeme auf die Bildbestände von Onlineshops zu, um technische Spezifikationen, Maße und Zertifikate unmittelbar aus den Bildpixeln auszulesen.

Für Entwickler und Shopbetreiber im WordPress- und WooCommerce-Ökosystem bedeutet dies, dass Bildmedien nicht länger als bloßes Beiwerk betrachtet werden dürfen. Veraltete Abläufe, die auf unkomprimierten JPEG-Dateien und einfachen alt-Attributen basieren, reichen nicht mehr aus, um in modernen visuellen Einkaufsumgebungen sichtbar zu bleiben.

#Die wachsende Bedeutung visueller Suchsysteme und multimodaler Modelle

Mit dem Aufkommen moderner multimodaler Sprach- und Bildmodelle wie Google Gemini und GPT-4o hat sich die Funktionsweise automatisierter Suchmaschinen-Crawler tiefgreifend gewandelt. Früher stützten sich Crawler fast ausschließlich auf den Text um das Bild herum, den Dateinamen und rudimentäre Meta-Tags. Heute analysieren Bildsuchmaschinen die Pixelstrukturen in Echtzeit:

• Visuelle Merkmalseinbettungen (Visual Embeddings): Bildmodelle übersetzen Formen, Proportionen und Oberflächenstrukturen in hochdimensionale Vektoren und vergleichen diese mit Milliarden registrierter Produktdaten.
• Integrierte Zeichenerkennung (OCR): Texte auf Typenschildern, Warnhinweisen, Verpackungen oder technischen Zeichnungen werden automatisch extrahiert und als verlässlicher Suchkontext indiziert.
• Abgleich von Bild und Text: Googles Richtlinien für Händlereinträge verlangen, dass Bilder den ausgezeichneten Inhalt darstellen. Ein Foto, das den Produktdaten widerspricht, ist damit ein Richtlinienproblem und nicht nur ein Zuordnungsproblem.

Verfügt ein WooCommerce-Katalog über unvollständige oder unscharfe Fotografien, können KI-Agenten die Produkte kaum mit den visuellen Anfragen mobiler Nutzer abgleichen.

#Was Google Lens mit einem Produktfoto macht

Google beschreibt Lens als Möglichkeit, mit der Kamera, einem Bild oder einem Screenshot zu suchen, wenn sich etwas schwer in Worte fassen lässt (Google Lens). Beim Einkaufen ermittelt Lens laut derselben Seite, wer einen Artikel herstellt, was er kostet und wo man ihn kaufen kann; die Seite nennt rund 35 Länder, in denen diese Shopping-Ergebnisse verfügbar sind. Lens übersetzt außerdem Text aus der Kamera in über 100 Sprachen, also dieselbe Texterkennung, die Etiketten und Typenschilder auf Produktfotos erfasst.

Im Oktober 2024 meldete Google, dass Lens fast 20 Milliarden visuelle Suchen pro Monat verarbeitet, und stellte eine Produktergebnisseite mit Bewertungen, Preisen mehrerer Händler und Bezugsquellen vor (Google, 3. Oktober 2024). Laut dem Beitrag erkennt Lens den fotografierten Artikel mit KI-Modellen und dem Shopping Graph, der mehr als 45 Milliarden Produkte umfasst. Eine eigene Lens-Einreichung für Shops gibt es nicht: Ein Produkt erreicht diese Ergebnisseite über die Daten, die Google bereits darüber hat, also den Merchant-Center-Feed und die Produktseite selbst. Google veröffentlicht keinen Lens-Leitfaden für Website-Betreiber, deshalb sind die praktischen Hebel die dokumentierten: die Google-Bilder-Richtlinien, strukturierte Produktdaten und die Bildanforderungen des Merchant Center, die weiter unten folgen.

#Wie Google ein Bild auf einer WordPress-Seite liest

Der Google-Leitfaden zur Bild-SEO zählt die Signale auf, die Google der Seite entnimmt (Google Search Central, Best Practices für Bilder). Unterstützte Formate sind BMP, GIF, JPEG, PNG, WebP, SVG und AVIF, und die Dateiendung sollte zum Dateityp passen. Der Alt-Text gilt als wichtigstes Attribut für Bildmetadaten, Keyword-Stuffing wird ausdrücklich abgeraten. Googles eigenes Beispiel geht von fehlendem Alt-Text über alt="puppy" zu alt="Dalmatian puppy playing fetch". Dateinamen sollen kurz und beschreibend sein, my-new-black-kitten.jpg ist also besser als IMG00023.JPG. Eine Umbenennungsregel im Upload-Prozess lohnt sich, weil Dateien von Kameras und Lieferanten selten mit brauchbaren Namen ankommen.

Der Kontext zählt so viel wie die Datei. Google entnimmt Informationen über das Motiv eines Bildes dem Seiteninhalt, einschließlich Bildunterschriften und Bildtiteln, und empfiehlt, Bilder in der Nähe von relevantem Text zu platzieren. Per CSS eingebundene Bilder werden nicht indexiert, was Produktfotos ausschließt, die Page-Builder oder Slider-Plugins als background-image einsetzen. Bei responsivem Markup empfiehlt Google, immer eine Fallback-URL im src-Attribut neben srcset oder <picture> zu behalten; WordPress ergänzt Inhaltsbilder bereits um srcset und sizes, ohne src zu entfernen (wp_image_add_srcset_and_sizes). Bild-Sitemaps dürfen <image:loc>-URLs auf anderen Domains enthalten, was wichtig ist, wenn die Mediathek über einen CDN-Hostnamen ausgeliefert wird. Um festzulegen, welches Bild eine Seite repräsentiert, verweist der Leitfaden auf primaryImageOfPage, mainEntityOfPage oder das Meta-Tag og:image.

#Moderne Bildverarbeitungsarchitektur in WordPress: libvips und AVIF

Jahrzehntelang verließ sich WordPress standardmäßig auf die PHP-Bibliothek GD (Graphics Draw) zur Generierung verschiedener Bildgrößen. Bei umfangreichen WooCommerce-Katalogen mit zehntausenden Artikeln verursacht GD jedoch einen immensen Speicherverbrauch und lange Verarbeitungszeiten, weshalb viele Händler bisher bei veralteten JPEG- oder PNG-Dateien blieben.

Ein zeitgemäßer technischer Stack kann auf die Bibliothek libvips setzen (über das Binding php-vips oder externe Worker mit Sharp). Das Projekt beschreibt libvips als bedarfsgesteuerte, horizontal parallelisierte Bibliothek, die im Vergleich zu ähnlichen Bibliotheken schnell arbeitet und wenig Speicher braucht (libvips). Das macht die Massenkonvertierung eines großen Katalogs nach AVIF praktikabel:

<?php
/**
 * Performante Bildkonvertierung in das AVIF-Format mit libvips in WordPress
 */
declare(strict_types=1);

namespace WPPoland\MediaArchitectureDE;

use Jcupitt\Vips\Image;
use WP_Error;

class ModernImageProcessor
{
    private const QUALITY_AVIF = 68; // Optimaler Kompromiss aus Dateigroesse und visueller Schaerfe

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

        try {
            // Sequentielles Laden der Bildpixel ohne volle Allokation im RAM
            $image = Image::newFromFile($sourcePath, ['access' => 'sequential']);

            // Speichern als AVIF unter Beibehaltung der IPTC-Metadaten
            $image->writeToFile($destinationPath, [
                'Q'           => self::QUALITY_AVIF,
                'compression' => 'av1',
                'strip'       => false, // IPTC-Urheber- und Produktangaben beibehalten
            ]);

            return true;
        } catch (\Throwable $e) {
            error_log(sprintf('AVIF-Generierung fehlgeschlagen fuer %s: %s', $sourcePath, $e->getMessage()));
            return false;
        }
    }
}

AVIF erzeugt bei vergleichbarer Bildqualität meist kleinere Dateien als JPEG und hält Kanten und gedruckten Text bei moderater Kompression sauber. Messen Sie die Ersparnis am eigenen Katalog, bevor Sie sich festlegen: Freisteller auf Weiß komprimieren ganz anders als Lifestyle-Fotos, und Etiketten, die lesbar bleiben müssen, brauchen eine höhere Qualitätsstufe als ein glatter Hintergrund.

#Wie WordPress 6.5 AVIF-Uploads verarbeitet

Die AVIF-Unterstützung kam mit Version 6.5 in den WordPress-Kern und hängt von der Bildbibliothek des Servers ab: Imagick oder GD müssen das Format unterstützen (Ankündigung im WordPress-Core-Blog). Die Ankündigung erklärt, wie man im WordPress-Dashboard prüft, ob der Server AVIF unter den unterstützten Formaten führt. Ist das der Fall, lassen sich AVIF-Dateien hochladen und erzeugen Zwischengrößen wie ein JPEG oder PNG. Andere Formate umzuwandeln ist optional und läuft über den Filter image_editor_output_format; das Beispiel der Ankündigung ordnet image/jpeg dem Ziel image/avif zu.

Eine Grenze gehört in jeden AVIF-Plan eines Shops. Das Bildattribut im Merchant Center akzeptiert JPEG, WebP, PNG, GIF, BMP und TIFF (Merchant Center, Bildlink), AVIF steht nicht auf der Liste. Ein Shop, der jeden Upload in AVIF umwandelt und die Originale löscht, hat für den Feed keine Datei mehr. Behalten Sie für jedes Produktbild ein JPEG- oder WebP-Original oder erzeugen Sie eines für den Feed, und liefern Sie AVIF über <picture> an Browser aus.

Wie sich Bildarchive performant mit externen Warenwirtschaftssystemen synchronisieren lassen, erfahren Sie in unserer Analyse zur woocommerce erp integration.

#Semantische Bildauszeichnung nach Schema.org mit ImageObject

Damit Suchmaschinen-Bots Bilder eindeutig einem bestimmten Produkt zuordnen können, müssen die HTML-Dokumente strukturierte Daten im JSON-LD-Format bereitstellen. Anstelle einer einfachen Liste von Bild-URLs innerhalb des Product-Schemas empfiehlt sich die detaillierte Definition über ImageObject:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Product",
      "@id": "https://industrie-shop.de/produkte/kugelhahn-edelstahl-dn50/#product",
      "name": "Edelstahl-Kugelhahn DN50 PN40",
      "sku": "VALV-SS-DN50",
      "image": [
        {
          "@type": "ImageObject",
          "@id": "https://industrie-shop.de/media/kugelhahn-dn50-hauptansicht.avif",
          "contentUrl": "https://industrie-shop.de/media/kugelhahn-dn50-hauptansicht.avif",
          "url": "https://industrie-shop.de/media/kugelhahn-dn50-hauptansicht.avif",
          "width": "2400",
          "height": "2400",
          "encodingFormat": "image/avif",
          "caption": "Industrieller Edelstahl-Kugelhahn DN50 in Seitenansicht mit Handhebel",
          "representativeOfPage": true,
          "creditText": "WPPoland Prueflabor",
          "copyrightNotice": "Alle Rechte vorbehalten 2026",
          "license": "https://industrie-shop.de/bildrechte"
        },
        {
          "@type": "ImageObject",
          "@id": "https://industrie-shop.de/media/kugelhahn-dn50-typenschild.avif",
          "contentUrl": "https://industrie-shop.de/media/kugelhahn-dn50-typenschild.avif",
          "url": "https://industrie-shop.de/media/kugelhahn-dn50-typenschild.avif",
          "width": "2000",
          "height": "1500",
          "encodingFormat": "image/avif",
          "caption": "Detailaufnahme des Typenschilds mit Seriennummer und Druckstufen nach PN40",
          "representativeOfPage": false
        }
      ]
    }
  ]
}

representativeOfPage ist eine schema.org-Eigenschaft, die das Hauptbild des Produkts markiert. Googles Bildleitfaden nennt primaryImageOfPage, mainEntityOfPage und og:image als Wege, ein bevorzugtes Bild anzugeben, und für Händlereinträge verlangt Google image und empfiehlt mehrere hochauflösende Dateien (mindestens 50.000 Pixel, Breite mal Höhe) in den Seitenverhältnissen 16x9, 4x3 und 1x1 (Google Search Central, Händlereinträge). Google dokumentiert nicht, dass Lens einer dieser Eigenschaften mehr Gewicht gibt; sie dienen der eindeutigen Kennzeichnung. Eine Nahaufnahme des Typenschilds mit passender Bildunterschrift liefert Lesern und Texterkennung die Spezifikation als Klartext direkt neben dem Bild.

Um sicherzustellen, dass Upload-Pfade und Schnittstellen gegen Angriffe abgeschirmt sind, empfiehlt sich ein regelmäßiges WordPress-Sicherheitsaudit.

#Responsive picture-Elemente und Optimierung von Core Web Vitals LCP

Die zentrale technische Herausforderung im E-Commerce besteht darin, hochauflösende Detailaufnahmen bereitzustellen, ohne die strengen Vorgaben der Google Core Web Vitals zu verletzen (Largest Contentful Paint unter 2,5 Sekunden).

Eine belastbare Frontend-Implementierung nutzt das semantische <picture>-Element mit Formatverhandlung und maßgeschneiderten srcset- sowie sizes-Angaben:

<!-- Performantes responsives Bild-Markup fuer das Hauptproduktbild -->
<picture class="woocommerce-product-hero-picture">
  <!-- Modernes AVIF-Format mit maximaler Kompression -->
  <source
    type="image/avif"
    srcset="/media/kugelhahn-dn50-600.avif 600w,
            /media/kugelhahn-dn50-1200.avif 1200w,
            /media/kugelhahn-dn50-2400.avif 2400w"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px"
  />
  <!-- WebP-Fallback fuer aeltere Browser -->
  <source
    type="image/webp"
    srcset="/media/kugelhahn-dn50-600.webp 600w,
            /media/kugelhahn-dn50-1200.webp 1200w,
            /media/kugelhahn-dn50-2400.webp 2400w"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px"
  />
  <!-- Standard-JPEG als letzte Rueckfallebene -->
  <img
    src="/media/kugelhahn-dn50-1200.jpg"
    alt="Edelstahl-Kugelhahn DN50 in technischer Seitenansicht"
    width="1200"
    height="1200"
    loading="eager"
    fetchpriority="high"
    decoding="async"
    class="object-cover w-full h-auto"
  />
</picture>

Wichtige technische Grundregeln:

1. fetchpriority="high" und loading="eager" auf dem Hauptbild: Dadurch lädt der Browser das kritische Bildelement bevorzugt herunter, bevor blockierende Skripte ausgeführt werden.
2. Vorabladen im <head>-Bereich: Ein Link-Header <link rel="preload" as="image" type="image/avif" href="..." imagesrcset="..." imagesizes="..."> lässt den Browser das Hauptbild anfordern, bevor er die Stylesheets verarbeitet hat.
3. Feste Angaben von width und height: Sie verhindern störende Layoutverschiebungen (Cumulative Layout Shift, CLS) beim asynchronen Laden.

#IPTC-Metadaten vs datenschutzgerechte Bereinigung

Zahlreiche Bild-Plugins in WordPress entfernen sämtliche Datei-Header pauschal, um einige wenige Kilobytes einzusparen. Damit verschwinden Urheber- und Copyright-Felder zusammen mit den privaten Daten.

Es gilt, gezielt zwischen verschiedenen Metadatentypen zu unterscheiden:

• Zu entfernende Daten (Datenschutz und Sicherheit): Exakte GPS-Standortkoordinaten, Seriennummern von Kameras sowie Software-Fingerabdrücke müssen beim Upload gelöscht werden.
• Zu bewahrende Daten (Namensnennung und Urheberrecht): Standardisierte IPTC-Felder wie By-line (Fotograf), Copyright Notice (Rechteinhaber), Headline (Bildtitel) und Object Name (eindeutige Modellnummer oder SKU).

Google Bilder kann Urheber, Credit und Lizenzangaben aus diesen Feldern anzeigen, wie der nächste Abschnitt beschreibt. Google sagt nicht, dass IPTC-Daten das Ranking beeinflussen; der Grund, sie zu behalten, sind Namensnennung und Rechte.

#Welche Bildlizenzfelder Google Bilder ausliest

Google dokumentiert zwei Wege, Rechteinformationen an ein Bild zu binden: in die Datei eingebettete IPTC-Fotometadaten oder strukturierte Daten vom Typ ImageObject auf der Seite (Google Search Central, Metadaten zu Bildlizenzen). Aus der Datei liest Google Web Statement of Rights, Licensor URL, Creator, Credit Line und Copyright Notice. Web Statement of Rights ist Pflicht für das Lizenz-Badge in Google Bilder, die anderen vier Felder sind empfohlen.

In strukturierten Daten ist contentUrl Pflicht, weil Google darüber entscheidet, auf welches Bild sich die Metadaten beziehen. Daneben muss mindestens eine der Eigenschaften creator, creditText, copyrightNotice oder license vorhanden sein; sobald eine gesetzt ist, empfiehlt der Test für Rich-Suchergebnisse die übrigen drei. license ist für das Lizenz-Badge nötig, und acquireLicensePage verweist auf eine Seite, die erklärt, wie man das Bild lizenziert. Google fügt hinzu, dass es nicht garantiert, dass diese Metadaten in den Suchergebnissen erscheinen, und die Seite sagt nichts über Rankings. Füllen Sie diese Felder für eigene Produktfotografie als Maßnahme für Rechte und Namensnennung aus. In der älteren IIM-Kodierung ist Credit Line das Feld 2:110 und Copyright Notice das Feld 2:116.

#Was der WordPress-Kern beim Upload mit IPTC und EXIF macht

WordPress liest IPTC-Felder beim Hochladen eines Bildes selbst aus. wp_read_image_metadata() übernimmt den Credit aus IPTC Credit (2#110) mit Creator (2#080) als Ausweichwert, das Copyright aus 2#116, die Bildunterschrift aus Description (2#120), den Titel aus Headline (2#105) oder Title (2#005) und den Aufnahmezeitpunkt aus 2#055 und 2#060 (WordPress-Entwicklerreferenz). Seit Version 4.4 erhält der Filter wp_read_image_metadata das rohe IPTC-Array, seit 5.0 auch das EXIF-Array. Ein Plugin kann so ein zusätzliches Feld wie die Herstellerteilenummer übernehmen, ohne die Datei erneut zu parsen.

Was in den erzeugten Bildgrößen erhalten bleibt, hängt vom Bildeditor ab. Mit Imagick ruft thumbnail_image() die Methode strip_meta() auf, die alle Profile außer icc, icm, iptc, exif und xmp entfernt (WP_Image_Editor_Imagick::strip_meta). EXIF steht auf dieser geschützten Liste, deshalb können GPS-Koordinaten aus einem Smartphone-Foto in verkleinerten Kopien erhalten bleiben. Wenn Standortdaten verschwinden müssen, entfernen Sie sie vor dem Upload oder in einem eigenen Schritt und prüfen Sie eine erzeugte Zwischengröße mit exiftool, statt sich auf eine Plugin-Option zu verlassen.

#Bildanforderungen im Google Merchant Center für Google Shopping

Google Merchant Center übernimmt das Hauptbild aus image_link und bis zu 10 weitere Ansichten aus additional_image_link (Bildlink, zusätzlicher Bildlink). Die dokumentierten Anforderungen:

1. Größe: Google empfiehlt Bilder ab etwa 1500 x 1500 Pixel und hat ab dem 31. Januar 2027 ein Minimum von 500 x 500 Pixel für alle Produkte angekündigt. Dateien dürfen 16 MB und 64 Megapixel nicht überschreiten.
2. Formate: JPEG, WebP, PNG, GIF, BMP und TIFF, mit einer Dateiendung, die zum Format passt. AVIF steht nicht auf der Liste.
3. Bildaufbau: Das Produkt soll mindestens 75 % und höchstens 90 % des Bildes einnehmen, ohne Rahmen, Werbeelemente, Wasserzeichen oder eingeblendete Logos.
4. Generierte Bilder: Mit generativer KI erstellte Bilder müssen Metadaten tragen, die das kenntlich machen, und eingebettete Tags wie IPTC DigitalSourceType dürfen nicht entfernt werden.
5. Zugriff: Die robots.txt muss Googlebot und Googlebot-Image zulassen, und Bild-URLs sollten keine Parameter enthalten, die sich bei jeder Feed-Übermittlung ändern.

Zusätzliche Bildlinks sind der Platz für weitere Ansichten und Einsatzfotos, die die Größe des Produkts zeigen.

Werden hochauflösende Dateien über einen cache-optimierten CDN-Hostnamen ausgeliefert, landen Crawler-Anfragen auf große Kataloge nicht beim PHP-Ursprungsserver.

#Skalierbare Bildverarbeitung an Edge-Knoten und headless WordPress

Auf stark frequentierten E-Commerce-Plattformen führt die dynamische Bildskalierung auf dem WordPress-Ursprungsserver schnell zu hohen Lastspitzen. Ein verbreitetes Muster verlagert diese Aufgaben an globale CDN-Knotenpunkte mit Cloudflare Images, Fastly Image Optimization oder separaten Sharp-Clustern.

Vorteile entkoppelter Bildinfrastrukturen:

• Bildoptimierung in Echtzeit: Hochauflösende Master-Dateien liegen sicher im Objektspeicher (S3 oder R2), während Edge-Server AVIF-Varianten sekundenschnell passend zum Endgerät generieren.
• Entlastung des Webservers: Crawler-Anfragen nach Mediendateien beantwortet der Edge-Cache, statische Bilder starten keinen PHP-Prozess.
• Vorbehalt bei Metadaten: Die Option metadata von Cloudflare gilt nur für JPEG-Ausgaben. copyright (Standard) behält nur das EXIF-Copyright-Tag, keep bewahrt den Großteil der EXIF-Daten einschließlich GPS-Position, und bei allen anderen Ausgabeformaten, auch WebP und PNG, werden sämtliche Metadaten verworfen (Cloudflare Images). Eine am Edge erzeugte AVIF-Variante trägt keinen IPTC-Credit, die Lizenzangaben gehören deshalb auch in die strukturierten Daten der Seite.
• Optimale Anbindung an moderne Frontends: Entkoppelte Architekturen auf Basis von Astro oder Next.js liefern optimierte Markups mit extrem schnellen Ladezeiten aus.

Informieren Sie sich über unsere Erfahrung mit entkoppelten Systemen im Bereich headless wordpress.

#Automatisierte Bildqualitätskontrolle und Farbraummanagement

Ein häufig unterschätzter Faktor im E-Commerce ist das Farbprofil der hochgeladenen Bilddateien. Produktfotografen speichern Master-Dateien oft im erweiterten Adobe RGB- oder Display P3-Farbraum ab. Werden diese Bilder ohne vorherige Farbprofilkonvertierung komprimiert, wirken die Farben in Browsern ausgewaschen oder falsch gesättigt und passen nicht mehr zum realen Produkt.

Ein professioneller Bildverarbeitungsprozess erzwingt die Konvertierung aller Bildmedien in das standardisierte sRGB-Farbprofil und überprüft die Bildintegrität über automatisierte Tests:

<?php
/**
 * Automatisierter Integrationstest fuer sRGB-Farbprofil und Schaerfegrad
 */
declare(strict_types=1);

namespace WPPoland\Tests\MediaDE;

use PHPUnit\Framework\TestCase;
use Jcupitt\Vips\Image;

class ImageFidelityValidationTest extends TestCase
{
    public function testColorProfileConversionToSrgb(): void
    {
        $testImagePath = __DIR__ . '/fixtures/product-sample.avif';
        $image = Image::newFromFile($testImagePath);

        // Ueberprueft, ob das Bild im sRGB-Farbraum vorliegt
        $interpretation = $image->interpretation;
        $this->assertEquals('srgb', $interpretation, 'Alle fuer Google Shopping bereitgestellten Bilder muessen sRGB nutzen.');
    }

    public function testImageResolutionMinimumRequirements(): void
    {
        $testImagePath = __DIR__ . '/fixtures/product-sample.avif';
        $image = Image::newFromFile($testImagePath);

        // Google Lens verlangt fuer technische Produkte mindestens 1500 Pixel an der laengeren Kante
        $maxDimension = max($image->width, $image->height);
        $this->assertGreaterThanOrEqual(1500, $maxDimension, 'Die Bildaufloesung muss fuer OCR-Erkennung ausreichend hoch sein.');
    }
}

Durch diese automatisierte Qualitätskontrolle in der CI/CD-Pipeline wird verhindert, dass unscharfe oder farblich verfälschte Produktbilder in den Datenfeed für das Google Merchant Center gelangen.

#Technische Checkliste für Google Lens und Bild-SEO-Audits

Überprüfen Sie Ihre Bildarchitektur anhand folgender Prüfpunkte:

1. AVIF-MIME-Type: Sicherstellen, dass der Server AVIF-Dateien mit dem korrekten Header Content-Type: image/avif ausliefert.
2. Vollständige Fallbacks: Kontrollieren, ob das <picture>-Markup verlässliche WebP- oder JPEG-Alternativen für ältere Browser enthält.
3. LCP-Konfiguration: Prüfen, ob das wichtigste Katalogbild mit fetchpriority="high" ausgestattet ist und kein loading="lazy" oberhalb der Sichtlinie aufweist.
4. Schema.org-Validierung: Im Test für Rich-Suchergebnisse kontrollieren, dass Product ein image enthält und ImageObject-Knoten mit Lizenzangaben contentUrl tragen.
5. IPTC-Erhalt: Sicherstellen, dass Kompressionsskripte Urheber- und Lizenzdaten nicht aus den Bilddateien entfernen.
6. Feed-Bilder: Verifizieren, dass die im Feed verlinkten Bilder JPEG, WebP oder PNG sind, etwa 1500 x 1500 Pixel groß und vor der Anforderung vom 31. Januar 2027 mindestens 500 x 500 Pixel.
7. Lesbarkeit von Typenschildern: Kontrollieren, dass Typenbezeichnungen und Barcodes nach der Kompression scharf und maschinenlesbar bleiben.
8. Cache-Header: Lange Ablaufzeiten (Cache-Control: public, max-age=31536000, immutable) für alle statischen Bildressourcen hinterlegen.
9. Schutz des Upload-Verzeichnisses: Die Ausführung von PHP-Skripten im Ordner /wp-content/uploads/ serverweit blockieren.

Visuelle Suche belohnt dieselbe Grundarbeit wie Bild-SEO: crawlbare Dateien in unterstützten Formaten, klare Auszeichnung und ein sauberer Feed. Wenn Sie diese Arbeit für Ihren Shop planen möchten, kontaktieren Sie uns gern über unsere kontaktseite.