XML-Sitemap-Fehler beheben: Ursachen und Lösungen

Sitemap-Fehler beheben Sie, indem Sie den exakten sitemaps.org-Namespace deklarieren, Sonderzeichen wie & in URLs maskieren, ausschließlich absolute https-URLs des eigenen Hosts listen, <lastmod> im W3C-Format angeben, die Datei unter 50.000 URLs und 50 MB halten und sicherstellen, dass die Sitemap-URL selbst mit HTTP 200 und echtem XML antwortet.

Das klingt nach viel, ist aber gut einzugrenzen: In der Praxis fallen fast alle Fehlermeldungen – ob aus der Google Search Console oder aus einem Validator – in eine von neun Kategorien. Dieser Guide geht sie der Reihe nach durch. Wenn Sie noch nicht wissen, welche Kategorie Ihr Problem betrifft, jagen Sie Ihre Datei zuerst durch unseren Sitemap-Validator: Er nennt Fehler mit Zeilenbezug und verweist auf die passende Korrektur.

Schnellübersicht: Symptom, Ursache, Lösung

Falscher oder fehlender Namespace

Das Wurzelelement <urlset> muss den Namespace des Protokolls wortwörtlich deklarieren. Schon ein Tippfehler, ein fehlendes Schema oder der veraltete 0.84-Namespace führt dazu, dass strenge Parser die komplette Datei verwerfen. So sieht die korrekte Zeile aus:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/seite/</loc>
  </url>
</urlset>

Kopieren Sie den Namespace aus der offiziellen Protokolldokumentation, statt ihn abzutippen. Achtung: http:// im Namespace ist korrekt – er ist ein Bezeichner, keine abrufbare Adresse, und darf nicht auf https „modernisiert“ werden.

Unmaskierte Sonderzeichen in URLs

XML reserviert fünf Zeichen, die in einem <loc>-Wert nicht roh stehen dürfen: &, <, >, " und '. Der Klassiker ist das Und-Zeichen in Query-Strings. Aus ?farbe=rot&groesse=m muss in der Sitemap ?farbe=rot&groesse=m werden. Ein einziges rohes & genügt, und der Parser bricht mit einem Syntaxfehler ab – oft mit einer Zeilenangabe, die auf die betroffene URL zeigt.

Relative oder unvollständige URLs

Jedes <loc> muss eine vollständige absolute URL sein: Schema, Host, Pfad. Ungültig sind relative Pfade wie /produkte/, schemalose Angaben wie //example.com/produkte/ und Hostnamen ohne Schema. Wenn Ihr CMS die Sitemap aus relativen Links generiert, konfigurieren Sie dort die kanonische Basis-URL – meist eine einzige Einstellung.

Ungültige lastmod-Werte

Das Protokoll verlangt das W3C-Datumsformat: 2026-07-16 oder mit Uhrzeit 2026-07-16T09:30:00+00:00. Häufige Fehlformen sind deutsche Schreibweisen wie 16.07.2026, Unix-Timestamps und englische Monatsnamen. Zwei weitere Fallstricke:

• Zukunftsdaten: Ein lastmod, das vor dem tatsächlichen Deployment liegt oder durch eine falsche Serverzeitzone in die Zukunft rutscht, untergräbt das Vertrauen der Suchmaschinen in alle Ihre Datumsangaben.
• Pauschale Daten: Wenn jede URL denselben Zeitstempel trägt (typisch: die Generierungszeit der Sitemap), ist der Wert wertlos. Dann lieber weglassen.

Zu groß: über 50.000 URLs oder 50 MB

Eine einzelne Sitemap darf höchstens 50.000 URLs enthalten und unkomprimiert höchstens 50 MB groß sein – das gzip-Komprimieren ändert am 50-MB-Limit der entpackten Datei nichts. Überschreiten Sie eine der Grenzen, teilen Sie die Datei auf mehrere Sitemaps auf und listen diese in einer Index-Datei. Wie das genau funktioniert, erklärt unser Guide zu Sitemap-Index-Dateien.

Die Sitemap-URL selbst antwortet falsch

Bevor ein Crawler auch nur ein Byte XML parst, muss der Abruf der Datei gelingen. Drei typische Störungen:

1. 404 oder 410: Die Sitemap wurde verschoben oder beim letzten Deployment nicht mehr erzeugt, aber die alte URL ist noch in robots.txt oder Search Console hinterlegt.
2. Redirects: Eine Weiterleitung von http auf https oder von non-www auf www funktioniert meist, ist aber fehleranfällig. Reichen Sie direkt die Ziel-URL ein.
3. HTML statt XML: Manche Server liefern bei Fehlern eine hübsche HTML-Fehlerseite mit Status 200 aus. Für den Crawler ist das eine kaputte Sitemap. Prüfen Sie den Content-Type: Er sollte application/xml oder text/xml sein.

URLs auf dem falschen Host

Die URLs in einer Sitemap müssen zum Host passen, der die Datei ausliefert – exakt, inklusive Subdomain und Schema. Liegt die Sitemap auf https://www.example.com/sitemap.xml, gehören keine URLs von https://example.com/… oder http://www.example.com/… hinein. Solche hostfremden Einträge werden ignoriert, sofern die Sitemap nicht per robots.txt-Querverweis für den anderen Host autorisiert ist. Die Lösung ist fast immer: Sitemap aus den kanonischen URLs generieren, nicht aus internen oder historischen Varianten.

Gelistete Seiten sind blockiert oder auf noindex

Eine Sitemap ist eine Empfehlungsliste: „Diese Seiten sollt ihr crawlen und indexieren.“ Wenn dieselben Seiten per robots.txt gesperrt sind oder ein noindex tragen, senden Sie widersprüchliche Signale, und die Search Console meldet das als Fehler oder Warnung. Entfernen Sie blockierte und nicht indexierbare URLs aus der Sitemap – oder heben Sie die Sperre auf, falls die Seiten doch in den Index sollen. Was grundsätzlich in eine Sitemap gehört, behandelt unser Guide zu Sitemap-Best-Practices.

„Couldn’t fetch“ in der Google Search Console

Diese Meldung bedeutet nur: Google konnte die Datei nicht abrufen. Die Ursache liegt fast nie im XML, sondern im Abrufweg. Prüfen Sie in dieser Reihenfolge:

• Liefert die URL im Browser und per curl Status 200 mit XML?
• Blockiert Ihre robots.txt den Pfad der Sitemap selbst?
• Sperrt eine Firewall, ein Bot-Schutz oder ein CDN den Googlebot aus (403, 429 oder Timeout)?
• Stimmt die eingereichte URL zeichengenau, inklusive https und www-Form?

Direkt nach dem Einreichen kann die Meldung auch schlicht bedeuten, dass Google die Datei noch nicht abgeholt hat – ein paar Stunden Geduld sind hier Teil der Diagnose. Details zum Einreichen dokumentiert Google in der Search-Central-Dokumentation.

Nach der Korrektur: neu prüfen, dann neu einreichen

Beheben Sie zuerst alle Fehler, dann die Warnungen, und validieren Sie die Datei erneut – erst lokal im Validator, dann per erneutem Einreichen in der Search Console. Suchmaschinen holen bekannte Sitemaps zwar von selbst regelmäßig ab, aber das erneute Einreichen beschleunigt die Rückmeldung und zeigt Ihnen schwarz auf weiß, dass der Fehler behoben ist.