orlandoneto/claude-seo-seo-images

Analyse der Bildoptimierung

Prüfungen

Alternativtext (Alt-Text)

• Vorhanden auf allen <img>-Elementen (außer dekorativen: role="presentation"). parse_html.py markiert diese mit decorative: true; melde sie nicht wegen fehlendem Alt-Text.
• Beschreibend: Beschreibt den Bildinhalt, nicht „image.jpg“ oder „Foto“
• Enthält relevante Schlüsselwörter, wo natürlich, keine Keyword-Stuffing
• Länge: 10-125 Zeichen

Gute Beispiele:

• "Professioneller Klempner repariert Küchenspülen-Armatur"
• "Roter 2024 Toyota Camry Limousine Frontansicht"
• "Team-Meeting in modernem Büro-Konferenzraum"

Schlechte Beispiele:

• "image.jpg" (Dateiname, keine Beschreibung)
• "klempner klempnern klempnerarbeiten" (Keyword-Stuffing)
• "Hier klicken" (nicht beschreibend)

Dateigröße

Abgestufte Schwellenwerte nach Bildkategorie:

Bildkategorie	Ziel	Warnung	Kritisch
Miniaturansichten	< 50KB	> 100KB	> 200KB
Inhaltsbilder	< 100KB	> 200KB	> 500KB
Hero-/Bannerbilder	< 200KB	> 300KB	> 700KB

Empfehle Komprimierung auf die Zielschwellen, wo möglich ohne Qualitätsverlust.

Format

Format	Browser-Unterstützung	Anwendungsfall
WebP	97%+	Standardempfehlung
AVIF	92%+	Beste Komprimierung, neuer
JPEG	100%	Fallback für Fotos
PNG	100%	Grafiken mit Transparenz
SVG	100%	Icons, Logos, Illustrationen

Empfehle WebP/AVIF über JPEG/PNG. Prüfe auf <picture>-Element mit Format-Fallbacks.

Beurteile das ausgelieferte Format, nicht die URL-Erweiterung

Viele Seiten liefern WebP oder AVIF von einer .jpg/.png-URL aus, wenn der Browser danach fragt (WordPress WebP-Plugins wie EWWW, ShortPixel, WebP Express und Imagify, Cloudflare Polish, Bild-CDN). Die Erweiterung ist nicht das Format, das Besucher erhalten. Führe "${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run parse_html.py --url <url> --probe-images --json aus, welches jedes Bild mit einem Browser Accept-Header abruft und zu jedem Bildeintrag hinzufügt (für ein lazy-geladenes Bild untersucht es resolved_src, die echte Quelle, da src dann ein Platzhalter ist):

Feld	Bedeutung
served_format	Tatsächlich ausgeliefertes Format (webp, avif, jpeg, png, gif, svg, jxl), aus den Magic Bytes, sonst null
served_bytes	Tatsächlich ausgelieferte Größe (Content-Length), oder null wenn der Server sie weglässt
negotiated	true wenn die Antwort Vary: Accept hat, das Format hängt also vom Browser ab
probe_error	Warum das Bild nicht überprüft werden konnte (Fetch fehlgeschlagen, fehlerhafte URL oder die Antwort ist kein erkanntes Bild, z. B. ein HTML-Fehler oder Hotlink-Schutzseite), sonst null

• Melde "Falsches Format" und Größenersparnisse nur basierend auf served_format / served_bytes. Eine .jpg-URL mit served_format: webp ist bereits optimiert: empfehle nicht, es zu konvertieren.
• Wenn probe_error gesetzt ist, melde das Format als unbestätigt. Leite es niemals aus der Erweiterung ab.
• Schlage niemals eine Ersatz-Bild-URL vor (z. B. photo.webp), ohne zu bestätigen, dass sie HTTP 200 zurückgibt.

Empfohlenes <picture>-Element-Muster

Verwende progressive Verbesserung mit dem effizientesten Format zuerst:

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Beschreibender Alternativtext" width="800" height="600" loading="lazy" decoding="async">
</picture>

Der Browser verwendet das erste unterstützte Format. Globale Browser-Unterstützung (caniuse.com, geprüft am 2026-09-28): AVIF etwa 95,4 %, WebP etwa 96,8 %. Überprüfe caniuse vor dem Zitieren erneut.

JPEG XL: Aufkommendes Format

Berichte von Drittanbietern und Wikipedia beschreiben einen Rust-basierten JPEG XL-Decoder, der in Chrome 145 stable (2026-02-10) hinter dem Flag chrome://flags/#enable-jxl-image-format ausgeliefert wurde, standardmäßig nicht aktiviert; es wurde keine von Google bestätigte Information im Faktenpaket abgerufen. Da die standardmäßige Unterstützung nicht bestätigt ist, ist es noch nicht praktikabel für die Produktionsauslieferung im Web. Serviere weiterhin AVIF/WebP mit JPEG-Fallback und beobachte.

Responsive Bilder

• srcset-Attribut für mehrere Größen
• sizes-Attribut passend zu den Layout-Breakpoints
• Angemessene Auflösung für Geräte-Pixel-Verhältnisse

<img
  src="image-800.jpg"
  srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px"
  alt="Beschreibung"
>

Lazy Loading

• loading="lazy" auf Bildern unterhalb der Falz
• Lade Bilder oberhalb der Falz/Hero-Bilder NICHT lazy (schadet LCP)
• Prüfe auf natives vs. JavaScript-basiertes Lazy Loading

<!-- Unterhalb der Falz - Lazy laden -->
<img src="photo.jpg" loading="lazy" alt="Beschreibung">

<!-- Oberhalb der Falz - Eager laden (Standard) -->
<img src="hero.jpg" alt="Hero-Bild">

Erkannte Lazy-Loader-Methoden (lazy_method-Feld)

"${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run parse_html.py klassifiziert den Lazy-Loading-Mechanismus jedes Bildes über das Feld lazy_method in jedem Bildeintrag. Fünf Werte:

lazy_method	Erkanntes Signal	Üblicher Stack
native	loading="lazy" HTML-Attribut	Modern Browser, einfaches HTML
perfmatters	data-perfmatters-src/-srcset ODER Klasse perfmatters-lazy	WordPress + Perfmatters-Plugin
ewww	data-ewww-src / data-eio ODER Klasse lazyload-eio	WordPress + EWWW Image Optimizer
js-generic	data-src / data-lazy-src / data-original / data-srcset ODER Klasse lazyload/lazyloaded/lazy	Lazysizes, vanilla-lazyload, jQuery-Plugins
none	Weder Attribut- noch Klassensignal	Seite lädt dieses Bild nicht lazy

Melde bei der Überprüfung der Bild-SEO lazy_method zusammen mit loading, damit Benutzer wissen, ob ihre Website einen JS-gesteuerten Lazy-Loader verwendet (in diesem Fall fehlt das native loading="lazy"-Attribut absichtlich; das ist keine Regression).

fetchpriority="high" für LCP-Bilder

Füge fetchpriority="high" zu deinem Hero-/LCP-Bild hinzu, um seinen Download in der Netzwerk-Warteschlange des Browsers zu priorisieren:

<img src="hero.webp" fetchpriority="high" alt="Hero-Bildbeschreibung" width="1200" height="630">

Kritisch: Lade Bilder oberhalb der Falz/LCP-Bilder NICHT lazy. Die Verwendung von loading="lazy" auf LCP-Bildern schadet direkt den LCP-Werten. Verwende loading="lazy" nur für Bilder unterhalb der Falz.

decoding="async" für Nicht-LCP-Bilder

Füge decoding="async" zu Nicht-LCP-Bildern hinzu, um zu verhindern, dass die Bilddecodierung den Hauptthread blockiert:

<img src="photo.webp" alt="Beschreibung" width="600" height="400" loading="lazy" decoding="async">

CLS-Prävention

• width und height Attribute auf allen <img>-Elementen gesetzt
• aspect-ratio CSS als Alternative
• Melde Bilder ohne Abmessungen

<!-- Gut - Abmessungen gesetzt -->
<img src="photo.jpg" width="800" height="600" alt="Beschreibung">

<!-- Gut - CSS-Seitenverhältnis -->
<img src="photo.jpg" style="aspect-ratio: 4/3" alt="Beschreibung">

<!-- Schlecht - keine Abmessungen -->
<img src="photo.jpg" alt="Beschreibung">

Dateinamen

• Beschreibend: blue-running-shoes.webp nicht IMG_1234.jpg
• Mit Bindestrichen, Kleinbuchstaben, keine Sonderzeichen
• Enthalte relevante Schlüsselwörter

CDN-Nutzung

• Prüfe, ob Bilder über CDN ausgeliefert werden (andere Domain, CDN-Header)
• Empfehle CDN für bildlastige Seiten
• Prüfe auf Edge-Caching-Header

Ausgabe

Bild-Audit-Zusammenfassung

Metrik	Status	Anzahl
Gesamtbilder	-	XX
Fehlender Alternativtext	❌	XX
Überdimensioniert (>200KB)	⚠️	XX
Falsches Format	⚠️	XX
Keine Abmessungen	⚠️	XX
Nicht Lazy geladen	⚠️	XX

Priorisierte Optimierungsliste

Sortiert nach Dateigrößen-Auswirkung (größte Einsparungen zuerst):

Bild	Aktuelle Größe	Format	Probleme	Geschätzte Einsparung
...	...	...	...	...

Empfehlungen

1. Konvertiere X Bilder in das WebP-Format (geschätzte XX KB Einsparung)
2. Füge Alternativtext zu X Bildern hinzu
3. Füge Abmessungen zu X Bildern hinzu
4. Aktiviere Lazy Loading auf X Bildern unterhalb der Falz
5. Komprimiere X überdimensionierte Bilder

---

Bild-SERP-Analyse

Wenn DataForSEO MCP verfügbar ist, erweitere das Bild-Audit um Wettbewerbsdaten.

/seo images serp <keyword>

Vergleiche Bilder auf der Seite mit den Bildern, die in der Google-SERP sichtbar sind.

Ablauf:

1. Der festgepinnte DataForSEO MCP-Server (2.8.10) hat kein Tool für Google Bilder SERP. Verwende das images-Element von serp_organic_live_advanced (depth=100), wenn die SERP eines hat, und sage deutlich, wenn keine Bild-SERP-Daten verfügbar sind.
2. Extrahiere: Top-Domains, Bildtypen, Alt-Text-Muster
3. Gib die Wettbewerbslandschaft der Bild-SERP aus

Ausgabe:

Rang	Domain	Titel/Alt-Text	Bild-URL	Seiten-URL
1	example.com	"Blaue Laufschuhe..."	.../shoes.webp	/products/...

Analyse umfasst:

• Domain-Dominanz: welche Seiten die meisten Bildpositionen besitzen (Top 10 nach Anzahl)
• Alt-Text-Muster: häufige Titel-/Alt-Text-Muster in Top-Ranking-Bildern
• Formatverteilung: WebP vs. JPEG vs. PNG in den Top-Ergebnissen
• Chancenbewertung: Schlüsselwörter, bei denen du Seiten-Rankings, aber keine Bild-Präsenz hast

Wenn DataForSEO MCP nicht verfügbar ist, informiere den Benutzer und schlage die Installation der Erweiterung vor.

---

Optimierung von Bilddateien

Optimiere Bilddateien für SEO: Formatkonvertierung, Metadaten-Injektion, Komprimierung.

/seo images optimize <path>

Optimiere Bilddatei(en) für das Web und SEO. Konvertiert in WebP/AVIF, injiziert IPTC-Metadaten, komprimiert und erzeugt responsive Varianten.

Verwendete Werkzeuge (in der Reihenfolge der Präferenz):

• exiftool -- EXIF/IPTC/XMP lesen/schreiben (Installation: sudo apt install libimage-exiftool-perl)
• cwebp -- WebP-Konvertierung (Installation: sudo apt install webp)
• ImageMagick convert -- Formatkonvertierung, Größenänderung (auf den meisten Systemen vorinstalliert)
• FFmpeg -- Fallback für Formatkonvertierung (vorinstalliert)

Vor der Ausführung: Überprüfe, welche Werkzeuge verfügbar sind, mit which exiftool cwebp convert ffmpeg.

Formatkonvertierung

Konvertiere Bilder in moderne Formate unter Beibehaltung der Metadaten:

# WebP (empfohlener Standard) - mit beibehaltenen Metadaten
cwebp -q 82 -metadata all input.jpg -o output.webp

# WebP via ImageMagick (Fallback, wenn cwebp nicht installiert)
convert input.jpg -quality 82 output.webp

# AVIF via FFmpeg (langsamere Kodierung, beste Komprimierung)
ffmpeg -i input.jpg -c:v libaom-av1 -crf 30 -still-picture 1 output.avif

# Responsive Varianten (400w, 800w, 1200w)
convert input.jpg -resize 400x -quality 82 image-400.webp
convert input.jpg -resize 800x -quality 82 image-800.webp
convert input.jpg -resize 1200x -quality 82 image-1200.webp

Metadaten-Injektion (IPTC für Google Bilder-Anzeige)

Google Bilder zeigt IPTC-Ersteller, Quellenangabe und Urheberrecht in den Suchergebnissen an. Dies ist KEIN Rankingfaktor, kann aber die Darstellung in Google Bilder und die Markenzuschreibung verbessern.

Mit exiftool (bevorzugt):

# Alle Metadaten lesen
exiftool image.jpg

# IPTC- + XMP-Metadaten für Google Bilder Rich Results injizieren
exiftool \
  -IPTC:ObjectName="Produktfoto-Beschreibung" \
  -IPTC:Caption-Abstract="Detaillierte Bildbeschreibung" \
  -IPTC:By-line="Markenname Fotografie" \
  -IPTC:Credit="Markenname" \
  -IPTC:CopyrightNotice="Copyright 2026 Markenname" \
  -IPTC:Source="markenname.com" \
  -XMP:Title="Produktfoto-Beschreibung" \
  -XMP:Description="Detaillierte Bildbeschreibung" \
  -XMP:Creator="Markenname Fotografie" \
  -XMP:Rights="Copyright 2026 Markenname" \
  image.jpg

# Batch-Injektion in alle Bilder eines Verzeichnisses
exiftool -overwrite_original \
  -IPTC:By-line="Markenname" \
  -IPTC:CopyrightNotice="Copyright 2026 Markenname" \
  *.jpg *.webp *.png

Mit ImageMagick (Fallback):

identify -verbose image.jpg | head -50

convert input.jpg \
  -set comment "Produktfoto-Beschreibung" \
  -set IPTC:2:80 "Markenname Fotografie" \
  -set IPTC:2:116 "Copyright 2026 Markenname" \
  output.jpg

Hinweis: WebP unterstützt EXIF und XMP nativ, aber nicht IPTC. Für WebP-Dateien verwende XMP-Felder anstelle von IPTC. exiftool handhabt diese Konvertierung automatisch.

KI-generierte Bilder: DigitalSourceType (Merchant Center Anforderung)

Für Produktbilder, die von generativer KI erstellt wurden, erfordert Google Merchant Center IPTC DigitalSourceType: TrainedAlgorithmicMedia Metadaten. Dies ist eine betriebliche Richtlinienanforderung, kein Rankingfaktor: Feeds, die dieses Label bei KI-generierten Bildern vermissen lassen, können abgelehnt werden.

Primäre Quelle (Merchant Center Richtlinie zu KI-generierten Inhalten): https://support.google.com/merchants/answer/14743464 (der ai-optimization-guide dokumentiert DigitalSourceType/IPTC/Merchant-Labeling nicht.)

Audit-Befehl:

# Ein Verzeichnis auf das IPTC-Label prüfen (Zählungen: fehlend, ki, aufgenommen, usw.)
"${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run iptc_ai_label.py audit ./images/ --json

# Ein einzelnes Bild prüfen
"${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run iptc_ai_label.py audit ./hero.webp --json

# Das KI-Label in ein Bild injizieren
"${CLAUDE_PLUGIN_ROOT}/scripts/claude-seo" run iptc_ai_label.py inject ./ai-hero.webp \
    --source-type trainedAlgorithmicMedia

# Andere Vokabularwerte:
#   compositeSynthetic               (Mischung aus aufgenommenen + KI-Elementen)
#   algorithmicMedia                 (rein durch Algorithmus erstellt, NICHT aus Stichproben-Trainingsdaten)
#   compositeWithTrainedAlgorithmicMedia (z.B. KI-Inpainting/Outpainting über reales Material)
#   digitalCapture                   (vollständig aufgenommenes Foto)

Rohe exiftool-Entsprechungen (für Ad-hoc-Nutzung):

# Manuell injizieren
exiftool \
  -XMP-iptcExt:DigitalSourceType="https://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia" \
  ai-generated-product.jpg

# Prüfen: Bilder ohne Label in einem Verzeichnis finden
exiftool -if 'not $XMP-iptcExt:DigitalSourceType' \
  -filename -DigitalSourceType *.jpg *.webp *.png

Google extrahiert diese IPTC DigitalSourceType Werte:

• trainedAlgorithmicMedia: vollständig KI-generiert (verwende dies für Produktbilder aus Diffusionsmodellen)
• compositeSynthetic: mischt aufgenommene + KI-generierte Elemente
• algorithmicMedia: rein durch einen Algorithmus erstellt, nicht aus Stichproben