Sprachen

Caching für SEO

Wie Browser- und Server-Caching mit Cache-Control, ETags und CDNs die Performance und Core Web Vitals verbessert – und welche Caching-Fallen das Crawling beeinflussen.

Erstveröffentlicht: 2. Juli 2026 · Zuletzt aktualisiert: 9. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2

Caching speichert eine Kopie einer Seite oder Ressource — im Browser, am CDN-Edge oder im eigenen Cache eines Crawlers — damit sie nicht neu erzeugt oder heruntergeladen werden muss. Es ist kein direkter Rankingfaktor, beeinflusst aber Seitengeschwindigkeit/Core Web Vitals über TTFB und LCP sowie die Crawling-Effizienz. Googles Crawler berücksichtigt ETag und Last-Modified sowie max-age als Hinweis für erneutes Crawling; andere HTTP-Caching-Direktiven werden nicht unterstützt. Die riskantesten Fehler sind CDN-Fehlkonfigurationen und veraltete Caches, die Bots blockieren oder in die Irre führen.

TL;DR — Caching arbeitet auf drei für SEO wichtigen Ebenen: Browser, CDN-Edge und der eigene Cache des Crawlers für bedingte Requests. Es ist kein Rankingfaktor, beeinflusst aber Seitengeschwindigkeit (TTFB/LCP und — über bfcache — Core Web Vitals bei wiederholter Navigation) sowie Crawling-Effizienz. Googles Crawler bevorzugt ETag gegenüber Last-Modified, liest max-age nur als Hinweis für erneutes Crawling und sagt laut eigener Dokumentation: “other HTTP caching directives aren’t supported.” (Übersetzung) „andere HTTP-Caching-Direktiven werden nicht unterstützt“. CDNs ermöglichen eine höhere Crawling-Rate, aber erst, wenn ihr Cache warm ist; die echten Risiken sind Starts mit kaltem Cache und CDN-/WAF-Fehlkonfigurationen, die Bots vollständig blockieren.

Evidence for this claim Google's crawler documentation supports ETag/If-None-Match and Last-Modified/If-Modified-Since, prefers ETag when both are present, and says other HTTP caching directives are unsupported; Google's separate max-age advice is a recrawl-timing hint, not proof it follows browser cache semantics. Scope: Google crawling Confidence: high · Verified: Crawling December: HTTP caching Evidence for this claim HTTP caching uses Cache-Control and validators to control reuse and revalidation. Scope: Current official or standards documentation. Confidence: high · Verified: MDN: HTTP caching Evidence for this claim Browser caches can reuse stored responses according to HTTP caching semantics. Scope: Current official or standards documentation. Confidence: high · Verified: MDN: HTTP caching

Die drei Caching-Ebenen

Caching für SEO ist nicht eine einzige Sache — es sind drei Ebenen, die jeweils etwas anders gesteuert werden:

  1. Browser-Cache — das Gerät des Besuchers speichert Dateien, sodass wiederholte Aufrufe das Netzwerk überspringen. Das ist es, worauf PageSpeed Insights mit „Serve static assets with an efficient cache policy“ hinweist.
  2. CDN-/Edge-Cache — ein Content Delivery Network speichert Kopien weltweit an Edge-Knoten (die vollständige Erklärung finden Sie im Deep Dive zu CDN und SEO). Googles eigene Beschreibung: CDNs sind Vermittler zwischen Ihrem Origin und dem Nutzer, und historisch lag ihr größter Schwerpunkt auf Caching — sie speichern den Inhalt einer URL, damit Ihr Server diese Datei eine Zeit lang nicht erneut ausliefern muss.
  3. Crawler-seitiger Cache — Googlebot und Bingbot führen mithilfe bedingter Requests eigene Aufzeichnungen darüber, ob sich Inhalte geändert haben. Das ist der Hebel für das Crawl-Budget; die Mechanik gehört in den Deep Dive zu bedingten Requests, hier bleibt es bei einer Zusammenfassung.

„Browser-Cache“ ist oben eine Kurzbezeichnung für mehr als einen Mechanismus. Laut MDNs Leitfaden zu HTTP-Caching sollte man Folgendes auseinanderhalten: den privaten HTTP-Cache (pro Browser, nach Request-Schlüssel und in modernen Browsern nach der Top-Level-Site partitioniert, um Cross-Site-Tracking zu begrenzen), den In-Memory-Cache für die aktuelle Sitzung, den weiter unten behandelten bfcache und — separat — den Cache Storage eines Service Workers, den das JavaScript der Website selbst steuert und den Cache-Control-Header nicht direkt regeln. „Prüfen Sie den Browser-Cache“ kann je nach tatsächlichem Fehler vier verschiedene Debugging-Schritte bedeuten.

Wie Caching die Core Web Vitals beeinflusst

Ressourcen über das Netzwerk abzurufen ist langsam und teuer. Caching entfernt Netzwerklatenz und Übertragungskosten für alles, was sich nicht geändert hat. Das wirkt sich direkt auf zwei vitals-nahe Messwerte aus: TTFB (eine gecachte Antwort überspringt die Neuerzeugung am Origin) und LCP (gecachte Bilder, CSS und Fonts werden früher gerendert).

Cache-Control: die wichtigen Direktiven

Cache-Control ist der wichtigste Header. Diese Direktiven sollten Sie kennen:

  • max-age=<seconds> — wie lange eine frische Kopie gültig ist. Für unveränderliche, versionierte Assets empfehlen Chromes Lighthouse-Dokumente ein Caching von einem Jahr oder länger — zum Beispiel Cache-Control: max-age=31536000.
  • no-cache — bedeutet nicht „nicht cachen“. Es bedeutet: „Speichern, aber vor der Wiederverwendung beim Server erneut validieren.“ Es ermöglicht weiterhin den schlanken 304-Ablauf.
  • no-store — die Direktive, die tatsächlich bedeutet, keine Kopie irgendwo in einem HTTP-Cache zu speichern. Das ist eine Caching-Direktive, kein allgemeiner Datenschutzschalter — laut RFC 9111 löscht sie den Browserverlauf nicht zuverlässig und sagt nichts über den eigenen Cache Storage eines Service Workers aus.
  • public / private — ob gemeinsam genutzte Caches (etwa ein CDN) die Antwort speichern dürfen oder nur der Browser des Endnutzers.
  • immutable — die erneute Validierung überspringen, solange die Antwort noch frisch ist. Das bedeutet nicht „wird nie veraltet“ — nach Ablauf von max-age gelten wieder die normalen Frische-Regeln.
  • must-revalidate — das andere Ende der Zeitachse: Diese Direktive ist erst nach dem Veralten einer Antwort relevant und weist den Cache an, beim Origin erneut zu validieren, statt die veraltete Kopie trotzdem auszuliefern.
  • s-maxage, stale-while-revalidate, stale-if-error — feinere Steuerungen vor allem für CDNs und andere Shared Caches (eigene Frischelebensdauer für Shared Caches, begrenzte veraltete Wiederverwendung während eines Hintergrundabrufs bzw. bei einem Origin-Fehler). Die Unterstützung variiert je nach Browser/CDN; prüfen Sie die Browser-/CDN-Unterstützung, bevor Sie sich darauf verlassen — und keine dieser zusätzlichen Direktiven wird von Googles Crawler berücksichtigt, wie wir sehen werden.

Cache-Busting mit versionierten Dateinamen

Der Trick, mit dem Sie aggressiv cachen und trotzdem sofort aktualisieren können: Legen Sie einen Inhalts-Hash in den Dateinamen — style.x234dff.css. Da die URL der Cache-Schlüssel ist, ändert eine Änderung der Datei die URL; Caches holen die neue Version daher sofort, während alte Versionen so lange wie gewünscht gecacht bleiben. Sowohl Googles web.dev-Leitfaden zum HTTP-Cache als auch Bings eigener Beitrag zur Frontend-Entwicklung beschreiben dasselbe Muster — Bing hasht Dateiinhalte in die URL, sodass “the URL acts as the cache key,” (Übersetzung) „die URL als Cache-Schlüssel fungiert“, was Caches konsistent hält und lange Ablaufzeiten ermöglicht.

Die bfcache-Falle — wo no-store still die CWV schädigt

Hier ist ein oft übersehener Punkt. Der Back/Forward Cache (bfcache) sorgt dafür, dass ein Zurückgehen eine Seite sofort wiederherstellt. Eine bfcache-Wiederherstellung überspringt die LCP-/CLS-/INP-Messung vollständig und ist für Ihre CrUX-Felddaten daher nur positiv. Laut Googles bfcache-Leitfaden hat Cache-Control: no-store auf dem Seitendokument selbst Browser historisch dazu gebracht, die Speicherung der Seite im bfcache zu verweigern. Wenn ein HTML-Dokument Frische braucht, Sie aber die Back/Forward-Cache-Berechtigung nicht opfern möchten, verwenden Sie no-cache oder max-age=0 statt no-store.

Wie ein Cache entscheidet, ob etwas „frisch genug“ ist

Bevor ein Validator ins Spiel kommt, prüft ein Cache die Frische: Hat das Alter der gespeicherten Antwort die von Cache-Control vorgegebene Frischelebensdauer überschritten (oder — ohne ausdrücklich angegebene Lebensdauer — eine heuristische, die der Cache schätzen darf)? Der Age-Response-Header gibt an, wie lange ein Shared Cache eine Antwort bereits hält. So erkennen Sie in DevTools oder einem CDN-Log, wie viel Frischelebensdauer noch übrig ist. Frisch bedeutet: Der Cache kann die Antwort sofort wiederverwenden, ganz ohne Request. Veraltet bedeutet: Er sollte vor der Wiederverwendung validieren; genau hier bewähren sich ETag/If-None-Match und Last-Modified/If-Modified-Since — beschrieben als Nächstes in der engeren Googlebot-Version dieses allgemeinen HTTP-Mechanismus.

Wie Googlebot Caching nutzt (der Aspekt der Crawling-Effizienz)

Google stellte in seinem Beitrag Crawling December: HTTP caching vom Dezember 2024 eine ungewöhnlich direkte Bitte: Aktivieren Sie Caching, damit seine Crawler unveränderte Seiten nicht erneut herunterladen müssen. Die auffällige Zahl des Beitrags: Cache-fähige Abrufe nehmen ab — vor 10 Jahren waren etwa 0,026 % aller Abrufe cache-fähig, heute sind es 0,017 %. Kleine Zahlen, aber Google möchte eindeutig, dass sie in die andere Richtung gehen.

ETag oder Last-Modified — was Google bevorzugt

Googles Crawling-Infrastruktur unterstützt die beiden Standard-Validatoren: ETag (mit If-None-Match) und Last-Modified (mit If-Modified-Since). Google empfiehlt ETag nachdrücklich, weil sein Wert unstrukturiert und daher weniger anfällig für Parsing-Fehler ist, die ein Datumsstring begünstigt — und wenn beide vorhanden sind, verwenden seine Crawler den ETag-Wert, wie es der HTTP-Standard verlangt. Google empfiehlt trotzdem, beide zu setzen, da andere Anwendungen wie CMS sie verwenden. Wenn Sie Last-Modified einsetzen, muss das Datum dem HTTP-Format entsprechen (zum Beispiel Fri, 4 Sep 1998 19:15:56 GMT), sonst wird es nicht geparst.

Wenn der gespeicherte Validator des Crawlers noch übereinstimmt, gibt Ihr Server einen 304 Not Modified ohne Body zurück — genau darum geht es. Wie Google formuliert: Ohne Body muss Ihr Server keine Rechenleistung für die Erzeugung von Inhalten aufwenden und keine Bandbreite für dessen Übertragung verbrauchen. (Die 304-Mechanik wird im Artikel zu bedingten Requests ausführlich als Crawl-Budget-Mechanismus behandelt; hier genügt zu wissen, dass sie existiert und beiden Seiten Geld spart.)

Die Nuance, die fast alle übersehen

Googles Crawler reagiert nicht so auf den vollständigen Satz der Cache-Control-Direktiven wie ein Browser oder CDN. Laut der offiziellen Crawler-Übersicht werden neben ETag/Last-Modified „other HTTP caching directives aren’t supported.“ Die eine teilweise Ausnahme: Google sagt, Sie können optional max-age setzen, um Crawlern zu helfen, den Zeitpunkt für erneutes Crawling zu bestimmen — ein Hinweis für erneutes Crawling, keine harte Sperre. no-cache, s-maxage, stale-while-revalidate und andere beeinflussen also weiterhin Browser- und CDN-Verhalten, ändern aber nicht, wie Googlebot cached. Auch Googles Empfehlung zur Invalidierung ist sinnvoll: Fordern Sie eine Cache-Aktualisierung bei wesentlichen Änderungen — nur das Copyright-Jahr in der Fußzeile zu aktualisieren, ist nicht wesentlich.

CDNs und Crawling

Ein CDN bringt mehr als Geschwindigkeit. Googles Crawling-Infrastruktur ist darauf ausgelegt, höhere Crawling-Raten auf Websites mit CDN zu ermöglichen, abgeleitet anhand der IP-Adresse, von der die URLs ausgeliefert werden — Google nimmt an, dass ein CDN-gestützter Origin mehr gleichzeitige Requests verkraften kann.

Aber es gibt einen Punkt, den Sie einplanen sollten: den kalten Cache. Beim ersten Zugriff auf eine URL ist der Cache des CDN „kalt“ — noch niemand hat sie angefordert, daher muss Ihr Origin sie mindestens einmal ausliefern, um den Cache zu füllen. Google warnt, dass der gleichzeitige Start vieler URLs deshalb eine echte Belastung für das Crawl-Budget darstellt, mit einer hohen Crawling-Rate über einige Tage. Planen Sie bei einem großen Launch oder einer Migration die volle Last pro URL für den Origin ein, bevor das CDN zu helfen beginnt.

Eine CDN-Fehlkonfiguration ist ein Crawling-Risiko

Die beunruhigendsten Caching-Probleme sind keine langsamen Cache-Dauern, sondern CDN- und WAF-Konfigurationen, die Bots blockieren. Googles CDN-Beitrag sagt ausdrücklich, dass das Senden von 503/429 bei vorübergehenden Blockierungen bevorzugt wird, während Netzwerk-Timeouts als endgültige, „harte“ Fehler behandelt werden, die dazu führen können, dass URLs aus dem Index entfernt werden. Die subtile Variante ist eine Soft-Blockade: ein Bot-Verifizierungs-Interstitial. Der Crawler sieht nur die Challenge-Seite, nicht Ihre Website — Google empfiehlt daher ausdrücklich, automatisierten Clients eine 503-Antwort zu geben. Am einfachsten prüfen Sie, ob ein CDN Google nicht unbemerkt blockiert, mit dem URL-Prüftool in der Search Console — sehen Sie sich das gerenderte Bild an. Wenn es eine Bot-Challenge oder eine leere Seite zeigt, sprechen Sie mit Ihrem CDN.

Weiterleitungen an das CDN auszulagern ist eine Technik, die ich mag. Im Marketing-Speak-Podcast habe ich sie so beschrieben: “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (Übersetzung) „Einer meiner persönlichen Favoriten, der meiner Meinung nach nicht oft genug genutzt wird: Es ist tatsächlich nur das Auslagern Ihrer Weiterleitungen auf die CDN-Ebene.“ (Zum Zitat)

Caching-Fallen, die Crawling und Indexierung beeinträchtigen

Das ist der Aspekt, den die meisten „Caching für SEO“-Artikel auslassen. Ein Cache macht Dinge nicht nur schnell — ein falscher Cache kann einem Bot die falschen Bytes ausliefern und Crawling oder Indexierung unterbrechen.

Ein echter Fall: Ein gemeinsam genutzter Cache liefert eine blockierende robots.txt aus. Ich habe einen Fall intermittierender Googlebot-Blockierung untersucht, der auf einen gemeinsamen CDN-Cache zwischen Testumgebung und Live-Website zurückging. Wie ich in Indexed, though blocked by robots.txt schrieb: “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (Übersetzung) „Eine mögliche Ursache wäre ein gemeinsam genutzter Cache zwischen einer Testumgebung und einer Live-Umgebung. Wenn der Cache der Testumgebung aktiv ist, kann die robots.txt eine blockierende Direktive enthalten.“ Die Lösung war, den Cache zu trennen oder .txt-Dateien im Cache der Testumgebung auszuschließen. Eine Caching-Fehlkonfiguration verursachte direkt einen Crawling-Fehler — genau diese Risikokategorie ist gefährlich.

Weitere Fallen derselben Art:

  • Ein veralteter CDN-Cache liefert Bots überholte Inhalte. Wenn Ihr Edge-Cache lange nach einer Veröffentlichung eine alte Version hält, sehen Bots weiterhin die alte Version. Leeren Sie ihn bei der Veröffentlichung oder koppeln Sie die Cache-Lebensdauer daran, wie oft sich die Seite tatsächlich ändert.
  • Vary / User-Agent-Fragmentierung des Caches. Der Schlüssel eines Shared Caches ist normalerweise nur die URL; Vary fügt Request-Header (etwa User-Agent oder Accept-Language) zu diesem Schlüssel hinzu, damit verschiedene Varianten getrennt gespeichert werden. Fehlt ein Header, der die Antwort tatsächlich verändert, kann ein Requester die Variante eines anderen erhalten — die Verwechslung von Mobile/Desktop oder Bot/Mensch. Fügen Sie Vary zu viele Header hinzu, fragmentieren Sie den Cache in so viele fast identische Schlüssel, dass sich die Trefferquote kaum verbessert. Separat partitionieren moderne Browser aus Datenschutzgründen auch ihre eigenen Caches nach Top-Level-Site, sodass eine beim Einbetten auf einer Website gecachte Ressource im Allgemeinen nicht beim Einbetten auf einer anderen wiederverwendet wird — ein anderer Mechanismus als Vary, den Sie beim Debuggen eines „Warum ist das nicht gecacht?“-Berichts nicht vermischen sollten.

Meine allgemeine Faustregel für die Dauer stammt aus der LCP-Arbeit: In meinem Ahrefs-Leitfaden zum Largest Contentful Paint habe ich sie so formuliert: “Your cache time should be as long as you are comfortable with” (Übersetzung) „Ihre Cache-Dauer sollte so lang sein, wie es für Sie vertretbar ist“ — und “An ideal setup is to cache for a really long period of time but purge the cache when you make a change to a page.” (Übersetzung) „Optimal ist eine sehr lange Cache-Dauer, aber der Cache sollte geleert werden, wenn Sie eine Seite ändern.“ Langer Cache, sofortiges Leeren. Diese Kombination hält Sie schnell und aktuell.

Ist Caching ein Rankingfaktor?

Nein — nicht direkt. Es gibt kein Ranking-Signal dafür, dass ETags gesetzt sind oder eine gute Cache-Control-Policy vorliegt. Caching beeinflusst zwei Dinge, die für Sichtbarkeit wichtig sind: Seitengeschwindigkeit/Core Web Vitals (ein ausdrücklicher Input der Seitenerfahrung) und Crawling-Effizienz (sie bestimmt, wie schnell neue und aktualisierte Inhalte entdeckt und aufgefrischt werden, und berührt damit indirekt frischeabhängige Ergebnisse). Richten Sie Caching ein, weil es Ihre Website schnell und leicht crawlbar macht — nicht, weil Sie einen direkten Ranking-Schub erwarten.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.