Crawl-Budget-Management

Das Crawl-Budget ist die Kombination aus zwei Faktoren: dem Crawl-Rate-Limit (wie viele Anfragen pro Sekunde Googlebot an Ihren Server stellen kann, ohne ihn zu überlasten) und der Crawl-Nachfrage (wie sehr Google Ihre Website crawlen möchte, basierend auf Popularität und Aktualität). Zusammen bestimmen sie die Gesamtzahl der Seiten, die Googlebot in einem bestimmten Zeitraum crawlt.

Für kleine Shops mit weniger als 5.000 Seiten ist das Crawl-Budget selten ein Problem. Google wird Ihre gesamte Website regelmäßig ohne Probleme crawlen. Aber sobald Ihr Shop 10.000 URLs überschreitet (einschließlich Parametervariationen, Filterseiten und paginierte Listen), wird das Crawl-Budget zu einem echten Engpass.

Ein mittelgroßer Modeshop, den wir auditiert haben, hatte 8.000 tatsächliche Produkte, aber über 340.000 crawlbare URLs aufgrund facettierter Navigation, Farb-/Größenparameter, Sortierungsvariationen und Paginierung. Googlebot verbrachte 85 % seines Crawl-Budgets mit diesen wertlosen Parameterseiten, während 30 % der tatsächlichen Produktseiten seit über 90 Tagen nicht mehr gecrawlt worden waren.

Crawl-Verschwendung tritt auf, wenn Googlebot Zeit damit verbringt, Seiten zu crawlen, die keinen SEO-Wert bieten. Im Ecommerce sind die größten Quellen facettierte Navigations-URLs, Parameterseiten, interne Suchergebnisseiten und übermäßige Paginierung.

Facettierte Navigation ist der größte Übeltäter. Eine Kategorieseite mit Filtern für Marke, Farbe, Größe, Preis und Bewertung kann Tausende von URL-Kombinationen erzeugen. Jede Kombination (/schuhe?marke=nike&farbe=schwarz&groesse=10) ist eine separate crawlbare URL, die typischerweise die gleichen Produkte in leicht unterschiedlicher Anordnung zeigt. Google muss nicht alle davon crawlen.

Sortierparameter verschwenden Crawl-Budget unauffällig. URLs wie /kategorie?sort=preis-aufsteigend, /kategorie?sort=preis-absteigend, /kategorie?sort=neueste und /kategorie?sort=beliebteste zeigen alle die gleichen Produkte. Diese Seiten fügen keinerlei einzigartigen Content hinzu, können aber Ihre crawlbare URL-Anzahl verdreifachen oder vervierfachen.

Session-IDs und Tracking-Parameter an URLs (/produkt?utm_source=email&session=abc123) erzeugen doppelte crawlbare Versionen jeder Seite. Wenn Ihre Plattform diese Parameter anhängt und sie nicht mit Canonical-Tags behandelt, vervielfachen Sie Ihre Crawl-Oberfläche unnötig.

Das primäre Werkzeug zur Vermeidung von Crawl-Verschwendung ist die robots.txt. Durch das Blockieren bestimmter URL-Muster teilen Sie Googlebot mit, diese Seiten nicht zu crawlen. Für Ecommerce bedeutet das typischerweise die Blockierung facettierter Filterparameter, Sortierungen, interner Suchergebnisse und Warenkorb-/Checkout-Seiten.

Eine praktische robots.txt für einen Ecommerce-Shop könnte Regeln wie Disallow: /*?sort=, Disallow: /*?filter=, Disallow: /search und Disallow: /cart enthalten. Diese Regeln verhindern, dass Googlebot Crawl-Budget für Seiten verschwendet, die nie in Suchergebnissen erscheinen sollten.

Seien Sie vorsichtig mit robots.txt-Blockierung. Sie verhindert Crawling, nicht Indexierung. Wenn andere Seiten auf eine blockierte URL verlinken, kann Google sie möglicherweise trotzdem basierend auf Ankertext und Linkkontext indexieren, auch ohne die Seite selbst zu crawlen. Für Seiten, die Sie komplett aus dem Index ausschließen möchten, kombinieren Sie robots.txt-Blockierung mit noindex Meta-Tags oder Canonical-Tags.

Ein weiterer Ansatz ist die Nutzung des URL-Parameter-Tools in der Google Search Console, um Google mitzuteilen, wie bestimmte Parameter den Seiteninhalt beeinflussen. Sie können angeben, ob ein Parameter wie "sort" den Inhalt ändert und ob Google alle, einige oder keine URLs mit diesem Parameter crawlen soll. Dies gibt Ihnen granulare Kontrolle, ohne Ihre robots.txt zu ändern.

Die Google Search Console bietet einen Crawl-Statistik-Bericht unter Einstellungen, der zeigt, wie Googlebot mit Ihrer Website interagiert. Dieser Bericht zeigt die gesamten Crawl-Anfragen, die durchschnittliche Antwortzeit, die Aufschlüsselung der Crawl-Anfragen nach Antworttyp und den Crawl-Zweck (Entdeckung vs. Aktualisierung).

Achten Sie auf die Aufschlüsselung der Antwortcodes. Wenn ein erheblicher Prozentsatz der Crawl-Anfragen 301/302-Weiterleitungen, 404-Fehler oder 5xx-Serverfehler zurückgibt, verschwenden Sie Crawl-Budget mit defekten oder weitergeleiteten URLs. Eine gesunde Ecommerce-Website sollte bei 90 % oder mehr der Crawl-Anfragen einen 200-Statuscode zurückgeben.

Die Dateityp-Aufschlüsselung zeigt, ob Googlebot unverhältnismäßig viel Zeit mit dem Herunterladen von Bildern, CSS, JavaScript oder anderen Ressourcen verbringt. Wenn JavaScript-Dateien Ihre Crawl-Anfragen dominieren, kann das auf Rendering-Probleme hinweisen, die Googlebot zu zusätzlichen Anfragen zwingen.

Vergleichen Sie Ihre Crawl-Statistiken von Monat zu Monat. Ein plötzlicher Rückgang der Crawl-Anfragen kann auf Server-Performance-Probleme oder robots.txt-Änderungen hinweisen, die zu viel blockiert haben. Ein plötzlicher Anstieg könnte bedeuten, dass Google eine neue Charge von Parameter-URLs entdeckt hat oder eine Sitemap-Änderung zuvor versteckte Seiten offengelegt hat. Beide Szenarien erfordern Untersuchung.

Wie Ihr Shop Seiten rendert, beeinflusst direkt die Crawl-Effizienz. Client-seitig gerenderte (CSR) Seiten mit JavaScript-Frameworks wie React oder Vue erfordern von Googlebot mehrere Anfragen: zuerst zum Herunterladen der HTML-Hülle, dann zum Abrufen und Ausführen des JavaScripts und schließlich zum Rendern des Seiteninhalts. Dieser Prozess ist langsamer und verbraucht mehr Crawl-Budget pro Seite.

Server-seitiges Rendering (SSR) liefert vollständig gerendertes HTML bei der ersten Anfrage, sodass Googlebot den Seiteninhalt sofort verstehen kann. Für Ecommerce-Seiten führt SSR oder Static Site Generation (SSG) typischerweise dazu, dass 40 % bis 60 % mehr Seiten pro Crawl-Sitzung gecrawlt werden im Vergleich zu CSR-Äquivalenten.

Shopify-Shops werden standardmäßig serverseitig gerendert, daher ist dies für Shopify-Händler selten ein Problem. Aber Shops auf Headless-Architekturen mit React/Next.js oder Vue/Nuxt.js müssen sicherstellen, dass ihre SSR-Implementierung korrekt funktioniert. Wir haben Headless-Shops gesehen, bei denen ein falsch konfiguriertes SSR-Setup dazu führte, dass Googlebot leere Produktseiten sah, was zur Massendeindexierung führte.

Testen Sie, wie Google Ihre Seiten sieht, mit dem URL-Inspektionstool in der GSC. Klicken Sie auf "Getestete Seite ansehen", um sowohl die HTML-Rohantwort als auch das gerenderte HTML zu sehen. Wenn der gerenderten Version Produktinformationen, Preise oder Bewertungen fehlen, braucht Ihr Rendering-Setup Aufmerksamkeit.

Über das Blockieren wertloser Seiten hinaus können Sie Googlebot aktiv auf Ihre wichtigsten Inhalte lenken. Interne Verlinkung ist das stärkste Signal für Crawl-Priorität. Seiten mit mehr internen Links werden häufiger gecrawlt und schneller nach Aktualisierungen.

Halten Sie Ihre XML-Sitemap schlank und aktuell. Nehmen Sie nur Seiten auf, die Sie tatsächlich indexiert haben möchten: Produktseiten, Kategorieseiten, wichtige Blogbeiträge und wesentliche Informationsseiten. Entfernen Sie ausverkaufte Produkte (oder leiten Sie sie um), noindexed Seiten und Parameter-URLs aus Ihrer Sitemap. Eine Sitemap mit 5.000 wichtigen URLs schlägt eine mit 50.000 URLs, von denen 90 % Müll sind.

Aktualisieren Sie die lastmod-Daten Ihrer Sitemap genau. Wenn Sie den Preis, die Beschreibung oder die Verfügbarkeit einer Produktseite aktualisieren, sollte das lastmod-Datum die Änderung widerspiegeln. Googlebot nutzt lastmod als Signal für die Recrawl-Priorität. Wir haben Shops gesehen, die alle lastmod-Daten auf denselben Wert gesetzt haben (oder das heutige Datum für jede Seite verwenden), was das Signal zerstört und Google dazu bringt, lastmod komplett zu ignorieren.

Für zeitkritische Änderungen wie Sales, Preissenkungen oder neue Produkteinführungen können Sie die Indexing API (für berechtigte Seitentypen) nutzen oder manuell eine Indexierung über das URL-Inspektionstool der GSC anfordern. Das ist keine skalierbare Lösung für Tausende von Seiten, funktioniert aber gut für einzelne Seiten mit hoher Priorität.