XML-Sitemap-Best-Practices: Was hineingehört

In eine XML-Sitemap gehören ausschließlich kanonische, indexierbare URLs, die mit HTTP 200 antworten – keine Redirects, keine 404-Seiten, keine noindex-Seiten und keine Parameter-Duplikate. Dazu ein <lastmod>, das der tatsächlichen letzten inhaltlichen Änderung entspricht, und eine Dateigröße unterhalb von 50.000 URLs und 50 MB.

Diese eine Regel deckt schon den Großteil aller Sitemap-Probleme ab. Der Rest ist Pflege: die Datei aktuell halten, sie für Suchmaschinen auffindbar machen und ein paar hartnäckige Mythen ignorieren. Der Reihe nach.

Was hineingehört – und was nicht

Denken Sie an die Sitemap als kuratierte Empfehlungsliste, nicht als Inventar. Jede URL darin sagt dem Crawler: „Diese Seite ist es wert.“ Entsprechend streng sollten die Aufnahmekriterien sein:

• Nur kanonische URLs. Wenn eine Seite per rel="canonical" auf eine andere verweist, gehört die kanonische Version in die Sitemap – nicht beide.
• Nur Status 200. Weiterleitungen, Soft-404s und Fehlerseiten haben in der Liste nichts verloren; jede davon ist ein verschwendeter Crawl-Abruf.
• Nur Indexierbares. Seiten mit noindex oder robots.txt-Sperre senden in der Sitemap ein widersprüchliches Signal.
• Keine Duplikate. Jede URL genau einmal, in exakt der kanonischen Schreibweise (Schema, Host, abschließender Slash).

Was nicht hineingehört, schadet doppelt: Es verbrennt Crawl-Budget und verwässert das Vertrauen der Suchmaschine in die Liste als Ganzes.

Grenzfälle entscheiden Sie nach demselben Prinzip. Paginierte Übersichten (Seite 2, 3, …) gehören meist nicht hinein – die Inhalte dahinter sind über die Detailseiten abgedeckt. Filter- und Sortier-URLs mit Parametern sind fast immer Duplikate der kanonischen Kategorie und bleiben draußen. Und interne Suchergebnisseiten haben in einer Sitemap nie etwas verloren.

lastmod: ehrlich oder gar nicht

Google hat mehrfach klargestellt, dass <lastmod> nur dann verwendet wird, wenn der Wert konsistent verlässlich ist. Das heißt konkret: Der Zeitstempel sollte sich auf die letzte inhaltlich relevante Änderung der Seite beziehen – nicht auf das Datum, an dem die Sitemap generiert wurde, und nicht auf kosmetische Template-Änderungen, die alle Seiten gleichzeitig betreffen. Wer bei jedem Build sämtliche URLs auf „heute“ setzt, trainiert der Suchmaschine ab, dem Feld zu glauben. Können Sie das echte Änderungsdatum nicht zuverlässig ermitteln, lassen Sie das Feld lieber weg.

changefreq und priority: Google ignoriert beide

Hier lohnt Deutlichkeit: <changefreq> und <priority> werden von Google ignoriert, und Bing misst ihnen ebenfalls kaum Bedeutung bei. Beide Felder sind gültiges XML und machen eine Sitemap nicht fehlerhaft, aber sie steuern nichts. Zeit, die Sie in das Feintuning von priority-Werten stecken, ist besser in korrekte lastmod-Angaben und interne Verlinkung investiert. Sie dürfen beide Felder ersatzlos streichen – die Datei wird dadurch nur kleiner.

Mythen und Realität

Größenlimits, Aufteilen und gzip

Pro Datei gelten 50.000 URLs und 50 MB unkomprimiert. Wer sich einem der Limits nähert, teilt die Sitemap auf mehrere Dateien auf und bündelt sie in einer Index-Datei – wie das geht, zeigt unser Guide zu Sitemap-Index-Dateien. Sinnvoll ist das Aufteilen oft schon weit unterhalb der Limits, etwa nach Inhaltstyp: eine Sitemap für Produkte, eine für Blogartikel, eine für statische Seiten. So sehen Sie in der Search Console pro Segment, wie viele URLs indexiert sind.

Alle gängigen Suchmaschinen akzeptieren gzip-komprimierte Sitemaps (sitemap.xml.gz). Die Kompression spart Bandbreite und Abrufzeit – das 50-MB-Limit bezieht sich aber auf die entpackte Datei, Komprimieren umgeht es also nicht.

Auffindbarkeit: robots.txt und Einreichen

Suchmaschinen finden Ihre Sitemap auf zwei Wegen, und Sie sollten beide bedienen:

1. Autodiscovery über robots.txt. Eine Zeile genügt, mit absoluter URL:

   Sitemap: https://example.com/sitemap.xml

   Die Zeile darf mehrfach vorkommen, wenn Sie mehrere Sitemaps oder einen Index haben, und wirkt für alle Crawler, die robots.txt lesen.
2. Aktives Einreichen. In der Google Search Console unter „Sitemaps“ und in den Bing Webmaster Tools. Der große Vorteil ist das Feedback: Beide Konsolen zeigen Abrufstatus, Fehler und die Zahl der gefundenen URLs.

Wie oft neu generieren?

So oft, wie sich Ihr Seitenbestand ändert. Praktisch heißt das:

• Dynamische Generierung – die Sitemap wird bei jedem Abruf oder aus der Datenbank erzeugt – ist der Standard für Shops, Verzeichnisse und Publikationen mit täglich neuen oder wegfallenden URLs. Sie ist nie veraltet, kostet aber bei sehr großen Sites Rechenzeit pro Abruf; ein kurzer Cache löst das.
• Statische Generierung – die Datei entsteht beim Build oder per Cronjob – passt zu Sites, die sich in Schüben ändern. Wichtig ist nur, dass die Sitemap-Erzeugung fest im Deploy-Prozess hängt und nicht vergessen werden kann.

Eine Sitemap, die gelöschte Seiten noch wochenlang listet oder neue Seiten wochenlang verschweigt, verfehlt ihren einzigen Zweck. Die vollständigen Formatregeln finden Sie bei sitemaps.org.

Der Pflege-Rhythmus

Einmal sauber aufgesetzt, braucht eine Sitemap wenig Aufmerksamkeit – aber nicht keine. Ein pragmatischer Rhythmus: Nach jedem größeren Relaunch, jeder URL-Struktur-Änderung und jeder Migration die Datei einmal komplett validieren; dazwischen genügt ein Blick in den Sitemap-Bericht der Search Console. Für die Validierung selbst brauchen Sie kein Setup: Der WebDoctor-Sitemap-Validator prüft die Datei per URL, Upload oder Copy-and-paste gegen das komplette Protokoll und markiert jeden Verstoß mit der passenden Korrektur. Häufige Fehlerbilder und ihre Behebung im Detail finden Sie im Guide Sitemap-Fehler beheben.