Ein Sitemap-Validator prüft, ob eine XML-Sitemap die erwartete Struktur und unterstützte Feldwerte verwendet. Screpy untersucht ein Dokument und zeigt Fehler, Warnungen und Quellbelege, damit Sie den Sitemap-Generator korrigieren können. Ein unauffälliges Ergebnis gilt nur für den geprüften Umfang: Es beweist weder, dass die aufgeführten Seiten funktionieren, noch dass Google sie indexiert hat.
Wählen Sie das zu prüfende Dokument
Geben Sie die genaue öffentliche XML-Adresse ein, etwa https://example.com/sitemap.xml, um die veröffentlichte Datei zu prüfen. Diese fiktive Adresse zeigt das Format. Eine Homepage kann stattdessen HTML liefern; mit Sitemap Checker finden Sie zunächst die Sitemap.
Wählen Sie eingefügtes XML, um den Quelltext vor der Veröffentlichung oder ein gespeichertes Dokument zu prüfen. Kopieren Sie das rohe XML, nicht die formatierte Tabelle des Browsers. Es gibt kein Datei-Upload-Feld. Die optionale Basis-URL liefert Kontext zum Vergleich der Ursprünge; sie repariert keine relativen Adressen. Auch mit https://example.com/ als Basis benötigt <loc>/products/</loc> eine vollständige HTTP- oder HTTPS-Adresse.
Ohne Basis-URL fehlt eingefügtem Inhalt der Ursprungskontext für diesen Vergleich. Seine unterstützte Struktur und Feldwerte lassen sich trotzdem prüfen.
Korrigieren Sie Wurzelelement, Namensraum und XML-Escaping
Eine Seiten-Sitemap benötigt ein urlset-Wurzelelement im Standard-Sitemap-Namensraum und ein loc in jedem url. Dieses fiktive Dokument mit einem Eintrag zeigt die erforderliche Struktur:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/products/blue-mug/</loc>
</url>
</urlset>
Übernehmen Sie den Namensraum-URI exakt, einschließlich http. Er bezeichnet das XML-Vokabular; ein Wechsel zu https erhöht hier nicht die Sicherheit, sondern ändert den Bezeichner. Ein Index verwendet ein anderes Wurzelelement, wie unten erklärt. Das Sitemap-Protokoll definiert beide Strukturen.
Schreiben Sie das & einer URL innerhalb von XML als &, beispielsweise ?color=blue&size=m. Korrigieren Sie das Escaping im Generator, statt einen benötigten URL-Parameter zu entfernen. Fehlende End-Tags, nicht unterstützter Inhalt oder eine DOCTYPE-Deklaration können die Prüfung vor einem detaillierten Bericht stoppen. Eine fehlgeschlagene Prüfung ist keine bestandene Validierung.
Leiten Sie aus jedem Befund eine Quellkorrektur ab
Lesen Sie Ergebnis und Abdeckung gemeinsam. Rot kennzeichnet Fehler, Gelb Warnungen oder teilweise Abdeckung, Grün das Fehlen relevanter Befunde im geprüften Umfang. Text und Symbole ergänzen die Farben. Suchen Sie den XML-Block anhand des Belegs und der Anfangszeile des Eintrags; korrigieren Sie anschließend seine erzeugende Quelle.
| Befund | Beispielproblem | Quellkorrektur |
|---|---|---|
| Ungültige Adresse | /products/ oder leeres loc |
Die gewünschte absolute HTTP- oder HTTPS-URL angeben. |
| Ungültiger optionaler Wert | lastmod mit 2026-02-30 oder priority mit 1.2 |
Wert korrigieren oder ein nicht zuverlässig pflegbares optionales Feld weglassen. |
| Wiederholtes Feld | Zwei loc-Felder in einem Eintrag |
Genau einen Feldwert ausgeben; dies ist ein Fehler. |
| Wiederholte Adresse | Dieselbe Adresse in zwei Einträgen | Quellliste bereinigen; dies ist eine Warnung. |
| Unerwartetes Element | priority in einem Indexeintrag |
Zum Dokumenttyp passende Felder verwenden. |
Die Duplikatprüfung vergleicht Adresszeichenfolgen nach Entfernung äußerer Leerzeichen. Sie stellt weder Inhaltsgleichheit verschiedener URLs fest noch wählt sie eine kanonische URL. Wiederholungen in anderen Dateien liegen ebenfalls außerhalb dieser Dokumentprüfung.
„Zu prüfende Einträge“ zählt Einträge mit Fehlern, nicht alle Warnungen oder dokumentweiten Probleme. Deshalb kann dort trotz eines Wurzel- oder Namensraumfehlers null stehen. Lesen Sie die Befunde, statt diese Kennzahl als Gültigkeitsbewertung zu betrachten. Mehrere Befunde können denselben Eintrag betreffen.
Prüfen Sie Bedeutung und Format von Datumswerten
lastmod, changefreq und priority sind in Seiten-Sitemaps optional. Ihr Fehlen ist kein Feldfehler. Verwenden Sie gegebenenfalls einen gültigen Wert wie 2026-09-01 oder 2026-09-01T14:30:00Z. Ein plausibles Format macht ein unmögliches Kalenderdatum nicht gültig.
Für eine Seite sollte lastmod eine wesentliche Änderung widerspiegeln, nicht jede Sitemap-Neuerstellung. Ein Generator, der alle Daten auf heute setzt, kann syntaktisch gültige, aber irreführende Angaben erzeugen. Vergleichen Sie das Quelldatum mit tatsächlichen Seitenänderungen; dieser Validator kann den Änderungsverlauf nicht überprüfen.
Laut Googles Sitemap-Leitfaden verwendet Google durchgehend korrekte, überprüfbare Änderungsdaten und ignoriert priority und changefreq. Diese beiden Felder zu korrigieren repariert gelieferte Metadaten; es verbessert nicht automatisch Rankings. Falls angegeben, muss die Priorität zwischen 0 und 1 liegen und die Häufigkeit einen unterstützten kleingeschriebenen Wert wie weekly verwenden.
Lesen Sie einen Index als Dateiliste
Ein sitemapindex enthält sitemap-Einträge. Jedes loc verweist auf eine untergeordnete Sitemap-Datei; das optionale lastmod beschreibt deren Änderung. Es bezeichnet nicht die Änderung jeder darin aufgeführten Seite. Ein Index mit drei Dateien hat somit drei Einträge, nicht drei Website-Seiten.
Screpy validiert den eingereichten Index selbst und öffnet keine untergeordneten Dateien. Prüfen Sie die jeweilige Datei separat, wenn Sie dort einen Fehler untersuchen. Für eine herunterladbare Bestandsliste extrahiert XML Sitemap Parser Einträge; er macht aus einem Index keine zusammengeführte Seitenliste.
Eine Ursprungswarnung vergleicht Schema, Hostnamen und Port des Eintrags mit der endgültigen URL des abgerufenen Dokuments oder der Basis eingefügten XMLs. Prüfen Sie unerwartetes http, abweichende Hosts oder Ports vor Adressänderungen. Eine Abweichung verlangt Prüfung, kein automatisches Urteil über eine ungültige Einreichung.
Google erlaubt konfigurierte websiteübergreifende Sitemap-Einreichungen mit entsprechenden Eigentumsnachweisen oder websitespezifischen Sitemap-Verweisen. Dieses Tool kann diese Einstellungen nicht überprüfen. Klären Sie die beabsichtigte Einreichung, bevor Sie legitime Adressen nur zur Beseitigung einer Warnung ersetzen.
Prüfen Sie die korrigierte Datei im angegebenen Umfang erneut
Das Protokoll begrenzt jede Datei auf 50.000 Einträge und 50 MiB unkomprimierten Inhalt. Screpy akzeptiert bis zu 256 KiB eingefügtes XML oder 50 MiB dekodiertes entferntes XML. Diese Grenzen messen Bytes, nicht Zeichen.
Die Validierung stoppt bei 50.000 verarbeiteten Einträgen; vollständige Gesamtzahl und XML-Wohlgeformtheit können unbekannt bleiben. Höchstens 1.000 Zeilen werden aufbewahrt; Antwortgrößenlimits können die Ausgabe weiter verkleinern. Mehr gelesene als sichtbare Einträge machen die angezeigte Liste nicht vollständig. Prüfen Sie die Abdeckung, bevor Sie Zahlen interpretieren oder Berichte teilen.
CSV und TXT enthalten aufbewahrte Einträge, JSON den begrenzten Bericht. Ein Export aus einem Teilergebnis garantiert keine vollständige Bestandsliste. Erweiterungselemente können ebenfalls teilweise Abdeckung verursachen: Das Tool prüft unterstützte Kernfelder, nicht vollständige Erweiterungsschemas oder vollständige XSD-Konformität.
Korrigieren Sie Generator, Vorlage oder Quelldatensätze, erzeugen Sie XML erneut und prüfen Sie die korrigierte veröffentlichte Adresse. Eine bloße Änderung der generierten Datei kann beim nächsten Durchlauf überschrieben werden. Prüfen Sie für große Dateien kleinere Quell-Sitemaps separat und dokumentieren Sie abgeschlossene Prüfungen.
Untersuchen Sie schließlich das Seitenverhalten separat. Bulk HTTP Status Checker hilft bei Antworten und Weiterleitungen gelisteter URLs. Bestandene XML-Prüfungen belegen weder Seitenstatus, Kanonisierung, noindex noch Indexierung. Prüfen Sie nach der Einreichung Googles Sitemap-Verarbeitung und Belege zur Seitenindexierung, statt den Bericht als Nachweis für Suchsichtbarkeit zu behandeln.