In der Search-Off-The-Record-Folge “Crawling Smarter Not Harder” philosophieren Gary, Lizzi und John darüber, wie das Crawling für Googlebot effizienter gestaltet werden kann.
Nur Crawlen, wenn sich etwas verändert hat
Das grundsätzliche Dilemma für Webcrawler versteckt sich in dieser Frage: Wie können wir alle relevanten Änderungen im Internet mitbekommen, ohne permanent Dinge anzuschauen, die sich gar nicht verändert haben?
Microsoft/Bing hat sich zur Lösung dieses Problems mit Yandex und anderen zusammengetan und das Open Source Protokoll IndexNow an den Start gebracht. Google verwendet den Standard bislang nicht und erwähnt ihn im Podcast mit keinem Wort.
Ein Grund dafür dürfte sein, dass Spammer solche Standards schnell derart missbrauchen, bis sie jeglichen Nutzen verlieren. So haben sowohl Bing als auch Google die Möglichkeit abgeschafft, Sitemaps per API bei den Suchmaschinen anzupingen, wie Anita in einem vergangenen Artikel erklärt hat.
In dem Artikel erfährst Du auch, warum Google keine Lust mehr hat, die Priority- oder ChangeFrequency-Angaben in Sitemaps zu berücksichtigen. Das LastMod-Datum ist zwar weiterhin relevant. Aber nur, wenn wir es nicht missbrauchen. Sobald massenweise Seiten auf ein frisches Datum gestellt werden, obwohl sich am Inhalt gar nichts verändert hat, behält sich Google vor, die Angabe komplett zu ignorieren.
Vorsicht: Das passiert gerne auch mal bei Migrationen oder Relaunches, wenn plötzlich alle Inhalte in einem neuen CMS oder auf einer anderen Domain live geschoben werden.
Significant Changes
Deshalb wünschen sich Suchmaschinen, dass wir das LastMod-Datum nur dann aktualisieren, wenn wir auf der Seite nicht nur einen Typo korrigieren, sondern “signifikante Änderungen” am Inhalt vornehmen. Das lesen wir nicht nur aus öffentlichen Äußerungen von Google heraus, sondern indirekt auch aus dem Google Content Warehouse API Leak.
Im Modul “PerDocData” werden vermeintlich alle Attribute aufgelistet, die Google zu einem Dokument (erreichbar über eine URL) wegspeichert oder zumindest in der Vergangenheit gespeichert hat. Darunter finden wir auch das Attribut “lastSignificantUpdate”, kurz LSU. Als “Quality Signal” will Google das Attribut dennoch nicht verstanden wissen, wie wir aus der Doku zum Modul “CompositeDocQualitySignals” lernen:
”Note: This is a misleading name as of 2022/10/14. The field is still set and has meaningful data, but no longer holds quality signals. All the data are freshness-related and they're not particularly sensitive” – Geleakte Google Doku zum Modul CompositeDocQualitySignals
Dazu passt, dass sich Gary, Lizzi und John im Podcast über Crawl Requests als Qualitätskriterium austauschen.
Viel Crawling = tolle Website?
Nicht direkt. Seltenes Crawling kann für gute Inhalte vollkommen ausreichend sein. Nämlich dann, wenn sich an den Seiten nur selten etwas ändert – wie bei einer Archivseite. Die Startseiten von Nachrichtenportalen müssen natürlich viel häufiger gecrawlt werden als ein alter Blogpost. Die Änderungsfrequenz ist das wichtigere Kriterium.
Und trotzdem ziehen wir die Crawl Requests des Googlebots zuweilen auch als Qualitätskriterium heran. Es muss uns stutzig machen, wenn wir guten Content liefern und der Bot trotzdem selten vorbeikommt. Zum Beispiel auf Kategorieseiten eines Shops, wo neue, nachgefragte Produkte dazukommen und alte ausverkauft werden.
Dann müssen wir uns fragen:
- Sieht Google die Produkte?
- Sind die Überschriften und Beschreibungen sinnvoll betextet?
- Geben wir den korrekten Status Code aus?
- Kann unser Server die Hits verkraften und zügig beantworten?
In diesem Sinne dürfen wir ableiten, dass Google Teile einer Seite gut gefallen, wenn regelmäßig gecrawlt wird. Als alleiniges Kriterium taugt die Crawl Rate natürlich nichts.
Mehr Effizienz für den Crawl-Prozess?
Zurück zur Aufgabe, überflüssig (umfangreiches) Crawling einzudämmen. Auch deshalb gibt Google den Website-Betreibern – zum Beispiel über die Core Web Vitals – Hinweise und Aufgaben wie die folgenden an die Hand:
- die eigene Seite schlanker gestalten,
- nicht unnötig große Bilder ausliefern,
- sich selten ändernde Ressourcen cachen und
- allgemein weniger Last über den Äther schicken.
Dann wird Crawling nicht nur für Google, sondern auch für Betreibende von Websites günstiger und weniger belastend für das Klima. Im Podcast können wir aber noch eine weitere Bitte von Google an Website-Zuständige herauslesen.
Nutze den Status Code 304
Dazu besteht keine Pflicht, aber die 304-Response “Not Modified” kann helfen. Hiermit werden Anfragen an eine Server-Ressource implizit an eine gecachte Variante des Inhalts weitergeleitet, wenn:
- Sich entweder der String des Etags nicht verändert hat (If-None-Match\=FALSE; Bedeutet Etag ist gleich geblieben und wir brauchen die Ressource nicht nochmal)
- Oder die Ressource nach einem bestimmten (Cache-) Datum angefragt wird (If-Modified-Since\=FALSE; Seite hat sich seit dem angegebenen Datum nicht verändert und wir brauchen die Ressource nicht nochmal)
Die komplette Ressource mit 200er Status Code kommt also nur zurück, wenn sich die Ressource verändert hat. Andernfalls kommt nur der Header mit dem Redirect an die bereits vorrätigen, gecachten Ressourcen.
Dass Google den 304er-Status tatsächlich respektiert, hat Dave Smart vor ein paar Jahren schon mal auf TameTheBots getestet.
Googles Wunsch ist sicher nicht uneigennützig, allerdings profitieren wir alle davon, wenn überflüssige Server-Anfragen gar nicht erst stattfinden. Arbeitest Du schon mit dem 304 Status Code?