Responsive Image SEO Test

von  · 

Google liebt Performance und Responsive Design, aber wie geht Google mit <picture>, <source> und srcset um? Kann man Bilder mit den neuen Tags erfolgreich in die Google Bilder-Suche bringen? Findet der Google-Bot, Bilder die mit <picture>, <source>, srcset eingebunden werden überhaupt? Ich konnte darauf keine Antwort finden, also hab ich es selbst ausprobiert.

Hintergrund

Um Performance und Responsive Design zu verbinden, müssen wir Bilder in der optimalen Größe für das jeweilige Gerät des Users ausliefern. Mobile-User sollen kleine Bilder bekommen, die schnell laden, Desktop-User sollen große hochauflösende Desktop-Bilder bekommen, ohne dass vom Browser im Hintergrund alle Bilder geladen werden müssen.

Statt eines statischen Bildes brauchen wir heute eine "Bilderweiche", in der wir verschieden große Bilder zusammen mit Ausspielungs-Regeln festlegen können und der Browser holt sich dann - je nach Gerät des Users - das richtige Bild aus dem Stapel (und lädt die anderen Bilder nicht).

Aktuell gibt es zwei Lösungen für eine solche Bilderweiche:

<picture> mit <source>

<picture>
<source srcset="GROSSES-BILD.jpg" media="(min-width:1200px)">
<source srcset="MITTLERES-BILD.jpg " media="(min-width: 700px)">
<source srcset="KLEINES-BILD.jpg" media="(min-width: 400px)">
<img src="KLEINES-BILD" />
<picture>

<img> mit srcset

<img src="KLEINES-BILD.jpg"
srcset="KLEINES-BILD.jpg 400w,
MITTLERES-BILD.jpg 700w
GROSSES-BILD.jpg 1200w" />

Beide Lösungen sind eigentlich nur unterschiedliche "Schreibweisen" der selben Idee und funktionieren im Prinzip gleich: Es gibt weiterhin ein <img> Tag. Dort wird ein Default-Bild festgelegt, dass angezeigt wird, wenn ein Browser mit der Stapel-Lösung nicht umgehen kann. In srcset stehen die Device-optimierten Bilder zusammen mit den Regeln, wann der Browser sie ausspielen soll. Hier könnt Ihr mehr darüber lesen.

Browser-Support

Browser-Unterstützung ist noch nicht komplett, trotzdem ist genau jetzt die Zeit sich die Tags mal durch die SEO-Brille anzuschauen, denn mit dem Javascript-Polyfill "Picturefill" kann man <picture>, <source> srcset schon heute sicher einsetzen und mit ihnen die Performance spürbar verbessern.

Testaufbau

Ich habe Bilder, die Google noch nicht kannte, über die neuen Tags (und aus Neugier noch über eine Menge anderer Methoden) eingebunden und dann mit einer "site" und "inurl"-Search in der Bilder-Suche geprüft, ob Google sie überhaupt indexiert hat. Den Trigger "abrufen wie durch Google" habe ich dabei nicht verwendet.

Bilder waren für den Googlebot im Markup nur jeweils über eine einzige Stelle verfügbar (z.B. unter scr oder unter scrset). Wurde das Bild gefunden, konnte ich sicher sein, dass Googlebot die verwendete Art der Einbindung lesen kann und das Bild garantiert nicht irgendwo anders her hatte.

Diesen Test habe ich zweimal auf unterschiedlichen URLs, mit unterschiedlichen (und Google immer unbekannten) Bildern wiederholt.

Ergebnis

Art der Bild-Einbindnung und wann das Bild jeweils indexiert wurde:

Bewertung

Was passiert da (vielleicht)?

Google kommt (mindestens) zweimal vorbei. Erst schnell (ca. 1 Tag) dann noch mal langsam (ca. 1 Monat). Das deckt sich mit der Erklärung, dass auch der normale Google-Bot Bilder indexiert:

"[...] so we crawl the URL with Googlebot first. If we find the URL leads to an image, we’ll usually revisit with Googlebot-Image. [...]"

Im schnellen Durchgang nimmt Google alle Bilder aus <img src="">, <link href=""> und <a href=""> Tags mit. Diese Bilder waren in meinen Tests durchaus schon für verschiedene Keywords in der Bildersuche zu finden - also nicht nur über eine site/inurl-Search. Im langsamen Durchgang erweitert und korrigiert Google den schnellen Durchgang. Meine Annahme ist, dass Google hier stabil sichtbare Bilder (z.B. <img srcset="" mit Javascript-Polyfill "Picturefill") zusätzlich indexiert und gefundene Bilder, die nicht stabil sichtbar sind wieder entfernt.

Bilder, in Tags, die noch nicht die volle Browser-Unterstützung haben, wurden nur indexiert, wenn sie durch einen Javascript-Polyfill sicher und stabil für alle Browser sichtbar waren. Google muss, um das zu erkennen, das Javascript lesen oder ausführen - was wieder gut zu dem wiederholten Aufruf passt, Javascript-Dateien für den Googlebot nicht zu sperren.

Hatte Google von einem Bild, nach dem 2. Durchgang, mehrere Größen (z.B. kleines Bild im <img>, große Version im scrset), wurde die kleine Größe verworfen und nur noch die große Version indexiert.

<picture>, <source> srcset einsetzen oder nicht?

Man kann <picture>, <source> srcset sorgenfrei verwenden, solange man durch einen Javascript-Fallback (z.B. Picturefill) sicherstellt, dass die Bilder in allen Browsern zu sehen sind. Das ist entscheidend! Ohne Polyfill-Fallback werden die Bilder nicht indexiert.

Besser <img> mit srcset statt <picture>?

Im meinem Test wurden Bilder aus beiden Schreibweisen indexiert, aber Bilder innerhalb von <img src=" " srcset="" /> scheinen stabiler in der Bildersuche auf. Die Menge der Test erlaubt hier noch keine sichere Aussage, aber ich fühle mich mit der <img src="KLEINES-BILD.jpg" srcset="GROSSES-BILD.jpg 1200w" /> Schreibweise wohler, als mit <picture> und <source srcset. Einfach weil man weniger neue Tags ins Spiel bringen muss und näher am ganz normalen <img> Tag dran ist.

Standard verwenden statt Eigenbau

Auf die neuen Tags umsteigen sollte, wer heute noch Eigenbau-Workarounds am Start hat, z.B. größtes Bild im <noscript> Tag oder ein <img> Tag, das nur mit Javascript in die Seite geschrieben wird. Bilder in solchen Lösungen wurden im Test zwar gefunden, eine <img srcset Lösung ist meiner Meinung nach trotzdem langfristig für den Bot verständlicher.

Link aufs größte Bild als Turbo nützen

Die Indexierung von Bildern in <source> und srcset ist aktuell (noch?) sehr langsam. Wer Bilder zu aktuellen Themen in den Index bekommen muss, kann und sollte nachhelfen. Z.B. mit einem Link auf das größte Bild.

Nicht abschrecken lassen!

Man sieht oft komplizierte responsive Bilder-Lösungen mit über fünf Größen und Retina-Versionen und WebP. Davon darf man sich nicht abschrecken lassen! Man braucht nicht für jeden Breakpoint ein optimiertes Bild. Es reicht, wenn man sicherstellt, dass Mobile Devices nicht das große Bild bekommen. Ob man für JPGs unbedingt Retina-Versionen braucht, halt ich sowieso für fragwürdig. Im Grunde reichen zwei Versionen des Bildes (mit einem Breakpoint bei 650px ?)? Sagt auch der Brad Frost.

Feedback

Ich hoffe mein Test hilft Dir. Hast Du selbst ähnliche oder ganz andere Beobachtungen gemacht? Gibt es etwas, dass ich in meinem Artikel dringend ergänzen oder ändern muss? Über Dein Feedback per Google+ oder Facebook würde ich mich freuen.