Ihre XML-Sitemap ändert sich bei jedem Deploy – aber hat sich der Inhalt geändert?

Freitag, 16:42 Uhr. Ein kleines Frontend-Release geht live: Button-Abstände, ein Fehler im Footer, eine aktualisierte JavaScript-Abhängigkeit. Kurz danach meldet die XML-Sitemap für tausende URLs denselben neuen lastmod-Zeitpunkt.

Technisch wurde die Website tatsächlich neu gebaut. Inhaltlich haben sich die meisten Seiten nicht verändert.

Genau hier verliert eine Sitemap an Aussagekraft. Sie ist nicht bloß eine Liste, die irgendwie existieren muss. Sie ist ein maschinenlesbares Signal darüber, welche URLs Sie für suchrelevant halten und wann sich diese Seiten wirklich wesentlich verändert haben.

Google beschreibt Sitemaps als Hinweis, nicht als Garantie: Eine eingereichte URL muss weder gecrawlt noch indexiert werden. Umso wichtiger ist, dass die Informationen, die Sie freiwillig liefern, konsistent und glaubwürdig sind.

Die nützlichste Audit-Frage lautet deshalb nicht: „Haben wir eine sitemap.xml?“

Sondern: „Erzählt unsere Sitemap die Wahrheit über unsere kanonischen Seiten und deren echte Änderungen?“

Mythos 1: Je mehr URLs in der Sitemap stehen, desto besser

Nein. Google empfiehlt, in der Sitemap die URLs aufzunehmen, die Sie in den Suchergebnissen sehen möchten. Das sind in der Regel die bevorzugten, kanonischen URLs.

Eine Sitemap ist daher kein vollständiger Export aller technisch erreichbaren Adressen. Typische Kandidaten, die nicht hineingehören, sind:

• Redirect-URLs,
• noindex-Seiten,
• interne Suchergebnisse,
• Session- oder Tracking-Varianten,
• Filter-URLs ohne eigenständigen Suchwert,
• Staging- oder Preview-Hosts,
• Duplikate mit Canonical auf eine andere URL,
• gelöschte oder nicht mehr erreichbare Seiten.

Wenn eine Sitemap gleichzeitig /produkt, /produkt?utm_source=x, /produkt?sort=asc und eine alte Redirect-URL enthält, sendet sie kein klares Inventar. Sie dokumentiert vielmehr, dass das URL-Modell nicht sauber getrennt ist.

Google nennt die Aufnahme einer URL in eine Sitemap ausdrücklich als eines von mehreren Canonical-Signalen. Das Signal ist schwächer als etwa ein Redirect oder ein sauber gesetztes rel="canonical", sollte diesen aber nicht widersprechen.

Mythos 2: priority und changefreq machen wichtige Seiten wichtiger

Für Google nicht.

Die aktuelle Search-Central-Dokumentation sagt ausdrücklich, dass Google die XML-Werte <priority> und <changefreq> ignoriert. Wer auf jeder Seite priority=1.0 einträgt oder die Startseite auf „daily“ setzt, baut damit keine zusätzliche Suchpriorität auf.

Das ist ein gutes Beispiel für technisch korrektes XML ohne praktischen Nutzen.

Wenn ein Generator diese Felder automatisch ausgibt, ist das nicht automatisch ein Fehler. Aber Teams sollten wissen, welche Metadaten tatsächlich ausgewertet werden und welche nur historischen Ballast darstellen.

Mythos 3: lastmod sollte einfach das Build-Datum sein

Das ist der problematischste Irrtum.

Google sagt, dass <lastmod> genutzt werden kann, wenn der Wert konsistent und überprüfbar korrekt ist. Er soll den Zeitpunkt der letzten wesentlichen Änderung der jeweiligen Seite beschreiben.

Als wesentliche Änderungen nennt Google beispielsweise:

• Änderungen am Hauptinhalt,
• Änderungen an strukturierten Daten,
• Änderungen an wichtigen Links auf der Seite.

Eine reine Aktualisierung des Copyright-Jahres gilt dagegen nicht als wesentliche Inhaltsänderung.

Das Sitemaps-Protokoll ist ebenfalls eindeutig: lastmod beschreibt die letzte Änderung der verlinkten Seite – nicht den Zeitpunkt, an dem die Sitemap generiert wurde.

Wenn Ihr Deployment-System also bei jedem Build auf allen URLs lastmod = now() setzt, beantwortet es die falsche Frage.

Warum falsches lastmod mehr als ein SEO-Schönheitsfehler ist

Ein unzuverlässiger Zeitstempel erzeugt vor allem drei betriebliche Probleme.

1. Sie verlieren ein sinnvolles Änderungssignal

Wenn jede URL immer „heute geändert“ aussieht, lässt sich nicht mehr unterscheiden, ob ein neuer Fachartikel veröffentlicht, eine Produktbeschreibung grundlegend überarbeitet oder nur das Frontend neu gebaut wurde.

Damit wird ein eigentlich nützliches Signal zu Rauschen.

2. Fehler in der Content-Pipeline bleiben verborgen

Ein global aktualisiertes lastmod ist häufig ein Symptom dafür, dass Sitemap-Generierung und Content-Lifecycle nicht sauber miteinander verbunden sind.

Vielleicht kennt das CMS ein echtes updatedAt, aber der Frontend-Generator verwendet stattdessen die Build-Zeit. Vielleicht wird bei jedem Import jeder Datensatz gespeichert und dadurch künstlich als geändert markiert. Vielleicht gibt es gar keine definierte Quelle für „inhaltlich aktualisiert“.

Das ist nicht nur eine Suchmaschinenfrage. Es ist eine Datenqualitätsfrage.

3. Monitoring bekommt falsche Erwartungen

Wenn Teams nach Releases prüfen wollen, welche Inhalte neu oder verändert sind, ist eine Sitemap mit Build-Zeit unbrauchbar. Das erschwert Vergleiche zwischen CMS, Live-Seite, Cache und Indexierungsdaten.

Eine gute Sitemap kann dagegen ein erstaunlich nützliches Betriebsinventar sein.

Was sollte lastmod praktisch auslösen?

Nicht jede technische Änderung braucht einen neuen Seitenzeitstempel.

Ein pragmatisches Modell ist:

lastmod aktualisieren, wenn sich die Bedeutung oder der für Nutzer relevante Inhalt der URL substanziell ändert.

Das kann je nach Website einschließen:

• Titel oder Haupttext,
• Produktdaten wie Preis oder Verfügbarkeit, wenn sie Bestandteil der Seite sind,
• zentrale Bilder oder Medien,
• strukturierte Daten,
• wichtige interne oder externe Verweise,
• FAQ- oder Leistungsinformationen,
• ein fachlich relevanter Datenstand.

Nicht automatisch relevant sind dagegen:

• ein unverändertes Redeployment,
• Hashes von JavaScript- oder CSS-Dateien,
• ein Framework-Upgrade ohne sichtbare Inhaltsänderung,
• globale Footer-Kleinigkeiten,
• ein neuer Build-Zeitstempel,
• Cache-Neuerzeugung ohne Content-Änderung.

Bei globalen Änderungen gibt es natürlich Grenzfälle. Wenn beispielsweise rechtlich oder fachlich relevante Hinweise auf jeder Seite geändert werden, kann das durchaus eine echte Seitenänderung sein. Entscheidend ist, dass die Regel bewusst definiert ist – nicht, dass der Build-Prozess zufällig überall einen neuen Zeitstempel verteilt.

Red Flag: Die Sitemap enthält URLs, die sofort weiterleiten

Die Search Console weist bei Sitemap-Problemen ausdrücklich darauf hin, Redirect-URLs durch die URLs zu ersetzen, die tatsächlich gecrawlt werden sollen.

Das ergibt Sinn: Eine Sitemap sollte möglichst direkt auf den finalen Zustand zeigen.

Prüfen Sie deshalb bei jedem Eintrag:

1. Liefert die URL eine finale erfolgreiche Antwort?
2. Gibt es davor oder danach einen Host-Wechsel?
3. Wird HTTP erst auf HTTPS umgeleitet?
4. verweist eine alte Sprach- oder CMS-Route auf einen neuen Pfad?
5. Ist der Canonical der Seite identisch mit der erwarteten Sitemap-URL?

Eine Sitemap voller 301-Antworten ist kein funktionaler Totalschaden. Sie ist aber ein Hinweis darauf, dass interne Suchsignale noch auf historischen Adressen basieren.

Red Flag: Nicht-kanonische und kanonische Varianten stehen nebeneinander

Google verwendet die Präsenz einer URL in der Sitemap als Canonical-Signal. Gleichzeitig kann die Seite selbst per rel="canonical" eine andere URL bevorzugen.

Wenn diese beiden Ebenen widersprechen, zwingen Sie die Suchmaschine dazu, Ihre Intention zu erraten.

Ein typischer Fehler nach Relaunches:

• Sitemap enthält https://example.de/leistungen?id=42
• die Seite canonicalisiert auf https://example.de/leistungen/webdesign
• interne Links verwenden teils beide Varianten.

Jede einzelne Komponente kann „funktionieren“. Zusammen ist das System unnötig uneindeutig.

Die bessere Regel lautet: Sitemap, interne Links, Canonical und Redirect-Ziele sollten so weit wie möglich auf dieselbe finale URL zeigen.

Red Flag: Gelöschte Inhalte bleiben monatelang in der Sitemap

Eine URL, die dauerhaft 404 oder 410 liefert, sollte nicht weiter als gewünschte Such-URL in der Sitemap geführt werden.

Das bedeutet nicht, dass entfernte Inhalte versteckt werden müssen. Ein korrekter 404- oder 410-Status ist ein legitimer Zustand. Aber die Sitemap sollte den aktuellen gewünschten Bestand repräsentieren, nicht das historische Archiv aller jemals existierenden Seiten.

Dasselbe gilt für Seiten, die bewusst noindex tragen: Wenn Sie sie nicht in Suchergebnissen sehen möchten, passen sie nicht zu dem Zweck, für den Google Sitemap-URLs empfiehlt.

Große Websites: Sitemaps nach Verantwortung statt nur nach Dateigröße schneiden

Google begrenzt eine einzelne Sitemap auf 50.000 URLs oder 50 MB unkomprimiert. Größere Bestände müssen auf mehrere Dateien verteilt und können über einen Sitemap-Index zusammengefasst werden.

Technisch reicht irgendeine Aufteilung. Operativ ist eine sinnvolle Aufteilung besser.

Beispiele:

• /sitemap-products.xml
• /sitemap-categories.xml
• /sitemap-articles.xml
• /sitemap-services.xml
• getrennte Sprach- oder Länderbestände, wenn die Architektur das sinnvoll macht.

Warum? Weil Search Console Sitemaps separat anzeigen kann. Damit wird schneller sichtbar, ob beispielsweise Produktseiten stabil entdeckt werden, während ein neuer Magazin-Generator Fehler produziert.

Die Sitemap-Struktur kann also gleichzeitig eine Monitoring-Struktur sein.

Vorsicht beim lastmod im Sitemap-Index

Im Sitemap-Index hat lastmod eine andere Bedeutung als auf einer Seiten-URL.

Dort beschreibt es laut Google beziehungsweise dem Sitemap-Protokoll, wann die jeweilige Sitemap-Datei geändert wurde. Es ist nicht automatisch der letzte Änderungszeitpunkt irgendeiner darin gelisteten Seite.

Auch hier ist „alles auf jetzt setzen“ wenig aussagekräftig.

Wenn ein großer Shop nur die Produkt-Sitemap verändert hat, sollten nicht zwingend alle anderen Sitemap-Dateien ebenfalls einen neuen Änderungszeitpunkt vortäuschen.

Was Search Console tatsächlich bestätigt

Ein grüner Sitemap-Status bedeutet nicht, dass alle enthaltenen Seiten indexiert sind.

Der Sitemaps-Bericht zeigt unter anderem:

• wann Google die Sitemap zuletzt gelesen hat,
• ob sie erfolgreich verarbeitet werden konnte,
• Parsing- oder Abrufprobleme,
• wie viele Seiten-URLs entdeckt wurden.

Google weist ausdrücklich darauf hin, dass „entdeckt“ keine Garantie für Crawling oder Indexierung ist.

Deshalb ist die richtige Betriebsfrage nicht: „Ist die Sitemap grün?“

Sondern:

• Sind die erwarteten URLs enthalten?
• Sind unerwartete URLs enthalten?
• Stimmen Canonicals und Statuscodes?
• Werden neue Inhalte zeitnah aufgenommen?
• verschwinden entfernte Inhalte wieder?
• passen lastmod-Werte zum Content-System?
• stimmen die entdeckten Mengen ungefähr mit dem erwarteten Bestand überein?
• zeigt der Page-Indexing-Report auffällige Ausschlussmuster?

Ein belastbarer Sitemap-Audit in neun Schritten

1. Sitemap-Inventar erfassen

Welche Sitemap-Dateien und Indizes existieren? Welche werden in robots.txt referenziert oder in Search Console eingereicht?

2. XML und Erreichbarkeit prüfen

Sind Dateien ohne Authentifizierung abrufbar, syntaktisch gültig, UTF-8-kodiert und innerhalb der Größenlimits?

3. URL-Menge mit dem erwarteten Bestand vergleichen

Wie viele Produkte, Artikel, Leistungen oder Kategorien sollte es geben – und wie viele enthält die Sitemap tatsächlich?

4. Stichprobe und Vollcrawl der Sitemap-URLs

Statuscodes, Redirects, Canonicals, noindex, Host, Protokoll und Sprache prüfen.

5. Negative Differenz prüfen

Welche indexierbaren, intern wichtigen Seiten fehlen aus der Sitemap?

6. Positive Differenz prüfen

Welche URLs stehen darin, obwohl sie Redirects, Fehler, Duplikate oder nicht indexierbare Zustände darstellen?

7. lastmod gegen echte Änderungsdaten vergleichen

Kommt der Wert aus dem CMS, einer Datenbank oder einem tatsächlichen Content-Commit? Oder nur aus der Build-Uhr?

8. Release-Verhalten testen

Vergleichen Sie die Sitemap vor und nach einem Deployment ohne Content-Änderung. Wenn sich tausende Zeitstempel ändern, obwohl keine Seiten fachlich geändert wurden, ist die Generierungslogik zu grob.

9. Search Console als Beobachtungsschicht nutzen

Prüfen Sie „Last read“, Status, entdeckte Seiten und die Indexierungsabdeckung pro Sitemap. Die Sitemap selbst ist nur eine Seite des Systems; die Reaktion des Crawlers ist die andere.

Was Website-Pflichtencheck dabei prüft

Website-Pflichtencheck kann eine XML-Sitemap nicht nur auf „vorhanden oder nicht vorhanden“ prüfen, sondern als Teil der gesamten URL-Architektur betrachten.

Je nach Website gehören dazu:

• Sitemap- und Sitemap-Index-Struktur,
• Größe, XML-Fehler und Erreichbarkeit,
• kanonische versus nicht-kanonische URLs,
• Redirects und Fehlerseiten,
• noindex-Konflikte,
• Sprach- und Host-Mischungen,
• echte lastmod-Quellen,
• Differenzen zwischen CMS, Sitemap und Live-Routing,
• Search-Console-Signale,
• Regressionen nach Deployments.

Das Ziel ist nicht, eine „perfekte SEO-Datei“ zu produzieren. Das Ziel ist ein verlässliches technisches Inventar, das dieselbe URL-Wahrheit erzählt wie Ihre Website.

Wenn Ihre Sitemap nach jedem Deploy behauptet, die gesamte Website sei gerade neu geschrieben worden, ist sie zwar aktuell generiert – aber nicht unbedingt aktuell informiert.