XML-Sitemap richtig einsetzen: Warum priority meistens egal ist

Eine XML-Sitemap wirkt auf den ersten Blick wie ein strategisches SEO-Instrument. Man listet wichtige Seiten auf, versieht sie mit Änderungsdatum, Aktualisierungsfrequenz und Priorität und gibt Suchmaschinen damit scheinbar eine klare Anweisung mit: Diese Seiten sind wichtig, bitte entsprechend behandeln. In dieser Logik steckt allerdings ein Missverständnis.

Eine Sitemap ist keine Abstimmung über Rankings. Sie ist ein technisches Verzeichnis, das Suchmaschinen hilft, relevante URLs zu entdecken und Änderungen besser einzuordnen, und mehr sollte man ihr nicht andichten. Gerade deshalb lohnt sich ein nüchterner Blick auf die drei Felder, die in vielen Sitemaps automatisch ausgespielt werden: lastmod, changefreq und priority.

Die wichtigste Information in einer XML-Sitemap ist die URL. Sie steht im <loc>-Element und sagt: Diese Seite existiert, sie ist öffentlich erreichbar, und sie soll grundsätzlich gefunden werden.

Das klingt banal, ist aber der Kern der Sache. Wer eine URL in die Sitemap aufnimmt, trifft eine redaktionelle und technische Aussage. Diese Seite gehört zum öffentlichen Bestand der Website, sie ist indexierbar, kanonisch und relevant genug, um Suchmaschinen aktiv genannt zu werden.

Genau hier passieren die meisten Fehler. In vielen Sitemaps landen URLs, die dort nichts verloren haben: interne Suchergebnisse, Filterseiten, Parameter-Varianten, Weiterleitungen, Login-Bereiche, doppelte Sprachversionen oder Seiten mit noindex. Eine solche Sitemap hilft nicht, sie macht das Angebot unklarer. Eine gute XML-Sitemap erkennt man deshalb an der Qualität der Auswahl, und Vollständigkeit ist hier kein Wert an sich.

Das Sitemap-Protokoll kennt ein Element namens priority. Der Wert liegt zwischen 0.0 und 1.0 und soll ausdrücken, wie wichtig eine URL im Verhältnis zu anderen URLs derselben Website ist.

Das sieht nach Steuerung aus, ist in der Praxis aber meistens Dekoration. Google ignoriert priority ebenso wie changefreq. Das steht ausdrücklich in der eigenen Search-Central-Dokumentation. Verwendet wird stattdessen vor allem die URL selbst und, sofern glaubwürdig gepflegt, das Änderungsdatum über lastmod.

Das ist nachvollziehbar. Priorität ist hochgradig subjektiv, und fast jede Website hält ihre Startseite, ihre Leistungsseiten, ihre Landingpages und ihre wichtigsten Blogartikel für besonders wichtig. Wenn am Ende jede zweite URL den Wert 1.0 bekommt, ist nichts mehr priorisiert, und das Signal verliert jede Bedeutung. Google selbst hat in einer offiziellen Stellungnahme begründet, dass priority in internen Studien die tatsächliche Wichtigkeit einer Seite gegenüber anderen Seiten desselben Auftritts kaum zuverlässig abbildet.

Die echte Priorität einer Seite entsteht außerhalb der Sitemap, in der Informationsarchitektur, der internen Verlinkung, der Navigation, der inhaltlichen Qualität und der Aktualität. Wer einer Seite Gewicht geben möchte, sollte sie sichtbar ins System der Website einbauen, statt ihr in einer XML-Datei eine hohe Zahl zuzuweisen.

Ähnlich verhält es sich mit changefreq. Das Element soll angeben, wie häufig sich eine Seite voraussichtlich ändert.

Auch das klingt nützlich, ist in der Realität aber zu grob. Eine News-Übersicht kann sich täglich ändern, während ein einzelner Artikel jahrelang stabil bleibt. Eine Startseite wiederum wird technisch oft täglich neu generiert, ohne dass sich ihr relevanter Inhalt ändert. Bei Veranstaltungsseiten kann das Muster sogar umkippen: monatelang nichts, dann kurz vor dem Termin mehrere Aktualisierungen innerhalb weniger Tage.

Suchmaschinen haben eigene Signale, um Crawl-Frequenz und Relevanz einzuschätzen, und ein pauschales daily, weekly oder monthly ist dafür kaum belastbar. Google bestätigt entsprechend, dass changefreq schlicht nicht verwendet wird, weil sich das Element konzeptionell ohnehin mit lastmod überschneidet. Wer nicht genau weiß, warum dieses Feld gesetzt wird, kann es weglassen.

Das nützlichste optionale Feld ist lastmod.

lastmod beschreibt den Zeitpunkt der letzten relevanten Änderung einer Seite, also nicht den Moment, in dem die Sitemap neu erzeugt wurde, das CMS den Cache geleert hat oder im Footer automatisch das neue Jahr erscheint.

Das Sitemap-Protokoll selbst macht klar, dass sich lastmod auf die Änderung der verlinkten Seite beziehen soll, nicht auf die Erstellung der Sitemap. Google ergänzt: Relevant sind substanzielle Änderungen, etwa am Hauptinhalt, an strukturierten Daten oder an Links. Kleine Änderungen in Sidebar oder Footer müssen das Datum nicht aktualisieren.

Das ist der entscheidende Punkt, und Google formuliert ihn an anderer Stelle besonders deutlich: Wenn eine Seite sich vor sieben Jahren zuletzt geändert hat, im lastmod aber als gestern aktualisiert ausgewiesen wird, verliert die Sitemap auf Dauer ihre Glaubwürdigkeit insgesamt. Ein falsches lastmod ist damit schlechter als gar keines, weil es nicht nur das jeweilige Frische-Signal entwertet, sondern auch das Vertrauen erodiert, das Google der gesamten Datei entgegenbringt.

Für normale Seiten genügt meist eine sehr knappe Sitemap:

Diese Variante kommt ohne priority und changefreq aus und verzichtet bewusst auf dekorative Scheingenauigkeit. Was bleibt, ist die saubere Substanz: klare URLs, kanonische Seiten, ehrliche Änderungsdaten.

Eine Sitemap soll kein Abbild aller technisch erreichbaren URLs sein, sondern ein Verzeichnis derjenigen Adressen, die wirklich in Suchergebnissen erscheinen sollen.

Nicht hinein gehören Seiten mit noindex, Weiterleitungen, Fehlerseiten, interne Suchergebnisse, Warenkorb- oder Login-Seiten, Session-URLs, unkontrollierte Parameter-Varianten und doppelte Inhalte unter mehreren Adressen. Auch Archivseiten, Tag-Seiten oder Filterkombinationen sollten nur dann aufgenommen werden, wenn sie bewusst als eigenständige Einstiegsseiten gedacht sind.

Das ist weniger eine technische Kleinigkeit als eine Frage der Haltung. Eine Website, die Suchmaschinen alles hinwirft, überlässt ihnen die Aufräumarbeit. Eine Website, die ihre Sitemap kuratiert, zeigt dagegen, welche Inhalte sie selbst für relevant hält. Genau diese Selbstauskunft ist es, die Google in der Sitemap erwartet.

Bei kleinen Websites genügt eine einzelne sitemap.xml. Bei größeren Projekten ist es sinnvoll, die Sitemap aufzuteilen, beispielsweise nach Seiten, Blogartikeln, Veranstaltungen, News oder öffentlichen Profilen.

Das ist nicht nur sauberer für Suchmaschinen, sondern auch hilfreicher für die eigene Analyse. In der Google Search Console lässt sich dann besser erkennen, welche Inhaltstypen indexiert werden, wo Fehler entstehen und welche Bereiche möglicherweise zu viel oder zu wenig Sichtbarkeit bekommen. Gerade bei Verbänden, Kongressplattformen, Newsbereichen oder großen redaktionellen Websites ist diese Trennung wertvoll, weil sie aus einer technischen Datei ein wartbares Inventar macht.

Eine XML-Sitemap ist sinnvoll, aber sie ist kein Ort für Wunschdenken. priority wirkt präzise, bleibt für Google aber bedeutungslos. Bei changefreq klingt der Mechanismus nützlich, fällt in den meisten Fällen aber zu pauschal aus. Nur lastmod entfaltet echten Wert, und das auch nur, wenn es die Wahrheit sagt.

Die wichtigste Arbeit passiert vorher, in den redaktionellen und architektonischen Entscheidungen: Welche Seiten sollen überhaupt indexiert werden, welche Adresse ist die kanonische, welche Inhalte sind öffentlich relevant, und welche Seiten wurden tatsächlich aktualisiert? Eine gute Sitemap beantwortet diese Fragen ohne Pathos, und genau darin liegt ihre eigentliche Leistung.