Crawl-Budget optimieren: Wie Google große Kataloge effizient crawlt

1. Was ist Crawl-Budget? Definition nach Google

Google definiert Crawl-Budget in der eigenen Dokumentation (Search Central) nicht als einzelne Kennzahl, sondern als Zusammenspiel zweier Faktoren: der Crawl-Rate-Limit und der Crawl-Demand. Für die meisten kleinen bis mittleren Websites ist Crawl-Budget laut Google kein relevantes Thema, weil Googlebot ohnehin alle wichtigen Seiten zeitnah erfasst. Google nennt selbst zwei Schwellenwerte, ab denen sich Crawl-Budget-Optimierung lohnt: Websites mit mehr als etwa einer Million eindeutigen Seiten, oder Websites mit mehr als 10.000 Seiten, die sich häufig ändern. Ein Magento-Shop mit einigen tausend Produkten, aber facettierter Navigation, überschreitet diese Schwelle oft unbemerkt, weil die Zahl crawlbarer URLs durch Filterkombinationen ein Vielfaches der echten Produktseiten beträgt.

Der praktische Effekt von limitiertem Crawl-Budget zeigt sich selten als komplette Nichterfassung von Seiten, sondern als Verzögerung: Neue Produkte werden später entdeckt, aktualisierte Preise oder Verfügbarkeiten später übernommen, und Änderungen an wichtigen Kategorieseiten brauchen länger, bis sie in den Suchergebnissen ankommen. Für Shops mit saisonalem Sortiment oder häufigen Preisänderungen ist das ein direkter Umsatzverlust, weil Google veraltete Informationen ausliefert oder neue Produkte schlicht zu spät indexiert.

2. Crawl Rate Limit vs. Crawl Demand im Detail

Die Crawl-Rate-Limit ist die technische Obergrenze: wie viele parallele Verbindungen und wie viele Anfragen pro Sekunde Googlebot an einen Server schickt, ohne ihn zu überlasten. Diese Grenze passt sich dynamisch an die Server-Antwortzeiten an. Antwortet der Server schnell und stabil mit niedrigen Fehlerraten, erhöht Googlebot die Rate schrittweise. Steigen Antwortzeiten oder häufen sich 5xx-Fehler, senkt Googlebot die Crawl-Rate sofort und teils über mehrere Tage spürbar. Ein Magento-Shop mit langsamer Time to First Byte oder häufigen 503-Fehlern unter Last limitiert sich damit selbst, unabhängig davon, wie viele Ressourcen der Server eigentlich zur Verfügung hätte.

Die Crawl-Demand ist die inhaltliche Seite: wie sehr Google eine URL überhaupt crawlen möchte, basierend auf wahrgenommener Popularität, Aktualität und dem Verhältnis zwischen bekannten und tatsächlich wertvollen URLs. Enthält ein Shop viele nahezu identische Filter-URLs ohne eigenständigen Inhalt, sinkt die durchschnittliche Crawl-Demand pro URL, weil Google aus Erfahrung lernt, dass ein großer Anteil der URLs eines Hosts keinen neuen Inhalt liefert. Dieser Lerneffekt wirkt sich negativ auf den gesamten Host aus, nicht nur auf die betroffenen Filter-URLs, und ist einer der Hauptgründe, warum Crawl-Budget-Probleme bei Magento-Katalogen strukturell entstehen.

3. Crawl Stats Report in der Google Search Console nutzen

Der Crawl Stats Report in der Google Search Console, erreichbar unter Einstellungen und Crawling-Statistiken, liefert die wichtigste Datenquelle für eine erste Einschätzung, ohne Server-Zugriff zu benötigen. Er zeigt die Gesamtzahl der Crawl-Anfragen der letzten 90 Tage, die durchschnittliche Antwortzeit und eine Aufschlüsselung nach Antwortcode, Dateityp, Crawl-Zweck (Entdeckung neuer URLs versus Aktualisierung bekannter URLs) und Googlebot-Typ. Ein hoher Anteil an Aktualisierungsanfragen gegenüber Entdeckungsanfragen bei gleichzeitig stagnierender Zahl neu indexierter Seiten ist ein starkes Indiz dafür, dass Googlebot Zeit mit wiederholtem Crawlen bekannter, aber wenig wertvoller URLs verbringt statt neue Inhalte zu finden.

Der Report zeigt zusätzlich Beispiel-URLs je Kategorie, was eine erste grobe Zuordnung erlaubt, aber keine vollständige URL-Liste ersetzt. Steigt die Antwortzeit über 90 Tage kontinuierlich an, sollte das nicht ignoriert werden: Ein steigender Trend allein reicht Google, um die Crawl-Rate-Limit vorsorglich zu senken, noch bevor tatsächliche Serverprobleme auftreten. Der Report ist ein guter Startpunkt, ersetzt aber keine echte Logfile-Analyse, weil er aggregiert und mit Verzögerung berichtet.

# Query the Search Console URL Inspection API for a specific low-value filter URL
curl -s -X POST \
  "https://searchconsole.googleapis.com/v1/urlInspection/index:inspect" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "inspectionUrl": "https://shop.example.com/damen/kleider.html?farbe=rot&groesse=m",
    "siteUrl": "https://shop.example.com/"
  }' | jq '.inspectionResult.indexStatusResult'

# Loop through a list of suspected crawl-waste URLs and log their coverage state
while read -r url; do
  echo "Checking: $url"
  curl -s -X POST "https://searchconsole.googleapis.com/v1/urlInspection/index:inspect" \
    -H "Authorization: Bearer ${ACCESS_TOKEN}" -H "Content-Type: application/json" \
    -d "{\"inspectionUrl\":\"${url}\",\"siteUrl\":\"https://shop.example.com/\"}" \
    | jq -r '.inspectionResult.indexStatusResult.coverageState'
done < suspected-filter-urls.txt

4. Server-Logfiles analysieren: Crawl-Verschwendung aufdecken

Die Search Console zeigt aggregierte Trends, aber keine vollständige URL-für-URL-Aufschlüsselung. Nur die rohen Server-Logfiles zeigen exakt, welche URL wie oft von welchem verifizierten Googlebot-Client wann angefragt wurde, inklusive Statuscode und Antwortzeit pro Anfrage. Wichtig ist die Verifikation: Der User-Agent-String "Googlebot" lässt sich fälschen, deshalb muss jede IP-Adresse per Reverse-DNS-Lookup gegen die offiziellen Google-IP-Bereiche geprüft werden, bevor eine Anfrage als echter Googlebot-Traffic gezählt wird. Tools wie der Screaming Frog Log File Analyser, JetOctopus oder Botify übernehmen diese Verifikation automatisch und aggregieren die Treffer nach URL-Mustern.

In der Praxis reicht für einen ersten Überblick oft schon eine Kombination aus grep und awk auf den rohen Zugriffslogs, um Anfragen nach User-Agent zu filtern und nach URL-Pfad oder Query-Parameter zu gruppieren. Entscheidend ist, nicht nur die Top-URLs nach Anfragehäufigkeit zu betrachten, sondern gezielt nach einzelnen Query-Parametern zu gruppieren, denn genau dort verstecken sich die größten Mengen an Crawl-Anfragen auf technisch unterschiedliche, inhaltlich aber identische URLs.

# Filter genuine Googlebot requests from an nginx access log and count hits per URL path
grep -i "Googlebot" /var/log/nginx/access.log \
  | awk -F'"' '{print $2}' \
  | awk '{print $2}' \
  | cut -d'?' -f1 \
  | sort | uniq -c | sort -rn | head -30

# Isolate requests that carry query parameters (typical crawl waste candidates)
grep -i "Googlebot" /var/log/nginx/access.log \
  | awk -F'"' '{print $2}' \
  | awk '{print $2}' \
  | grep -oE '\?[a-zA-Z0-9_=&%-]+' \
  | awk -F'&' '{for(i=1;i<=NF;i++) print $i}' \
  | cut -d'=' -f1 \
  | sort | uniq -c | sort -rn

# Verify a client IP is a genuine Googlebot via reverse DNS before trusting the log line
host 66.249.66.1

5. Facettierte Navigation als Crawl-Falle

Facettierte Navigation ist der häufigste Crawl-Budget-Killer in Magento-Shops, weil sie eine kombinatorische Explosion an URLs erzeugt. Bietet eine Kategorie fünf Filterattribute mit jeweils sechs Werten an, ergeben sich theoretisch bis zu 6 hoch 5, also über 7.700 Kombinationen, allein für diese eine Kategorie, sofern jede Kombination als eigene crawlbare URL existiert. Die meisten dieser Kombinationen liefern kein einzigartiges Sortiment, sondern eine leere oder nahezu identische Ergebnisliste im Vergleich zu benachbarten Filterkombinationen, was aus Sicht von Google klassischer Duplicate Content beziehungsweise Thin Content ist.

Google selbst nennt facettierte Navigation in der eigenen Crawling-Dokumentation ausdrücklich als Beispiel für unbeabsichtigte "Crawler-Fallen", die durch relative URLs, Session-Parameter oder nahezu unendliche Filterkombinationen entstehen. Ein Magento-Standardlayout ohne Anpassung generiert für jede Filterkombination einen eigenen, in HTML verlinkten Link, den Googlebot findet und crawlt, selbst wenn kein Nutzer jemals aktiv nach genau dieser Kombination sucht. Ohne Gegensteuerung wächst diese URL-Menge nicht linear, sondern potenziell mit jedem zusätzlichen Filterattribut.

<!-- Category page with two active layered navigation filters -->
<!-- URL: https://shop.example.com/damen/kleider.html?farbe=blau&groesse=38 -->
<link rel="canonical" href="https://shop.example.com/damen/kleider.html">

<!-- Only canonicalize to the base category if the filtered view has no
     unique content value. If a specific filter combination has real
     search demand and should stay indexable, use a self-referencing
     canonical instead of pointing back to the base category. -->

6. Magento-Parameter reduzieren: Pagination, Sortierung, Store-Switcher

Neben der Filterkombinatorik erzeugt Magento eine Reihe systemeigener Query-Parameter, die zusätzliches Crawl-Volumen ohne SEO-Wert verursachen. Die Paginierung über "?p=2", "?p=3" und so weiter erzeugt für jede Kategorieseite mehrere zusätzliche URLs, von denen besonders tief liegende Seiten wie "?p=15" kaum noch relevante Produkte enthalten. Die Sortierparameter "product_list_order" und "product_list_dir" erzeugen für dieselbe Produktmenge beliebig viele URL-Varianten, die sich nur in der Reihenfolge unterscheiden, inhaltlich aber vollständig identisch sind. Der Store-Switcher-Parameter "___store=" taucht auf, sobald interne Links ohne konsequente URL-Bereinigung erzeugt werden, und multipliziert jede betroffene URL um die Zahl der konfigurierten Store-Views.

Auch interne Suchergebnisseiten unter "/catalogsearch/result/?q=" werden von Magento standardmäßig crawlbar und teilweise indexierbar ausgeliefert, obwohl sie strukturell Thin Content darstellen und je nach eingegebenem Suchbegriff beliebig viele Varianten erzeugen. Der Parameter "product_list_limit=" für die Anzahl angezeigter Produkte pro Seite verhält sich analog zu den Sortierparametern: gleicher Inhalt, andere URL. In Summe erzeugen allein diese systemeigenen Parameter oft mehr Crawl-Volumen als die eigentliche Filterkombinatorik, weil sie auf jeder einzelnen Kategorieseite des Shops greifen.

<!-- catalogsearch_result_index.xml: keep internal search results out of the
     index without blocking Googlebot from crawling them entirely -->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <head>
        <meta name="robots" content="noindex,follow"/>
    </head>
</page>

7. Interne Verlinkung und Seitenarchitektur für Crawl-Effizienz

Die Seitenarchitektur bestimmt, wie effizient Googlebot ein gegebenes Crawl-Budget über die tatsächlich wichtigen Seiten verteilt. Eine flache Kategoriestruktur mit maximal drei bis vier Klicks von der Startseite zu jeder Produktseite sorgt dafür, dass PageRank und Crawl-Priorität gleichmäßig verteilt werden. Tief verschachtelte Kategoriebäume mit fünf oder mehr Ebenen verdünnen diesen Effekt: Produkte in tiefen Unterkategorien werden seltener gecrawlt und seltener aktualisiert, selbst wenn sie inhaltlich genauso relevant sind wie Produkte in flachen Kategorien.

Verwaiste Seiten, also Produkte oder Landingpages, die ausschließlich über die XML-Sitemap erreichbar sind, aber über keinen einzigen internen Link verfügen, werden von Google strukturell schlechter bewertet und seltener erneut besucht, selbst wenn sie initial indexiert wurden. Paginierungsketten in Kategorien mit vielen Produkten verstärken das Problem zusätzlich: Googlebot besucht die erste Ergebnisseite regelmäßig, verliert aber mit jeder weiteren Seite an Priorität, sodass Produkte auf Seite acht oder neun faktisch von der Crawl-Frequenz der Startseite abgekoppelt sind. Konsequente Querverlinkung zwischen verwandten Produkten und Kategorien sowie eine begrenzte Klicktiefe sind die wirksamsten strukturellen Gegenmaßnahmen.

8. Praktische Maßnahmen: robots.txt, Canonical, Noindex

Die drei zentralen technischen Werkzeuge gegen Crawl-Budget-Verschwendung sind robots.txt, Canonical-Tags und Noindex, und sie lösen unterschiedliche Probleme. robots.txt verhindert das Crawlen bestimmter URL-Muster von vornherein und eignet sich für Parameter, die garantiert keinen SEO-Wert haben, etwa Session-IDs oder den Store-Switcher-Parameter. Wichtig dabei: Eine per robots.txt blockierte URL kann trotzdem in den Suchergebnissen auftauchen, wenn sie extern verlinkt wird, allerdings ohne Snippet und ohne dass Google den Inhalt kennt, was in seltenen Fällen zu einem unschönen Ergebnis-Eintrag ohne Beschreibung führt.

Canonical-Tags eignen sich für Filterkombinationen, die inhaltlich eine Teilmenge der Basiskategorie darstellen und weiterhin gecrawlt werden dürfen, deren Rankingsignale aber auf die Basis-URL gebündelt werden sollen. Noindex ist die richtige Wahl für Seiten, die gecrawlt werden dürfen, aber definitiv nicht im Suchindex erscheinen sollen, etwa interne Suchergebnisseiten. Wichtig ist, robots.txt und Noindex niemals gleichzeitig auf dieselbe URL anzuwenden: Eine per robots.txt blockierte Seite kann Googlebot gar nicht erst crawlen und damit auch das Noindex-Tag nicht lesen, wodurch die Seite trotz Noindex-Absicht im Index verbleiben kann.

User-agent: *
# Store-switcher and session parameters carry zero unique SEO value
Disallow: /*?*___store=
Disallow: /*?*___from_store=
Disallow: /*?*SID=

# Sort and display-mode parameters duplicate the same product set
Disallow: /*?*product_list_order=
Disallow: /*?*product_list_dir=
Disallow: /*?*product_list_mode=
Disallow: /*?*product_list_limit=

# Internal search result pages are handled via noindex,follow, not blocked here
Allow: /catalogsearch/result/

Sitemap: https://shop.example.com/sitemap.xml

9. Crawl-Budget-Fresser im Vergleich zur Lösung

Die folgende Übersicht ordnet die häufigsten Crawl-Budget-Fresser in Magento-Shops den jeweils passenden Gegenmaßnahmen zu, basierend auf dem typischen Anteil, den sie am gesamten Crawl-Volumen eines Shops einnehmen können.

In der Praxis wirken die Maßnahmen aus der Tabelle am stärksten in Kombination: robots.txt reduziert das Volumen an der Wurzel, Canonical bündelt verbleibende Signale, und eine bereinigte interne Verlinkung sorgt dafür, dass das freigewordene Crawl-Budget tatsächlich bei den wichtigen Produkt- und Kategorieseiten ankommt, statt erneut in Parametervarianten zu versickern.

10. Zusammenfassung

Crawl-Budget-Optimierung für Magento-Shops löst ein strukturelles Problem: Ohne Gegensteuerung wächst die Zahl crawlbarer URLs durch facettierte Navigation und systemeigene Parameter schneller als die Zahl tatsächlich wertvoller Seiten. Der Crawl Stats Report in der Search Console liefert den ersten Überblick, während eine echte Logfile-Analyse die genauen URL-Muster offenlegt, auf die Googlebot die meisten Anfragen verwendet. Erst mit dieser Datengrundlage lassen sich robots.txt, Canonical-Tags und Noindex gezielt statt pauschal einsetzen.

Der Effekt zeigt sich nicht sofort, sondern über Wochen: Sinkt das Crawl-Volumen auf wertlosen Parameter-URLs, verschiebt sich Googlebots Aufmerksamkeit spürbar zu neuen und aktualisierten Produktseiten, was sich in der Search Console an einer steigenden Zahl entdeckter und aktualisierter URLs ablesen lässt. Eine flache, konsequent verlinkte Seitenarchitektur verstärkt diesen Effekt zusätzlich, weil sie verhindert, dass sich das neu gewonnene Crawl-Budget erneut in tiefen Paginierungsketten oder verwaisten Seiten verliert.

11. FAQ: Crawl-Budget für Magento-Shops