Sitemap auslesen: Jede Sitemap finden, prüfen und exportieren

Eine Sitemap auszulesen ist etwas anderes, als eine zu bauen. Du willst keine neue Datei erzeugen, du willst wissen, was in einer bereits existierenden steht: bei einer Website, die du gerade übernommen hast, bei der Konkurrenz, oder bei deiner eigenen, weil die Agentur von letztem Jahr nie gesagt hat, was sie da eingereicht hat. Dieser Artikel zeigt, wie du die Sitemap-Datei einer beliebigen Domain findest, ihre Struktur liest und die enthaltenen URLs weiterverarbeitest, ohne dich durch XML-Syntax zu quälen.

Wann sich das Auslesen überhaupt lohnt

Drei Situationen kommen in der Praxis am häufigsten vor. Erstens: Du übernimmst eine Website ohne Übergabedokumentation und willst wissen, welche Seiten überhaupt als relevant markiert sind. Zweitens: Du prüfst eine Konkurrenzseite, weil dich interessiert, wie viele Produktseiten sie führt oder ob sie eine Blog-Sitemap getrennt von der Hauptsitemap pflegt. Drittens, und das ist der unangenehmste Fall: Du willst kontrollieren, ob eine beauftragte Agentur die Sitemap tatsächlich sauber eingerichtet hat, statt ihr das einfach zu glauben.

In allen drei Fällen reicht "Datei im Browser öffnen" nicht aus. Der Browser rendert die XML-Struktur zwar lesbar, sagt dir aber nichts darüber, ob die Datei dem sitemaps.org-Protokoll entspricht, ob URLs doppelt vorkommen oder ob sich hinter einer harmlos aussehenden .xml-Endung in Wirklichkeit eine Fehlerseite verbirgt, die der Server mit Statuscode 200 ausliefert. Wie du selbst eine Sitemap sauber neu aufbaust statt nur eine bestehende zu lesen, steht separat im Artikel XML-Sitemap erstellen.

Die Sitemap einer Website finden

Es gibt keinen verbindlichen Speicherort für Sitemaps. Das sitemaps.org-Protokoll schreibt keinen festen Dateinamen vor, es verlangt nur, dass die Datei per HTTP oder HTTPS erreichbar ist. In der Praxis führen zwei Wege zum Ziel.

Beide Wege sind unabhängig voneinander und schließen sich nicht aus – manche Websites tragen die Sitemap in der robots.txt ein und legen sie zusätzlich unter einem der üblichen Pfade ab. Ein Beispiel aus der Praxis: WordPress-Installationen mit dem eingebauten Sitemap-Feature (seit Version 5.5) legen ihre Datei unter /wp-sitemap.xml ab, verlinken sie aber nicht immer in der robots.txt. Wer nur die robots.txt liest, findet in diesem Fall gar nichts, obwohl die Sitemap längst existiert.

Für die eigene Domain kommt ein dritter Weg dazu, der bei fremden Websites naturgemäß nicht funktioniert: die Google Search Console. Im Bericht "Sitemaps" listet sie alle eingereichten Dateien samt Status, allerdings nur für Properties, für die du Inhaber- oder Nutzerrechte hast. Ob die robots.txt selbst überhaupt korrekt aufgebaut ist und die Sitemap-Zeile nicht versehentlich in einem falschen Block steht, zeigt dir der Robots.txt-Tester.

Was in der Rohdatei wirklich steht

Öffnest du die Datei direkt, siehst du eines von zwei möglichen Wurzelelementen, und der Unterschied entscheidet über den nächsten Schritt.

Eine sitemapindex-Datei enthält, entgegen der naheliegenden Erwartung, keine einzige Seiten-URL. Wer im Editor nach <loc> sucht und trotzdem eine URL findet, liest gerade den Verweis auf eine Kind-Sitemap, nicht eine indexierbare Seite. Diese zweistufige Struktur ist bei Websites mit mehreren Zehntausend URLs praktisch die einzige Option, weil eine einzelne Sitemap-Datei laut Google Search Central maximal 50.000 URLs oder 50 MB unkomprimiert fassen darf – der Index selbst folgt derselben Grenze, bezogen auf die Zahl der Kind-Sitemaps (Stand der Recherche 07.09.2026, kann sich ändern).

Prüfen statt nur öffnen

Eine Sitemap zu finden und zu öffnen beantwortet nur die Frage, ob sie existiert. Ob sie brauchbar ist, ist eine andere Frage. Zwei Probleme fallen beim bloßen Lesen praktisch nie auf, weil sie im Browser unsichtbar bleiben:

Erstens Duplikate: Dieselbe URL kann mehrfach in der Datei stehen, mit oder ohne abschließenden Slash, mit oder ohne www. – für einen Menschen beim Überfliegen kaum zu erkennen, für ein Skript trivial. Zweitens hreflang-Fehler: Sitemaps können pro URL alternative Sprachversionen über <xhtml:link rel="alternate" hreflang="…"> auszeichnen. Google verlangt dabei zwei Dinge – jede Seite muss sich selbst in ihrer eigenen Alternates-Liste nennen, und verweist Seite A auf Seite B, muss B zurück auf A verweisen. Fehlt die Rückverlinkung bei auch nur einer von hundert Sprachvarianten, sieht das im rohen XML aus wie jede andere Zeile auch. Wer die Tags von vornherein korrekt erzeugen will, statt sie hinterher zu reparieren, findet dafür den Hreflang-Generator.

Ein konkretes Beispiel für den ersten Fall: Bei einem Umzug von HTTP auf HTTPS bleibt die alte Sitemap nach der Migration ungelöscht liegen, weil kein Migrations-Schritt explizit dafür zuständig war, und ein neu aufgesetztes Plugin trägt zusätzlich die HTTPS-URLs ein, statt die alten zu ersetzen. Ergebnis: dieselbe Seite taucht zweimal auf, einmal mit jedem Protokoll. Google verarbeitet das zwar meist stillschweigend, aber für eine Content-Bestandsaufnahme verdoppelt sich dadurch die gezählte URL-Anzahl, ohne dass eine einzige neue Seite existiert.

Der Sitemap Validator prüft Duplikate und hreflang-Reziprozität automatisch mit, sobald die Datei geladen ist, zusammen mit strukturellen Fehlern wie einem falschen Wurzelelement, einer fehlenden xmlns-Deklaration oder einem ungültigen Datumsformat in lastmod.

URLs exportieren und weiterverarbeiten

Sobald eine Sitemap geladen ist, willst du die enthaltenen URLs meist nicht einzeln lesen, sondern als Liste weiterverwenden – zum Abgleich mit einer Crawl-Liste, zum Import in eine Tabelle, oder einfach zum Zählen, wie viele Produktseiten eine Konkurrenzseite tatsächlich führt. Der Validator exportiert die extrahierten URLs wahlweise als CSV oder als reine Textliste, eine URL pro Zeile, ohne dass du das XML von Hand parsen musst.

Ein konkretes Beispiel: Ein Redakteursteam übernimmt einen Blog mit rund 400 Artikeln und weiß nicht, wie viele davon überhaupt noch in der Sitemap stehen, weil frühere Löschungen nie sauber nachgezogen wurden. Sitemap laden, URL-Liste exportieren, gegen die tatsächliche Artikelliste im CMS abgleichen – fünf Minuten statt eines Nachmittags mit Copy-Paste aus dem Quelltext.

Ist das Öffnen im Browser nicht einfacher?

Für eine einzelne, kleine Sitemap: ja, ehrlich gesagt schon. Wer nur kurz nachsehen will, ob überhaupt eine Datei existiert, muss dafür kein Werkzeug bemühen. Sobald es aber um mehr als eine Handvoll URLs geht, um eine sitemapindex-Struktur mit mehreren Kind-Dateien oder um die Frage, ob die Datei tatsächlich valide ist, kippt die Rechnung. Ein Beispiel: Eine sitemapindex-Datei mit zwanzig Kind-Sitemaps sieht im Browser aus wie zwanzig anklickbare Zeilen – ob eine davon eine 404-Seite verlinkt oder doppelte URLs enthält, siehst du erst, wenn du jede einzelne öffnest und mit den anderen abgleichst. Der Browser rendert eine gültige und eine fehlerhafte Sitemap optisch praktisch identisch, solange das XML überhaupt wohlgeformt ist – ein fehlendes xmlns-Attribut sieht auf den ersten Blick genauso aus wie ein korrektes. Genau die Fehler, die zählen, sind die, die man beim Draufschauen nicht sieht.

Häufige Fragen zum Sitemap-Auslesen