Ein Kunde schickte mir einmal eine Site, die von einer professionellen Agentur 18 Monate lang „SEO-optimiert" worden war. Die Rankings waren flach. Der Traffic war Jahr-für-Jahr rückläufig. Der Bericht der Agentur war 47 Seiten lang und enthielt einen Abschnitt zu „Brand-Voice-Alignment". Was er nicht enthielt, war die Tatsache, dass 3.400 Seiten mit dem Status-Code 200 zurückgegeben wurden, aber noindex-Tags in den Meta-Angaben eingebettet waren. Dreieinhalbtausend Seiten. Weg. Unsichtbar. Die Agentur hatte die Site nie wirklich gecrawlt.
Wichtigste Erkenntnis: Ein Screaming Frog Crawl, abgeglichen mit Search Console Daten, findet immer noch die meisten technischen SEO-Probleme auf jeder Website; die Methode ist wichtiger als exotische Tools.
Ich habe es in einer Woche behoben. Mit Screaming Frog und Google Search Console.
Das ist das Ding mit Technical SEO: Es belohnt Menschen, die sich tatsächlich die Daten ansehen, statt nur darüber zu sprechen. Und ehrlich gesagt: Bei 90% der Sites, die ich über Seahawk überprüfe, brauche ich keine Ahrefs, keine Semrush oder irgendwelche großen Plattformen, um die Probleme zu finden, die die Performance wirklich schaden. Zwei Tools. Ein Prozess. Hier ist er.
---
Bevor du etwas Crawlst, Richte Screaming Frog Richtig Ein
Die meisten Leute öffnen Screaming Frog, fügen eine URL ein und klicken Start. Das ist ok für einen 50-Seiten-Blog. Bei allem Größeren wartest du 40 Minuten auf einen Crawl, der dir falsche Daten liefert.
Konfiguration ist wichtiger als Crawling-Geschwindigkeit
Das Erste, das ich mache: Gehe zu Konfiguration > Spider und stelle sicher, dass ich das richtige Protokoll crawle. Wenn die Website auf HTTPS läuft (sollte sie), starte ich von der kanonischen HTTPS-Startseite. Ich deaktiviere auch das Crawlen bestimmter Dateitypen – PDFs, Bilder, Videos –, außer ich will diese spezifisch überprüfen. Das halbiert die Crawl-Zeit.
Dann stelle ich Configuration > Respect Canonical Tags auf aus. Kontraintuiv, ich weiß. Aber ich möchte jede kanonisierte URL sehen, um prüfen zu können, ob die Kanonisierung tatsächlich korrekt ist. Falls Screaming Frog kanonisierte Seiten überspringt, wirst du nie erfahren, dass sie existieren.
Noch eine Sache: Unter Konfiguration > Custom Extraction richte ich eine Extraktionsregel ein, um die rohen <title>- und Meta-Description-Tags direkt aus dem HTML-Quellcode zu extrahieren. Warum? Weil manche WordPress-Sites, besonders solche, die Yoast zusammen mit einem Page Builder verwenden, zwei Title-Tags ausgeben. Screaming Frogs Standard-Spalte zeigt dir nur die erste. Die Extraktionsregel zeigt dir alles.
---
Der erste Durchlauf: Worauf ich in den Crawl-Daten achte
Wenn der Crawl fertig ist, starte ich nicht mit defekten Links. Jeder startet mit defekten Links. Ich starte mit dem Response Codes Tab und filtere nach 3xx Redirects.
2021 übernahm Seahawk einen E-Commerce-Client – ein mittelgroßer Möbelhändler mit etwa 8.000 URLs. Das Dev-Team hatte zwei Jahre lang Redirects ad hoc bearbeitet. Wir fanden 19 Redirect-Ketten, manche davon vier Sprünge lang. Seite A leitete auf Seite B um, die auf Seite C umleitet, die auf Seite D umleitet. Google sagt, es folgt bis zu 10 Sprüngen, aber in der Praxis verschwendet alles über zwei Sprünge Crawl-Budget und schwächt die Link-Equity. Wir reduzerten alles auf Single-Hop-Redirects. Allein das – ohne Content-Änderungen, ohne Link-Building – brachte drei Category-Pages von Seite 3 auf Seite 1 innerhalb von sechs Wochen.
Die Reihenfolge, in der ich die Tabs durcharbeite
- Response Codes → 3xx, Redirect-Ketten und Schleifen
- Response Codes → 4xx, kaputte Seiten (nach Inlinks filtern, um zu priorisieren)
- Indexability → Non-Indexable, noindex, Canonicals, die anderswohin zeigen, blockiert durch robots.txt
- Page Titles, fehlend, dupliziert, über 60 Zeichen
- Meta Description, fehlend oder dupliziert (kein Ranking-Faktor, aber Click-Through-Rate zählt)
- H1, fehlend, dupliziert oder mehr als eine pro Seite
- Bilder → Alt-Text fehlt, schneller Gewinn, besonders für Product-Sites
- Directives → Canonical, überprüfe, dass diese der tatsächlich indexierbaren URL entsprechen
Diese Reihenfolge ist absichtlich. Ich arbeite von strukturellen Problemen (Redirects, fehlerhafte Seiten) hinunter zu On-Page-Problemen. Das Beheben einer fehlerhaften Redirect-Kette hilft jeder Seite in dieser Kette. Das Beheben einer fehlenden Meta Description hilft einer Seite.
---
Ebenen in der Search Console: Wo es interessant wird
Screaming Frog zeigt dir, was auf der Website ist. Search Console zeigt dir, was Google auf der Website sieht. Die Lücke zwischen diesen beiden Datensätzen ist der Ort, an dem die echten Probleme liegen.
Open Coverage (or Indexing → Pages in the newer interface). You're looking at four things:
- Error, Seiten, die Google indexieren wollte und nicht konnte
- Valid with warnings, oft „Submitted URL not selected as canonical", was ein Durcheinander ist, das du entwirren musst
- Excluded, Seiten, die Google nicht indexieren wollte (gecrawlt aber nicht indexiert, noindexed, usw.)
- Valid, Seiten, die Google indexiert hat
Der „Excluded"-Bucket wird kriminell unternutzt. Die meisten Leute ignorieren ihn. Ich gehe direkt dahin. Filtere nach „Crawled, currently not indexed." Das ist Google, das sagt: Ich habe diese Seite gefunden, ich habe sie gelesen, und ich habe entschieden, dass sie nicht indexiert werden sollte. Das ist fast immer ein Thin-Content-Problem. Oder es ist eine Seite, die absolut in Ordnung ist, aber zu ähnlich einer anderen Seite, ein klassisches Problem mit facettierter Navigation oder Tag-Archiven.
GSC-Ausschlüsse gegen Ihren Screaming Frog Crawl abgleichen
Exportieren Sie Ihren Screaming Frog Crawl als CSV. Exportieren Sie die „Ausgeschlossenen" URLs aus der Search Console. Laden Sie beide in Google Sheets und führen Sie ein VLOOKUP durch. Alle URLs, die im Screaming Frog Crawl und in der GSC-Ausschlussliste erscheinen, haben höchste Priorität bei der Untersuchung.
Ich kenne Leute, die dafür zu Python-Skripten greifen. Du brauchst das nicht. VLOOKUP in Sheets dauert vier Minuten und gibt dir die gleiche Antwort.
---
Crawl Budget: Spielt nur eine Rolle, wenn deine Website wirklich groß ist
Okay, lass mich ehrlich sein. Wenn deine Website unter 1.000 Seiten hat, ist Crawl Budget nicht dein Problem. Du kannst dich damit aufhören zu sorgen.
Aber sobald du über etwa 10.000 URLs hinausgehst – und viele WooCommerce- oder Magento-Shops erreichen das allein durch Produktvarianten und gefilterte URLs – wird Crawl Budget zum Problem. Die Google Search Central-Dokumentation zum Crawl Budget ist tatsächlich eines der klareren Dinge, die sie geschrieben haben. Lesen lohnt sich.
Die zwei Hebel, die dir in Search Console zur Verfügung stehen, sind der Bericht Crawl Stats und das Tool URL Inspection. Crawl Stats zeigt dir die Crawl-Aktivität von Google über 90 Tage: gecrawlte Seiten pro Tag, Antwortzeiten, Antwort-Codes. Wenn du an einem bestimmten Datum einen Spike bei 404ern siehst, ist das ein schiefgelaufenes Deployment. Wenn die durchschnittliche Crawl-Zeit über 2 Sekunden liegt, ist dein Server das Problem, nicht dein SEO.
---
Interne Verlinkung: Das, was Agenturen immer übersehen
Ich habe über hundert Sites bei Seahawk auditiert, wo der Client echtes Geld in Link Building, Guest Posts, Digital PR usw. ausgegeben hat, und hatte verwaiste Seiten, auf die kein interner Link zeigte. Google kann nicht priorisieren, was es durch deine Site-Struktur nicht finden kann.
In Screaming Frog filterst du das Crawl nach Inlinks = 0. Jede Seite mit null internen Links ist eine Waise. Gleiche das mit den indexierten Seiten in Search Console ab. Wenn die Seite indexiert ist, aber keine internen Links hat, bedeutet das, dass Google sie über eine XML-Sitemap oder einen externen Backlink gefunden hat. Das ist fragil. Gib ihr einen internen Link von einer relevanten Seite und du gibst Google ein strukturelles Signal, dass diese Seite wichtig ist.
Ein paar Dinge, auf die ich bei Internal Linking achte
- Paginierungsseiten, die auf Produkt-/Artikelseiten verlinken, aber diese Seiten verlinken nicht zurück auf Kategorieseiten
- Blog-Posts aus 2019, auf die noch nie von neueren Inhalten aus verlinkt wurde
- Seiten mit Dutzenden eingehenden internen Links, aber sehr niedrigem Traffic in der Search Console – oft ein Zeichen, dass die Seite selbst das Problem hat, nicht die Links.
---
Core Web Vitals: So liest du die Daten richtig
Search Console bietet einen Core Web Vitals Report. Die Daten stammen direkt aus dem Chrome UX Report von echten Nutzern. Das heißt: Felddaten von realen Besuchern auf ihren Geräten, nicht aus dem Labor. Das sagt dir viel mehr als ein einzelner Lighthouse-Test.
Der Report ordnet URLs in „Gut", „Verbesserungsbedürftig" und „Schlecht" nach LCP, FID (inzwischen durch INP ersetzt) und CLS. Versuche nicht, alles auf einmal zu reparieren. Sortiere nach der Gruppe „Schlecht" und schau, welches URL-Pattern die meisten fehlgeschlagenen Seiten hat. Meist ist es ein einzelnes Template – alle Produktseiten mit CLS-Problemen oder alle Kategorieseiten mit langsamem LCP. Repariere das Template, repariere hunderte Seiten auf einmal.
Eine Sache, die ich auf die harte Tour gelernt habe: CLS-Probleme auf Seiten mit Anzeigen oder Cookie-Bannern kommen fast immer von Elementen, die nach dem ersten Render oberhalb der Faltung eingefügt werden. Screaming Frog wird das nicht erkennen. Du musst dir die tatsächliche Seite ansehen. Nutze Chrome DevTools mit aktivierten Layout Shift Regions im Rendering-Bereich.
---
Die Robots.txt- und Sitemap-Überprüfung (dauert 10 Minuten, spart Wochen)
Gehe zu yourdomain.com/robots.txt. Lese jede Zeile. Ich habe mit eigenen Augen eine live laufende Produktionsseite mit Disallow: / in der robots.txt gesehen. Keine Staging-Seite. Produktion. Ein sieben Jahre altes Unternehmen. Ihr Entwickler hatte die robots.txt des Staging-Systems während einer Migration kopiert und niemals überprüft. Sie waren im Grunde vier Monate lang für Google unsichtbar, bevor sie es bemerkten.
Gehe in Search Console zu Sitemaps. Prüfe, was eingereicht wurde. Prüfe, wann Google die Sitemap zuletzt abgerufen hat. Wenn die Sitemap über eine Woche nicht abgerufen wurde, stimmt etwas nicht. Prüfe auch die eingereichte URL-Anzahl gegen die indexierten URLs – wenn du 4.000 URLs eingereicht hast und nur 1.200 sind indexiert, musst du ein Gespräch über Content-Qualität führen, nicht über technische Fixes.
---
FAQ
Brauche ich die bezahlte Version von Screaming Frog?
Die kostenlose Version ist auf 500 URLs begrenzt. Für alles darüber, was auf die meisten Seiten zutrifft, die eine Audit verdienen, brauchst du die bezahlte Lizenz. Sie kostet £259 pro Jahr. Das entspricht etwa einer Stunde Agenturzeit. Kauf sie.
Wie oft sollte ich ein technisches Audit durchführen?
Für aktive Seiten, die regelmäßig veröffentlichen oder Produkte häufig wechseln, würde ich sagen vierteljährlich. Für kleinere, eher statische Seiten ist zweimal pro Jahr ausreichend. Ein Audit einmal durchzuführen und es als „erledigt" zu behandeln ist wie das Öl im Auto einmal zu wechseln und zu erwarten, dass es ewig läuft.
Screaming Frog zeigt Status 200, aber GSC zeigt, dass die Seite nicht indexiert ist – warum?
Fast immer einer von drei Dingen: ein noindex Meta-Tag, ein noindex HTTP-Header oder ein Canonical-Tag, der woanders hinzeigt. Führe die URL durch das URL Inspection Tool der Search Console und es sagt dir genau, was es gefunden hat. Das Tool ist unterschätzt – es zeigt dir die zuletzt von Google gecrawlte Version der Seite, einschließlich des gerenderten HTML, was JavaScript-injizierte noindex-Tags erfasst, die ein einfacher HTTP-Request nicht sehen würde.
Wie sieht es mit JavaScript-gerenderten Websites aus?
Screaming Frog hat einen JavaScript Rendering Mode unter Configuration > Spider > Rendering. Schalte ihn für JS-lastige Seiten ein. Es ist langsamer, deutlich langsamer, aber es ist die einzige Möglichkeit, Probleme mit Inhalten oder Links zu erfassen, die JavaScript nach dem initialen HTML-Load injiziert. Für eine React oder Next.js Site solltest du immer im JS Rendering Mode crawlen.
Reicht Google Search Console für Keyword-Recherche aus?
Zum Finden von Queries, für die deine bestehenden Seiten ranken – ja, das ist ausgezeichnet. Zum Entdecken neuer Keyword-Chancen – nein, du brauchst etwas anderes. Aber das sprengt den Rahmen eines technischen Audits.
---
Zwei Tools. Ein Tabellenkalkulationsprogramm. Ein paar Stunden. Das ist wirklich alles, was es braucht. Die teuren Plattformen haben ihren Platz, ich bin nicht dagegen, aber ich habe zu viele Website-Besitzer gesehen, die annehmen, dass mehr Geld auch mehr Ergebnisse bedeutet. Die Probleme liegen fast immer in den Basics. Sie müssen nur jemanden haben, der tatsächlich hinschaut.