If Modified Since
Was ist der If-Modified-Since-Header?
Der If-Modified-Since-Header ist ein HTTP-Request-Header für bedingte Anfragen. Ein Client teilt damit mit, dass eine Ressource nur dann erneut übertragen werden soll, wenn sie sich seit einem bestimmten Zeitpunkt geändert hat. Ist keine Änderung erfolgt, antwortet der Server idealerweise mit dem Statuscode 304 und spart dadurch Bandbreite, Ladezeit und Crawling-Ressourcen.
Der If-Modified-Since-Header gehört zur HTTP-Kommunikation zwischen Browser, Crawler und Server. Im SEO-Kontext wird der Header oft als Teil von Caching- und Serverlogik relevant, weil Suchmaschinen nicht jede Datei bei jedem Abruf vollständig neu laden müssen. Die deutsche Entsprechung lautet einmalig: wenn seit einem Zeitpunkt geändert. Gemeint ist immer eine bedingte Anfrage auf Basis eines Datums.
Wie der If-Modified-Since-Header funktioniert
Der If-Modified-Since-Header wird vom Client im Request gesendet und bezieht sich auf den letzten bekannten Änderungszeitpunkt einer Ressource. Der Server vergleicht dieses Datum mit dem tatsächlichen Änderungsdatum der angefragten URL oder Datei. Wenn die Ressource seit diesem Zeitpunkt unverändert ist, sollte der Server 304 Not Modified liefern. Wenn sie neuer ist, folgt meist 200 OK mit vollständigem Inhalt.
Die Mechanik ist einfach, wird in der Praxis aber oft falsch verstanden: Der If-Modified-Since-Header prüft keine inhaltliche Ähnlichkeit und keine Relevanz für Google. Der If-Modified-Since-Header prüft ausschließlich, ob der Server die Ressource seit einem Zeitstempel als geändert betrachtet. Ein einzelner Leerraum im HTML, ein neu erzeugtes Build-Datum oder eine CMS-interne Aktualisierung kann deshalb schon dazu führen, dass wieder 200 OK statt 304 Not Modified zurückkommt.
Für Browser ist das vor allem ein Performance-Thema. Für Suchmaschinen ist es zusätzlich ein Effizienzsignal. Ein Crawler, der bei unveränderten Dateien regelmäßig 304 Not Modified erhält, kann seine Abrufe wirtschaftlicher verteilen. Genau deshalb gehört das Thema zur technischen SEO und passt fachlich in ein technisches SEO-Audit.
Was 304 Not Modified wirklich bedeutet
304 Not Modified wird häufig mit einem SEO-Vorteil an sich verwechselt. Genau das ist der Denkfehler. Der Statuscode verbessert keine Rankings direkt, und er ersetzt auch keine saubere Informationsarchitektur. 304 Not Modified bedeutet nur, dass eine bereits bekannte Ressource unverändert blieb und deshalb nicht noch einmal vollständig übertragen werden musste. Der Nutzen liegt in Effizienz, Serverlast und schnelleren Wiederabrufen, nicht in einem unmittelbaren Ranking-Boost.
Der Statuscode ist besonders sinnvoll bei statischen oder selten geänderten Ressourcen wie Bildern, JavaScript, CSS, PDFs oder älteren HTML-Seiten. Bei stark personalisierten Seiten, dynamisch generierten Responses oder unpräzisen Last-Modified-Zeitstempeln ist der Effekt kleiner. Wenn ein Server bei jedem Request ein neues Änderungsdatum erzeugt, kann der If-Modified-Since-Header seinen Zweck praktisch nicht mehr erfüllen.
If-Modified-Since und Last-Modified: der Unterschied
Der Unterschied zwischen If-Modified-Since und Last-Modified liegt in der Richtung der Kommunikation. Last-Modified ist ein Response-Header des Servers. Er teilt dem Client mit, wann eine Ressource zuletzt geändert wurde. If-Modified-Since ist der spätere Request-Header des Clients, der genau dieses Datum wiederverwendet, um eine bedingte Anfrage zu stellen.
Ohne einen sinnvollen Last-Modified-Wert fehlt dem Client oft die Grundlage für den nächsten bedingten Abruf. Deshalb hängen beide Header technisch zusammen, obwohl sie nicht dasselbe sind. Wer Serverantworten prüft, sollte diese Abfolge konkret kontrollieren: erst Last-Modified im Response, danach bei einem erneuten Abruf If-Modified-Since im Request und im Idealfall 304 Not Modified im Response.
Warum der If-Modified-Since-Header für SEO relevant ist
Der If-Modified-Since-Header beeinflusst technische SEO indirekt über Crawling-Effizienz und Performance. Suchmaschinen-Crawler müssen Milliarden von URLs wirtschaftlich abrufen. Wenn unveränderte Ressourcen zuverlässig per 304 Not Modified beantwortet werden, sinken unnötige Datenübertragungen. Das kann helfen, Serverressourcen für wirklich neue oder geänderte Inhalte freizuhalten. Im Umfeld von technischem Crawling und Website-Optimierung für Google ist das ein wiederkehrender Prüfpunkt.
Der SEO-Effekt ist aber begrenzt und klar einzuordnen. Eine schlecht verlinkte URL wird durch den If-Modified-Since-Header nicht besser gefunden. Dünner Content wird durch 304 Not Modified nicht hochwertiger. Und eine fehlerhafte Indexierungslogik wird dadurch nicht repariert. Der Header ist ein Infrastrukturthema. Er unterstützt gutes SEO, ersetzt gutes SEO aber nicht.
Typische Fehler bei If-Modified-Since
Ein häufiger Fehler ist die Annahme, dass jeder 304-Response automatisch korrekt ist. Das stimmt nicht. Wenn Inhalte tatsächlich geändert wurden, aber der Server trotzdem 304 Not Modified zurückgibt, sehen Browser und Crawler veraltete Versionen. Das kann bei Relaunches, Preisänderungen, strukturierten Daten oder aktualisierten Canonical-Tags problematisch werden, weil technische Änderungen verspätet ausgeliefert werden.
Ebenso verbreitet ist das Gegenproblem: Der Server liefert fast nie 304 Not Modified, weil das Änderungsdatum bei jedem Deploy, Cache-Warmup oder Template-Render neu gesetzt wird. Dann werden auch unveränderte Ressourcen immer wieder vollständig ausgeliefert. Das kostet Bandbreite und verlangsamt wiederholte Abrufe. Bei großen Websites mit vielen Assets summiert sich dieser Mehraufwand deutlich.
So prüfst du den Header in der Praxis
Der If-Modified-Since-Header lässt sich mit den Browser-Developer-Tools, per curl oder in technischen Crawls prüfen. Für eine belastbare Bewertung reichen zwei Abrufe derselben Ressource: Zuerst kontrollierst du, ob der Server einen plausiblen Last-Modified-Header sendet. Danach fragst du dieselbe Ressource mit diesem Datum im If-Modified-Since-Header erneut an. Bleibt die Datei unverändert, ist 304 Not Modified die erwartbare Antwort.
Messbar ist das zum Beispiel so: In einem technischen Crawl oder Monitoring prüfst du, ob statische Ressourcen sauber mit Statuscodes und Headern antworten. Genau dafür werden technische Checks und Statuscode-Analysen im Alltag genutzt, etwa mit einem Technik-Crawler für technische SEO-Prüfungen oder ergänzend über einen kostenlosen SEO-Check. Wichtig ist die Reihenfolge: erst den Header sehen, dann die Reaktion auf den Folgeabruf bewerten.
Prüfe hier die technische Basis deiner Domain direkt im Artikel:
Abgrenzung zu ETag und Cache-Control
Der Unterschied zwischen If-Modified-Since und ETag liegt in der Art des Vergleichs. If-Modified-Since arbeitet mit einem Datum. ETag arbeitet mit einer Kennung für eine konkrete Version der Ressource. ETag kann präziser sein, wenn Datumswerte ungenau sind oder Inhalte sehr häufig ausgeliefert werden. Der Nachteil ist, dass ETags in verteilten Systemen sauber synchronisiert sein müssen, sonst entstehen unnötige Unterschiede zwischen Servern.
Der Unterschied zwischen If-Modified-Since und Cache-Control liegt wiederum in der Aufgabe. Cache-Control steuert, ob und wie lange eine Ressource zwischengespeichert werden darf. If-Modified-Since steuert die bedingte Rückfrage nach Ablauf oder erneuter Prüfung. Beide Mechanismen arbeiten oft zusammen. Cache-Control bestimmt das Caching-Verhalten, If-Modified-Since reduziert den Aufwand beim erneuten Abruf.
Praxisnutzen im SEO-Alltag 2026
Im Alltag ist der If-Modified-Since-Header vor allem bei größeren Websites mit vielen wiederkehrend geladenen Ressourcen nützlich. Shops, Publisher und Unternehmensseiten mit umfangreichen Bild-, CSS- und JavaScript-Dateien profitieren am stärksten. Eine kurze Beobachtung aus Projekten seit 2008: Probleme entstehen selten durch den Header selbst, sondern fast immer durch ungenaue Serverlogik, Caching-Layer oder Deploy-Prozesse, die Änderungsdaten unbeabsichtigt verfälschen.
Wenn du technische SEO, Performance und saubere Serverantworten strukturiert prüfen willst, ist ein transparenter Prüfprozess sinnvoll. Für tiefergehende Analysen oder ein sauberes technisches Setup findest du auf der Seite zu Full-Service-SEO und im kostenlosen Potenzialcheck passende Anlaufstellen.
Häufige Fragen zum If-Modified-Since-Header
Ist If-Modified-Since das Gleiche wie Last-Modified?
Nein. Last-Modified ist die Serverangabe zum letzten Änderungszeitpunkt einer Ressource. If-Modified-Since ist die spätere Anfrage des Clients mit genau diesem Datum, um nur bei Änderungen neuen Inhalt abzurufen.
Verbessert 304 Not Modified direkt mein Google-Ranking?
Nein. 304 Not Modified ist kein direkter Rankingfaktor im Sinne eines Bonus. Der Nutzen liegt in effizienteren Abrufen, geringerer Serverlast und oft besseren technischen Rahmenbedingungen für Crawling und Performance.
Wo sehe ich, ob ein Server If-Modified-Since unterstützt?
Am einfachsten in den Browser-Developer-Tools oder per curl. Du prüfst zuerst den Last-Modified-Header und sendest dann denselben Wert in einer zweiten Anfrage als If-Modified-Since. Reagiert der Server bei unverändertem Inhalt mit 304, funktioniert die Logik.
Brauche ich If-Modified-Since auch bei HTML-Seiten?
Das kann sinnvoll sein, wenn HTML-Seiten nicht bei jedem Aufruf dynamisch neu erzeugt werden. Bei stark personalisierten oder ständig neu gerenderten Seiten ist der Effekt oft kleiner als bei statischen Assets wie Bildern, CSS oder JavaScript.
Was ist besser: ETag oder If-Modified-Since?
Das hängt vom Setup ab. ETag ist oft präziser, weil eine konkrete Versionskennung verglichen wird. If-Modified-Since ist einfacher und arbeitet nur mit einem Datum. Viele Systeme nutzen beide Verfahren parallel.
Kann ein falscher 304-Status SEO-Probleme auslösen?
Ja. Wenn der Server geänderte Inhalte trotzdem als unverändert behandelt, sehen Browser und Crawler veraltete Versionen. Das kann dazu führen, dass technische oder inhaltliche Anpassungen verspätet erkannt werden.
Sie haben noch Fragen?
