Cost of Retrieval: Was Google das Crawlen deiner Website wirklich kostet

Im April 2025 habe ich für die AFS Akademie einen Gastbeitrag zu Cost of Retrieval veröffentlicht. Seitdem habe ich in über 30 Audits gesehen, wie massiv Cost of Retrieval die Sichtbarkeit beeinflusst. Dieser Artikel geht klar deutlich tiefer – mit konkreten Zahlen aus echten Projekten und den Erkenntnissen, die ich seitdem gewonnen habe.

Cost of Retrieval: Das Konzept hinter dem Begriff

Cost of Retrieval kommt aus dem Information Retrieval – also aus einem Forschungsfeld, das sich mit der gezielten Extraktion von Informationen aus großen Datenmengen beschäftigt. Für SEO lautet die zentrale Frage letztlich: Lohnt sich der rechnerische Aufwand, Informationen aus einer Website zu extrahieren?

Auf der einen Seite steht die Rechenleistung, die Google investieren muss: Server-Anfragen, Rendering, Speicherung, mehrfache Snapshots. Auf der anderen Seite steht der Informationsgehalt der Seite. Ist der Informationswert höher, crawlt und indexiert Google. Ist der Aufwand höher, passiert nichts.

Das ist keine Theorie. Google speichert von indexierten Seiten Snapshots auf eigenen Servern. Bei einem Onlineshop mit 5.000 Produktseiten à 2 MB kommen schnell 10 GB Speicherbedarf zusammen – nur für eine einzige Domain. Rechnet man das auf Milliarden von Websites hoch, wird ziemlich klar, warum Google extrem selektiv crawlt.

Abb. 1: Kosten-Nutzen-Abwägung – Rechenaufwand vs. Informationswert beim Crawlen

Warum Cost of Retrieval 2026 so relevant ist

Jeden Tag gehen Tausende neue Websites online, viele davon mit KI-generierten Inhalten, die in ähnlicher Form schon existieren. Google filtert mittlerweile immer stärker. Die Schwelle, ab der sich das Crawlen lohnt, steigt kontinuierlich.

Modernes Retrieval läuft mehrstufig ab: lexikalische Kandidaten-Generierung, semantisches Retrieval, Reranking, Synthese. Cost of Retrieval entscheidet, ob eine Seite überhaupt in die erste Stufe gelangt. Wer hier rausfällt, existiert für Google und KI-Systeme nicht. Google bestätigt das indirekt in der offiziellen Crawl-Budget-Dokumentation: „Googlebot tries not to crawl too fast to avoid overloading the server.“ Google crawlt weniger, wenn dein Server langsam antwortet – so einfach ist das.

Koray Tugberk Gübür beschreibt Cost of Retrieval in seinem Semantic SEO Framework als einen der drei Grundpfeiler – neben Content Quality und Entity Understanding. Ganz ehrlich: Cost of Retrieval ist der Pfeiler, den die meisten SEOs übersehen, weil er nicht in Keyword-Rankings sichtbar wird. Cost of Retrieval wirkt im Verborgenen – und richtet dort den größten Schaden an.

Die 5 Faktoren, die den Cost of Retrieval bestimmen

Abb. 3: Die 5 Faktoren des Cost of Retrieval

1. Server-Antwortzeit (TTFB)

Time to First Byte (TTFB) misst die Zeitspanne zwischen der Anfrage des Crawlers und dem ersten empfangenen Byte der Server-Antwort. Google empfiehlt TTFB-Werte unter 200 Millisekunden. Realistisch sind 200–400 Millisekunden. Ab 600 Millisekunden steigt der Cost of Retrieval messbar.

Bei einem E-Commerce-Kunden lag die durchschnittliche Server-Reaktionszeit in der Google Search Console bei über 600 Millisekunden – obwohl Cloudflare vorgeschaltet war. Die Crawling-Statistiken zeigten: Der Server reagierte viermal langsamer als empfohlen. Bei einem anderen Kunden erreichten die Kategorieseiten 900 Millisekunden TTFB. Der Grund: 48 Produkte plus Topseller wurden bei jedem Seitenaufruf ungecacht aus der Datenbank geladen. Ohne Cache waren die Kategorieseiten vier- bis achtmal langsamer als mit Cache.

Warum ist das problematisch? Google crawlt nicht immer mit warmem Cache. Der Googlebot erfasst die langsame Version, wenn er eine Kategorieseite ohne Cache trifft – und bewertet den Cost of Retrieval entsprechend hoch.

Ich habe Martin Splitt – Developer Advocate bei Google – im Oktober 2025 auf Mastodon direkt gefragt, wie man den TTFB noch weiter runterbekommt. Mein Setup: schlankes WordPress auf OpenLiteSpeed, dedizierter Hetzner-Server, an allem gedreht, trotzdem maximal 300 Millisekunden in der GSC. Seine Antwort: „300ms is ja schon super. Bedenke, dass wir meistens aus den USA crawlen, also könnte ein CDN da helfen, aber ich würd bei so einer niedrigen response time jetzt nicht zu viel drüber nachdenken.“

Das bestätigt letztlich: Unter 300 Millisekunden ist exzellent. Google crawlt überwiegend aus den USA – die physische Distanz zum Server kann sich deswegen auf den TTFB auswirken. Ein CDN wie Cloudflare kann hier helfen, aber ab 300 Millisekunden ist der Grenznutzen gering.

Empfehlung: TTFB unter 400 Millisekunden halten. Unter 300 Millisekunden ist laut Google exzellent. Wer über 600 Millisekunden liegt, verliert messbar Crawl-Frequenz, ganz ehrlich. Den exakten TTFB-Wert zeigen die Crawling-Statistiken in der Google Search Console unter Einstellungen.

Abb. 2: TTFB-Skala – Server-Antwortzeiten von exzellent bis kritisch

2. Seitengröße und HTML-Komplexität

Google hat im März 2026 erstmals die konkreten Byte-Limits der Crawling-Infrastruktur offengelegt: Googlebot lädt bei einer HTML-Seite maximal die ersten 2 MB – inklusive HTTP Header. Bei PDF-Dateien liegt die Grenze bei 64 MB. Alles oberhalb der 2 MB rendert Google nicht, indexiert es nicht und, klar, für Google ist es schlicht nicht da.

Entscheidend ist, was bei einer Überschreitung passiert: Google weist die Seite nicht zurück, sondern kappt sie exakt bei 2 MB und verarbeitet dieses Fragment, als wäre es die komplette Datei. Liegen strukturierte Daten, das Canonical-Tag oder die Meta Description hinter der 2 MB Marke – etwa weil davor Megabytes an Inline-CSS, Base64-Bildern oder ein aufgeblähtes Mega-Menü sitzen – fehlen diese Elemente für Google vollständig. Die Reihenfolge im HTML-Quelltext ist deswegen nicht bloß Best Practice, sondern letztlich existenziell: title, canonical, meta description und structured data gehören so weit nach oben wie möglich.

Ein weiteres Detail aus dem Blogpost: Sub-Ressourcen wie JavaScript- und CSS-Dateien haben jeweils ein eigenes 2 MB Limit und zählen nicht gegen die Größe der übergeordneten HTML-Seite. Ein fettes JS-Bundle mit 3 MB wird also ebenfalls bei 2 MB abgeschnitten – unabhängig davon, wie schlank die HTML-Seite selbst ist. Medien, Fonts und einige exotische Dateitypen werden vom Web Rendering Service gar nicht erst angefordert.

Bei einem Kunden lieferten die Bing Webmaster Tools den Hinweis „HTML zu lang“. Der Quelltext bestätigte das Problem: über 12.000 Zeilen HTML – 8.000 Zeilen mehr als bei vergleichbaren Wettbewerber-Websites. Bei solchen Dimensionen riskiert man, dass Google die Seite nicht vollständig erfasst, weil der Content jenseits des 2 MB Cutoffs liegt.

Große Hero-Slider und eingebettete Videos blähen Seiten auf bis zu 15 MB auf. Drei konkrete Maßnahmen: Slider entfernen, Videos extern einbetten, Bilder komprimieren. Und eine vierte: Kritische HTML-Elemente an den Anfang des Quelltexts verschieben – vor Menüs und vor Inline-Ressourcen.

3. Rendering-Aufwand und JavaScript-Abhängigkeit

Zwischen einem statischen Blog und einer JavaScript-lastigen Single Page Application liegt eine enorme Bandbreite im Cost of Retrieval. Google kann JavaScript rendern – aber das Rendering kostet Rechenzeit, und diese Rechenzeit fließt direkt in den Cost of Retrieval.

Bei einem Shopware-Kunden blockierte die robots.txt Teile des Widgets-Subdirectories. Die Folge: Die Startseite konnte beim Rendern nicht vollständig geladen werden. Google speicherte die Startseite ohne den eigentlichen Content – die wichtigste Seite der Domain, inhaltsleer im Index. Solche Probleme entdeckt man nur, wenn man den gerenderten Output in der Google Search Console prüft.

Google hat außerdem bestätigt, dass der Web Rendering Service (WRS) komplett zustandslos arbeitet – Local Storage und Session-Daten werden zwischen Requests gelöscht. JavaScript, das auf gespeicherte Session-Daten angewiesen ist, um Content auszugeben, produziert im WRS leere Seiten. Auch hier gilt das 2 MB Limit: Der WRS kann nur den Code ausführen, den der Crawler tatsächlich abgerufen hat. Wird ein JavaScript-Bundle bei 2 MB abgeschnitten, fehlt dem WRS der Rest des Codes.

Ein weiteres Cost-of-Retrieval-Problem bei JavaScript: Content, der auf dem Handy erst nach Klick auf „Mehr erfahren“ nachgeladen wird. Google crawlt Mobile First. Das heißt: Google behandelt den Content als Hidden Content und ignoriert ihn möglicherweise komplett, wenn der Text hinter einem Overlay versteckt ist.

Pro-Tipp: Interne Verlinkung per JavaScript vermeiden. Crawler können JavaScript-Links im Zweifelsfall nicht zuverlässig interpretieren und folgen ihnen möglicherweise nicht. Klassische <a href>-Links sind die sichere Variante.

4. Crawl Budget und Seitenanzahl

Crawl Budget beschreibt die Anzahl der Seiten, die Google auf einer Domain in einem bestimmten Zeitraum crawlt. Je mehr Seiten existieren, desto stärker verteilt Google das Crawl Budget – und desto weniger Aufmerksamkeit erhält jede einzelne Seite. Ein hoher Cost of Retrieval auf vielen Seiten erschöpft das Crawl Budget schneller.

Bei einem Shopware-Kunden zeigte die Google Search Console ein Indexierungsverhältnis von 4:1. Etwa 2.800 URLs waren nicht indexiert, während nur rund 700 URLs im Index standen. Google verschwendete einen Großteil des Crawl Budgets für Seiten, die am Ende nicht indexiert wurden – 404-Fehler, 500er-Fehler, Duplikate.

Abb. 5: Crawl-Budget-Verschwendung – Indexierungsverhältnis 4:1

Bei einem anderen Kunden haben wir die nicht-indexierten Seiten systematisch bereinigt: von 786 auf 633, dann weiter runter. Parallel stieg die Crawl-Frequenz für die relevanten Seiten. Je weniger Seiten Google regelmäßig crawlen muss, desto weniger Crawl Budget wird für irrelevante URLs verbraucht.

Faustregel: Jede Seite ohne echten Mehrwert verschwendet Crawl Budget. Konsequent löschen oder per noindex aus dem Index nehmen.

5. Technische Roadblocks, die das Crawling verhindern

Neben den Performance-Faktoren existieren technische Fehler, die den Cost of Retrieval unendlich hoch treiben – weil sie das Crawling komplett blockieren:

• 429 Too Many Requests: Bei einem Kunden trat dieser Statuscode auf, als Semrush einen Backlink-Check durchführte. Der Server war überlastet. Google deprioritisiert eine Seite nach einem 429-Fehler und kommt nicht einfach später zurück.
• Fehlerhaft konfigurierte robots.txt: Der Crawler erhält versehentlich keinen Zugriff auf indexierungsrelevante Inhalte.
• Falsche Robots-Meta-Tags: noindex oder nofollow an Stellen, wo keins sein sollte.
• Weiterleitungsschleifen: Der Crawler läuft ins Leere und bricht ab.
• Falsche Canonical-Tags: Google indexiert die falsche URL-Version – oder gar keine.
• 500er-Fehler: Interne Serverprobleme verhindern den Zugriff komplett.

Cost of Retrieval optimieren: Server, Datenbank, Seitenstruktur

Was kann man konkret tun? Cost of Retrieval lässt sich auf 3 Ebenen senken.

Abb. 4: 3 Ebenen der Cost-of-Retrieval-Optimierung

Server und Hosting optimieren

Shared Hosting reicht für Business-Websites und Webshops in der Regel nicht aus. Wenn eine Website auf dem geteilten Server langsam antwortet, bremst das den Cost of Retrieval aller Websites auf demselben Server. Ein eigener Server – physisch oder Cloud – bietet mehr Performance und ermöglicht gezielte Optimierungen.

3 konkrete Maßnahmen für niedrigeren Cost of Retrieval auf Server-Ebene:

• Schneller Webserver: OpenLiteSpeed statt Apache einsetzen. OpenLiteSpeed verarbeitet bis zu 60.000 Anfragen pro Sekunde.
• IPv6 und HTTP/3 aktivieren: Moderneres Routing, geringere Latenz, schnellere Antwortzeiten.
• DNS optimieren: Cloudflare bietet einen der schnellsten DNS-Dienste – kostenlos. Eine schnelle DNS-Auflösung verbessert direkt den TTFB.

Datenbank schlank halten

Bei CMS und Shopsystemen, die auf relationalen Datenbanken basieren: Datenbank regelmäßig optimieren. Eine aufgeblähte Datenbank ohne Indexierung und Caching verlängert die Zugriffszeiten bei jedem einzelnen Seitenaufruf – und erhöht damit den TTFB und den Cost of Retrieval.

Seitenstruktur statisch aufbauen

Seiten am besten so statisch wie möglich bauen. Komplexe Effekte, die per JavaScript statt per CSS laufen, treiben den Cost of Retrieval beim Rendering hoch. Die Faustregel ist klar: Wenn die Seite auch ohne JavaScript funktioniert, kann Google sie effizient crawlen.

Cost of Retrieval messen: Tools und Methoden

Google Search Console: Unter Einstellungen zeigen die Crawling-Statistiken die durchschnittliche Server-Reaktionszeit und die Crawl-Frequenz. Schaut der Googlebot nur selten vorbei, spricht das eher für einen hohen Cost of Retrieval.

Bing Webmaster Tools: Wird oft unterschätzt. Die Bing Webmaster Tools geben Hinweise wie „HTML zu lang“ aus, die Google nicht explizit meldet.

site:-Befehl: site:domain.org in der Google-Suche listet alle indexierten Seiten. Passt die Zahl der indexierten Seiten zur erwarteten Seitenanzahl? Tauchen ungewollte Dateien wie PDFs im Index auf?

Crawling-Tools: Screaming Frog, Ahrefs oder Semrush für einen vollständigen Crawl. Screaming Frog crawlt kostenlos bis zu 500 URLs.

Quelltext-Check: Ein direkter Blick in den HTML-Code lohnt sich ehrlicherweise immer. Falsch gesetzte Robots-Meta-Tags oder fehlerhafte Canonical-Tags sieht man im Quelltext sofort.

Cost of Retrieval in der Praxis: Keywordkönig-Wettbewerb

Beim SEO-Wettbewerb von Agenturtipp 2025 zum Keyword „Keywordkönig“ war Cost of Retrieval einer der drei Hebel, mit denen wir Platz 3 bei Google und den ersten Platz beim KI-Wettbewerb von RankScale erreicht haben.

Cost of Retrieval war der erste Hebel: eine technisch schnelle, leicht abrufbare Website. Kein aufgeblähtes CMS, schlankes HTML, schneller Server, minimales JavaScript. Google konnte die Seite effizient crawlen und indexieren – in einer Wettbewerbssituation, in der Geschwindigkeit buchstäblich den Unterschied gemacht hat.

Die anderen beiden Hebel – Information Gain durch semantisch optimierten Content und Brand SEO – konnten nur wirken, weil die technische Basis stimmte. Cost of Retrieval ist die Voraussetzung für Sichtbarkeit, nicht das Sahnehäubchen.

Häufige Fragen zu Cost of Retrieval

Quellen

• Illyes, Gary (2026): „Inside Googlebot: demystifying crawling, fetching, and the bytes we process“, Google Search Central Blog – offizielle Byte-Limits: 2 MB HTML, 64 MB PDF, WRS-Statelessness, Partial Fetching
• Windolph, Benny (2025): „Cost of Retrieval: Warum Google manche Seiten nicht crawlt oder indexiert“, AFS Akademie
• Gübür, Koray Tugberk: „Semantic SEO“, Holistic SEO Digital – Cost of Retrieval als Grundpfeiler
• Splitt, Martin (2025): Mastodon-Konversation zu TTFB und Googlebot-Crawling aus den USA, Google Developer Advocate
• Google: „Managing your crawl budget for large sites“, Google Search Central
• Google: „How Google Search works“, Google Search Central – Crawling, Indexing, Serving Pipeline
• Screaming Frog: „How to Find Expired Domains“ – Crawl-Analyse-Methodik