Eine XML-Sitemap ist eine maschinenlesbare Datei, mit der eine Website Suchmaschinen mitteilt, welche Seiten und anderen Inhalte sie für wichtig hält.
Sie ist damit eine Art Inhaltsverzeichnis für Crawler.
Das Bild ist allerdings nicht perfekt. Ein Inhaltsverzeichnis bestimmt normalerweise verbindlich, welche Kapitel ein Buch besitzt. Eine Sitemap besitzt gegenüber einer Suchmaschine wesentlich weniger Macht.
Sie kann sagen:
Diese URLs existieren und ich möchte, dass ihr sie kennt.
Sie kann nicht sagen:
Diese URLs müsst ihr indexieren.
Noch weniger kann sie sagen:
Diese URLs sollen gut ranken.
Google beschreibt Sitemaps als Hilfe, um Seiten und Dateien effizienter zu entdecken und zu crawlen. Die Aufnahme einer URL in eine Sitemap garantiert weder Crawling noch Indexierung. (Google for Developers)
Genau diese Einordnung ist wichtig, weil XML-Sitemaps im SEO häufig entweder überschätzt oder unterschätzt werden.
Warum braucht eine Suchmaschine überhaupt eine Sitemap?
Suchmaschinen entdecken viele neue Seiten über Links.
Ein Crawler kennt beispielsweise die Startseite.
Dort findet er einen Link zu einer Kategorie.
Auf der Kategorie findet er zehn Artikel.
In diesen Artikeln entdeckt er weitere Links.
So entsteht ein Netzwerk, durch das sich der Crawler bewegen kann.
Diesen Ablauf haben wir bereits unter Wie Suchmaschinen Websites finden behandelt.
Eine Sitemap bietet zusätzlich einen zweiten Weg:
Website
│
├── interne Links → Crawler entdeckt URLs
│
└── XML-Sitemap → Website nennt URLs ausdrücklich
Besonders bei großen, neuen oder komplex aufgebauten Websites kann das hilfreich sein. Google nennt außerdem Websites mit wenigen externen Links und umfangreiche Video-, Bild- oder Newsbestände als Fälle, in denen Sitemaps besonders nützlich sein können. (Google for Developers)
Eine XML-Sitemap ersetzt keine interne Verlinkung
Angenommen, eine Website besitzt 5.000 Artikel.
Alle 5.000 stehen in der Sitemap.
Von 2.000 Artikeln führt aber kein einziger interner Link zu irgendeiner anderen Seite.
Google kann diese URLs möglicherweise trotzdem über die Sitemap entdecken.
Für die Website selbst bleibt die Struktur jedoch schlecht.
Besucher können die Inhalte kaum finden.
Thematische Zusammenhänge werden nicht sinnvoll dargestellt.
Wichtige Seiten sind möglicherweise nur über die Sitemap erreichbar.
Google weist ausdrücklich darauf hin, dass gut intern verlinkte Websites ihre wichtigen Seiten häufig bereits über normale Navigation und Links auffindbar machen. Eine Sitemap ist eine zusätzliche Crawlinghilfe, nicht der Ersatz dafür. (Google for Developers)
Für Casiopeya wollen wir deshalb beides sauber aufbauen:
interne Linkstruktur für Menschen und Crawler
plus
XML-Sitemap als technische URL-Liste.
Wie sieht eine XML-Sitemap aus?
Eine sehr einfache Sitemap kann ungefähr so aussehen:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.de/wissen/was-ist-dns/</loc>
<lastmod>2026-08-09</lastmod>
</url>
<url>
<loc>https://example.de/wissen/was-ist-webhosting/</loc>
<lastmod>2026-08-08</lastmod>
</url>
</urlset>
Google unterstützt das XML-Sitemap-Format und erwartet bei den angegebenen Seiten vollständige absolute URLs. Relative Adressen wie /wissen/was-ist-dns/ reichen in der Sitemap nicht aus; eingetragen wird die komplette URL einschließlich Protokoll und Hostname. (Google for Developers)
Für Menschen wirkt XML zunächst technisch.
Die eigentliche Struktur ist aber überschaubar.
Was bedeutet urlset?
<urlset> bildet den Container für die URLs einer normalen Sitemap.
Darin befinden sich einzelne <url>-Einträge.
Vereinfacht:
<urlset>
<url>
...
</url>
<url>
...
</url>
</urlset>
Das XML-Namespace-Attribut verweist auf das Sitemap-Protokoll.
Ein CMS erzeugt diese Struktur normalerweise automatisch. Ein WordPress-Redakteur muss also nicht nach jedem neuen Artikel XML-Code von Hand ergänzen.
Was bedeutet loc?
<loc> steht für die Adresse der betreffenden Ressource.
Beispielsweise:
<loc>https://example.de/wissen/caching/</loc>
Das ist der wichtigste Eintrag.
Google verlangt vollständige absolute URLs und versucht, die angegebenen URLs so zu crawlen, wie sie in der Sitemap stehen. Deshalb sollte eine Sitemap nicht wahllos verschiedene Varianten derselben Adresse enthalten. (Google for Developers)
Wenn die bevorzugte URL lautet:
https://example.de/wissen/caching/
sollte dort nicht zusätzlich stehen:
http://example.de/wissen/caching/
https://www.example.de/wissen/caching/
sofern diese Varianten lediglich auf die bevorzugte Adresse weiterleiten.
In die Sitemap gehören bevorzugte URLs
Google empfiehlt, in der Sitemap die URLs anzugeben, die man in den Suchergebnissen sehen möchte – also normalerweise die bevorzugten kanonischen URLs. Die Sitemap selbst ist dabei nur ein schwächeres Canonical-Signal als beispielsweise eine permanente Weiterleitung oder rel="canonical". (Google for Developers)
Das ergibt eine vernünftige Grundregel:
Eine saubere Sitemap sollte die gültigen Ziel-URLs der Website abbilden.
Nicht deren technische Vergangenheit.
Weiterleitende URLs gehören normalerweise nicht in die Sitemap
Angenommen, ein Artikel lag früher unter:
https://example.de/blog/caching-alt/
und wurde dauerhaft verschoben nach:
https://example.de/wissen/caching/
Die alte URL liefert nun eine permanente Weiterleitung.
Dann sollte die Sitemap in der Regel direkt die neue kanonische Zieladresse enthalten.
Es wäre widersprüchlich, Google gleichzeitig mitzuteilen:
Meine bevorzugte URL ist die alte Adresse.
und beim Aufruf zu antworten:
Nein, bitte zur neuen Adresse gehen.
Konsistenz ist bei technischer SEO wesentlich hilfreicher als möglichst viele Signale.
Auch 404-Seiten haben in einer sauberen Sitemap nichts verloren
Dasselbe Prinzip gilt für gelöschte Inhalte.
Wenn eine URL nicht mehr existiert und mit einem korrekten Fehlerstatus beantwortet wird, sollte sie nicht dauerhaft weiter in der Sitemap als gewünschte Such-URL aufgeführt werden.
Eine Sitemap sollte möglichst den aktuellen veröffentlichten Bestand darstellen.
Das macht sie nebenbei auch für den Betreiber zu einem interessanten Diagnosewerkzeug.
Wenn tausende tote URLs in der Sitemap stehen, stimmt wahrscheinlich etwas mit ihrer Erzeugung nicht.
Was bedeutet lastmod?
<lastmod> gibt an, wann der Inhalt einer URL zuletzt wesentlich verändert wurde.
Beispielsweise:
<lastmod>2026-08-09</lastmod>
Google kann dieses Signal verwenden, um das erneute Crawling bereits bekannter URLs besser zu planen – allerdings nur dann, wenn die Angaben dauerhaft zuverlässig sind. Google empfiehlt, damit das Datum der letzten signifikanten Änderung abzubilden. Änderungen am Hauptinhalt, strukturierten Daten oder wichtigen Links können relevant sein; eine bloße Aktualisierung eines Copyright-Jahres sollte dagegen nicht als substanzielle Seitenänderung ausgegeben werden.
Damit wird lastmod deutlich interessanter, als es auf den ersten Blick aussieht.
lastmod sollte nicht täglich künstlich aktualisiert werden
Ein naiver SEO-Trick könnte so aussehen:
Jede Nacht setzt das System bei allen 5.000 Artikeln:
<lastmod>2026-08-09</lastmod>
Morgen:
<lastmod>2026-08-10</lastmod>
obwohl sich kein einziger Artikel verändert hat.
Damit verliert das Signal gerade seinen Nutzen.
Google erklärt ausdrücklich, dass lastmod verwendet werden kann, wenn die Werte konsistent und überprüfbar korrekt sind.
Eine gute Sitemap versucht also nicht, Suchmaschinen mit künstlicher Aktualität zu beeindrucken.
Sie liefert möglichst ehrliche technische Informationen.
Eine kleine Textänderung muss nicht zwingend lastmod verändern
Wenn ein Tippfehler korrigiert wurde:
Wordpres
zu:
WordPress
ist das technisch natürlich eine Änderung.
Für die Planung eines erneuten Crawls ist sie möglicherweise kaum relevant.
Anders sieht es aus, wenn:
mehrere Abschnitte ergänzt,
veraltete Informationen aktualisiert,
wichtige interne Links ergänzt,
strukturierte Daten verändert
oder wesentliche Inhalte neu aufgebaut wurden.
Google nennt ausdrücklich signifikante Änderungen am Hauptinhalt, an strukturierten Daten oder an Links als Beispiele, bei denen ein aktualisiertes lastmod sinnvoll sein kann.
Das Veröffentlichungsdatum ist nicht automatisch lastmod
Ein Artikel kann veröffentlicht worden sein am:
01.03.2025
und grundlegend aktualisiert werden am:
09.08.2026.
Dann beschreibt lastmod sinnvollerweise den neueren relevanten Änderungszeitpunkt.
Das ursprüngliche Veröffentlichungsdatum kann weiterhin an anderer Stelle bestehen bleiben.
Die beiden Informationen beantworten unterschiedliche Fragen:
Wann erschien der Inhalt erstmals?
und
Wann wurde diese Version wesentlich verändert?
Was bedeuten priority und changefreq?
Wer ältere Sitemap-Anleitungen liest, begegnet häufig zwei weiteren Elementen:
<changefreq>weekly</changefreq>
<priority>0.8</priority>
changefreq soll theoretisch beschreiben, wie häufig sich die Seite verändert.
priority soll eine relative Priorität innerhalb der Website ausdrücken.
Für Google kann man sich die Arbeit heute sparen: Google dokumentiert ausdrücklich, dass es die Werte von <priority> und <changefreq> ignoriert.
Das ist ein schönes Beispiel für SEO-Einstellungen, die technisch existieren können, aber für Google keine praktische Wirkung besitzen.
priority ist kein Regler für Rankings
Insbesondere priority wurde früher gerne missverstanden.
Der Gedankengang:
wichtige Seite = priority 1.0
weniger wichtige Seite = priority 0.5
führt schnell zur Versuchung:
Dann gebe ich eben allen Seiten 1.0.
Selbst wenn Google das Element berücksichtigen würde, wäre dadurch keinerlei zusätzliche relative Information entstanden.
Da Google priority ohnehin ignoriert, gibt es keinen Grund, daraus eine SEO-Wissenschaft zu machen.
Wie viele URLs passen in eine Sitemap?
Eine einzelne Sitemap darf nach Googles aktuellen Vorgaben höchstens 50.000 URLs beziehungsweise unkomprimiert höchstens 50 MB enthalten. Wird eine dieser Grenzen überschritten, muss der Bestand auf mehrere Sitemap-Dateien aufgeteilt werden.
Für einen normalen Blog ist diese Grenze riesig.
Bei Shops, Verzeichnissen oder großen Portalen ist sie dagegen durchaus relevant.
Dann kommt ein Sitemap-Index ins Spiel.
Was ist ein Sitemap-Index?
Ein Sitemap-Index enthält nicht direkt die einzelnen Seiten der Website.
Er listet mehrere Sitemap-Dateien auf.
Vereinfacht:
sitemap-index.xml
│
├── sitemap-posts-1.xml
├── sitemap-posts-2.xml
├── sitemap-pages.xml
├── sitemap-categories.xml
└── sitemap-products.xml
Damit muss beispielsweise in der Search Console nur der Index eingereicht werden.
Google kann von dort die darunterliegenden Sitemap-Dateien entdecken.
Ein Sitemap-Index kann auch bei kleineren Websites praktisch sein
Man braucht keine 50.001 URLs, um einen Sitemap-Index zu verwenden.
Ein CMS kann Inhalte bereits vorher logisch auf mehrere Dateien verteilen.
Zum Beispiel:
Beiträge
Seiten
Kategorien
Produkte
Das kann die Verwaltung und Analyse vereinfachen.
WordPress verwendet in seiner Core-Sitemap ebenfalls einen Sitemap-Index und teilt unterstützte Inhalte in verschiedene Sitemap-Gruppen auf. Der zentrale WordPress-Endpunkt lautet standardmäßig /wp-sitemap.xml.
Wie funktioniert die WordPress-Sitemap?
WordPress besitzt eine eigene Sitemap-Funktion.
Der Hauptindex ist standardmäßig erreichbar unter:
https://example.de/wp-sitemap.xml
Die URL wird über WordPress-Rewrite-Regeln erzeugt; es muss also keine physische Datei namens wp-sitemap.xml im Webverzeichnis liegen. WordPress besitzt außerdem eine Funktion, den Sitemap-Index in die von WordPress erzeugte robots.txt einzufügen.
Das ist praktisch, weil ein normales WordPress-Projekt damit grundsätzlich bereits eine Sitemap-Basis besitzt.
WordPress teilt verschiedene Inhaltstypen auf
WordPress kann im Sitemap-System unter anderem verschiedene öffentliche Inhaltstypen und Taxonomien in getrennten Sitemap-Dateien darstellen. Die Core-Implementierung wurde ausdrücklich als erweiterbares Sitemap-System entwickelt und erzeugt einen Index für die unterstützten Bereiche.
Das bedeutet beispielsweise, dass Seiten und Beiträge nicht zwangsläufig alle in einer einzigen riesigen XML-Datei stehen.
Der zentrale Index verweist auf die jeweiligen Unter-Sitemaps.
Brauche ich dann überhaupt ein SEO-Plugin für Sitemaps?
Nicht zwingend.
Wenn die native WordPress-Sitemap genau die URLs enthält, die deine Website benötigt, erfüllt sie bereits die grundlegende Aufgabe.
SEO-Plugins können allerdings zusätzliche Steuerungsmöglichkeiten oder eigene Sitemap-Strukturen mitbringen.
Dann sollte man vermeiden, mehrere konkurrierende Sitemap-Systeme zu betreiben, ohne zu wissen, welches tatsächlich verwendet wird.
Wie bei Caching gilt:
Doppelt vorhanden bedeutet nicht doppelt gut.
Zwei verschiedene Sitemap-Indizes sind nicht automatisch ein Problem
Technisch kann eine Website mehrere Sitemaps bereitstellen.
Google unterstützt auch mehrere eingereichte Sitemaps.
Unübersichtlich wird es jedoch, wenn sie sich widersprechen.
Beispielsweise:
Core-Sitemap enthält Autorenarchive.
SEO-Sitemap schließt sie aus.
Eine dritte Erweiterung erzeugt zusätzlich sitemap.xml.
Dann sollte geklärt werden, welche Struktur der tatsächlichen SEO-Architektur entsprechen soll.
Ein bewusst gewähltes System ist leichter zu warten.
Welche WordPress-Seiten gehören in die Sitemap?
Die Antwort ergibt sich nicht aus WordPress, sondern aus der Seitenstrategie.
Ein Wissensportal könnte beispielsweise sinnvoll indexierbar machen:
Wissensartikel,
wichtige Containerseiten,
Magazinbeiträge,
ausgewählte Kategorieseiten.
Andere automatisch erzeugte Archive erfüllen möglicherweise keinen eigenständigen Suchzweck.
Die Sitemap sollte daher nicht nach dem Prinzip funktionieren:
Alles, wofür WordPress eine URL erzeugen kann, kommt hinein.
Sondern:
Welche URLs sollen als eigenständige Suchergebnisse funktionieren?
Google empfiehlt entsprechend, URLs in die Sitemap aufzunehmen, die man in den Suchergebnissen sehen möchte.
Kategoriearchive können sinnvoll sein
Eine Kategorie ist nicht automatisch dünner SEO-Ballast.
Wenn sie als echte Themenübersicht aufgebaut wird und Nutzern hilft, kann sie eine wichtige Containerseite sein.
Bei Casiopeya könnte beispielsweise:
/wissen/web-wordpress/
eine zentrale Hub-Seite darstellen.
Dann gehört sie selbstverständlich in die Sitemap.
Eine leere automatisch erzeugte Archivseite mit zwei Beiträgen und ohne eigenen Zweck ist anders zu bewerten.
Es geht also nicht um den URL-Typ.
Es geht um die Aufgabe der Seite.
Tags müssen nicht zwangsläufig indexiert werden
WordPress macht es leicht, hunderte Schlagwörter anzulegen.
Dadurch können ebenso viele Tagarchive entstehen.
Wenn jedes davon lediglich ein oder zwei Beiträge auflistet, entsteht schnell eine große Menge schwacher, sich überschneidender Seiten.
In solchen Projekten kann es sinnvoll sein, Tagarchive gar nicht als eigenständige Suchseiten zu verwenden.
Wer sie nicht indexieren möchte, sollte sie entsprechend auch nicht als gewünschte kanonische Such-URLs in die Sitemap aufnehmen.
Autorenarchive hängen von der Website ab
Bei einem großen Magazin mit bekannten Autoren können Autorenseiten einen echten Nutzen besitzen.
Bei einem Ein-Personen-Blog kann das Autorenarchiv dagegen fast identisch mit der normalen Beitragsübersicht sein.
Es gibt deshalb keine universelle Regel:
Autorenarchive immer indexieren
oder
Autorenarchive immer ausschließen.
Die richtige Entscheidung kommt wieder aus der Informationsarchitektur.
Eine Sitemap ist damit auch ein Spiegel der SEO-Strategie
Wenn du die Sitemap öffnest und selbst nicht erklären kannst, warum einzelne URL-Gruppen darin stehen, lohnt sich eine Prüfung.
Die Sitemap sollte im Idealfall ungefähr die Antwort auf folgende Frage darstellen:
Welche öffentlich erreichbaren URLs dieser Website betrachten wir als eigenständige, bevorzugte Inhalte?
Damit wird aus einer technischen XML-Datei ein erstaunlich nützliches Architekturwerkzeug.
Gehören noindex-Seiten in die Sitemap?
Wenn eine Seite bewusst mit noindex gekennzeichnet wird, lautet die Botschaft:
Diese URL soll nicht in den Suchindex.
Wenn dieselbe Seite gleichzeitig in der Sitemap steht, lautet die Botschaft sinngemäß:
Diese URL gehört zu den Seiten, die ich der Suchmaschine als bevorzugten Bestand mitteile.
Das ist unnötig widersprüchlich.
Eine saubere Sitemap sollte deshalb auf die URLs ausgerichtet sein, die tatsächlich als Suchergebnisse vorgesehen sind. Googles eigene Empfehlung lautet entsprechend, URLs aufzunehmen, die man in den Suchergebnissen sehen möchte.
Die Sitemap darf trotzdem kein Indexierungsfilter sein
Das Gegenteil wäre ebenfalls falsch.
Nur weil eine Seite nicht in der Sitemap steht, bedeutet das nicht:
Google darf sie nicht indexieren.
Wenn Google eine URL über interne oder externe Links entdeckt und sie crawlbar sowie indexierbar ist, kann sie grundsätzlich auch ohne Sitemap verarbeitet werden.
Die Sitemap steuert also nicht verbindlich den Index.
Sie hilft bei Entdeckung und Crawling.
Für echte Indexierungssteuerung werden andere Mechanismen benötigt.
Die Sitemap ist auch keine robots.txt
robots.txt steuert den Zugriff von Crawlern auf bestimmte URL-Bereiche.
Eine Sitemap nennt URLs.
Das sind beinahe gegensätzliche Aufgaben.
Vereinfacht:
Sitemap:
Diese URLs solltest du kennen.
robots.txt:
Diese Bereiche darfst du unter bestimmten Regeln nicht crawlen.
Die beiden Dateien können miteinander verbunden werden, weil die robots.txt die Adresse einer Sitemap nennen kann.
Sie ersetzen einander aber nicht.
Wie wird eine Sitemap in robots.txt angegeben?
Eine Zeile kann beispielsweise so aussehen:
Sitemap: https://example.de/wp-sitemap.xml
Google unterstützt diese Methode ausdrücklich. Beim nächsten Crawlen der robots.txt kann Google dadurch die angegebene Sitemap finden. Es dürfen dort auch mehrere Sitemap-Adressen angegeben werden.
WordPress kann seinen Sitemap-Index ebenfalls in die automatisch erzeugte robots.txt eintragen.
Damit muss Google die Sitemap nicht ausschließlich über Search Console kennenlernen.
Soll ich die Sitemap trotzdem in der Search Console einreichen?
Ja, das ist sinnvoll.
Nicht weil das Einreichen eine Indexierung erzwingt.
Der praktische Vorteil liegt vor allem in der Kontrolle.
Google empfiehlt den Sitemaps-Bericht der Search Console unter anderem deshalb, weil dort sichtbar wird, wann die Sitemap verarbeitet wurde und ob dabei Fehler aufgetreten sind. Das Einreichen bleibt lediglich ein Hinweis an Google.
Damit erhält der Betreiber eine deutlich bessere Diagnosemöglichkeit als durch bloßes Hoffen.
Eine Sitemap muss nicht bei jeder Veröffentlichung neu eingereicht werden
Wenn die Sitemap unter derselben URL automatisch aktualisiert wird, muss sie nicht nach jedem neuen Artikel manuell erneut in Search Console eingetragen werden.
Das CMS ergänzt die neue URL.
Google kann die Sitemap bei späteren Abrufen erneut verarbeiten.
Genau darin liegt der Sinn einer dynamisch erzeugten Sitemap.
Ein redaktioneller Workflow soll idealerweise so aussehen:
Artikel veröffentlichen
↓
CMS aktualisiert Sitemap
↓
interne Links entstehen
↓
Crawler entdeckt Änderung
Keine manuelle XML-Pflege.
Keine tägliche Search-Console-Routine.
Der alte Sitemap-Ping funktioniert für Google nicht mehr
Ältere SEO-Plugins und Anleitungen verwenden möglicherweise noch einen speziellen Google-Ping-Endpunkt und senden nach jeder Sitemap-Aktualisierung einen HTTP-Aufruf.
Google hat diesen nicht authentifizierten Sitemap-Ping eingestellt. Solche Anfragen liefern heute keinen Nutzen mehr; Google nennt Search Console und die Angabe in robots.txt als weiterhin unterstützte Wege.
Das ist ein gutes Beispiel dafür, warum technische SEO-Anleitungen regelmäßig veralten.
Kann ich die Sitemap automatisiert über eine API einreichen?
Ja.
Google bietet über die Search Console API auch eine Sitemap-Einreichung für verifizierte Properties an.
Das kann bei größeren automatisierten Website-Umgebungen praktisch sein.
Für einen normalen einzelnen WordPress-Blog ist es meistens unnötig.
Wenn die Sitemap dauerhaft erreichbar und bereits in Search Console registriert ist, muss nicht bei jedem neuen Artikel ein API-Prozess ausgelöst werden.
Automatisierung sollte einen echten Bedarf lösen.
Sitemap-Einreichung ist keine Indexing API für normale Artikel
Hier werden zwei Dinge gerne vermischt.
Eine Sitemap informiert Google über URLs und Änderungen.
Das bedeutet nicht:
Indexiere diese Seite jetzt sofort.
Auch eine über Search Console eingereichte Sitemap bleibt ausdrücklich nur ein Hinweis. Google garantiert dadurch weder den Abruf noch die Verwendung für das Crawling.
Das Konzept sollte deshalb immer lauten:
auffindbar machen und konsistente Signale liefern
statt
Indexierung erzwingen.
Was passiert bei einer neuen Website?
Bei einer brandneuen Domain können Sitemaps besonders nützlich sein, weil möglicherweise noch kaum externe Links auf die Website zeigen.
Google nennt neue Websites mit wenigen eingehenden Links ausdrücklich als einen Fall, in dem eine Sitemap hilfreich sein kann.
Für ein neues Wissensportal wäre ein sinnvoller Start deshalb:
Domain und Hosting technisch sauber,
wichtige Seiten intern verlinkt,
XML-Sitemap vorhanden,
Search Console eingerichtet,
Sitemap dort eingereicht.
Danach muss die Website aber trotzdem ihren normalen Weg durch Crawling, Indexierung und Ranking gehen.
Eine Sitemap beschleunigt nicht automatisch jede URL
Nehmen wir an, die Website besitzt 20.000 URLs.
Die Sitemap wird eingereicht.
Es wäre falsch zu erwarten, dass Google nun alle 20.000 innerhalb weniger Minuten abruft.
Google entscheidet selbst über Crawling und Indexierung. Die Sitemap erleichtert die Entdeckung und kann Informationen über Aktualisierungen liefern, garantiert aber keine Bearbeitung jeder enthaltenen URL.
Je größer eine Website wird, desto wichtiger wird deshalb auch die Qualität ihrer URL-Struktur.
Eine saubere Sitemap hilft bei der Diagnose großer Websites
Nehmen wir einen Shop mit:
20.000 Produkten
500 Kategorien
3.000 Ratgeberseiten
Diese Gruppen könnten in getrennten Sitemaps organisiert werden.
Dann lässt sich bei Problemen leichter erkennen:
Produkt-Sitemap funktioniert.
Kategorie-Sitemap funktioniert.
Ratgeber-Sitemap meldet Fehler.
Eine logische Aufteilung kann deshalb nicht nur Google helfen, sondern auch der eigenen technischen Analyse.
Sollte man Sitemaps nach Inhaltstyp aufteilen?
Das ist häufig sinnvoll, aber keine Pflicht.
Eine WordPress-Website könnte beispielsweise besitzen:
posts-sitemap
pages-sitemap
categories-sitemap
products-sitemap
Das erleichtert die Orientierung.
Bei 30 URLs braucht niemand zehn separate Dateien.
Bei einer großen Website werden Gruppen dagegen nützlich.
Sitemap-Architektur sollte wie die übrige Technik so komplex sein wie nötig – und nicht komplexer.
Was passiert bei mehr als 50.000 URLs?
Dann muss die Sitemap aufgeteilt werden.
Beispielsweise:
artikel-1.xml 50.000 URLs
artikel-2.xml 50.000 URLs
artikel-3.xml 18.432 URLs
Darüber liegt:
sitemap-index.xml
Google erlaubt maximal 50.000 URLs beziehungsweise 50 MB unkomprimierte Größe pro einzelner Sitemap. Sitemap-Indexdateien können wiederum bis zu 50.000 Sitemap-Verweise enthalten.
Damit lassen sich auch extrem große Websites strukturieren.
Die Sitemap kann komprimiert werden
Große Sitemap-Dateien können als komprimierte Dateien bereitgestellt werden.
Das reduziert die übertragene Datenmenge.
Für WordPress-Nutzer ist dieses Detail normalerweise irrelevant, weil CMS oder SEO-System die technischen Dateien selbst verwalten.
Bei sehr großen individuell entwickelten Plattformen kann es dagegen Teil der Infrastrukturplanung werden.
Gehören Bilder in eine Sitemap?
Das Sitemap-System kann zusätzliche Informationen zu Bildern enthalten.
Google unterstützt Erweiterungen für Bild-, Video- und News-Inhalte sowie für lokalisierte Seitenvarianten.
Ob eine separate beziehungsweise erweiterte Bild-Sitemap sinnvoll ist, hängt stark vom Projekt ab.
Für ein Fotoportal kann das erheblich interessanter sein als für eine textlastige Informationsseite mit wenigen Illustrationen.
Video-Sitemaps besitzen zusätzliche Informationen
Bei umfangreichen Videoinhalten kann eine Sitemap zusätzliche Video-Metadaten enthalten.
Google nennt beispielsweise Informationen wie Laufzeit oder weitere Eigenschaften als mögliche Sitemap-Daten.
Auch hier gilt:
Die normale Artikel-Sitemap muss nicht mit allen denkbaren Erweiterungen vollgepackt werden.
Spezielle Sitemap-Typen sind Werkzeuge für spezielle Inhalte.
News-Sitemaps sind ebenfalls ein Spezialfall
News-Websites können Google zusätzliche Informationen zu aktuellen Nachrichtenartikeln bereitstellen.
Für ein normales Evergreen-Wissensportal ist das kein notwendiger Bestandteil.
Der häufige SEO-Fehler wäre wieder:
Wenn es eine technische Funktion gibt, muss ich sie aktivieren.
Nein.
Ein Werkzeug ist nur dann sinnvoll, wenn der entsprechende Inhalt und Anwendungsfall existiert.
hreflang kann ebenfalls mit Sitemaps kombiniert werden
Bei mehrsprachigen oder regional unterschiedlichen Seitenvarianten können entsprechende Beziehungen auch über Sitemap-Erweiterungen angegeben werden.
Google nennt lokalisierte Seitenvarianten ausdrücklich als einen möglichen Einsatzzweck des XML-Formats.
Für eine ausschließlich deutschsprachige Website ist das zunächst irrelevant.
Wenn Casiopeya später beispielsweise deutsch- und englischsprachige Varianten besitzt, wird dieses Thema interessant.
Wo sollte die Sitemap liegen?
Für normale Websites ist der Stamm der Website ein sinnvoller Ort.
Google empfiehlt dies insbesondere deshalb, weil eine Sitemap ohne spezielle Cross-Site-Verfahren grundsätzlich nur URLs in ihrem eigenen Verzeichnis beziehungsweise darunter abdecken kann.
Typische Adressen sind daher beispielsweise:
https://example.de/sitemap.xml
https://example.de/sitemap_index.xml
https://example.de/wp-sitemap.xml
Der genaue Dateiname ist nicht entscheidend.
Die korrekte Erreichbarkeit und Struktur sind es.
Der Dateiname sitemap.xml ist nicht vorgeschrieben
WordPress zeigt das sehr schön.
Die Core-Sitemap liegt standardmäßig unter:
/wp-sitemap.xml
Ein SEO-Plugin kann beispielsweise:
/sitemap_index.xml
verwenden.
Eine individuell entwickelte Plattform könnte einen anderen Namen wählen.
Google braucht keine magische Datei namens exakt sitemap.xml.
Es muss lediglich wissen, wo die gültige Sitemap liegt und sie erfolgreich abrufen können.
Die Sitemap muss öffentlich abrufbar sein
Wenn Google die Sitemap verwenden soll, muss Googlebot sie erreichen können.
Eine Datei hinter einem Login wäre als öffentliche Sitemap offensichtlich ungeeignet.
Auch Serverfehler, Weiterleitungsschleifen oder ungültiges XML können die Verarbeitung verhindern.
Der Sitemaps-Bericht der Search Console kann dabei helfen, Verarbeitungsfehler sichtbar zu machen.
Eine hübsche Sitemap ist nicht notwendig
Manche Sitemaps besitzen ein XSL-Stylesheet und sehen im Browser beinahe wie eine normale Tabelle aus.
Andere zeigen einfach XML.
Für Google ist die optische Darstellung für Menschen nicht entscheidend.
WordPress besitzt beispielsweise eigene Sitemap-Stylesheet-Funktionen, während die eigentlichen Daten weiterhin als XML ausgeliefert werden.
Ein Sitemap-Design bringt deshalb keinen SEO-Vorteil.
Es kann lediglich die manuelle Kontrolle angenehmer machen.
Wie kontrolliert man eine Sitemap?
Die einfachste Prüfung beginnt im Browser.
Öffne die Sitemap.
Funktioniert die URL?
Siehst du die erwarteten Sitemap-Gruppen beziehungsweise URLs?
Dann lohnt sich eine Stichprobe.
Stehen dort:
HTTPS-Adressen?
die korrekte www- oder non-www-Variante?
aktuelle URLs?
keine offensichtlich gelöschten Seiten?
die gewünschten Inhaltstypen?
Schon diese einfache Prüfung entdeckt erstaunlich viele Konfigurationsprobleme.
Danach kommt die Search Console
Dort lässt sich die Sitemap einreichen und überwachen.
Google zeigt über den Sitemaps-Bericht unter anderem Informationen über den Abruf und mögliche Verarbeitungsprobleme.
Das ist wesentlich nützlicher als regelmäßig die XML-Datei anzustarren.
Die Sitemap selbst sagt:
Das möchte meine Website melden.
Search Console hilft bei der Frage:
Kann Google damit etwas anfangen?
Sitemap und tatsächlicher Index müssen nicht gleich groß sein
Angenommen, die Sitemap enthält:
1.000 URLs.
Es wäre falsch zu erwarten, dass Google exakt 1.000 indexierte Seiten meldet.
Google garantiert nicht, jede Sitemap-URL zu crawlen oder zu indexieren.
Die Differenz ist deshalb nicht automatisch ein Fehler.
Sie kann aber ein Anlass zur Analyse sein.
Wenn von 1.000 wichtigen eigenständigen Artikeln nur 100 indexiert werden, lohnt sich die Frage nach dem Warum.
Dann wird die Sitemap zum Diagnosewerkzeug
Man kann beispielsweise feststellen:
Diese 1.000 URLs wollen wir indexieren.
Welche davon kennt Google?
Welche wurden gecrawlt?
Welche sind indexiert?
Welche betrachtet Google als Duplikate?
Welche besitzen technische Probleme?
Damit wird ein klar definierter Sitemap-Bestand zur Bezugsgröße.
Das ist wesentlich sinnvoller, als sämtliche technisch jemals erzeugten URLs einer WordPress-Installation als Sollwert zu verwenden.
Viele Sitemap-URLs bei kaum indexierten Seiten sind ein Signal
Das Problem lautet dann nicht automatisch:
„Google ignoriert meine Sitemap.“
Möglicherweise befinden sich darin hunderte:
sehr ähnliche Archive,
Filterseiten,
dünne Taxonomien,
Weiterleitungen,
technisch fehlerhafte URLs.
Dann funktioniert die Sitemap vielleicht perfekt.
Sie macht nur eine schwache Seitenarchitektur sichtbar.
Eine Sitemap kann schlechte Inhalte nicht in gute Suchergebnisse verwandeln.
Ebenso wenig repariert sie technische Indexierungssperren
Eine URL kann korrekt in der Sitemap stehen und gleichzeitig:
noindex
enthalten,
auf eine andere URL kanonisieren,
mit einem Fehler antworten
oder nicht sinnvoll erreichbar sein.
Die Sitemap überschreibt solche Signale nicht.
Google betrachtet die Gesamtheit der technischen Informationen und entscheidet über Crawling und Indexierung selbst.
Genau deshalb müssen Sitemaps mit der restlichen Architektur übereinstimmen.
Der ideale Zustand ist langweilig
Eine gut gepflegte Sitemap sollte eigentlich wenig Aufmerksamkeit benötigen.
WordPress veröffentlicht einen neuen Wissensartikel.
Die Sitemap enthält ihn automatisch.
Die interne Navigation verlinkt ihn.
Die URL ist kanonisch.
Sie antwortet mit 200.
lastmod wird bei wesentlichen Änderungen sinnvoll aktualisiert.
Search Console kann die Sitemap fehlerfrei verarbeiten.
Fertig.
Sitemaps sollten nicht zum täglichen SEO-Ritual werden.
Ein sinnvoller WordPress-Workflow
Für eine normale Wissenswebsite würde ich ungefähr folgende Logik verwenden:
Artikel wird veröffentlicht
↓
nur gewünschte öffentliche Inhalte sind indexierbar
↓
Sitemap wird automatisch aktualisiert
↓
kanonische HTTPS-URL steht in der Sitemap
↓
interne Links führen zur Seite
↓
Sitemap ist in Search Console registriert
↓
Google entdeckt und verarbeitet Änderungen
Der Redakteur muss dabei nicht über XML nachdenken.
Das System erledigt die technische Routine.
Wann sollte man sich die Sitemap trotzdem genauer ansehen?
Bei:
Relaunch,
Domainumzug,
HTTPS-Migration,
Theme- oder SEO-Plugin-Wechsel,
größeren Änderungen der Permalinkstruktur,
neuen Custom Post Types,
neuen Shopfunktionen,
auffälligen Indexierungsproblemen.
Dann kann sich verändern, welche URLs erzeugt und gemeldet werden.
Bei solchen größeren Eingriffen lohnt ein erneuter technischer Check.
Besonders nach einem Domainumzug wird die Sitemap wichtig
Wenn eine Website von einer alten auf eine neue Domain umzieht, werden neue URLs erzeugt.
Google empfiehlt bei Site Moves unter anderem, die neue Sitemap einzureichen, damit die neuen Adressen schneller entdeckt werden können.
Das ersetzt die notwendigen Weiterleitungen nicht.
Aber es ergänzt sie.
Wieder sehen wir dasselbe Prinzip:
Mehrere konsistente Signale erzählen dieselbe Geschichte.
Die Sitemap sollte dann nur noch die neue Zielstruktur zeigen
Wenn der Umzug abgeschlossen ist, sollten interne Links, Canonicals und neue Sitemap auf die neue Domain beziehungsweise die neuen URLs ausgerichtet sein.
Die alten URLs übernehmen ihre Rolle über Weiterleitungen.
Eine dauerhaft gemischte Sitemap mit alten und neuen Zieladressen würde unnötig unklar werden.
Technische Migrationen funktionieren am saubersten, wenn jede Ebene eine eindeutige Aufgabe besitzt.
Was du dir über XML-Sitemaps merken solltest
Eine XML-Sitemap ist eine maschinenlesbare Liste wichtiger URLs und Dateien einer Website.
Sie hilft Suchmaschinen, Inhalte zu entdecken und effizienter zu crawlen.
Sie garantiert weder Crawling noch Indexierung.
In die Sitemap gehören vorzugsweise die kanonischen URLs, die als Suchergebnisse vorgesehen sind. Google betrachtet die Aufnahme in eine Sitemap zudem als ein schwaches Canonical-Signal.
<loc> nennt die vollständige URL.
<lastmod> kann eine wesentliche letzte Änderung signalisieren und ist nur dann hilfreich, wenn die Angaben zuverlässig sind.
<priority> und <changefreq> werden von Google ignoriert.
Eine Sitemap darf höchstens 50.000 URLs beziehungsweise 50 MB unkomprimierte Größe besitzen. Größere Bestände werden auf mehrere Dateien und gegebenenfalls einen Sitemap-Index verteilt.
WordPress besitzt eine eigene Sitemap-Infrastruktur und stellt den Hauptindex standardmäßig unter /wp-sitemap.xml bereit.
Die Sitemap kann über die Google Search Console eingereicht und zusätzlich in robots.txt angegeben werden. Der alte Sitemap-Ping-Endpunkt von Google ist dagegen eingestellt.
Die wichtigste Regel ist jedoch:
Eine Sitemap ist kein Ersatz für eine gute Website-Struktur.
Sie sagt der Suchmaschine, welche URLs existieren sollen.
Die interne Verlinkung erklärt anschließend wesentlich besser, wie diese Seiten zusammengehören.
Der nächste sinnvolle Schritt
Genau deshalb folgt jetzt Interne Verlinkung richtig aufbauen.
Dort können wir den für Casiopeya besonders wichtigen Teil behandeln: Hub-Seiten, Themencluster, Linktexte, verwaiste Seiten, Linktiefe, kontextuelle Links, Navigation und die Frage, wie neue Artikel sinnvoll auch aus älteren Inhalten verlinkt werden.
Das ist für unsere konkrete Architektur sogar wichtiger als die Sitemap – denn damit machen wir aus einer Sammlung einzelner Artikel tatsächlich ein zusammenhängendes Wissensportal.