Screaming Frog: Weniger ist mehr – Dein effizienter Crawl

Ich sehe häufig, dass der Impuls für eine SEO-Analyse (insbesondere bei einer neuen Seite) ist, mit dem ScreamingFrog zu crawlen.

Ich halte davon nichts. Ein Crawl ist etwas, das Du brauchst, wenn Du die Analyse schon zur Hälfte abgeschlossen hast.

Und wenn Du nicht mindestens 10 Minuten in die Konfiguration steckst, dann machst Du mit hoher Wahrscheinlichkeit etwas falsch und brauchst einen zweiten Crawl innerhalb der nächsten Tage.

Der ScreamingFrog-SEO-Spider ist ein Datensammler

Wie komme ich dazu? Nun, der ScreamingFrog ist ein großartiges Tool. Er kann unheimlich viel. Er ist aber vor allem eine Daten-Sammel-Maschine. Wenn Du den Crawl startest, dann solltest Du wissen, was genau für Daten Du brauchst.

Und das braucht Vorbereitung. Und vorbereitende Gedanken:

• Möchtest Du eine Liste crawlen (beispielsweise wichtige Seiten oder veränderte Seiten)?
• Möchtest Du die Validität der Sitemaps prüfen?
• Oder die Qualität der internen Verlinkung untersuchen?
• Möchtest Du allgemeine technische Fehler finden?
• Oder geht es Dir um inhaltliche Optimierung und Quick Wins?
• …

Das kannst Du nicht sagen, bevor Du nicht angefangen hast, die Seite zu untersuchen:

• Was ist das für eine Zielgruppe?
• Welche Fehler kennst Du schon?
• Welche Seitenbereiche gibt es?
• Welche sind davon wichtig? Worin unterscheiden sie sich?
• Was sind die Einzelfehler, die Du schon kennst und von denen Du eine skalierte Liste brauchst?

Interessiert Dich beispielsweise das Content-Inventar, dann:

• Brauchst Du nicht indexierte Seiten meist nicht zu speichern (es sei denn Du glaubst, dass indexierungswürdige Seiten auf noindex stehen)
• Kannst Du Canonicals und Redirects normalisieren lassen, denn sie sind out of Scope für Deinen Task
• Musst Dir aber ordentlich Gedanken über Custom Extractions machen

Willst Du die interne Verlinkung analysieren (und das solltest Du!), dann:

• Können Dir viele der Extractions egal sein. Bilder brauchst Du nicht und ob Du JavaScript aktivieren musst, oder nicht, ist einzelfallabhängig
• Solltest Du Dir vorher überlegen, ob Canonicals für Dich normalisiert werden sollen oder nicht
• Bietet es sich bei größeren Seiten (10 Mio. URLs aufwärts) unter Umständen an 2 Crawls zu machen. Einen nur für die Links und einen zweiten mit den relevanten Meta-Daten der relevanten Seiten

Willst Du ein wenig in technischen Problemen wühlen, dann:

• Brauchst Du gespeichertes HTML
• Kannst aber manche Extraction weglassen
• Solltest aber genau überlegen, ob Du wirklich die komplette Seite absammeln willst

Willst Du eine Migration vorbereiten, dann:

• Brauchst Du vor allem einen Fokus auf vollständige Inventare und Verlinkungen
• Die Extraction der vollständigen Inhalte ist nicht so wichtig
• Und für Accessibility, Meta-Daten, etc. machst Du einen eigenen Crawl des Stage-Systems. Der Systemabgleich ist etwas anderes als die Untersuchung von Optimierungspotenzialen

Bevor Du also einen Crawl konfigurierst, musst Du Dir Fragen stellen:

• Welche URLs brauche ich? Vollständig? Reicht ein Segment?
• Welche Daten brauche ich? Reichen die Standard-Extractions oder muss ich extra Extractions konfigurieren?
• Wie sollten die Daten für die Auswertung herausfallen?

Wenn Du den Crawl angeworfen hast (insbesondere bei aktiviertem JavaScript): Nach 15 Minuten einmal schauen, welche Pfade Du in die Excludes aufnehmen möchtest. Im Crawling von Parameter-URLs, Share-URLs, Tracking-Scripten und Consent-Bannern steckt kein Mehrwert. Wenn Du das Problem einmal erkannt hast, kannst Du Dein Ticket schreiben. Davon, die URLs vollständig zu erheben, wird nichts besser. Im Gegenteil: Der Crawl läuft länger. Der Server rödelt mehr. Die Umwelt nimmt mehr Schaden, es kostet mehr Ressourcen und vor allem: Es macht Deine Auswertung unnötig langsam und unübersichtlich.

Bei kleineren Crawls hab ich einen kleinen Tick. Ich lösche URLs bei der Auswertung. Diese URL entsteht durch dieses Problem. Ticket geschrieben, URLs gelöscht. Natürlich sollte man sich sicher sein, dass man alle Probleme auf diesen URLs erwischt hat. Aber gerade Dinge, wie Paginierung, Canonicals, HTTP-Links, Redirects, etc.: Die brauche ich nicht mehr in meiner Analyse, nachdem ich das Problem beschrieben habe.

Und jede URL, die ich nicht in meiner Analyse habe, gibt mir mehr Fokus. In einer perfekten Welt ist meine Fragestellung so klar, dass ich keine einzige URL dabei habe, die nicht auf meine Analyse einzahlt.

Beispiel (News-)Artikel crawlen

Beispielsweise könnte ich anhand der Google Search Console validieren, ob die indexierten URLs, die nicht in der Sitemap stehen, ein größeres Thema sind oder nur ein kleines Timing-Artefakt. Wenn ich also weiß, dass die Sitemaps grundsätzlich alle indexierbaren URLs enthalten, dann könnte ich alle Nicht-Artikel-URLs excluden, die Sitemaps als Source nehmen und meine Analyse ausschließlich auf die Artikel fokussieren. Ich würde dann:

• Autor
• Bewertung
• Länge
• Volltext
• Verschlagwortung / Tags
• Breadcrumb
• Vorhandensein von Integrationen (Bild, Video, Tool, Bildergalerie, Produktlinks, Tabellen, Zwischenüberschriften, etc.)
• Interne Links innerhalb von Artikeln
• Sichtbares Publikationsdatum, datePublished aus Schema.org, dateModified aus Schema.org
• Title, Description, og:title, og:description, og:image, schema:image, schema:headline
• isAccessibleForFree

ziehen. Damit kann man dann ungefähr jede Analyse durchführen, die man möchte: * Welche Inhalte müssen zuerst optimiert werden? * Wie sieht das mit Traffic aus? * Welche Inhalte sollten gemeinsam aktualisiert werden, weil sie zum gleichen Thema gehören? * Welche Artikel verweisen mit individuellen Ankertexten aufeinander? * Welche sollten zusätzliche Links erhalten?

Beispiel Produkte crawlen

Bei Produkten sieht das etwas anders aus. Hier interessieren mich andere Datenpunkte:

• Hersteller
• Verfügbarkeit / Preis / Finanzierungsoptionen
• Kategorien
• Produktbeschreibung (Volltext)
• Produkteigenschaften / Technische Daten (möglichst strukturiert)
• Produktbilder/-videos
• Verlinkte Datenblätter
• Produkt-Schema-Verwandtschaften vs. Interne Verlinkung

Hier interessieren mich ganz andere Fragen.

Wer die Auswertung im ScreamingFrog macht, der macht was falsch

Ich habe es inzwischen zu einem gewissen Nerd-Tum im ScreamingFrog gemacht. Xpath besser als CSS, besser als RegEx. Je mehr RegEx-Extractions, desto leichter schmiert der Crawl ab. Aber: teilweise kann man die Daten mit RegEx wesentlich besser ansteuern als mit anderen Extractions. Und: Je weniger Ballast wir extrahieren, desto besser. Das Tolle ist: Du musst die Extractions nicht mehr selbst schreiben. Claude, ChatGPT und Gemini helfen Dir gern. Du musst nur noch bei Beginn des Crawls checken, ob die Extraction auch wirklich funktioniert.

Spezifische Extractions mit möglichst geringem Beifang sind wichtig. Sie reduzieren nicht nur Größe und Laufzeit des Crawls. Sondern sie reduzieren die Größe der Exporte. Und Du willst alle Daten exportieren. Auch wenn ScreamingFrog ermöglicht eine PageRank-Berechnung (=LinkScore) zu machen: Du möchtest Deine eigene Berechnung machen, um Kontrolle über die Aussagekraft zu haben. Auch wenn ScreamingFrog ermöglicht Daten gegen ein LLM zu ballern, dann möchtest Du das offline machen. Nicht nur, weil Du dann Batch-APIs nutzen kannst und Kosten sparst, sondern auch, weil Du die Daten vorher noch mal qualitätssichern kannst und Dein Crawl nicht langsamer fertig wird, weil Du viele Dinge an die AI schickst. Und auch wenn Du im ScreamingFrog Ngram-Analysen machen kannst, so spricht viel dafür, das außerhalb des ScreamingFrogs auf Basis von Exporten zu machen, denn dann kannst Du das direkt skaliert exportieren, so wie Du es brauchst.

Der zentrale Produktivitätshack für ScreamingFrog

Meinen zentralen Produktivitätshack für den ScreamingFrog hab ich vor ca. 5 Jahren entdeckt: Die Änderung der default-Configuration. Du kannst eine eigene Standardkonfiguration anlegen. Das hab ich gemacht. Sie heißt: DefaultNone. In der Konfiguration ist alles(!) deaktiviert, was man deaktivieren kann. Das zwingt mich bei jedem Setting zu überlegen, ob ich das brauche oder nicht. Ich konfiguriere den Crawl gezielt. Ich überlege, ob ich die interne Verlinkung brauche, oder nicht. Wenn ich die internen Links nicht speichere, dann wird der Crawl oft Faktor 10 oder mehr kleiner. Finde ich immer noch wild. Vielleicht brauche ich die Links nicht zu speichern. Vielleicht interessieren mich nur bestimmte Elemente. Nur ganz selten möchte ich externe Links speichern. Noch seltener abfragen. Das reduziert die Laufzeit massiv und erhöht die Geschwindigkeit, mit der der Crawl läuft.

Der ScreamingFrog ist das Schweizer Taschenmesser des SEOs. Man kann fast jeden Task in irgendeiner Form damit unterstützen, weil der Crawler so mächtig ist. Aber manchmal braucht man nur das Messer oder den Korkenzieher oder die Pinzette. Und im Gegensatz zum Schweizer Taschenmesser kann ich dann alle Funktionen zu Hause lassen, die ich nicht brauche.

Weniger ist mehr. Das gilt für den ScreamingFrog genauso wie für das Analysedokument, das Du auf Basis Deines Crawls zusammengeschrieben hast.

Falls Du Dich fragst, warum ich nicht auf die coolen Accessibility-Features eingegangen bin: Nun zu Accessibility mit dem ScreamingFrog analysieren hat Sandra einen hervorragenden Artikel geschrieben. Zu Segmenten im ScreamingFrog haben wir auch einen tollen HowTo-Artikel von Andreas. Aber auch hier gilt: Ich persönlich bevorzuge die Segmente offline zu bilden.

Die Stärke des ScreamingFrog ist das flexible Datensammeln. Weniger die Auswertung.

Was ist Dein Lieblings-Feature im ScreamingFrog? Wo arbeitest Du anders mit dem Frog?