HTML
Kurz oder moderat cachen, aber immer revalidierbar halten. Keine immutable-Direktive fuer kanonische Seiten.
Technik
HTTP Cache SEO: ETag, Last-Modified und immutable Assets technisch sauber einsetzen
Viele Teams denken bei Caching nur an Ladezeit. Technisch sauber gesetzte Cache-Header beeinflussen aber auch, wie effizient Googlebot und andere Systeme Inhalte erneut abrufen, wann 304-Antworten moeglich sind und wie konsistent HTML, Assets und Freshness-Signale ausgeliefert werden.
Zuletzt aktualisiert: 07.04.2026
Quellen: Google Search Central, MDN, web.dev
Warum Cache-Header ueber Performance hinausgehen
Google hat mehrfach erklaert, dass Googlebot bedingte Requests mit ETag und Last-Modified unterstuetzt. Wenn ein Dokument unveraendert ist und der Server korrekt mit 304 Not Modified antwortet, muss der Inhalt nicht erneut komplett uebertragen werden. Das spart Bandbreite und macht Revalidierung effizienter.
Gleichzeitig gilt: Nicht jedes Objekt sollte gleich behandelt werden. Versionierte CSS- und JS-Dateien koennen sehr aggressiv gecacht werden. HTML-Dokumente dagegen brauchen meist kuerzere Fristen und saubere Revalidierung, weil Canonicals, structured data, interne Links, Metadaten oder sichtbare Inhalte sich aendern koennen.
Versionierte Assets
Lange TTL, Fingerprint im Dateinamen und optional immutable. Genau hier liegt der groesste sichere Hebel.
Freshness-Signale
lastmod, dateModified und echte Inhaltsaenderungen muessen zusammenpassen, sonst entstehen widerspruechliche Signale.
1. Was ETag und Last-Modified praktisch leisten
ETag liefert einen Identifier fuer eine bestimmte Version einer Ressource. Last-Modified liefert einen Zeitstempel. Fordert ein Client oder Bot die Ressource spaeter erneut an, kann der Server pruefen, ob sich seitdem wirklich etwas geaendert hat.
Wenn nichts neu ist, folgt idealerweise eine 304-Antwort statt eines erneuten kompletten 200-Downloads. Google Search Central empfiehlt ausserdem, bei Last-Modified ein korrektes HTTP-Datumsformat zu verwenden und zusaetzlich eine sinnvolle max-age-Angabe zu setzen, damit Crawler wissen, wann eine Revalidierung sinnvoll wird.
Cache-Control: public, max-age=300
ETag: "post-2026-04-07-v3"
Last-Modified: Tue, 07 Apr 2026 10:30:00 GMT2. Unterschied zwischen HTML und versionierten Assets
| Ressource | Empfehlung | Warum |
|---|---|---|
| HTML-Dokumente | public, max-age=0, must-revalidate oder kurze TTL mit Revalidierung |
HTML aendert sich inhaltlich, semantisch und fuer SEO haeufiger als Assets. |
| CSS/JS mit Fingerprint | public, max-age=31536000, immutable |
Die URL aendert sich bei jeder neuen Version. Lange TTL ist deshalb sicher. |
| Bilder mit stabiler URL | Moderate TTL + ETag/Last-Modified | Bei gleicher URL muessen Updates revalidierbar bleiben. |
| API/JSON fuer Frontend | Kurz cachen oder explizit revalidieren | Veraltete API-Antworten koennen Layout, Preise oder CTA-Logik falsch machen. |
3. immutable richtig einsetzen
MDN und web.dev behandeln immutable als Optimierung fuer Ressourcen, die sich unter derselben URL nicht mehr aendern sollen. In der Praxis bedeutet das: Nur versionierte Assets mit Hash im Dateinamen sind gute Kandidaten.
Ein typisches Beispiel sind von Vite generierte Dateien wie app-DcwmOEIp.css oder app-DcwmOEIp.js. Hier ist eine lange Lebensdauer sinnvoll, weil jede neue Version automatisch eine neue URL bekommt.
Falsch waere derselbe Ansatz fuer HTML oder fuer Bilder, die weiterhin unter derselben URL ausgetauscht werden. Dann bleibt alter Inhalt zu lange im Cache und kann visuelle, funktionale und SEO-bezogene Inkonsistenzen erzeugen.
Cache-Control: public, max-age=31536000, immutable4. Wo stale-while-revalidate hilft und wo Vorsicht noetig ist
stale-while-revalidate kann sinnvoll sein, wenn Nutzer eine leicht veraltete Antwort kurzzeitig weiterverwenden duerfen, waehrend im Hintergrund aktualisiert wird. Das kann bei bestimmten APIs, Bildern oder Edge-Caches Performance bringen.
Fuer kanonisches HTML sollte man vorsichtiger sein. Wenn Seiten haeufig geaendert werden, neue JSON-LD-Blöcke erhalten, andere Title/Description-Werte bekommen oder wichtige interne Links angepasst werden, ist zu aggressive Stale-Auslieferung kontraproduktiv.
Die technische Frage lautet also nicht nur: Kann ich das cachen? Sondern: Darf diese Ressource fuer Nutzer, Bots und Debugging-Tools kurzzeitig veraltet sein, ohne dass daraus Fehlinterpretationen entstehen?
5. Typische Fehlkonfigurationen mit SEO-Folgen
- HTML wird wie ein versioniertes Asset behandelt und mit sehr langer TTL oder immutable ausgeliefert.
lastmodim Sitemap-Eintrag wird geaendert, obwohl sich HTML und sichtbarer Inhalt nicht real geaendert haben.Last-Modifiedwird aus Deploy-Zeit statt aus echter Inhaltsaenderung gebaut und sendet dadurch irrelevante Freshness-Signale.- Assets haben keine Fingerprints, bekommen aber trotzdem sehr aggressive Cache-Direktiven.
- HTML, API und Assets werden ueber verschiedene Caches inkonsistent ausgeliefert, wodurch Layout-Brueche oder veraltete Meta-Daten entstehen.
- Server antwortet bei unveraenderten Ressourcen immer wieder mit vollem
200statt sauberer Revalidierung.
6. Pragmatische Baseline fuer Laravel- und Vite-Projekte
Fuer viele Laravel-Projekte ist diese Baseline solide:
- HTML: kurze TTL oder direkte Revalidierung, kein immutable.
- Vite-Build-Dateien in
/build/: lange TTL plus immutable. - Bilder mit haeufigen Updates: keine ewige TTL ohne Versionierung.
- Sitemap-
lastmod, JSON-LD-dateModifiedund echte Inhaltsaenderung synchron halten. - Nach Deploys pruefen, ob Edge-Cache, App-Cache und Browser-Cache dieselbe neue Version sehen.
- Bei wichtigen Landingpages Head-HTML, Canonical, Robots und strukturierte Daten immer mit
curl -Iund HTML-Check gegenpruefen.
# HTML
Cache-Control: public, max-age=0, must-revalidate
# Versionierte Vite-Assets
Cache-Control: public, max-age=31536000, immutableFAQ
Braucht jede Seite ETag und Last-Modified gleichzeitig?
Nicht zwingend. Beides kann funktionieren. Wichtig ist, dass die gewaehlte Revalidierungsstrategie sauber implementiert ist und nicht bei jeder Auslieferung kuenstlich neue Werte erzeugt.
Ist 304 ein Rankingfaktor?
Nein, nicht direkt. Der Nutzen liegt in effizienterer Revalidierung, geringerer Uebertragung und stabilerer technischer Auslieferung.
Kann falsches Caching SEO-Messungen verfälschen?
Ja. Wenn HTML, Assets oder APIs asynchron veralten, entstehen falsche Eindruecke bei Debugging, Rendering, Structured-Data-Checks und manuellen Audits.
Quellen
- Google Search Central Blog: Caching and crawling in December — Google bestaetigt Unterstuetzung fuer ETag sowie Last-Modified/If-Modified-Since und empfiehlt bei Last-Modified eine korrekte Datumsangabe plus max-age.
- Google Search Central Blog: Better details about when Googlebot last visited a page — fruehe, aber weiterhin nuetzliche Einordnung zu 304 Not Modified und reduzierter Bandbreite bei unveraenderten Seiten.
- MDN: Cache-Control header — Referenz fuer Direktiven wie max-age, immutable und stale-while-revalidate.
- web.dev: Prevent unnecessary network requests with the HTTP Cache — praxisnahe Erklaerung zu Revalidierung, Cache-Control und immutable fuer Assets.
- web.dev: Service worker caching and HTTP caching — gute Einordnung, wo Browser-, Edge- und andere Cache-Ebenen zusammenspielen.
Technische Auslieferung konsistent halten statt nur Caches aggressiv zu drehen
Wenn HTML, Assets, JSON-LD und Freshness-Signale nicht sauber zusammenspielen, entstehen genau die Fehler, die in technischen SEO-Audits oft erst spaet auffallen. Wir priorisieren die Stellen, an denen Caching, Rendering und Crawlbarkeit wirklich zusammenhaengen.
Weiterfuehrende Links fuer diese Seite