// KOSTENLOSES TOOL · XML-SITEMAP PRÜFEN
XML-Sitemap prüfen
Füge deine sitemap.xml ein — oder zieh die Datei ins Feld — und du siehst jeden Protokollfehler mit Zeilennummer und Korrektur: loc, lastmod samt Zeitzone, priority, changefreq, hreflang-Paare und die Grenze von 50.000 URLs. Kostenlos, im Browser, ohne Upload.
Auch aufEnglishDeutschEspañolFrançais日本語한국어Português (Brasil)繁體中文
Geprüft wird beim Tippen. Du kannst eine sitemap.xml oder sitemap.xml.gz auch direkt auf dieses Feld ziehen — dein Browser liest und entpackt die Datei, sie verlässt ihn nie.
XML-Sitemap prüfen — in drei Schritten
Alles auf dieser Seite. Der Validator liest die Datei, die du ihm gibst — er ruft deine Website nicht ab, also füg die XML ein oder zieh die Datei herein, statt eine URL zu tippen.
- Datei einfügen oder ablegen. Füg die XML links ins Feld ein oder zieh sitemap.xml beziehungsweise sitemap.xml.gz darauf — dein Browser entpackt selbst. Geprüft wird sofort, bei jedem Tastendruck.
- Die Befunde abarbeiten. Jeder Befund hat eine Zeilennummer und die Korrektur. Fehler sind Dinge, die ein Crawler ablehnt oder falsch liest; Warnungen sind gültiges XML, das dich trotzdem etwas kostet — ein lastmod in der Zukunft etwa oder eine doppelte URL.
- Bericht kopieren, korrigieren, erneut prüfen. Rechts steht ein Bericht als reiner Text — Dateityp, Abstand zu den Grenzen von 50.000 URLs und 50 MB, jeder Befund — den du ins Ticket kopieren kannst. Korrigier, füg die neue Datei ein, bestätige, dass sie sauber zurückkommt.
Was dieser Sitemap-Validator prüft
Drei Durchgänge über die Datei, die du einfügst. Zuerst die XML-Wohlgeformtheit: nicht geschlossene und falsch verschachtelte Tags, ein nicht maskiertes & in einem Query-String, ein nicht deklariertes Namensraum-Präfix — jeweils an der Zeile gemeldet, in der es passiert, statt als ein einziges pauschales „Parse-Fehler". Dann das Protokoll von sitemaps.org: Wurzel <urlset> oder <sitemapindex> im Namensraum http://www.sitemaps.org/schemas/sitemap/0.9, genau ein absolutes <loc> pro Eintrag, <lastmod> als echtes W3C-Datetime, <priority> zwischen 0.0 und 1.0, <changefreq> eines der sieben erlaubten englischen Wörter. Zuletzt die Grenzen und die Querbezüge: 50.000 URLs, 50 MB unkomprimiert, doppelte URLs, gemischte Hosts und xhtml:link-hreflang-Annotationen in beide Richtungen.
Eine XML-Sitemap ist eine Datei unter einer festen URL, die die Seiten aufzählt, die gecrawlt werden sollen — jede als <loc>-Element, optional mit <lastmod>, gebündelt unter einer <urlset>-Wurzel oder einem <sitemapindex>, der auf mehrere solcher Dateien zeigt. Mehr ist das Protokoll nicht, und es ist immer noch das Schema 0.9, auf das sich die Suchmaschinen geeinigt haben. Genau deshalb lohnt sich ein Sitemap-Check einmal pro Generator-Änderung: die Fehler sind mechanisch, und jeder ist eine Ein-Zeilen-Korrektur, sobald dir jemand die Zeile nennt.
| Regel | Stufe | Warum |
|---|---|---|
Wohlgeformtes XML: Tags geschlossen und verschachtelt, & als &, jedes Präfix deklariert | Fehler | Ein Crawler parst die Datei streng. Ein einziges nacktes Kaufmanns-Und, und die ganze Datei fliegt raus, nicht nur diese URL. |
Wurzel ist <urlset> oder <sitemapindex> und deklariert den 0.9-Namensraum | Fehler | Ohne Namensraum sind die Elemente keine Sitemap-Elemente — die Datei parst und führt nichts. |
Ein <loc> pro Eintrag, absolut mit http(s), höchstens 2.048 Zeichen | Fehler | Eine Sitemap wird ohne Kontext gelesen; es gibt keine Basis-URL, gegen die /impressum/ aufgelöst werden könnte. |
<lastmod> ist W3C-Datetime, mit Zeitzone, sobald eine Uhrzeit dabeisteht | Fehler | 01.09.2026 und 2026-09-01 08:00:00 werden beide abgelehnt. Siehe den nächsten Abschnitt — das ist der Fehler, den deutschsprachige Exporte am häufigsten produzieren. |
<priority> 0.0–1.0 mit Punkt, <changefreq> aus der englischen Liste | Fehler | 1,0 mit Dezimalkomma und täglich statt daily sind gültiges XML und ungültiges Sitemap-Protokoll. |
| Nur Protokollelemente im Sitemap-Namensraum; Erweiterungen deklarieren ihren | Fehler | <lastmodified> und <image:loc> ohne xmlns:image sind die zwei üblichen Tippfehler. |
| 50.000 Einträge und 50 MB unkomprimiert pro Datei | Fehler | Über einer der beiden Grenzen wird die Datei als Ganzes abgelehnt, nicht gekürzt. Gzip hilft nicht — gemessen wird vorher. |
| hreflang-Alternates: Selbstverweis, Rückverweis, gültiger Code, x-default | Fehler | Eine einseitige Annotation verwirft Google vollständig und stillschweigend. |
Doppelte <loc>, gemischte Hosts, zukünftiges oder grobes <lastmod> | Warnung | Gültiges XML, das dich trotzdem Crawl-Budget oder Glaubwürdigkeit kostet. |
<priority> oder <changefreq> überhaupt vorhanden | Warnung | Googles eigene Doku sagt, dass beides ignoriert wird. Gut zu wissen, bevor du ein Release darauf verwendest, sie zu erzeugen. |
lastmod, MEZ/MESZ und was aus TYPO3, Contao und WordPress hier ankommt
<lastmod> ist das einzige optionale Feld, das Google laut eigener Doku überhaupt liest — und im deutschsprachigen Raum ist es genau das Feld, das am zuverlässigsten falsch geschrieben wird. Der Grund ist keine Schlamperei, sondern eine Kollision von Konventionen: W3C-Datetime will 2026-09-01 oder 2026-09-01T09:15:00+02:00, deutsche Systeme schreiben Daten als 01.09.2026 und Dezimalzahlen mit Komma, und PHP liefert je nach Formatstring einmal +02:00 und einmal +0200. Was der Validator zu den vier Formen sagt, die tatsächlich ankommen:
| Im Export | Befund | Korrekt |
|---|---|---|
01.09.2026 | Fehler — kein W3C-Datetime | 2026-09-01 |
2026-09-01T08:00:00+0200 | Fehler — der Versatz braucht den Doppelpunkt | 2026-09-01T08:00:00+02:00 |
2026-09-01T08:00:00 | Fehler — Uhrzeit ohne Zeitzone | …+02:00 oder …Z |
2026-09-01 08:00:00 | Fehler — Leerzeichen statt T | 2026-09-01T08:00:00Z |
Dahinter liegt die Falle, die kein Validator der Welt sehen kann und die es trotzdem nur hier gibt: Deutschland, Österreich und die Schweiz wechseln zwischen MEZ (+01:00) und MESZ (+02:00). Ein Export, der die lokale Uhrzeit aus der Datenbank nimmt und ganzjährig einen festen Versatz anhängt, ist ein halbes Jahr lang um eine Stunde daneben. Meistens harmlos — bis der Versatz in die falsche Richtung zeigt und lastmod in der Zukunft landet: Google glaubt ein Datum in der Zukunft nicht, und wenn eine ganze Datei so aussieht, verliert die Datei ihre Glaubwürdigkeit als Crawl-Hinweis. Der sichere Ausweg ist unspektakulär: schreib alles in UTC mit Z, oder nimm ein reines Datum ohne Uhrzeit. 2026-09-01 ist gültig, eindeutig und für ein Crawl-Signal präzise genug.
Zu den Exporten selbst: bei TYPO3, Contao, WordPress-Plug-ins oder einem selbstgebauten Generator hast du auf die Formatierung selten direkten Zugriff — deshalb ist der Reflex „einmal durch den Validator, bevor es deployt wird" hier mehr wert als anderswo. Zwei Muster, die aus CMS-Exporten regelmäßig kommen und die du sofort erkennst: relative <loc> wie /impressum/ — bei TYPO3 fast immer eine Frage von config.absRefPrefix beziehungsweise der Site-Konfiguration, denn eine Sitemap wird ohne Basis-URL gelesen und ein relativer Pfad ist dort schlicht bedeutungslos; und deutsche Wörter in <changefreq> (täglich, wöchentlich), das aus gut gemeinter Lokalisierung entsteht. Die sieben erlaubten Werte sind Protokoll-Schlüsselwörter und bleiben englisch — always, hourly, daily, weekly, monthly, yearly, never — falls du sie überhaupt ausgibst, wozu es keinen Grund gibt.
Der Knopf Fehlerhaftes Beispiel oben lädt genau diese Datei: deutsches Datum, +0200 ohne Doppelpunkt, 1,0 mit Komma, täglich, ein relativer Pfad, ein nacktes & im Query-String ein doppelt geführtes <loc> und ein <lastmodified>, das niemand als Tippfehler bemerkt hat. Zehn Befunde in einer 21-Zeilen-Datei, jeder mit seiner Zeile — ungefähr die Ausbeute eines echten, ungeprüften CMS-Exports.
50.000 URLs, 50 MB — und wie du sauber aufteilst
Zwei harte Zahlen: 50.000 URLs und 50 MB unkomprimiert pro Sitemap-Datei. Gemessen wird vor gzip, eine 60-MB-Datei zu komprimieren bringt sie also nicht unter die Grenze — es verkürzt nur den Download. Der Bericht über den Befunden zeigt dir für beide, wie nah du dran bist; das ist die Zahl, die man in einer wachsenden Site im Blick behält, denn beim Überschreiten wird die Datei als Ganzes ungültig, nicht etwa gekürzt.
Danach teilst du nach Bereichen auf und veröffentlichst einen <sitemapindex>: eine Datei pro Inhaltstyp oder pro Monat — je nachdem, was die <lastmod>-Werte ehrlich hält. Ein Index fasst bis zu 50.000 <sitemap>-Einträge mit je einem <loc> und optional einem <lastmod> — kein <priority>, kein <changefreq>, keine eingestreuten <url>-Elemente, was dieser Validator alles meldet. Ein Index darf keinen weiteren Index führen, der Baum ist also exakt zwei Ebenen tief. Füg eine Index-Datei ein und der Validator schaltet automatisch auf die Index-Regeln um; den Kind-Dateien folgen kann er nicht, weil er nichts abruft.
Noch etwas, das keine Grenze ist, sich aber so verhält: halt die Datei ehrlich. Jede URL darin sollte 200 zurückgeben und indexierbar sein — ein <loc>, das weiterleitet, 404 liefert oder noindex trägt, bringt dem Crawler bei, der Sitemap weniger zu glauben. Das zu bestätigen kostet einen Abruf pro URL und ist damit Serverarbeit, nichts, was eine Seite in deinem Browser beantworten kann. clize seo check --domain deinedomain.de macht genau das und stellt es neben die Search-Console-Daten.
Warum hier eine Datei statt einer URL steht
Jeder andere kostenlose Sitemap-Validator will eine URL und ruft sie serverseitig ab. Dieser läuft vollständig in der Seite, die du gerade ansiehst, und ein Browser darf eine Datei von einer fremden Domain nicht lesen, solange diese Domain es nicht ausdrücklich erlaubt — Same-Origin-Policy, durchgesetzt als CORS. Praktisch keine Website schickt Access-Control-Allow-Origin für ihre Sitemap mit, ein URL-Feld würde hier also bei fast jeder eingegebenen Adresse scheitern. Statt ein Feld auszuliefern, das meistens Fehler wirft, nimmt das Tool die Datei.
Was damit abgedeckt ist und mit einem URL-Feld gar nicht ginge:
- Noch nicht veröffentlicht — die Datei, die dein Generator gerade lokal geschrieben hat, vor dem Deploy.
- Aus der CI — das Artefakt aus der Pipeline, geprüft bevor es je einen Host erreicht.
- Hinter Login, VPN oder Staging-Passwort — ein abrufender Validator bekommt die Login-Seite und meldet sie als kaputtes XML.
- Intern oder ohne Internetzugang — nichts an der Datei verlässt deinen Rechner. Für Sitemaps, die aus Datenschutz- oder Compliance-Gründen nicht an einen fremden Server gehen dürfen, ist das der Unterschied zwischen prüfbar und nicht prüfbar.
Der Preis dafür gehört klar gesagt: dieses Tool kann dir nicht sagen, ob https://deinedomain.de/sitemap.xml wirklich 200 liefert, ob die robots.txt darauf zeigt oder ob die URLs darin leben. Es liest die Bytes, die du ihm gibst. Für eine veröffentlichte Datei holst du sie selbst — curl -s https://deinedomain.de/sitemap.xml, bei gzip curl -s https://deinedomain.de/sitemap.xml.gz | gunzip — und fügst die Ausgabe ein. Übrigens: google.com/ping?sitemap= wurde 2023 abgeschaltet und tut nichts mehr. Was heute zählt, ist eine Sitemap:-Zeile in der robots.txt, eine einmalige Einreichung in der Search Console und den Bing Webmaster Tools — und ein <lastmod>, das stimmt.
// FAQ
Was prüft ein XML-Sitemap-Validator?
Drei Dinge. Dass die Datei wohlgeformtes XML ist — Tags geschlossen und verschachtelt, Kaufmanns-Und maskiert, Namensraum-Präfixe deklariert. Dass sie dem Protokoll von sitemaps.org folgt — Wurzel <urlset> oder <sitemapindex> im 0.9-Namensraum, genau ein absolutes <loc> je Eintrag, ein gültiges W3C-Datetime in <lastmod>, <priority> zwischen 0.0 und 1.0 und <changefreq> aus der erlaubten Liste. Und dass sie innerhalb der Grenzen bleibt und in sich stimmig ist — unter 50.000 URLs und 50 MB unkomprimiert, keine doppelten URLs, und hreflang-Alternates, die aufeinander zurückverweisen.
Warum meldet der Validator mein lastmod als Fehler, obwohl das Datum stimmt?
Fast immer wegen der Schreibweise, nicht wegen des Datums. Gültig sind JJJJ-MM-TT oder JJJJ-MM-TTThh:mm:ss mit Zeitzone. Das deutsche Format 01.09.2026 ist ungültig, ein Leerzeichen statt des Trennzeichens T ist ungültig, eine Uhrzeit ohne Zeitzone ist ungültig, und der Versatz braucht den Doppelpunkt: +02:00, nicht +0200. Wenn dein Export die lokale Uhrzeit schreibt, ist die einfachste sichere Variante entweder UTC mit angehängtem Z oder ein reines Datum ohne Uhrzeit.
Schreibe ich in lastmod +01:00 oder +02:00?
Das hängt vom Zeitpunkt ab, den der Wert beschreibt: MEZ im Winter ist +01:00, MESZ im Sommer ist +02:00. Deshalb ist ein fester, ganzjährig angehängter Versatz für ein halbes Jahr falsch. Wenn dein Generator keine echte Zeitzonenlogik hat, schreib den Zeitstempel in UTC und häng Z an, oder lass die Uhrzeit ganz weg. Ein Datum ohne Uhrzeit ist gültig und für ein Crawl-Signal genau genug.
Kann ich damit eine Sitemap-Index-Datei prüfen?
Ja. Füg eine Datei ein, deren Wurzel <sitemapindex> ist, und der Validator schaltet auf die Index-Regeln um: jeder Eintrag ist ein <sitemap> mit einem <loc> und höchstens einem <lastmod>, ohne <priority>, <changefreq> oder eingestreute <url>-Elemente. Den Kind-Sitemaps folgen kann er nicht, weil er nie etwas abruft — prüf jede Kind-Datei, indem du sie nacheinander einfügst.
Kann er eine gepackte sitemap.xml.gz prüfen?
Ja. Zieh die .gz-Datei auf das Feld oder wähl sie über den Datei-Knopf, dein Browser entpackt sie lokal, bevor die Prüfung läuft. Beachte: gzip ändert die Größengrenze nicht. Die 50 MB werden an der unkomprimierten Datei gemessen, und genau die zeigt der Bericht.
Wie viele URLs darf eine XML-Sitemap enthalten?
Bis zu 50.000 URLs, und die Datei darf 50 MB unkomprimiert nicht überschreiten. Was du zuerst erreichst, ist die Obergrenze. Danach teilst du auf mehrere Sitemaps auf und führst sie in einem Sitemap-Index, der seinerseits bis zu 50.000 Einträge fassen darf. Ein Index darf keinen weiteren Index führen, die Struktur endet also nach zwei Ebenen.
Wird meine Datei hochgeladen, und warum ruft das Tool meine Sitemap nicht selbst ab?
Es wird nichts hochgeladen. Der Validator ist ein Skript in deinem Browser: nichts, was du einfügst oder ablegst, verlässt die Seite, es gibt kein Konto und keine Anmeldung, und nach dem Laden funktioniert die Seite offline. Genau deshalb kann er auch keine URL abrufen — die Same-Origin-Policy hindert eine Seite auf einer Domain daran, eine Datei auf einer anderen zu lesen, solange diese keine CORS-Header schickt, was für Sitemaps praktisch nie der Fall ist. Hol die Datei mit curl und füg die Ausgabe ein; dafür kannst du auch Dateien prüfen, die noch nicht veröffentlicht sind, in der CI entstehen oder hinter einem Login liegen.
Eine gültige Datei ist der Boden. Dann sieh nach, was indexiert wurde.
Die eigene Site zu prüfen kostet nichts: der Befehl liest deine Sitemap und deine Search-Console-Property zusammen, listet jede Seite mit HTTP-Status und Indexstand, markiert die Seiten, die noch nie eine Impression bekommen haben, und zeigt die Zugriffe nach Quelle mit KI-Engines getrennt ausgewiesen. Ein Befehl aus deinem Agenten heraus.
$ npm i -g @clize/clize && clize install $ clize seo check --domain deinedomain.de[ Agent SEO by Clize → ]