Crawl-Budget optimieren mit der Google Search Console

Redaktionell bereinigtes und gekürztes Transkript des oben eingebundenen Livestreams von SISTRIX (SEOPRESSO Podcast). Grundlage sind die automatisch erzeugten Untertitel; Formulierungen wurden zur Lesbarkeit geglättet, offensichtliche Erkennungsfehler korrigiert und Sprecherzuordnungen in eckigen Klammern ergänzt. Um Begrüßungs-, Housekeeping-, Technik- und Verabschiedungspassagen wurde gekürzt, die fachlichen Aussagen sind vollständig erhalten. Einzelne Passagen können vom gesprochenen Wort abweichen.

Warum Logfile-Analyse wichtig ist

[Björn] Ich gehe davon aus, dass nur eine Handvoll SEOs wirklich prozessorientiert mit Logfiles arbeitet, sofern sie die Daten haben, aufbereiten können und ein Tool dafür haben. Warum ist die Logfile-Analyse wichtig, und welche Einblicke bekommt man daraus?

[Juliane] Logfiles sind unser Bild davon, womit sich Suchmaschinen und andere Bots auf unserer Seite auseinandersetzen: Was finden sie, wie oft crawlen sie etwas? Das ist meine einzige Datenquelle, mit der ich ein umfassendes Bild bekomme und auch sehe, was auf meinem Server herumliegt, das mir nicht offensichtlich ist, weil es nicht meine sichtbare URL-Struktur ist, sondern die ganzen Ressourcen drumherum. Ich habe einen Blick in den Maschinenraum. Ich kann sehr spezifisch herausfinden, wie schnell eine neue URL gefunden wird, ob es Missverhältnisse beim Crawling gibt oder ob bestimmte Verzeichnisse sehr häufig gecrawlt werden.

[Björn] Vieles davon bekommt man doch auch mit einem guten Crawler wie Screaming Frog. Was ist der Unterschied zu den Logfile-Daten?

[Juliane] Mit einem normalen Crawler sehe ich, wenn ich die Inspection-API von Google anbinde, vielleicht das letzte Crawldatum einer URL. Aber ich sehe nicht, wie häufig sie gecrawlt wurde, ob einmal oder hundertmal. Ich finde auch nicht heraus, wenn URLs gar nicht gecrawlt werden, oder ob sich Suchmaschinen in bestimmten Ressourcen festbeissen und sie häufig crawlen. Diese Frequenz bekomme ich mit einem Screaming Frog einfach nicht heraus.

Warum Crawling eine begrenzte Ressource ist

[Björn] Das Ziel der Logfile-Analyse ist, das Crawling effizienter zu gestalten, damit Google die wichtigsten Seiten crawlt und sich nicht mit Fehlern beschäftigt. Warum ist Crawling eine begrenzte Ressource, und welche Auswirkung hat ineffizientes Crawling auf die SEO-Performance?

[Juliane] Nur mit Crawl-Effizienz können wir unser Crawl-Budget optimieren. Crawling ist am Ende eine begrenzte Ressource: Täglich werden hunderte Millionen neue Dokumente veröffentlicht, daneben gibt es unzählige bekannte Dokumente, die immer wieder gecrawlt werden müssen. Wir sind in einer Wettbewerbssituation und müssen zusehen, dass wir keine Ressourcen für unnötiges URL-Inventar verschwenden. Wenn wir Crawling-Ressourcen verschwenden, bekommen wir Probleme bei der Performance, da ist Google in der Dokumentation eindeutig, und ich sehe es auch in der Realität. Erstens werden neue URLs nicht schnell genug entdeckt, gecrawlt und indexiert. Gerade in Bereichen, die von Schnelligkeit leben, etwa Publishing, entscheidet das, ob ich in der Schlagzeilen-Box lande oder nicht. Zweitens kommt es zu Verzögerungen bei Aktualisierungen bestehender URLs: Der Crawler kommt später vorbei, Änderungen werden nicht schnell genug erkannt. Und drittens belastet unnötiges Crawling meine Serverkapazitäten, das kann Ausfallzeiten provozieren und ist ein Kostentreiber. Und nicht banal: Jede unnötig gecrawlte URL erzeugt einen CO2-Abdruck, den wir sparen können.

Das Problem der Logfile-Beschaffung

[Björn] Man guckt über die Logfile-Analyse von vorne auf das Auto und identifiziert Fehler, bevor es Crawling-Probleme gibt. Aber die Logfile-Beschaffung ist im Unternehmen oft ein Albtraum, riesige Files, Terabytes an Daten. Man kann nur kurze Zeiträume anschauen und braucht Tools, die diese Größen verarbeiten. Du hast auf der SEOcom eine leichte Alternative über die Google Search Console vorgestellt. Welche Daten von dort sind besonders wertvoll?

[Juliane] Das sind die Crawling-Statistiken, die leider sehr versteckt sind. Wenn man nicht weiß, wo man sie findet, stolpert man nicht darüber wie über den Indexbericht. Man findet sie unter den Einstellungen. Dort haben wir einen großen Datenschatz, um das Crawl-Verhalten zu analysieren und strukturelle Probleme zu erkennen. Wichtig: Die Crawling-Statistiken sieht man nur mit einer Domain-Property, nicht mit einer Folder-Property. Auf Domain-Ebene sind auch alle untergeordneten Subdomains mit drin, das ist ein großer Vorteil. Ich kann eine Gesamtbetrachtung machen, gerade wenn ich eine eigene API oder meine Bilder auf einer Subdomain hoste. Unter den Crawling-Statistiken gibt es auf der übergeordneten Ebene den Bereich Hosts mit den bis zu 20 meistabgerufenen Subdomains der letzten 90 Tage. Wenn du mehr als 20 Subdomains hast, ist das schon ein Ansatzpunkt. Und man findet oft alte Stagings oder Subdomains, die crawlbar sind, aber null Relevanz haben und blockiert oder abgeschaltet gehören. Da ist sehr oft schon Potenzial.

Die drei Schritte der Logfile-light-Methode

[Björn] Kannst du uns Schritt für Schritt durch die Methode führen, wie du die Daten aus der GSC mit Looker Studio oder Google Sheets verbindest?

[Juliane] Es sind drei Schritte. Schritt eins: die Daten aus der GSC holen. Google stellt vier Bereiche zur Verfügung, nach Dateityp, nach Zweck, nach Antwort (Statuscode) und nach Googlebot-Typ. In jedem Bereich stecken bis zu 1.000 Beispiel-URLs. Man kann sich durch alles durchklicken und überall exportieren, das sind aber bis zu 45 Dateien, je mehr Ausprägungen, etwa Statuscodes, desto mehr Berichte. 45 mal manuell exportieren geht, aber es gibt ein Chrome-Plugin von Valentin Pletzer, damit hat man eine One-Click-Lösung und lädt die ganzen Crawling-Statistiken gebündelt herunter. Schritt zwei: die Daten konsolidieren, aggregieren und teilweise extrahieren, weil wir Analysen machen wollen, die über die GSC-Oberfläche hinausgehen. Wir zerlegen zum Beispiel den URL-Pfad, um Verzeichnisanalysen zu machen. Dafür habe ich ein Master-Template gebaut, entweder in Google Sheets oder komfortabler in n8n, ein Apps-Script führt die Daten zusammen. Schritt drei: Diese Master-Datei bindet man an Looker Studio an. Am Ende hat man zwei Dateien und kann direkt loslegen und nach Auffälligkeiten suchen.

Was man im Template und in den Statistiken sieht

[Juliane] Ganz oben haben wir die Summaries, wie in den Crawling-Statistiken: Gibt es Peaks bei den Crawling-Anfragen, Auffälligkeiten bei der Serverantwortzeit, wie groß sind die Downloads? Der Vorteil im Template ist, dass wir in einzelne Zeiträume hineinzoomen und Korrelationen betrachten können, zum Beispiel: Ich habe einen Anstieg an Crawl-Requests, wie reagiert mein Server, geht die durchschnittliche Reaktionszeit nach oben? Steigende Crawling-Anfragen bei parallel steigender Server-Reaktionszeit können darauf hindeuten, dass ich perspektivisch Kapazitätsprobleme bekomme. Darunter kommen die Details: die Verteilung der Statuscodes, die Dateitypen (habe ich vorrangig HTML, oder wie hier im Beispiel PDFs mit 6 Prozent?), und die Verteilung zwischen Discovery- und Refresh-Crawls. Das ist ein Unterschied zu klassischen Logfiles, dort haben wir diese Information nicht, Google stellt sie hier bereit. So kann ich analysieren, ob ein Verzeichnis mit hoher Veröffentlichungsfrequenz, etwa der Blog, auch einen entsprechend hohen Discovery-Anteil hat.

[Juliane] Dann kommt die Segmentierung: Welche Verzeichnisse werden am häufigsten gecrawlt? Das kann ich nach Statuscodes filtern und sehr tief hineingehen und Auffälligkeiten über die letzten drei Monate sehen. Der Vorteil gegenüber Logfiles ist der lange Zeitraum, ich habe großen Interpretationsspielraum für Trends und Peaks, den ich bei Logfiles wegen der begrenzten Zeiträume oft nicht habe. In der aggregierten Form sehe ich auch Auffälligkeiten bei häufig gecrawlten URLs. In einem Beispiel ist bei den Top-gecrawlten URLs direkt ein 404 dabei, eine fehlerhafte CSS-Datei, die ständig gecrawlt wird. Warum, muss nicht sein, das findet man hier schon in den Daten.

Worauf man beim Einstieg achten sollte

[Björn] Worauf sollte man achten, wenn man in so eine Analyse startet?

[Juliane] Ich würde auf zwei, drei Punkte achten. Erstens die Statuscode-Verteilung: Statuscode 200 sollte in der Regel überwiegen. Wenn ich viele Redirects oder viele 400er habe, ein gewisser Anteil ist normal, aber es sollte nicht der Hauptanteil sein, werde ich aufmerksam. Ich hatte einen Fall, da hatte Statuscode 301 dreißig Prozent des gesamten Crawlings ausgemacht, und das war nicht erklärbar, wir hatten kein Republishing. Daneben 20 Prozent Statuscode 404, das wiederum war erklärbar, weil es eine sehr dynamische Seite mit dynamischem URL-Inventar war. Der 30-Prozent-Anteil mit 301 war nicht zurückführbar. Wir haben uns über das Dashboard angeschaut, welche URLs und Verzeichnisse betroffen sind, und festgestellt, dass es Parameter-URLs waren, die 23 Prozent des gesamten Crawlings ausgemacht und extreme Ressourcen gefressen haben. Das haben wir uns über die Crawling-Statistiken erschlossen und dann optimiert.

[Björn] Man sollte darauf hinzielen, mindestens 95 Prozent Statuscode 200 zu haben. Interessant ist auch die Discovery-Refresh-Verteilung, gerade bei großen Plattformen: Google soll eine gute Mischung aus neuem und altem Content haben. Und die Dateityp-Verteilung, um ein JavaScript-Problem zu erkennen.

[Juliane] Genau, jede Domain ist anders, eine bildlastige Domain hat mehr Images. Man muss es hinterfragen, aber allein durch diese Views hat man schon sehr gute Optimierungsansätze. In einem Projekt haben wir neben dieser Logfile-light-Methode parallel eine echte Logfile-Analyse gemacht, und die Erkenntnisse waren nahezu die gleichen. Probleme sind fast immer strukturell, selten eine einzelne URL, die das Crawl-Budget kaputt macht. Auch die Tageszeit-Verteilung ist spannend: Wann kommt Google vorbei und hat einen Peak? Ein guter Indikator, wann man große Änderungen oder eine Migration machen sollte.

Use Case: Migration überwachen

[Björn] Wie würdest du die Analyse nutzen, um zu identifizieren, ob eine Migration erfolgreich läuft?

[Juliane] Für eine URL-Migration würde ich vorab den Status quo ermitteln, sonst weiß ich nicht, wo meine Abweichungen sind. Praktisch: Die Daten werden in der GSC drei Monate rückwirkend gespeichert, ich kann also auch unmittelbar nach der Migration noch rückwirkend schauen. Dann beobachte ich Redirects und 404-Seiten. Wenn ich bei der Migration alles umleite, sollte das Crawling im Bereich 301 massiv nach oben gehen. Gehen die 404-Anteile massiv nach oben, sind vielleicht Inhalte auf der Strecke geblieben. Das Crawling der 404-Seiten sollte sich mit der Zeit einpegeln, und wenn nicht, ist es der Punkt, mit 410 zu arbeiten. Ich habe ein Migrationsprojekt gesehen, bei dem der 404-Anteil lange bei 40 bis 50 Prozent lag, dann wurde im Nachgang auf 410 umgestellt, was sich positiv aufs Crawling ausgewirkt hat. Auch die Dateityp-Verteilung ist spannend: Wird auf einmal vermehrt JavaScript oder CSS gecrawlt? Ist das gewollt, weil wir die Templates geändert haben?

Use Case: URL-Inventar gegen Sitemap

[Björn] Wie gehst du beim Ungleichgewicht zwischen den URLs, die du hast, und den URLs, die du über die Sitemap rausschickst, vor, um URLs zu reduzieren?

[Juliane] Man sollte den Crawl-Ballast reduzieren, damit die relevanten Inhalte in den Index kommen. Ein Crawl-Budget-Problem kommt oft durch technische Fehler, durch facettierte Navigation, Kalenderintegration oder Parameter-URLs. Das sollte als technischer Fehler behoben werden. Ist es kein Fehler, sondern ein notwendiger Bestandteil, sollte über die robots.txt nachgedacht werden: unnötige Verzeichnisse vom Crawling aussperren. Aber Achtung, dann tauchen sie eventuell im Indexbericht als „indexiert, obwohl durch robots.txt gesperrt" auf, da sind weiterführende Tasks nötig, etwa Link-Maskierung. Beim Thema Redirects: Wenn ich einen riesigen Anteil habe, schaue ich, wie ich Redirect-Ketten abbaue, gerade bei Republishing hat man nicht selten fünf bis zehn Ketten. Und die Website-Architektur: Sind meine wichtigen Inhalte, die in der Sitemap stehen, auch gut intern verlinkt? Wenn sie in Klicktiefe acht liegen, bringt das nichts. Dazu der Einsatz korrekter Statuscodes: Bei permanent gelöschten Inhalten 410 statt 404, das wird im Nachgang bis zu 50 Prozent weniger gecrawlt. Bei unveränderten 200er-Inhalten kann ich mit Statuscode 304 (Not Modified) arbeiten, das spart Crawling-Ressourcen. Und natürlich die Page-Performance, Ladegeschwindigkeit und Server-Antwortzeit.

[Juliane] Wichtig: Das sollte sich jeder anschauen, auch kleinere Websites. Durch technische Fehler entsteht schnell ein riesiges URL-Inventar. Ich hatte einen Fall mit eigentlich nur gut 1.000 URLs, der durch eine Filternavigation im Newsarchiv auf einmal über eine Million URLs hatte. Schon habe ich ein Crawl-Budget-Thema, obwohl nur 1.000 URLs in der Sitemap stehen.

Zwei Fragen aus dem Livestream

[Björn] Wie bekomme ich mehr als das 1.000-Zeilen-CSV-Export-Limit aus der GSC heraus?

[Juliane] Bei den Crawling-Statistiken bekommst du über keinen Weg mehr heraus, es gibt keine API und keinen Workaround. Der Workaround ist, alle Daten aus den verschiedenen Berichten zu ziehen und zu aggregieren. Einen kleinen Hack gibt es für einzelne Verzeichnisse: Mit dem Plugin von Valentin kann man sich pro Subfolder, wenn er als Property angelegt ist, mehr Daten ziehen.

[Björn] Gibt es einen guten Prozentwert fürs Crawl-Reporting?

[Juliane] Ich würde sagen, 95 Prozent Statuscode 200 sollte man erreichen. Und wenn man sich anschaut, welche die wichtigsten Seiten sind und Google diese hauptsächlich crawlt, ist alles gut. Man sollte immer darauf achten, dass die wichtigsten Ressourcen und Statuscodes die Überhand haben, und Auffälligkeiten, die man sich nicht erklären kann, immer hinterfragen.