0

Sitemap.xml Validator – Echter Protokoll-Compliance-Checker

Fügen Sie eine sitemap.xml (oder einen Sitemap-Index) ein oder laden Sie sie hoch und validieren Sie sie anhand des echten sitemaps.org-Protokolls: Stammelement und Namespace, absolute <loc>-URLs, die dokumentierten 50.000-URL-/50-MB-Grenzwerte, <lastmod>, <priority>, <changefreq> – plus ein Aktualitätshistogramm und die Erkennung doppelter URLs.

🗺️

Datei hierher ziehen oder zum Auswählen klicken

oder klicken Sie zum Durchsuchen – eine einzelne .xml-Datei

Buy Me a Coffee at ko-fi.com
Verarbeitung... 0%
XML analysieren
Überprüfung der Sitemap-Protokollregeln
URLs analysieren
Fertig

Ergebnis

Eine sitemap.xml-Datei kann perfekt wohlgeformtes XML sein und dennoch eine fehlerhafte Sitemap sein: Ein fehlender xmlns-Namespace, eine relative <loc>-URL, eine <priority> von „1.5“ oder eine <changefreq> von „Daily“ anstelle von „daily“ bestehen alle einen generischen XML-Validator, während das eigentliche Sitemap-Protokoll, das Google, Bing und jeder andere Verbraucher der Datei erwartet, stillschweigend scheitert. Dieses Tool analysiert Ihre eingefügte oder hochgeladene Sitemap mit dem nativen DOMParser des Browsers und vergleicht sie mit den tatsächlichen Regeln, die auf sitemaps.org veröffentlicht sind: Das Stammelement muss <urlset> für eine reguläre Sitemap oder <sitemapindex> für einen Sitemap-Index (automatisch erkannt) sein, idealerweise mit dem genauen Namensraum http://www.sitemaps.org/schemas/sitemap/0.9 deklariert und jede <url> (oder <sitemap>, in einem Index). Datei) muss einen <loc> enthalten, der in eine echte absolute http/https-URL aufgelöst wird.

Über die Struktur hinaus dokumentiert das Protokoll auch harte Grenzwerte und präzise Feldformate, die dieses Tool Feld für Feld überprüft. Eine einzelne Sitemap-Datei darf nicht mehr als 50.000 URLs auflisten und unkomprimiert nicht größer als 50 MB sein – Grenzwerte, die auch für Sitemap-Indexdateien gelten, wobei <sitemap>-Einträge anstelle von <url>-Einträgen gezählt werden – und dieses Tool misst Ihren tatsächlich eingefügten/hochgeladenen Inhalt mit beiden. Jeder <lastmod>, falls vorhanden, wird mit den echten W3C-Datums-/Uhrzeitformaten verglichen, die die Spezifikation akzeptiert: ein bloßes Datum (JJJJ-MM-TT) oder ein vollständiger Zeitstempel mit Stunden, Minuten, optionalen Sekunden und einem obligatorischen Zeitzonenbezeichner. Jede <priority> muss, sofern vorhanden, eine Dezimalzahl zwischen 0,0 und 1,0 sein, und jede <changefreq> muss genau einer der sieben in der Spezifikation definierten Werte sein – immer, stündlich, täglich, wöchentlich, monatlich, jährlich, nie – kein plausibel aussehendes Synonym. Bei jedem Verstoß werden die spezifische Eintragsnummer und der tatsächliche Wert angegeben, wobei die Obergrenze auf 50 angezeigte Verstöße pro Regel mit einem „+N mehr“-Hinweis begrenzt ist, damit der Bericht auch auf einer Sitemap nahe der URL-Grenze lesbar bleibt.

Zwei Überprüfungen gehen über die Anforderungen des schriftlichen Protokolls hinaus, decken aber echte, häufige Probleme auf: Ein <lastmod>-Aktivitätshistogramm gruppiert jedes gültige Datum der letzten Änderung nach Monat, sodass Sie auf einen Blick sehen können, ob der Inhalt einer Website tatsächlich aktuell gehalten wird oder ob die meisten URLs einen veralteten Zeitstempel von vor Jahren tragen, und ein Duplikat-<loc>-Detektor markiert jede URL, die mehr als einmal in derselben Datei aufgeführt ist – ein häufiger Nebeneffekt von Sitemap-Generatoren, die mehrere Quellen ohne Deduplizierung zusammenführen. Alles läuft lokal: Parsing, Regelprüfung und das Histogramm werden alle in Ihrem Browser aus dem von Ihnen eingefügten Text oder der Datei, die Sie über die Datei-API hochgeladen haben, berechnet, es wird nichts abgerufen oder auf einen Server hochgeladen, und es wird niemals eine einzelne URL in Ihrer Sitemap angefordert oder gecrawlt – dieses Tool überprüft das Sitemap-Dokument selbst, nicht, ob die darin aufgelisteten Seiten tatsächlich existieren oder 200 OK zurückgeben.