Stand: März 2026 — Abgeglichen anhand der neuesten Google-Dokumentation zum Crawl Budget, gegengeprüft mit Gary Illyes’ Deep-Dive zum Crawl Budget von 2024 und getestet mit echten Server-Logdaten von SEOJuice-Kundenseiten.
TL;DR: Wenn Ihre Website weniger als 10.000 Seiten hat, ist das Crawl Budget sehr wahrscheinlich nicht Ihr Problem. Hören Sie auf, es zu optimieren. Aber wenn Sie einen E-Commerce-Shop mit 500K Produktseiten betreiben, eine Kleinanzeigen-Plattform mit unendlichen URL-Parametern oder irgendetwas mit Facettennavigation — dann tötet das Crawl Budget Ihr Indexing still und heimlich. Diese Anleitung zeigt, wie Sie diagnostizieren, ob Sie wirklich ein Crawl-Budget-Problem haben, und wie Sie es beheben, falls ja. Die Antwort ist meistens langweilig: schnellere Server, sauberere URLs, besseres robots.txt.
Ihr tatsächliches Crawl Budget ist das kleinere von diesen beiden. Wenn Google heute wirklich 50.000 Ihrer Seiten crawlen will (hohe Nachfrage), aber Ihr Server nur 5.000 Abrufe verarbeiten kann, ohne langsamer zu werden (niedrige Rate Limit), bekommen Sie 5.000. Wenn Ihr Server 100.000 Abrufe schafft, aber Google nur 2.000 Ihrer Seiten wirklich relevant findet (niedrige Nachfrage), bekommen Sie 2.000.
Genau hier machen die meisten Guides einen Fehler. Sie behandeln das Crawl Budget wie einen festen Pool, den Sie „sparen“ müssen, indem Sie unwichtige Seiten blockieren. In Wahrheit ist es dynamisch, ändert sich täglich — und bei den meisten Websites ist es überhaupt nicht der Engpass.
Ich muss das klar sagen, weil ich gesehen habe, wie Agenturen Crawl-Budget-Optimierung an Websites mit 200 Seiten verkaufen.
Wenn Ihre Seite weniger als etwa 10.000 eindeutige URLs hat, ist Crawl-Budget-Optimierung höchstwahrscheinlich Zeitverschwendung.
Gary Illyes hat das selbst mehrfach gesagt — unter anderem bei Google I/O und auf Twitter. Seine genaue Formulierung: „Wenn Ihre Website ein paar tausend URLs hat, wird sie in den meisten Fällen effizient gecrawlt.“ Martin Splitt, Googles Developer Advocate, hat das in einer JavaScript-SEO-Office-Hours-Folge aufgegriffen und gesagt, dass Crawl Budget erst dann wirklich „zum Thema wird, sobald man im Bereich von zehntausenden Seiten oder mehr landet“.
Google crawlt Milliarden von Seiten pro Tag. Ihr WordPress-Blog mit 500 Seiten ist ein Rundungsfehler. Google crawlt alles davon innerhalb weniger Tage — ohne dass Sie irgendetwas Spezielles tun müssen.
Wann Crawl Budget wirklich relevant ist:
Wenn nichts davon auf Sie zutrifft, springen Sie zum FAQ-Bereich unten und machen Sie mit Ihrem Leben weiter. Ernsthaft. Investieren Sie Ihre Zeit stattdessen in Content-Qualität und internes Linking. Ich glaube immer noch, dass das ein Punkt ist, den 90% derjenigen hören sollten, die „Crawl-Budget-Optimierung“ machen: Ihr Problem sitzt sehr wahrscheinlich ganz woanders.
2. Prüfen Sie Ihre Indexierungslücke. Vergleichen Sie die Anzahl der Seiten in Ihrer Sitemap mit der Anzahl der indexierten Seiten im GSC-„Pages“-Bericht. Wenn Sie 100.000 URLs in der Sitemap haben, aber nur 40.000 indexiert sind, dann verbraucht irgendetwas Ihr Crawl Budget, bevor es überhaupt bei den Seiten ankommt, die zählen.
3. Schauen Sie in die Server-Logs. Das ist die echte Diagnose. GSC liefert aggregierte Daten. Server-Logs liefern die Wahrheit — jede einzelne Anfrage, die Googlebot gemacht hat, wann, auf welche URL und mit welcher Antwort. Wenn Sie sehen, dass Googlebot 60% seines Crawls für paginierte Archivseiten oder gefilterte URLs ausgibt, dann ist das Ihr Problem — schwarz auf weiß.
Ich bin offen mit einer Einschränkung: Ich bin nicht sicher, dass der GSC-Crawl-Stats-Bericht immer verlässlich ist. Wir haben Abweichungen zwischen dem, was GSC meldet, und dem, was die Server-Logs unserer Kunden zeigen, gesehen. Manchmal deutlich — Lücken von 30–40%. Ich weiß nicht, ob das ein Sampling-Thema auf Googles Seite ist, ein Caching-Artefakt oder etwas anderes. Deshalb empfehle ich immer, bei hohen Einsätzen mit Server-Logs zu verifizieren.
| Diagnose-Signal | Gesund | Warnung | Kritisch |
|---|---|---|---|
| Neue Seite indexiert innerhalb von | 1-3 Tagen | 1-2 Wochen | 4+ Wochen oder nie |
| GSC Crawl-Anfragen/Tag vs. Gesamtseiten | > 50% der Seiten pro Woche gecrawlt | 10-50% pro Woche | < 10% pro Woche |
| Durchschnittliche Server-Antwortzeit | 200ms | 200-500ms | > 500ms |
| % Crawl auf nicht indexierbaren URLs | < 10% | 10-30% | > 30% |
| Redirect Chains im Crawl | Keine | 5% der Anfragen | > 5% treffen auf Chains |
| 5xx-Fehlerrate während des Crawls | 0% | 1% | > 1% |
Hinweis: Diese Schwellenwerte basieren auf Erfahrungswerten aus Mustern in den SEOJuice-Kundendaten und nicht auf offiziellen Zahlen, die Google veröffentlicht hat. Je nach Website-Größe, Nische und Serverarchitektur kann es Abweichungen geben.
Wenn die meisten Ihrer Signale in der Spalte „Gesund“ liegen, haben Sie kein Crawl-Budget-Problem. Optimieren Sie lieber etwas anderes.
Dieser Crawl-Budget-Faktor hat den höchsten Einfluss und bekommt am wenigsten Aufmerksamkeit. Jeder will über robots.txt und Sitemaps sprechen. Niemand will darüber sprechen, warum Ihr Server für eine einfache HTML-Anfrage 1,2 Sekunden braucht.
Googlebot ist höflich. Er überwacht Ihre Server-Antwortzeit in Echtzeit. Wenn Ihr Server langsamer wird, senkt Googlebot seine Crawl-Rate, um Sie nicht zu überlasten. Das ist Crawl-Rate-Limit in Aktion. Ein Server mit 100ms Antwortzeit wird deutlich stärker gecrawlt als einer, der 800ms braucht.
"If the site is really fast, Googlebot will be able to use more connections and crawl the site faster. If the site slows down or responds with server errors, it will slow down and crawl less."
— Gary Illyes, Senior Search Analyst, Google (Google Developers Blog)
Das ist ein direktes Zitat aus dem offiziellen Crawl-Budget-Blogpost. „Richtig schnell“ bedeutet für Google < 200ms bis zum Time to First Byte (TTFB). Nicht die Ladezeit der Seite — sondern TTFB. Also: Wie lange es dauert, bis Ihr Server anfängt, die HTML-Antwort zu senden.
Kurzfristige Quick Wins für die Server-Antwortzeit:
Bei einer SEOJuice-Kundenseite (Furniture-E-Commerce-Shop, grob 80K Produktseiten) haben wir beobachtet, wie die Crawl-Rate in GSC innerhalb von zwei Wochen von 15.000 Requests/Tag auf 3.000 fiel. Keine Änderungen an Content oder Struktur. Ursache? Ihr Hosting-Provider hat sie auf einen neuen Server-Cluster migriert und TTFB ging von 180ms auf 900ms. Nachdem sie das Hosting behoben hatten, erholte sich die Crawl-Rate innerhalb von vier Tagen. Keine robots.txt-Änderungen. Keine Sitemap-Updates. Nur schnellere Server.
URL-Parameter sind die häufigste Quelle für Crawl Waste. Und das Problem ist heimtückisch, weil man oft nicht merkt, dass es passiert.
Betrachten Sie einen E-Commerce-Shop mit Filtern. Ein Nutzer stöbert Schuhe, wählt aus: Größe 10, Farbe schwarz, Marke Nike, sortiert nach Preis, Seite 2. Das ist dann eine URL wie:
/shoes?size=10&color=black&brand=nike&sort=price&page=2Jetzt multiplizieren Sie das mit allen möglichen Kombinationen. 8 Größen, 12 Farben, 40 Marken, 4 Sortieroptionen, 50 Ergebnis-Seiten. Das ergibt: 8 × 12 × 40 × 4 × 50 = 768.000 URLs. Von einer Kategorie-Seite. Und der Content in den meisten dieser Seiten überschneidet sich stark — Größe 10 schwarz Nike-Schuhsortiert nach Preis ist größtenteils dasselbe wie Größe 10 schwarz Nike-Schuhsortiert nach „neueste“.
Googlebot weiß das nicht. Er sieht 768.000 eindeutige URLs und beginnt zu crawlen. Ihre echten Produktseiten — also die, die ranken sollen — sitzen in einer Warteschlange hinter hunderttausenden gefilterten Varianten, nach denen nie jemand suchen wird.
Das meinen Leute mit „Facettierte Navigation erzeugt Crawl Traps“. Es ist nicht so, dass Google in einer endlosen Schleife feststeckt (auch wenn das bei bestimmten Paginierungs-Setups passieren kann). Es ist so, dass Google sein begrenztes Crawl Budget auf URLs verteilt, die keinen echten Mehrwert liefern.
Ich möchte an dieser Stelle präzise sein: Das URL-Parameter-Tool in der Google Search Console wurde 2022 abgekündigt und entfernt. Google hatte früher die Möglichkeit, welche Parameter es ignorieren soll, vorzugeben. Diese Option ist weg. Stattdessen haben Sie jetzt drei Werkzeuge:
Jedes hat Trade-offs. Ich decke robots.txt und Canonicals weiter unten in eigenen Abschnitten ab.
Ihre robots.txt ist die erste Datei, die Googlebot prüft, bevor er Ihre Website crawlt. Gleichzeitig ist sie die am häufigsten missverstandene Datei im SEO. Entweder lässt man sie leer (verpasst eine Chance) oder man geht zu weit (blockiert Dinge, die man nicht blockieren sollte).
Die entscheidende Grundregel: Blocken Sie Dinge, die Crawl Budget verschwenden, nicht Dinge, die „unwichtig“ sind. Das ist ein Unterschied. Eine „unwichtige“ Seite muss möglicherweise trotzdem indexiert werden. Eine Seite, die Crawl Budget verschwendet, liefert keinen einzigartigen Suchwert und existiert nur in Tausenden von Parameter-Variationen.
# Block faceted navigation parameters
User-agent: *
Disallow: /*?sort=
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*&sort=
Disallow: /*&color=
Disallow: /*&size=
# Block internal search results
Disallow: /search?
Disallow: /search/
# Block session-based URLs
Disallow: /*?sessionid=
Disallow: /*?ref=
# Block admin, cart, and account pages
Disallow: /admin/
Disallow: /cart/
Disallow: /my-account/
Disallow: /checkout/
# Block print and PDF versions
Disallow: /*?print=
Disallow: /*?format=pdf
# DO NOT block CSS, JS, or images
# Googlebot needs these to render your pages
Allow: /*.css
Allow: /*.js
Allow: /*.jpg
Allow: /*.png
Allow: /*.webp
Sitemap: https://example.com/sitemap.xmlSchwere Fehler, die ich gesehen habe:
/products/, weil er /products?filter= blockieren will — und indexiert aus Versehen seinen gesamten Katalog ab.Punkt Nummer drei lohnt sich zu wiederholen, weil er auch erfahrene SEOs erwischt. Robots.txt blockiert Crawling. Sie blockiert kein Indexing. Wenn Sie Indexierung verhindern wollen, nutzen Sie <meta name="robots" content="noindex"> oder einen X-Robots-Tag als HTTP-Header. Aber denken Sie daran: Damit Google einen noindex-Tag sieht, muss es die Seite zuerst crawlen. Wenn Sie also Crawling per robots.txt blockieren UND noindex hinzufügen, wird Google den noindex-Tag nie sehen. Das erzeugt ein Paradox, das Menschen seit Jahren verwirrt.
Eine Sitemap garantiert kein Indexing. Sie garantiert nicht einmal Crawling. Was sie macht: Google einen Hinweis geben, welche URLs existieren, wann sie zuletzt geändert wurden und (zumindest diskutierbar) wie wichtig sie im Verhältnis zueinander sind.
Die Fehler, die Menschen mit Sitemaps machen, liegen fast immer darin, zu viel aufzunehmen — nicht zu wenig.
Was Sie in Ihre Sitemap aufnehmen sollten:
<lastmod>-Daten — nicht das aktuelle Datum, nicht das gleiche Datum auf jeder Seite, sondern das echte Datum der letzten ÄnderungWas Sie aus Ihrer Sitemap ausschließen sollten:
Ich habe Sitemaps mit 500.000 URLs gesehen, bei denen tatsächlich nur 80.000 indexierbar waren. Die anderen 420.000 waren Redirects, noindexed-Seiten, Parameter-Variationen und kaputte URLs. Diese Sitemap hilft Google nicht — sie schickt es auf eine Schatzsuche, bei der 84% der Karte falsch sind.
Martin Splitt hat <lastmod> als „eines der am häufigsten missbrauchten Tags in Sitemaps“ bezeichnet, weil so viele CMS-Plattformen es auf das aktuelle Datum für jede Seite setzen. Wenn jede Seite sagt „Ich wurde gerade erst geändert“, lernt Google, dieses Signal komplett zu ignorieren. Wenn Ihr CMS keine echten Änderungsdaten trackt, fixen Sie das, bevor Sie sich mit anderen Sitemap-Themen beschäftigen.
Ich widme der Facettennavigation einen eigenen Abschnitt, weil sie die Schnittstelle aus Crawl Budget, Duplicate Content und technischer Architektur ist — und wenn man sie falsch angeht, kann es das SEO einer Seite still über Monate hinweg ruinieren.
Das Problem: Facettierte Navigation (Filter in E-Commerce, Kleinanzeigen, Jobbörsen) erzeugt exponentiell viele URL-Kombinationen. Die Mathematik haben wir oben gesehen. Aber die Lösung ist nicht so simpel wie „alles mit robots.txt blockieren“, denn einige facettierte Seiten haben echten Suchwert.
Denk dran: „Nike-Laufschuhe Größe 10“ ist eine echte Suchanfrage, die eine echte Person in Google eingibt. Eine facettierte Seite, die dazu passt, könnte dafür ranken. Alle facettierten URLs zu blockieren bedeutet, diese Chance zu verlieren.
Das Framework, das ich empfehle (und das wir für SEOJuice-Kunden mit genau diesem Problem umsetzen):
| Facet-Typ | Beispiel | Suchwert | Empfohlener Ansatz |
|---|---|---|---|
| Kategorie + Marke | /shoes/nike/ | Hoch — Leute suchen nach Marke+Kategorie | Indexieren, in Sitemap aufnehmen, saubere URL nutzen |
| Kategorie + 1 Filter | /shoes?color=black | Mittel — hängt vom Suchvolumen ab | Suchvolumen prüfen. Indexieren, wenn >100 monatliche Suchanfragen, sonst canonical auf Parent |
| Kategorie + 2+ Filter | /shoes?color=black&size=10 | Niedrig — für die meisten Suchanfragen zu spezifisch | Canonical auf den einzelnen relevantesten Filter oder auf die Parent-Kategorie |
| Sortier-Variationen | /shoes?sort=price-asc | Keiner — niemand sucht nach „Schuhe sortiert nach Preis“ | Mit robots.txt blockieren oder noindex |
| Paginierung tiefe Seiten | /shoes?page=47 | Keiner — ab Seite 2-3 wird’s meist uninteressant | Noindex ab Seite 3-5, aber crawlbar lassen |
| Session-/Tracking-Parameter | /shoes?utm_source=email | Keiner | Mit robots.txt blockieren, auf Server-Ebene entfernen |
So sieht die Implementierung des Canonical-Tags für Multi-Filter-Seiten aus:
<!-- On /shoes?color=black&size=10&sort=price -->
<link rel="canonical" href="https://example.com/shoes?color=black" />
<!-- On /shoes?sort=price -->
<link rel="canonical" href="https://example.com/shoes" />
<!-- On /shoes (the clean category page) -->
<link rel="canonical" href="https://example.com/shoes" />Ein Fehler, den ich selbst gemacht habe und den wir noch nicht vollständig gelöst haben: Was tun mit facettierten Seiten, die sich Backlinks aufgebaut haben. Ein Kunde hatte tausende externe Links, die auf gefilterte URLs zeigten. Diese auf die Parent-Seite zu canonisieren, sollte Equity nach oben fließen lassen — klingt theoretisch gut.
In der Praxis haben wir nach der Canonical-Implementierung einen Rückgang von 15% in den Rankings der Parent-Seite gesehen. Ich weiß immer noch nicht, warum. Meine beste Vermutung: Die plötzliche Konsolidierung tausender Signale hat die Bewertung durch Google verwirrt — aber das ist Spekulation. Wir haben Canonicals auf den am stärksten verlinkten gefilterten Seiten zurückgerollt und sie indexierbar gelassen. Das ist ein Kompromiss, mit dem ich mich nicht richtig wohlfühle.
Kurzfassung: rel="next" und rel="prev" sind veraltet. Google hat 2019 bestätigt, dass es das Signal seit Jahren nicht mehr genutzt hat. Was macht man stattdessen?
Drei Optionen, sortiert nach meiner Präferenz:
Option 1: „Load more“ oder Infinite Scroll mit pushState. Das ist der sauberste Ansatz für neue Websites. Nutzer sehen eine URL. Google crawlt den gesamten Inhalt. Es gibt keine Paginierungs-URLs, die Crawl Budget verschwenden. Aber: Das braucht JavaScript — und das verursacht eigene Crawl-Budget-Kosten (mehr dazu unten).
Option 2: Klassische Paginierung mit noindex ab Seite 2+. Halten Sie die paginierten URLs crawlbar (damit Google Produkte/Artikel findet, die dort verlinkt sind), aber setzen Sie noindex, damit Google versucht, identische Template-Seiten nicht zu indexieren. Das Canonical auf jeder paginierten Seite sollte self-referenziert sein — canonischen Sie nicht alle Seiten auf Seite 1, denn der Content ist unterschiedlich.
Option 3: View-all-Seite. Wenn der paginierte Content insgesamt weniger als etwa ~200 Elemente hat, denken Sie über eine einzige View-all-Seite nach, die die paginierte Serie canonicalisiert. Google hat historisch View-all-Seiten bevorzugt. Der Nachteil: Ladezeit. Wenn Ihre View-all-Seite 8 Sekunden braucht, schadet das mehr als es hilft.
<!-- Page 2 of blog archive -->
<meta name="robots" content="noindex, follow">
<link rel="canonical" href="https://example.com/blog/page/2" />
<!-- Important: use "noindex, follow" — not "noindex, nofollow"
You want Google to follow the links on paginated pages
to discover the actual content pages -->Achten Sie auf die follow-Direktive. Das ist entscheidend. Sie wollen die paginierte Seite nicht im Index, aber Sie wollen ganz sicher, dass Google die Links darauf verfolgt, um die echten Content-Seiten zu finden. Wenn Sie hier nofollow verwenden, würden Sie jeden Artikel oder jedes Produkt verwaisen, das nur ab Seite 2+ in Ihrem Archiv verlinkt ist.
Dieser Abschnitt ist relevant für alle, die eine JavaScript-lastige Website betreiben (React, Vue, Angular, Next.js ohne korrektes SSR). Wenn Ihre Seite traditionell servergerendertes HTML liefert, springen Sie weiter.
Google crawlt in zwei Wellen. Erste Welle: Google lädt und verarbeitet das rohe HTML. Zweite Welle: Google rendert die Seite mit einem headless Chromium-Browser, um JavaScript auszuführen und den finalen Content zu sehen. Diese zweite Welle passiert später — manchmal erst Stunden später, manchmal erst nach Tagen.
Martin Splitt hat das in seinen JavaScript-SEO-Office-Hours ausführlich erklärt. Die Kernidee: Rendering ist für Google teuer. Es verbraucht mehr Ressourcen als ein einfacher HTML-Abruf. Google muss eine Chromium-Instanz starten, Ihr JavaScript ausführen, auf API-Calls warten, die sich auflösen, und danach das gerenderte DOM verarbeiten. Das bedeutet: Seiten, die von JavaScript abhängen, werden weniger effizient gecrawlt als servergerenderte Seiten.
Auswirkungen auf das Crawl Budget:
Die Lösung: Server-side Rendering (SSR) oder Static Generation (SSG). Next.js, Nuxt, SvelteKit unterstützen das. Wenn Sie kein vollständiges SSR hinbekommen, nutzen Sie dynamic rendering: Sie liefern vorgerendertes HTML an Googlebot und die volle JS-Erfahrung für Nutzer. Google rät technisch davon ab, aber Stand Anfang 2026 funktioniert es in der Praxis. Wir haben die SPA-spezifischen Herausforderungen in unserem Guide zu SPA-SEO-Best Practices behandelt.
Worauf Sie in Ihren Logs achten sollten:
Tools: Screaming Frog Log Analyzer ist das beliebteste dedizierte Tool. Sie können Logs auch mit Kommandozeilen-Tools auswerten (grep nach Googlebot-User-Agent, dann per awk ausgeben). Für kontinuierliches Monitoring verarbeitet die Crawl-Analytics-Funktion von SEOJuice Server-Logs automatisch und markiert Crawl-Budget-Probleme.
Ein echtes Beispiel aus unseren Daten: Ein Kunde hatte eine WordPress-Seite mit rund 25.000 veröffentlichten Beiträgen. Guter Content, ordentlich Traffic. Aber ihre Server-Logs zeigten, dass Googlebot 40% seines Crawl-Budgets für /wp-json/-API-Endpunkte und /feed/-URLs ausgab. Das sind keine Seiten, nach denen jemand sucht. Zwei Zeilen in robots.txt haben diese 40% für echte Content-Seiten freigeräumt. Innerhalb von drei Wochen stieg die Crawl-Rate auf Artikelseiten um 60%, und es wurden 12 neue Seiten indexiert, die monatelang in der „Discovered — currently not indexed“-Hölle festhingen.
# WordPress-specific crawl budget savings
User-agent: *
Disallow: /wp-json/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /author/*/feed/
Disallow: /category/*/feed/
Disallow: /tag/*/feed/
Disallow: /?replytocom=
Disallow: /trackback/Interne Links sind das stärkste Signal, das Sie kontrollieren können, um Google mitzuteilen, welche Seiten wichtig sind. Nicht Meta-Tags. Nicht Sitemap-Priority-Werte (die Google ohnehin ignoriert). Interne Links.
Jeder Link ist eine Stimme. Eine Seite, die von Ihrer Startseite, Ihrer Navigation und 50 weiteren Seiten verlinkt wird, wird häufiger gecrawlt als eine Seite, die nur von einer einzigen Archivseite drei Klicks tief verlinkt ist. Das ist grundlegende PageRank-Verteilung — und so entscheidet Googlebot, wo es sein Crawl Budget ausgibt.
Die praktische Konsequenz: Wenn Seiten nicht indexiert werden und 3+ Klicks von Ihrer Startseite entfernt sind, erhöhen zusätzliche interne Links von gut angebundenen Seiten ihre Crawl-Häufigkeit. Wir sehen das regelmäßig: Seiten, die von 0-1 internen Links auf 5+ kommen, bekommen ihren ersten Googlebot-Besuch innerhalb von 48 Stunden — selbst auf großen Websites, auf denen neue Seiten sonst typischerweise Wochen warten.
Deshalb haben wir automatisches internes Linking in SEOJuice eingebaut. Manuell interne Links über 10.000+ Seiten zu verwalten ist unmöglich. Aber der Crawl-Priority-Vorteil macht es zu einer der technisch besten Aktivitäten mit dem höchsten ROI.
Eine flache Architektur (jede Seite ist in 3 Klicks oder weniger erreichbar) ist besser für das Crawl Budget als tiefe Hierarchien. „Flach“ heißt aber nicht „alles mit allem verlinken“. Es bedeutet strategisches Linking — Topic Clusters, Hub-Seiten, kontextbezogene Links — sodass klare Crawl-Pfade zu Ihren wichtigsten Seiten entstehen.
Ich möchte konkret sein, was wir tatsächlich tun, statt vage Marketing-Sprache zu verwenden.
SEOJuice erfasst Crawl-Verhalten über drei Eingaben: GSC-Crawl-Stats (über die Search-Console-API), unsere eigenen Crawl-Daten (wir crawlen Kundenseiten, um das interne Link-Graf aufzubauen) und optional die Integration von Server-Logs.
Was wir aufbereiten:
Noch machen wir in der Produktoberfläche keine vollständige Logdatei-Analyse (beliebige Server-Logformate im großen Stil zu parsen ist eine Engineering-Aufgabe, die ich nicht zufriedenstellend gelöst habe). Aber GSC-Daten plus unser eigener Crawler liefern den meisten Websites genug, um Crawl-Budget-Probleme zu identifizieren und zu beheben — ohne eine Logdatei anfassen zu müssen.
Wenn Sie bis hierhin gelesen haben und feststellt haben, dass Sie wirklich ein Crawl-Budget-Problem haben, dann sind das die Fixes — in Reihenfolge der Wirkung:
Schritt 1–3 lösen das Problem für die Mehrheit der Websites, die tatsächlich Crawl-Budget-Optimierung brauchen. Schritt 4–9 ist für den Rest — Websites mit komplexen Architekturen, bei denen die Basics nicht reichen.
Nein. Crawl Budget entscheidet nur darüber, ob Ihre Seiten gecrawlt und indexiert werden — nicht darüber, wie sie ranken, sobald sie indexiert sind. Aber eine Seite, die nie gecrawlt wird, wird nie indexiert, und eine Seite, die nie indexiert wird, kann nicht ranken. Crawl Budget ist also Voraussetzung, kein Ranking-Faktor. Wenn Sie es optimieren, verbessern Sie keine Rankings für bereits indexierte Seiten — Sie helfen Seiten, die aktuell gar nicht erst indexiert werden.
Fast nie. Die Crawl-Rate-Einstellungen in GSC erlauben es, die Crawl-Rate von Googlebot zu reduzieren, nicht zu erhöhen. Der einzige Grund, das zu nutzen, ist, wenn Googlebot Ihren Server buchstäblich überfordert. Wenn Ihr Server die Last bewältigen kann: einfach lassen. Ich habe gesehen, wie Leute die Rate reduzieren in der Annahme, Google würde sich dann stärker auf wichtige Seiten „fokussieren“. So funktioniert das nicht — Google crawlt einfach weniger von allem.
Beliebte, häufig aktualisierte Seiten: mehrmals pro Tag. Statische Seiten, die sich über Monate nicht ändern: alle paar Wochen. Der Durchschnitt liegt grob bei jeder 1–2 Wochen pro Seite, aber das variiert massiv. News-Websites werden innerhalb von Minuten gecrawlt. Eine selten aktualisierte „Über uns“-Seite könnte einen Monat zwischen Besuchen haben. Das <lastmod>-Tag kann Hinweise geben, dass sich eine Seite geändert hat — aber nur, wenn Sie es korrekt einsetzen: Google ignoriert es, wenn es immer auf das Datum von heute gesetzt ist.
Sie können Ihr Crawl-Rate-Limit erhöhen (schnellere Server) und Crawl Waste reduzieren (damit mehr Budget in wichtige Seiten fließt). Aber Sie können Google nicht direkt sagen, dass es Sie stärker crawlen soll. Die Crawl-Nachfrage entscheidet Google basierend auf dem wahrgenommenen Content-Wert. Der beste indirekte Weg: häufig veröffentlichen, Backlinks aufbauen, Content wirklich nützlich machen. Websites mit hohem Wert werden aggressiver — und automatisch — gecrawlt.
Ja. Google crawlt die Seite trotzdem, um den noindex-Tag zu sehen. 100.000 noindexed Seiten bedeuten 100.000 Crawl-Budget-Treffer (wenn auch seltener als bei indexierten Seiten). Wenn diese Seiten wirklich nie indexiert werden müssen, ist robots.txt crawl-effizienter — aber robots.txt blockiert, sodass Google nichts auf der Seite sieht, inklusive Links. Nutzen Sie noindex+follow, wenn Sie Link Discovery möchten, aber keine Indexierung. Nutzen Sie robots.txt, wenn Sie nicht möchten, dass die Seite überhaupt gecrawlt wird.
Dieser Artikel ist Teil unserer technischen SEO-Serie. Wenn Sie gerade Crawl-Budget-Themen aufarbeiten, helfen Ihnen diese verknüpften Guides:
Wenn Sie ein großes Projekt betreiben und automatisiertes Crawl-Budget-Monitoring wollen, SEOJuice verfolgt Crawl Waste, Indexing-Velocity und Server-Antwortzeit für alle Ihre Seiten. Es ersetzt keine Logdatei-Analyse für komplexe Architekturen, aber es zeigt den Großteil der Crawl-Budget-Probleme, die wirklich zählen — durchgehend, nicht nur dann, wenn sich jemand erinnert, mal ein Audit zu fahren. Jetzt eine kostenlose Testphase starten und sehen Sie innerhalb weniger Minuten, wohin Ihr Crawl Budget geht.
no credit card required