English
Server, HTTP & Caching

Cache-Control

Auch genannt: Cache-Control-Header

Cache-Control ist ein HTTP-Header, mit dem ein Server festlegt, ob und wie lange Browser, CDNs und andere Caches eine Antwort speichern und wiederverwenden dürfen. Der Header steuert damit Ladezeit, Serverlast und die Aktualität ausgelieferter Inhalte.

Wie funktioniert Cache-Control?

Der Server sendet Direktiven in der Antwort, durch Komma getrennt. Die wichtigsten laut MDN:

  • max-age=N hält die Antwort N Sekunden lang frisch.
  • s-maxage=N gilt nur für geteilte Caches wie CDNs und überschreibt dort max-age.
  • no-cache erlaubt das Speichern, verlangt aber vor jeder Wiederverwendung eine Prüfung beim Server.
  • no-store verbietet das Speichern vollständig.
  • public erlaubt das Speichern in geteilten Caches, private nur im Browser des einzelnen Nutzers.
  • immutable kennzeichnet Inhalte, die sich während der Frischezeit nicht ändern.
  • stale-while-revalidate=N erlaubt, eine abgelaufene Antwort noch N Sekunden zu nutzen, während im Hintergrund geprüft wird.

Die Prüfung beim Server läuft meist über ETag oder Last-Modified. Hat sich nichts geändert, antwortet der Server mit 304 ohne Inhalt.

Cache-Control und SEO

Google unterstützt heuristisches HTTP-Caching nach dem HTTP-Standard, vor allem über ETag/If-None-Match und Last-Modified/If-Modified-Since. Laut Dokumentation sollte man ETag bevorzugen, weil es keine Probleme mit Datumsformaten gibt. Für Cache-Control schreibt Google, max-age sei nicht erforderlich, aber als Ergänzung zu erwägen, damit Crawler besser einschätzen können, wann eine URL wieder gecrawlt werden soll. Andere HTTP-Caching-Richtlinien unterstützt Google nach eigener Angabe nicht. Ob ein einzelner Crawler Caching nutzt, hängt vom zugehörigen Produkt ab.

Cache-Header und 304 im Vergleich
Header / StatusGegenstück in der AnfrageWas es tutBedeutung für Google-Crawler
Cache-Control (dieser Begriff)– (Direktiven auch in Anfragen möglich)listet Direktiven für Caches, z. B. max-age (frisch für N Sekunden), no-cache (Wiederverwendung nur nach Prüfung), no-store (nicht speichern)max-age ist optional und hilft Crawlern einzuschätzen, wann sie die URL wieder abrufen; andere Caching-Direktiven unterstützt Google nicht
ETagIf-None-MatchKennung für die aktuelle Version einer Ressourceunterstützt und von Google empfohlen, weil es keine Probleme mit Datumsformaten gibt; hat Vorrang, wenn beide Validatoren gesetzt sind
Last-ModifiedIf-Modified-SinceZeitpunkt, zu dem die Ressource laut Server zuletzt geändert wurdeunterstützt; das Datum muss dem HTTP-Format entsprechen, z. B. Fri, 4 Sep 1998 19:15:56 GMT
304 Not ModifiedAntwort auf eine bedingte GET- oder HEAD-Anfragemeldet, dass die gespeicherte Kopie noch gilt; die Antwort hat keinen Bodyder Crawler meldet dem nächsten System, dass der Inhalt dem letzten Crawl entspricht; die Suche kann Signale neu berechnen, sonst keine Wirkung auf die Indexierung

Google rät, ETag und Last-Modified beide zu setzen, weil auch andere Anwendungen sie nutzen. Ob ein Google-Crawler Caching nutzt, hängt vom zugehörigen Produkt ab: Googlebot nutzt es beim erneuten Crawlen für die Google Suche. Laut Google-Blog vom Dezember 2024 ließen sich nur 0,017 % aller Abrufe aus dem Cache bedienen. Quellen: Google Crawling Infrastructure: Overview of Google crawlers and fetchers, HTTP caching (last updated 2026-06-12); Google Search Central Blog: Crawling December: HTTP caching (2024-12-09); Google Crawling Infrastructure: HTTP status codes, network and DNS errors (last updated 2026-02-04); MDN: HTTP caching; RFC 9111: HTTP Caching; RFC 9110: HTTP Semantics (8.8.2 Last-Modified, 8.8.3 ETag, 15.4.5 304). Stand: .

Beispiel

HTTP
# Statische Datei mit Hash im Dateinamen
Cache-Control: public, max-age=31536000, immutable

# HTML-Seite, die vor jeder Nutzung geprüft werden soll
Cache-Control: no-cache

# Seite mit Kundendaten
Cache-Control: private, no-store

Häufige Fehler

  • no-cache wird als „nicht speichern“ gelesen. Dafür gilt no-store.
  • Lange max-age-Werte auf Dateien ohne Versionierung im Dateinamen. Nutzer sehen dann alte CSS- oder JS-Dateien.
  • public bei personalisierten Antworten, die ein geteilter Cache ausliefern könnte.
  • Kein Header gesetzt. Caches dürfen dann heuristisch entscheiden, wie lange sie speichern (MDN).

Quellen

  1. Cache-Control – MDN Web Docsdeveloper.mozilla.org
  2. Übersicht über die Google-Crawler (HTTP-Caching) – Google Search Centraldevelopers.google.com
  3. RFC 9111: HTTP Caching – IETFrfc-editor.org

Stand: