Der HTTP 304 Not Modified Header informiert den Googlebot darüber, dass eine angeforderte Seite seit seinem letzten Besuch unverändert geblieben ist, wodurch der Crawler das Herunterladen des gesamten Antwortkörpers überspringen kann. Durch die Verwendung dieses Statuscodes bestätigt Ihr Server, dass die im Google-Index gespeicherte Version aktuell bleibt. Diese Kommunikation spart erheblich Bandbreite und Server-Rechenleistung sowohl für den Website-Betreiber als auch für die Google-Suchinfrastruktur.
Die effiziente Verwaltung einer Website erfordert ein klares Verständnis davon, wie Crawler mit Ihrer Server-Hardware interagieren. Wenn der Googlebot eine Seite anfordert, muss er nicht immer die vollständige HTML-Datei erhalten, um zu bestätigen, dass der Inhalt noch relevant ist. Der 304-Statuscode dient als leichtgewichtiges Validierungssignal, das bestätigt, dass der Seitenstatus identisch mit dem letzten dokumentierten Crawl ist. Die korrekte Implementierung dieses Protokolls ist eine Standardpraxis zur Aufrechterhaltung einer leistungsstarken Webarchitektur.
Warum prüft der Googlebot auf den 304-Statuscode?
Der Googlebot arbeitet mit einem spezifischen Crawl-Budget für jede Domain, das die Menge an Zeit und Ressourcen darstellt, die der Crawler Ihrer Website zuweist. Wenn Ihr Server so konfiguriert ist, dass er einen 304-Statuscode zurückgibt, wenn der Inhalt identisch ist, erkennt der Crawler, dass er den gesamten Seitenkörper nicht erneut verarbeiten muss. Dies verhindert, dass der Bot redundante Aufgaben ausführt, die keinen Mehrwert für den Index bieten.
In einem typischen Konto kann sich der technische Overhead schnell ansammeln, wenn der Server für jede Anfrage einen vollständigen Download erzwingt. Durch die Bereitstellung einer 304-Antwort minimiert der Server die über das Netzwerk übertragene Datenmenge. Diese Effizienz stellt sicher, dass der Crawler seine begrenzte Zeit damit verbringt, neue Seiten zu entdecken oder wichtige Updates zu identifizieren, anstatt wiederholt statische Dateien zu indexieren, die seit Monaten oder sogar Jahren unverändert geblieben sind.
Wie funktioniert der Prozess der bedingten Anfrage?
Der Mechanismus basiert auf zwei spezifischen HTTP-Headern: If-Modified-Since und ETag. Wenn der Googlebot eine Seite anfordert, die er bereits besucht hat, fügt er das Datum seines letzten Besuchs oder den ETag-Identifikator in die Anfrage-Header ein. Dies ermöglicht es dem Server, die aktuelle Version der Ressource mit der Version zu vergleichen, die zuvor von der Suchmaschine gesehen wurde.
- Der Googlebot sendet eine Anfrage mit dem ‘If-Modified-Since’-Header, der den Zeitstempel der letzten zwischengespeicherten Version enthält.
- Ihr Server prüft das Änderungsdatum der Datei gegen diesen Zeitstempel.
- Wenn die Datei unverändert ist, gibt der Server einen 304-Statuscode ohne den Antwortkörper zurück.
- Der Googlebot bestätigt, dass der Inhalt aktuell ist, und geht zum nächsten URL in seiner Warteschlange über.
Wenn der Server eine ETag-Übereinstimmung erkennt, vermeidet er den hohen Aufwand, das gesamte Dokument neu zu generieren oder abzurufen. Stattdessen sendet er einen kurzen HTTP-Antwort-Header. Dieser Handshake ist im Vergleich zu einer vollständigen Dokumentübertragung extrem schnell und reduziert die Latenz für jedes Crawl-Ereignis erheblich. Es ist eine grundlegende Methode zur Optimierung der Kommunikation zwischen Ihrer Hosting-Umgebung und den Rechenzentren von Google.
Was sind die Vorteile einer korrekten 304-Implementierung?
Das korrekte Bereitstellen von 304-Headern reduziert die Serverlast und Latenz. Wenn Ihr Server nicht für jede einzelne Crawl-Anfrage das vollständige HTML, CSS oder JavaScript generieren muss, spart dies Speicher und CPU-Zyklen. Dies ist besonders nützlich für große Websites mit Tausenden von Seiten, die sich nicht täglich ändern, wie z. B. Archivbereiche oder Richtlinienseiten.
Darüber hinaus kann die Reduzierung der pro Anfrage heruntergeladenen Gesamtbytes zu schnelleren Crawl-Zyklen führen. Wenn Ihr Server derzeit bei Crawl-Bursts mit hohem Verkehrsaufkommen zu kämpfen hat, können 304-Antworten als Druckentlastungsventil fungieren. Durch die Bereitstellung dieser Statuscodes ermöglichen Sie dem Googlebot, seine Aufgabe schneller zu erledigen, was zu einer effizienteren Nutzung Ihrer Bandbreite und potenziell zu einer höheren Crawl-Frequenz für die Seiten führt, die tatsächlich wichtig sind.
Google verwendet moderne Protokolle, um Ressourcen auf beiden Seiten des Crawling-Prozesses zu sparen.
Google Search Central
Wie Alien Road diese Technologie anwendet
Bei Alien Road führen wir eine tiefgehende Server-Log-Analyse durch, um sicherzustellen, dass der Googlebot gegebenenfalls 304-Statuscodes erhält. Wir beginnen mit der Überprüfung der ‘If-Modified-Since’- und ‘ETag’-Logik innerhalb Ihrer Serverkonfiguration oder Ihres Anwendungs-Frameworks. Bei einem typischen E-Commerce-Kunden stellen wir oft fest, dass statische Produktbeschreibungsseiten unnötigerweise erneut gecrawlt werden, weil der Server das letzte Änderungsdatum nicht korrekt validiert.
Unser Prozess umfasst die Prüfung der Server-Antwort-Header während einer Simulation von Googlebot-Anfragen. Wir prüfen, ob der Server die vom Crawler gesendeten bedingten Header angemessen auswertet. Wenn wir feststellen, dass der Server für jede einzelne Anfrage einen 200 OK zurückgibt, selbst für Dateien, die sich nicht geändert haben, implementieren wir serverseitige Anpassungen, um sicherzustellen, dass die Header korrekt gesendet werden.
- Überprüfen Sie die Server-Zugriffsprotokolle, um hochfrequente Crawl-Muster bei statischen Assets zu identifizieren.
- Stellen Sie sicher, dass die ETag-Generierung aktiviert ist und korrekt mit den Dateiversionen übereinstimmt.
- Testen Sie Serverantworten mit Tools wie cURL, um sicherzustellen, dass 304-Antworten für unveränderte Dateien zurückgegeben werden.
- Überwachen Sie die Crawl-Statistiken der Google Search Console, um eine Reduzierung der pro Tag heruntergeladenen Gesamtbytes zu bestätigen.
Ist 304 besser als eine 200 OK-Antwort?
Eine 200 OK-Antwort zeigt an, dass der Server den Inhalt der Seite erfolgreich geliefert hat, was eine vollständige Datenübertragung erfordert. Im Gegensatz dazu ist eine 304-Antwort ein leichtgewichtiges Signal, das die vollständige Übertragung verhindert. Während eine 200-Antwort für neue oder aktualisierte Inhalte notwendig ist, ist die 304-Antwort das ideale Ergebnis für statische Seiten, da sie die Frische ohne den Ressourcen-Overhead bestätigt.
Die Wahl zwischen diesen Antworten ist keine Frage der Präferenz, sondern der Protokollgenauigkeit. Wenn Sie einen 304 bereitstellen, wenn sich der Inhalt tatsächlich geändert hat, wird der Googlebot weiterhin die veraltete Version in seinem Cache verwenden. Deshalb ist das Testen Ihrer Serverkonfiguration ein Kernbestandteil jedes technischen Audits. Das Ziel ist es, der Suchmaschine die genauesten Informationen so schnell wie möglich bereitzustellen.
Wo man diese Woche anfangen sollte
Beginnen Sie damit, die Header Ihrer am häufigsten gecrawlten Seiten über den Netzwerk-Tab in den Entwicklertools Ihres Browsers zu überprüfen. Suchen Sie nach den ‘ETag’- oder ‘Last-Modified’-Headern in der Antwort. Wenn diese Header fehlen, unterstützt Ihr Server möglicherweise keine bedingten Anfragen ordnungsgemäß, und Sie sollten Ihre Webserverkonfiguration, wie Apache oder Nginx, aktualisieren, um diese Einstellungen einzubeziehen.
Sobald Sie bestätigt haben, dass die Header gesendet werden, behalten Sie Ihre Serverprotokolle für die nächsten Tage im Auge. Filtern Sie die Protokolle nach Googlebot-User-Agents und suchen Sie nach einem Anstieg der 304-Antwortcodes. Dies ist ein klarer Indikator dafür, dass Ihr Server erfolgreich mit dem Crawler kommuniziert und Ihre Ressourcen für die Momente bewahrt, in denen sie wirklich benötigt werden.