Screaming Frog für technische SEO-Audits richtig einsetzen

1. Crawl-Konfiguration für große Magento-Shops richtig aufsetzen

Die Standardeinstellungen von Screaming Frog sind für einen Blog mit 200 Seiten gedacht, nicht für einen Magento-Shop mit 50.000 Produkten und ebenso vielen Filterkombinationen. Vor jedem Audit gehört daher ein bewusstes Setup: Max Crawl Depth begrenzt, wie tief der Crawler in die Kategoriehierarchie vordringt, Max URLs to Crawl verhindert, dass ein einzelner Lauf unkontrolliert wächst, und die Speed-Einstellung mit reduzierter Thread-Zahl schützt den Live-Server vor spürbarer Zusatzlast während der Öffnungszeiten. Für Kataloge über 100.000 URLs ist der Database Storage Mode statt des reinen Arbeitsspeicher-Modus Pflicht, sonst stürzt der Crawl bei Speicherknappheit unvorhersehbar ab.

Der JS-Rendering-Modus entscheidet, ob Screaming Frog eine Seite nur als rohes HTML liest oder wie ein echter Browser rendert. Hyvä-Shops liefern die meisten Inhalte serverseitig aus, sodass der schnellere Text Only-Modus meist ausreicht. Sobald Alpine.js jedoch Inhalte nachträglich einblendet, etwa dynamische Größentabellen oder nachgeladene Bewertungen, liefert nur JavaScript-Rendering ein vollständiges Bild - erkennbar an Abweichungen zwischen dem gerenderten Screenshot und dem rohen HTML-Quelltext im rechten Panel.

# Headless crawl of a large Magento catalog with a memory-safe crawl limit
# JS rendering mode and thread throttling are stored inside the saved config file
screamingfrogseospider --crawl "https://shop.example.com/" \
  --headless \
  --config "magento-audit.seospiderconfig" \
  --output-folder "/audits/2026-07-11" \
  --export-tabs "Internal:All,Response Codes:All,Page Titles:All" \
  --bulk-export "Response Codes:Client Error (4xx) Inlinks,Canonicals:Canonicalised" \
  --save-crawl \
  --timestamped-output

2. Include/Exclude-Regeln und Custom Extraction gezielt einsetzen

Ohne Exclude-Regeln crawlt Screaming Frog jede Sortier-, Filter- und Paginierungs-URL, die die Magento-Layered-Navigation generiert - bei mehrstufigen Facetten schnell mehrere Millionen Kombinationen. Regex-Excludes im Tab Configuration > Exclude halten den Crawler gezielt von Parametern wie ?product_list_order=, ?p= jenseits von Seite 5 oder ?customer_group= fern, sodass sich der Crawl auf tatsächlich indexierbare, einzigartige Seiten konzentriert. Ergänzend grenzt Configuration > Include den Crawl auf einen Teilbereich ein, etwa nur eine Sprachversion, wenn gezielt ein einzelner Store-View geprüft werden soll.

Custom Extraction erlaubt es, per XPath oder CSSPath beliebige Werte direkt während des Crawls auszulesen, statt Seiten manuell zu öffnen. Für Magento-Audits eignen sich vor allem Preis, Lagerstatus und Canonical-Ziel als eigene Spalten in der Exportdatei - so lassen sich Abweichungen zwischen angezeigtem Preis und strukturierten Daten oder fehlerhafte Canonical-Ketten in Sekunden über tausende URLs hinweg per Filter aufdecken, statt sie stichprobenartig zu übersehen.

<!-- Custom Extraction (Screaming Frog > Configuration > Custom > Extraction) -->
<!-- Extractor 1 (CSSPath): .price-box .price -> extracts the displayed price -->
<!-- Extractor 2 (XPath):  //div[@data-stock-status]/@data-stock-status -> extracts raw stock status -->
<!-- Extractor 3 (XPath):  //link[@rel="canonical"]/@href -> extracts the canonical target -->

<div class="price-box" data-price-amount="49.90">
  <span class="price">49,90 €</span>
</div>
<div class="stock available" data-stock-status="IN_STOCK">
  Auf Lager
</div>
<link rel="canonical" href="https://shop.example.com/produkt/beispielartikel.html">

3. Response Codes systematisch auswerten

Der Tab Response Codes ist der erste Stopp nach jedem Crawl: Er trennt 2xx, 3xx, 4xx und 5xx sauber nach Häufigkeit und zeigt sofort, ob strukturelle Probleme vorliegen. Entscheidend ist dabei nicht nur die reine Anzahl an 404-Fehlern, sondern der Filter Client Error (4xx) Inlinks, der zeigt, von wie vielen internen Seiten aus jeweils auf eine tote URL verlinkt wird. Eine 404-Seite mit 300 internen Links verdient klare Priorität vor einer, die nur von einer vergessenen Testseite aus erreichbar ist.

Redirect-Ketten sind der zweite kritische Punkt: Der Bulk-Export Redirect Chains deckt Fälle auf, in denen eine alte Produkt-URL über zwei oder drei Weiterleitungen zum Ziel führt, statt direkt zu verlinken. Jede zusätzliche Weiterleitung kostet Crawl-Budget und verzögert die Weitergabe von Linksignalen. In Magento-Shops entstehen solche Ketten typischerweise durch mehrfache URL-Key-Änderungen ohne Bereinigung der zugehörigen Redirect-Tabelle im Backend.

4. Titles und Meta-Descriptions: Duplicate-Analyse

Der Tab Page Titles gruppiert automatisch nach Duplicate, Missing, Over 60 Characters und Below 30 Characters. In Magento-Shops entstehen Duplicate Titles fast immer durch automatisch generierte Kategorie-plus-Filter-Kombinationen, etwa wenn „Damenschuhe" und „Damenschuhe - Größe 38" denselben Title-Tag aus dem Kategorienamen ziehen, weil die Filterseite kein eigenes Title-Template besitzt. Die Duplicate Details-Ansicht listet exakt, welche URL-Cluster betroffen sind, statt nur die Gesamtzahl zu nennen.

Der Tab Meta Description funktioniert identisch und deckt zusätzlich häufig fehlende Beschreibungen auf Unterkategorien auf, die nie manuell gepflegt wurden. Statt jede URL einzeln zu korrigieren, lohnt sich der Blick auf das zugrunde liegende Template: Ein dynamisches Title-Pattern mit Filterwert-Platzhalter im Magento-Backend behebt hunderte Duplicate-Titles in einer einzigen Änderung, während Screaming Frog den Erfolg im nächsten Crawl sofort bestätigt.

5. Canonicals und Hreflang-Auswertung

Der Tab Canonicals zeigt vier Zustände, die alle einzeln geprüft werden müssen: Canonicalised für Seiten mit abweichendem Canonical-Ziel, Missing für Seiten ohne jedes Canonical-Tag, Multiple für widersprüchliche Mehrfachangaben und Non-Indexable Canonical, wenn das Canonical-Ziel selbst per noindex gesperrt ist. Faceted-Nav-Seiten in Magento zeigen häufig ein Canonical auf die ungefilterte Kategorie, was korrekt ist - problematisch wird es erst, wenn Paginierungsseiten fälschlich auf Seite 1 statt auf sich selbst kanonisieren und dadurch aus dem Index fallen.

Der Tab Hreflang prüft internationale Shops auf drei typische Fehlerbilder: fehlende Rückverweise (Missing Return Links), inkonsistente Sprachcodes zwischen den Varianten und Hreflang-Ziele, die selbst nicht kanonisch sind. Ein Sitemap-Export mit fehlerhaften Hreflang-Paaren ist die häufigste Ursache, warum internationale Store-Views trotz korrekt gepflegter Inhalte in der falschen Sprache ranken.

<!-- Sitemap hreflang error: missing reciprocal link on the second URL -->
<url>
  <loc>https://shop.example.com/de/produkt/beispielartikel.html</loc>
  <xhtml:link rel="alternate" hreflang="de-DE" href="https://shop.example.com/de/produkt/beispielartikel.html"/>
  <xhtml:link rel="alternate" hreflang="en" href="https://shop.example.com/en/product/sample-item.html"/>
</url>
<url>
  <loc>https://shop.example.com/en/product/sample-item.html</loc>
  <xhtml:link rel="alternate" hreflang="de-DE" href="https://shop.example.com/de/produkt/beispielartikel.html"/>
  <!-- Error: reciprocal hreflang="en" entry pointing back to itself is missing -->
</url>

6. Crawl-Budget und URL-Explosion durch Facettennavigation

Layered Navigation ist die häufigste Ursache für ausuferndes Crawl-Volumen in Magento-Shops. Fünfzig Kategorien mit je zehn Filterattributen erzeugen rechnerisch weit über eine Million theoretische URL-Kombinationen, von denen die meisten identischen oder nahezu identischen Inhalt zu einer bereits existierenden Seite liefern. Der URL-Wachstumsgraph in Screaming Frog während eines laufenden Crawls zeigt schonungslos, wenn die Anzahl entdeckter URLs exponentiell statt linear steigt - ein klares Warnsignal für unkontrollierte Facetten-Kombinationen.

Die Gegenmaßnahme kombiniert mehrere Ebenen: rel="nofollow" auf Filterlinks jenseits der ersten Facette, gezielte Disallow-Regeln im robots.txt für Parameterkombinationen und ein Canonical auf die Basiskategorie. Bevor eine robots.txt-Änderung live geht, sollte sie über die Exclude-Liste in Screaming Frog simuliert werden, um den tatsächlichen Effekt auf die Crawl-Größe zu messen, statt blind auf die Produktion zu vertrauen.

7. Befunde exportieren und priorisieren: von Rohdaten zur Maßnahmenliste

Ein Crawl-Export mit zwanzig Tabs und hunderttausend Zeilen ist für sich genommen keine Maßnahmenliste. Der entscheidende Schritt ist die Überführung in eine priorisierte Tabelle nach Aufwand und Wirkung: kritische Fehler wie 404-Seiten mit hohem internen Linkaufkommen oder fehlende Canonicals auf Top-Kategorien zuerst, kosmetische Meta-Description-Lücken auf Long-Tail-Seiten zuletzt. Screaming Frog liefert dafür mit Crawl Analysis und dem Overview-Tab bereits eine erste automatische Priorisierung nach Fehlertyp und Häufigkeit.

In der Praxis bewährt sich ein gemeinsames Google Sheet mit Spalten für Befund, betroffene URL-Anzahl, geschätzter Traffic-Impact aus der GSC-Integration und Verantwortlichkeit. So wird aus einer technischen Rohdatenliste ein Backlog, das Entwicklung und SEO gemeinsam abarbeiten können, mit klarer Nachverfolgung, welche Punkte im nächsten Crawl tatsächlich behoben wurden.

8. Integration mit Google Search Console und Analytics APIs

Unter Configuration > API Access verbindet Screaming Frog den Crawl direkt mit der Google Search Console API und Google Analytics 4. Jede gecrawlte URL wird dadurch automatisch mit echten Klicks, Impressionen, CTR und Position angereichert - Daten, die sich in keinem reinen Crawl finden lassen, aber für die Priorisierung entscheidend sind. Eine Seite mit technischem Fehler und hohem Klickvolumen verdient sofortige Aufmerksamkeit, eine fehlerhafte Seite ohne jeden Traffic kann meist warten.

Die GA4-Integration deckt zusätzlich verwaiste Seiten auf: URLs, die in Analytics Traffic verzeichnen, aber im Crawl keine oder kaum interne Links erhalten, sowie umgekehrt gecrawlte Seiten ganz ohne jeden Traffic. Beide Muster deuten auf strukturelle Navigationsprobleme hin, die ohne die kombinierte Sicht aus Crawl- und Analytics-Daten unentdeckt blieben.

{
  "api_access": {
    "google_search_console": {
      "auth_type": "oauth2",
      "property": "https://shop.example.com/",
      "date_range_days": 90,
      "sync_fields": ["clicks", "impressions", "ctr", "position"]
    },
    "google_analytics_4": {
      "auth_type": "oauth2",
      "property_id": "properties/123456789",
      "metrics": ["sessions", "conversions", "engagementRate"]
    }
  },
  "crawl_join": {
    "match_on": "url",
    "purpose": "Verify orphaned URLs with GSC clicks and zero internal links"
  }
}

9. Wiederkehrende Crawls planen und Ergebnisse über Zeit vergleichen

Ein einmaliger Audit-Crawl beschreibt nur eine Momentaufnahme. Der eigentliche Wert entsteht durch wiederkehrende Crawls, die nach jedem Deployment oder mindestens wöchentlich laufen. Screaming Frogs eingebauter Scheduling-Task oder ein per Cron gesteuertes CLI-Skript erledigen das automatisiert, inklusive Export der relevanten Tabs als CSV in ein Archiv mit Zeitstempel, ohne dass jemand den Crawl manuell anstoßen muss.

Der Compare-Modus von Screaming Frog stellt zwei Crawls direkt gegenüber und markiert neue 404-Fehler, geänderte Title-Tags, verlorene Canonicals oder gesunkene Wortanzahl automatisch. Damit lassen sich Regressionen nach einem fehlerhaften Release erkennen, bevor Google die betroffenen Seiten erneut crawlt und Rankingverluste in der Search Console sichtbar werden - ein entscheidender Zeitvorsprung gegenüber rein reaktivem Monitoring.

#!/bin/bash
# Scheduled crawl every Monday at 03:00 via cron, diffed against the previous run
# Crontab entry: 0 3 * * 1 /opt/seo/crawl-and-diff.sh

TODAY=$(date +%F)
PREV=$(ls -1 /audits | tail -n 1)

screamingfrogseospider --crawl "https://shop.example.com/" \
  --headless --config "magento-audit.seospiderconfig" \
  --output-folder "/audits/${TODAY}" \
  --bulk-export "Response Codes:All,Canonicals:All,Hreflang:All" \
  --save-crawl

# Compare today's response codes export against the previous crawl to flag regressions
diff "/audits/${PREV}/response_codes_all.csv" "/audits/${TODAY}/response_codes_all.csv" \
  > "/audits/${TODAY}/regressions.diff"

mail -s "Screaming Frog Audit ${TODAY}: Regressionen" seo@mironsoft.de < "/audits/${TODAY}/regressions.diff"

Screaming-Frog-Einstellungen im direkten Vergleich

Viele Audit-Fehler entstehen nicht durch fehlendes SEO-Wissen, sondern durch eine falsche Grundkonfiguration des Crawlers selbst. Die folgende Übersicht zeigt die häufigsten Fehlkonfigurationen und ihre korrekte Einstellung.

In der Praxis verstärken sich diese Einstellungen gegenseitig: Ein zu großzügiges Crawl-Limit ohne Exclude-Regeln füllt den Datenbankmodus mit tausenden wertlosen Facetten-URLs, bevor überhaupt eine einzige echte Produktseite geprüft wurde. Wer die Tabelle als Checkliste vor jedem Audit durchgeht, spart Stunden an Nachbereinigung der Exportdaten.

10. Zusammenfassung

Screaming Frog entfaltet seinen vollen Wert erst mit einer Crawl-Konfiguration, die auf die Größe und Struktur eines Magento-Shops zugeschnitten ist: sinnvolle Crawl-Limits, Database Storage Mode für große Kataloge, gezieltes JS-Rendering und Exclude-Regeln gegen die URL-Explosion durch Facettennavigation. Die zentralen Reports zu Response Codes, Titles, Canonicals und Hreflang liefern dabei nicht nur Rohdaten, sondern über Filter wie Inlinks-Anzahl und Duplicate Details eine klare Priorisierung, welche Probleme zuerst behoben werden müssen.

Der eigentliche Unterschied zwischen einem einmaligen Audit und nachhaltiger technischer SEO liegt in der Wiederholung: geplante Crawls, ein Vergleich gegen den vorherigen Lauf und die Anreicherung mit Search-Console- und Analytics-Daten machen aus Screaming Frog kein Einmal-Werkzeug, sondern ein kontinuierliches Frühwarnsystem für Regressionen nach jedem Deployment.

11. FAQ: Screaming Frog für technische SEO-Audits