Kostenloser Sitemap-Validator

Was ist eine sitemap.xml und warum ist sie wichtig?

Eine Sitemap ist ein strukturiertes XML-Dokument, das die URLs einer Website auflistet, die Suchmaschinen kennen sollen. Sie wird von einem stabilen Pfad aus bereitgestellt, fast immer /sitemap.xml, und folgt dem Sitemap-Protokoll — einer kleinen Spezifikation, die ursprünglich 2005 von Google veröffentlicht und ein Jahr später als gemeinsamer Standard von Google, Yahoo und Microsoft übernommen wurde. Das Format ist einfach: ein <urlset>-Wurzelelement mit einem <url>-Element pro Seite, mit optionalen Metadaten darüber, wann jede URL zuletzt geändert wurde, wie oft sie sich ändert und wie sie in Bezug auf Priorität zu anderen auf derselben Website steht.

Der Zweck einer Sitemap ist Entdeckung, nicht Ranking. Suchmaschinen crawlen das Web, indem sie Links von Seite zu Seite folgen. Auf einer kleinen Website mit sauberer interner Verlinkung ist jede Seite von der Startseite aus in wenigen Klicks erreichbar, und Crawler finden alles ohne Hilfe. Auf einer großen Website, auf einer Website mit tiefer Paginierung, auf einer Website mit isolierten Landingpages, auf die kein interner Link zeigt, oder auf einer Website, die gerade neue Inhalte veröffentlicht hat, können Crawler Tage oder Wochen brauchen, um URLs allein über Links zu entdecken. Die Sitemap löst dies, indem sie dem Crawler eine vollständige Liste im Voraus übergibt.

Sitemaps garantieren keine Indexierung. Google hat dies in seiner Dokumentation seit dem Start des Protokolls ausdrücklich festgestellt: Eine URL in deiner Sitemap ist ein Signal, dass du sie indexiert haben möchtest, kein Befehl, dass sie es wird. Seiten mit geringer Qualität, doppelten Inhalten oder dünnen Informationen werden unabhängig von der Sitemap-Aufnahme übersprungen. Was die Sitemap ändert, ist die Crawl-Effizienz. Mit einer Sitemap kann Google deine neuen und aktualisierten Seiten zuerst crawlen, sie basierend auf dem lastmod-Feld priorisieren und das Verschwenden von Anfragen an veraltete oder archivierte URLs vermeiden.

Sitemaps sind auch für den Long Tail wichtig. Eine Website mit 100.000 Produktseiten, 5.000 Blog-Beiträgen und 200 Kategorie-Landingpages hat zu viel, als dass ein internes Verlinkungsmuster jede URL in wenigen Klicks zugänglich machen könnte. Ohne Sitemap verlässt sich die Website auf Googlebots explorative Crawling-Aktivität, um die tiefen URLs zu finden, was funktioniert, aber langsam ist. Mit einer Sitemap kennt Google jede URL sofort, und der Crawler kann sein Budget für Aktualitätsprüfungen und Inhaltsqualität statt für Entdeckung aufwenden. Für E-Commerce, Nachrichtenverlage, Marktplätze und inhaltslastige Websites ist die Sitemap nicht optional.

So verwendest du diesen Checker

Der Checker nimmt eine Sitemap-URL oder einen Domain-Root und gibt einen strukturierten Bericht über Validität, Vollständigkeit und Erreichbarkeit zurück.

Schritt 1 — Gib die Sitemap-URL ein. Füge die vollständige URL zu deiner Sitemap ein oder nur die Domain — der Checker erkennt sie automatisch über robots.txt und versucht gängige Pfade wie /sitemap.xml, /sitemap_index.xml und /sitemap.xml.gz. Er folgt auch automatisch Sitemap-Index-Dateien und geht jede darin enthaltene untergeordnete Sitemap durch.

Schritt 2 — Überprüfe den Validierungsbericht. Der Checker validiert das XML gegen das Sitemap-Protokoll-Schema, kennzeichnet fehlerhafte lastmod-Werte, prüft auf URLs über dem 2048-Zeichen-Pfadlimit und verifiziert, dass die Datei unter den harten Limits von 50 MB unkomprimiert und 50.000 URLs liegt. Jedes Problem wird mit der genauen URL oder Zeilennummer angezeigt, die es ausgelöst hat.

Schritt 3 — Prüfe die Erreichbarkeit. Für eine Stichprobe von URLs in der Sitemap führt der Checker eine HEAD-Anfrage durch und meldet den Antwortcode. URLs, die 404, 301, 302 oder 5xx in deiner Sitemap zurückgeben, sind Rauschen, das Crawl-Budget verschwendet; der Bericht zeigt sie gruppiert an, damit du sie korrigieren oder entfernen kannst.

Das Sitemap-Protokoll im Detail

Eine minimal gültige Sitemap sieht so aus:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-04-27T12:00:00+00:00</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/article</loc>
    <lastmod>2026-04-15</lastmod>
  </url>
</urlset>

Nur <loc> ist erforderlich. Die anderen drei optionalen Felder sind <lastmod>, <changefreq> und <priority>, und die moderne Best Practice behandelt jedes davon unterschiedlich.

Harte Limits und das Sitemap-Index-Muster

Eine einzelne Sitemap-Datei darf höchstens 50.000 URLs enthalten und muss unter 50 MB unkomprimiert bleiben. Diese Limits sind seit dem Start im Protokoll enthalten und werden von jedem großen Crawler durchgesetzt. Dateien über dem Limit werden nicht nur abgeschnitten — sie werden von Googlebot vollständig abgelehnt, der dann einen Fehler in der Search Console meldet. Für eine Website mit mehr URLs als in eine einzelne Datei passen, definiert das Protokoll ein Sitemap-Index-Format, das mehrere untergeordnete Sitemaps auflistet:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-pages.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-04-27</lastmod>
  </sitemap>
</sitemapindex>

Der Index kann bis zu 50.000 untergeordnete Sitemaps auflisten, jede mit 50.000 URLs, für ein theoretisches Limit von 2,5 Milliarden URLs auf der gesamten Website. In der Praxis ergibt eine Strukturierung nach Inhaltstyp — Seiten, Produkte, Blog-Beiträge, Tags, Kategorien — eine wartbare Struktur, die es auch ermöglicht, bei jedem Deploy nur die geänderte Sub-Sitemap neu zu generieren. Die Konvention ist, den Index sitemap.xml oder sitemap_index.xml und die Kinder mit beschreibenden Pfaden zu benennen.

lastmod-Präzision und wann Google ihm vertraut

Google hat wiederholt erklärt, dass es lastmod verwendet, wenn der Wert korrekt ist, und ihn für die gesamte Sitemap entwertet, wenn er unzuverlässig erscheint. Eine Website, die für jede URL immer das heutige Datum meldet, meldet Aktualität, die nicht existiert; Google erkennt das Muster und hört auf, das Feld zu gewichten. Das Gleiche gilt für lastmod-Werte, die sich nie aktualisieren, auch wenn sich der Inhalt ändert — das Fehlen des Signals ist selbst ein Signal.

Verwende das vollständige ISO 8601-Datetime-Format einschließlich des Zeitzonenversatzes: 2026-04-27T12:00:00+00:00. Die reine Datumsform 2026-04-27 ist gültig und akzeptiert, aber die Datetime-Form wird für hochfrequente Websites bevorzugt, bei denen die Tageszeit eine Rolle spielt. Setze lastmod auf die tatsächliche Änderungszeit des Seiteninhalts, nicht auf die Deploy-Zeit deiner Anwendung. Seiten, die sich nicht geändert haben, sollten ihren alten lastmod-Wert behalten, auch wenn der Rest der Sitemap neu generiert wird.

changefreq und priority: meist ignoriert

Die Felder <changefreq> und <priority> wurden im ursprünglichen Protokoll definiert, um Website-Betreibern eine Möglichkeit zu geben auszudrücken, wie oft sich eine Seite ändert (always, hourly, daily, weekly, monthly, yearly, never) und eine relative Priorität innerhalb der Website (eine Dezimalzahl zwischen 0.0 und 1.0). Modernes Google ignoriert beides. Der Crawler entscheidet die Crawl-Häufigkeit aus beobachteten Änderungsmustern und entscheidet die Priorität aus Inhaltsqualität und Link-Equity, nicht aus Sitemap-Deklarationen.

Die praktische Empfehlung ist, beide Felder wegzulassen. Sie machen die Sitemap größer und komplexer, ohne das Crawler-Verhalten zu ändern. Bings Dokumentation legt nahe, dass changefreq noch schwach berücksichtigt wird, aber der Einfluss ist gering genug, dass die Pflege genauer Werte selten den Engineering-Aufwand wert ist. Eine saubere Sitemap mit nur <loc> und <lastmod> ist der moderne Standard.

Autodiscovery über robots.txt vs Search Console-Einreichung

Zwei Möglichkeiten, Google über eine Sitemap zu informieren: in robots.txt deklarieren oder über Search Console einreichen. Beide funktionieren, beide werden empfohlen, und beide zusammen sind die moderne Best Practice.

User-agent: *
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

Die robots.txt-Deklaration wird von jedem wohlerzogenen Crawler gelesen — Googlebot, Bingbot, DuckDuckBot, Yandex und den meisten SEO-Tools — ohne plattformspezifisches Setup. Die Search Console-Einreichung ist Google-spezifisch, ermöglicht aber die Indexierungsberichte, die zeigen, wie viele URLs in der Sitemap indexiert sind, wie viele ausgeschlossen sind und warum. Für eine Website, die SEO ernst nimmt: über Search Console für Sichtbarkeit einreichen und in robots.txt für Portabilität deklarieren.

Bild-, Video- und News-Sitemap-Erweiterungen

Das Basisprotokoll hat Erweiterungen für Bild-, Video- und News-Inhalte. Bild-Sitemaps fügen ein <image:image>-Element hinzu, das die Bilder auf jeder Seite auflistet, was Google hilft, Bilder auf JavaScript-gerenderten Seiten zu entdecken, bei denen die Bild-URLs nicht im ursprünglichen HTML vorhanden sind. Video-Sitemaps fügen ein <video:video>-Element mit Titel, Beschreibung, Thumbnail und Laufzeit hinzu und bleiben der kanonische Weg, Video an Google Video zu übermitteln. News-Sitemaps verwenden ein separates <news:news>-Element mit Veröffentlichungsdatum und erforderlichem Namespace und sind obligatorisch für die Aufnahme in Google News.

Für eine typische Marketing- oder Content-Website deckt eine einfache URL-Sitemap den Anwendungsfall vollständig ab. Die Erweiterungen sind die Komplexität nur dann wert, wenn Bild-Auffindbarkeit, Video oder News-Aufnahme eine bedeutende Traffic-Quelle ist.

Häufige Fehler, die das SEO beeinträchtigen

404s und Weiterleitungen in der Sitemap. URLs aufzulisten, die 404 zurückgeben oder auf eine andere URL weiterleiten, verschmutzt die Sitemap mit Rauschen. Google kennzeichnet diese in der Search Console als Sitemap-Fehler und kann den Rest der Sitemap entwerten. Überprüfe die Sitemap bei jedem Deploy und entferne non-200 URLs. Weiterleitungen sollten durch die Ziel-URL ersetzt werden.

Aufnahme nicht-kanonischer URLs. Seiten mit rel="canonical", die auf eine andere URL zeigen, sollten nicht in der Sitemap erscheinen. Die Sitemap ist eine Liste von Seiten, die du indexiert haben möchtest; kanonisierte Seiten sind Seiten, von denen du Suchmaschinen explizit gesagt hast, sie zu ignorieren. Ihre Aufnahme erzeugt widersprüchliche Signale.

Immer aktuelles lastmod. lastmod bei jeder Regenerierung für jede URL auf das heutige Datum zu setzen teilt Google mit, dass das Feld unzuverlässig ist, und der Crawler hört auf, es zu gewichten. Setze lastmod aus der echten Änderungszeit des Seiteninhalts, nicht aus der Deploy-Zeit. Seiten, die sich nicht geändert haben, sollten ihren vorherigen lastmod behalten.

Sitemap durch robots.txt blockiert. Eine Disallow: /sitemap.xml-Zeile oder ein breiteres Disallow: /sitemap, das die Datei trifft, verhindert, dass Crawler die Sitemap überhaupt abrufen. Teste nach der Änderung von robots.txt immer mit curl oder einem Sitemap-Checker, um zu bestätigen, dass die Sitemap-URL erreichbar ist.

Sub-Sitemaps innerhalb eines Sitemap-Index liefern 404. Ein Sitemap-Index, der zehn untergeordnete Sitemaps auflistet, von denen nur neun auflösen, führt dazu, dass die fehlende als Fehler markiert wird. Schlimmer noch: Wenn sich das Pfadmuster zwischen Deploys ändert, wird jede alte Sub-Sitemap-URL zu einer 404, bis der Index neu generiert wird. Generiere den Index aus derselben Wahrheitsquelle wie die Kinder, um sie synchron zu halten.

Protokolle in einer Sitemap mischen. Eine Sitemap, die unter https://example.com/sitemap.xml bereitgestellt wird, sollte nur https://-URLs enthalten. Gemischte http://-URLs werden als anderer Host behandelt und vom Sitemap-Prozessor des kanonischen Hosts ignoriert. Das Gleiche gilt für www vs. non-www-Inkonsistenz: Wähle eines und verwende es durchgängig in der Sitemap.

Vergessen, Sonderzeichen in URLs zu escapen. XML erfordert, dass &, <, >, " und ' in Attribut- und Elementwerten escaped werden. URLs mit rohen Ampersands brechen den XML-Parser, und die gesamte Sitemap schlägt bei der Validierung fehl. Generiere URLs über eine Bibliothek, die das Escaping übernimmt, anstatt Strings manuell zu verketten.

Sonderfälle, die niemand erwähnt

Eine sitemap.xml, die mit dem falschen Content-Type bereitgestellt wird, bricht einige Crawler. Der korrekte Content-Type ist application/xml oder text/xml. Einige Server geben text/plain oder text/html für .xml-Dateien zurück, wenn der MIME-Typ nicht konfiguriert ist, und Bingbot insbesondere ist dafür bekannt, solche Antworten abzulehnen. Der Checker testet den Content-Type und kennzeichnet ihn als Warnung, wenn er nicht übereinstimmt.

Komprimierte Sitemaps als .xml.gz sparen enorm Bandbreite — Sitemaps komprimieren auf 5-10 % ihrer ursprünglichen Größe aufgrund der starken URL-Präfix-Wiederholung. Sowohl Google als auch Bing akzeptieren gzip-komprimierte Sitemaps ohne zusätzliche Konfiguration, und das Dateigrößenlimit wird gegen die unkomprimierte Größe gemessen. Der einzige Nachteil ist, dass einige Hosting-Plattformen .gz-Dateien mit falscher Content-Encoding bereitstellen, wodurch der Crawler rohe Gzip-Bytes erhält, die nicht geparst werden können. Teste die gzip-Version in einem Browser; wenn du binären Datenmüll anstelle von XML siehst, fehlt der Content-Encoding: gzip-Header in der Antwort.