HTML
Kurz oder moderat cachen, aber immer revalidierbar halten. Keine immutable-Direktive für kanonische Seiten.
← Zur Kategorie Technik
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 möglich sind und wie konsistent HTML, Assets und Freshness-Signale ausgeliefert werden.
Autor: Redaktion KI-Q
Veröffentlicht: 07.04.2026
Aktualisiert: 07.04.2026
Quellen: Google Search Central, MDN, web.dev
Warum Cache-Header über Performance hinausgehen
Google hat mehrfach erklärt, dass Googlebot bedingte Requests mit ETag und Last-Modified unterstützt. Wenn ein Dokument unverändert ist und der Server korrekt mit 304 Not Modified antwortet, muss der Inhalt nicht erneut komplett übertragen werden. Das spart Bandbreite und macht Revalidierung effizienter.
Gleichzeitig gilt: Nicht jedes Objekt sollte gleich behandelt werden. Versionierte CSS- und JS-Dateien können 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 ändern können.
Versionierte Assets
Lange TTL, Fingerprint im Dateinamen und optional immutable. Genau hier liegt der größte sichere Hebel.
Freshness-Signale
lastmod, dateModified und echte Inhaltsänderungen müssen zusammenpassen, sonst entstehen widersprüchliche Signale.
1. Was ETag und Last-Modified praktisch leisten
ETag liefert einen Identifier für eine bestimmte Version einer Ressource. Last-Modified liefert einen Zeitstempel. Fordert ein Client oder Bot die Ressource später erneut an, kann der Server prüfen, ob sich seitdem wirklich etwas geändert hat.
Wenn nichts neu ist, folgt idealerweise eine 304-Antwort statt eines erneuten kompletten 200-Downloads. Google Search Central empfiehlt außerdem, bei Last-Modified ein korrektes HTTP-Datumsformat zu verwenden und zusätzlich 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 ändert sich inhaltlich, semantisch und für SEO häufiger als Assets. |
| CSS/JS mit Fingerprint | public, max-age=31536000, immutable |
Die URL ändert sich bei jeder neuen Version. Lange TTL ist deshalb sicher. |
| Bilder mit stabiler URL | Moderate TTL + ETag/Last-Modified | Bei gleicher URL müssen Updates revalidierbar bleiben. |
| API/JSON für Frontend | Kurz cachen oder explizit revalidieren | Veraltete API-Antworten können Layout, Preise oder CTA-Logik falsch machen. |
3. immutable richtig einsetzen
MDN und web.dev behandeln immutable als Optimierung für Ressourcen, die sich unter derselben URL nicht mehr ändern 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 wäre derselbe Ansatz für HTML oder für 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 nötig ist
stale-while-revalidate kann sinnvoll sein, wenn Nutzer eine leicht veraltete Antwort kurzzeitig weiterverwenden duerfen, während im Hintergrund aktualisiert wird. Das kann bei bestimmten APIs, Bildern oder Edge-Caches Performance bringen.
Für kanonisches HTML sollte man vorsichtiger sein. Wenn Seiten häufig geändert 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 für 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 geändert, obwohl sich HTML und sichtbarer Inhalt nicht real geändert haben.Last-Modifiedwird aus Deploy-Zeit statt aus echter Inhaltsänderung gebaut und sendet dadurch irrelevante Freshness-Signale.- Assets haben keine Fingerprints, bekommen aber trotzdem sehr aggressive Cache-Direktiven.
- HTML, API und Assets werden über verschiedene Caches inkonsistent ausgeliefert, wodurch Layout-Brueche oder veraltete Meta-Daten entstehen.
- Server antwortet bei unveränderten Ressourcen immer wieder mit vollem
200statt sauberer Revalidierung.
6. Pragmatische Baseline für Laravel- und Vite-Projekte
Für 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 häufigen Updates: keine ewige TTL ohne Versionierung.
- Sitemap-
lastmod, JSON-LD-dateModifiedund echte Inhaltsänderung synchron halten. - Nach Deploys prüfen, 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 gegenprüfen.
# 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 Übertragung 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 bestätigt Unterstuetzung für 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 — Frühe, aber weiterhin nützliche Einordnung zu 304 Not Modified und reduzierter Bandbreite bei unveränderten Seiten.
- MDN: Cache-Control header — Referenz für 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 für 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 spät auffallen. Wir priorisieren die Stellen, an denen Caching, Rendering und Crawlbarkeit wirklich zusammenhängen.
Weiterführende Links für diese Seite