XML-Sitemap: ein identisches lastmod auf allen URLs macht Ihre Sitemap nutzlos

Eine XML-Sitemap sagt den Suchmaschinen, welche URLs es gibt und welche sich geändert haben. Die erste Funktion erfüllt fast jedes CMS. Die zweite verfehlt ein guter Teil von ihnen, und zwar unsichtbar: Die Datei ist gültig, die Search Console liest sie fehlerfrei, und trotzdem liefert sie keine Information mehr darüber, was sich bewegt hat. Die Ursache liegt an einem einzigen Feld, lastmod, und daran, wie es gefüllt wird.

Was Google mit lastmod wirklich macht

Die Position von Google steht schwarz auf weiß in seiner Dokumentation zum Erstellen einer Sitemap: Der Wert von lastmod wird genutzt, „wenn er stimmig und überprüfbar ist“, zum Beispiel im Abgleich mit der tatsächlich letzten Änderung der Seite. Google ergänzt, dass die Felder priority und changefreq ignoriert werden. Von den drei optionalen Feldern des Formats zählt eines, und auch das nur, wenn es die Wahrheit sagt.

Aus Sicht der Suchmaschine sieht die Rechnung so aus. Ein Bot verfügt je Website über ein begrenztes Crawl-Budget. Liest er eine Sitemap erneut, vergleicht er die angegebenen Daten mit denen, die er gespeichert hat. Eine URL, deren Datum vorgerückt ist, verdient einen neuen Besuch; eine URL, deren Datum sich nicht bewegt hat, kann warten. Rücken bei jedem Lesen alle Daten gleichzeitig vor, kann die Suchmaschine eine wirklich aktualisierte Seite nicht mehr von einer unveränderten unterscheiden. Sie vertraut dem Feld irgendwann nicht mehr und fällt auf ihre eigenen Heuristiken zurück, die meist langsamer sind.

Der typische Defekt: das Datum des Builds

Viele Generatoren statischer Websites und eine ganze Reihe von CMS schreiben in lastmod das Datum, an dem die Website neu erzeugt wurde. Auf einer täglich veröffentlichenden Website tragen dann alle URLs das Tagesdatum, auch drei Jahre alte Artikel, die niemand angefasst hat. Die Sitemap meldet permanent, dass sich alles geändert hat.

Wir haben diesen Defekt im Sommer 2026 auf mehreren Websites im Produktivbetrieb überprüft, auf insgesamt über dreihundert URLs: in jedem Fall ein einziger lastmod-Wert für die gesamte Sitemap, gleich der Uhrzeit des letzten Builds. Keine dieser Websites schickte im Übrigen einen HTTP-Header Last-Modified oder ein ETag auf ihren Seiten, und keine beantwortete die bedingten Anfragen der Bots. Die Suchmaschine hatte also keine Möglichkeit zu wissen, was sie neu laden sollte.

Diagnose in drei Prüfungen

Die Prüfung dauert wenige Minuten und braucht nur ein Terminal.

1. Die verschiedenen lastmod-Werte zählen. Die Sitemap abrufen, die lastmod-Tags extrahieren und die eindeutigen Werte zählen. Eine gesunde Sitemap auf einer Website mit mehreren hundert Seiten enthält Dutzende davon. Ein einziger Wert, oder eine Handvoll Werte mit demselben Tagesdatum, zeigt den Defekt an.
2. lastmod mit der Seite vergleichen. Eine alte URL aus der Sitemap nehmen, die Seite öffnen und das im Artikel oder in seinen strukturierten Daten angezeigte Änderungsdatum mit dem lastmod-Wert vergleichen. Eine Abweichung von mehreren Monaten bestätigt, dass lastmod die Seite nicht beschreibt.
3. Die HTTP-Header testen. Eine Seite mit einer HEAD-Anfrage abrufen und sehen, ob der Server Last-Modified oder ETag zurückgibt. Dann dieselbe Anfrage erneut senden, diesmal mit If-Modified-Since auf dem empfangenen Datum. Ein Server, der 304 Not Modified antwortet, kann sagen, dass eine Seite sich nicht geändert hat; ein Server, der jedes Mal 200 zurückgibt, zwingt den Bot, alles erneut herunterzuladen.

Diese drei Tests brauchen kein kostenpflichtiges Werkzeug. Sie gehören zu den Prüfungen, die wir vor jeder Diskussion über die Indexierung eines Mediums empfehlen.

Warum das für ein Medium schwerer wiegt als für eine Unternehmenswebsite

Eine Unternehmenswebsite mit zwanzig Seiten wird ohnehin vollständig neu gecrawlt. Ein Medium, das mehrere Artikel pro Woche veröffentlicht und andere korrigiert, lebt von einem verlässlichen Aktualitätssignal: Es bringt einen aktualisierten Artikel wieder nach oben, und es bewahrt den Bot davor, sein Budget auf unveränderten Seiten auszugeben. Ist das Signal kaputt, zeigen sich nach einigen Wochen zwei Symptome:

• Neue Artikel brauchen länger bis zur Indexierung, weil sie in einer Sitemap untergehen, in der alles neu erscheint.
• Korrekturen an alten Artikeln werden nicht berücksichtigt, weil nichts eine korrigierte Seite von einer Seite unterscheidet, die ein Build lediglich neu erzeugt hat.

Bei einem Medium, das auch generative Engines anvisiert, zahlt man das Problem ein zweites Mal: Die Bots der KI-Suche, die sich auf dieselben Sitemaps stützen, erben es. Ein Inhalt, der zur Korrektur einer Zahl überarbeitet wurde, wird wochenlang weiter in seiner alten Fassung ausgeliefert.

Das Kriterium für die Korrektur

Den Defekt zu beheben heißt, lastmod das Datum der letzten redaktionellen Änderung jeder Seite tragen zu lassen, und nichts anderes. Konkret:

Das Abnahmekriterium ist dasselbe wie das der Diagnose: Nach der Korrektur muss die Zahl der verschiedenen lastmod-Werte die tatsächliche Geschichte des Mediums abbilden, und zwei aufeinanderfolgende Builds ohne redaktionelle Änderung müssen zwei identische Sitemaps ergeben. Ändert sich die Sitemap, obwohl nichts geschrieben wurde, ist die Korrektur nicht erledigt.

Der Sonderfall des Mediums im Unterverzeichnis

Liegt ein Medium unter einem Pfad der Hauptwebsite, zum Beispiel ein Blog, der unter /blog/ von einer anderen Plattform ausgeliefert wird, kommt eine zweite Schwierigkeit hinzu: Die robots.txt, die die Sitemap deklariert, wird nur an der Wurzel des Hosts gelesen. Eine robots.txt im Unterverzeichnis wird nie abgerufen, und die Sitemap-Zeilen darin existieren für die Suchmaschinen nicht, wie die Dokumentation von Google zu robots.txt in Erinnerung ruft. Die Sitemap des Mediums muss dann in der robots.txt der Hauptwebsite deklariert oder direkt in der Search Console eingereicht werden. Google hat 2023 die Möglichkeit gestrichen, eine Sitemap per einfacher HTTP-Anfrage zu „pingen“: Ohne ausdrückliche Deklaration hat ein Medium im Unterpfad keinen Kanal, über den es entdeckt wird.

Diese beiden Defekte, einheitliches lastmod und unentdeckte Sitemap, lassen sich ein für alle Mal auf der Ebene des Publikationswerkzeugs beheben. Das ist die Art Detail, die ein für ein Medium gedachtes CMS von Haus aus regeln muss, weil keine Redaktion es bei jeder Veröffentlichung von Hand prüfen wird. Zu den übrigen Aktualitätssignalen, dem angezeigten Überarbeitungsdatum und den strukturierten Daten, verweisen wir auf unseren Artikel „Aktualität: datieren, überarbeiten, belegen“.