Was ist ein Sitemap-Index?

Das Sitemap-Protokoll setzt jeder Datei zwei Obergrenzen: 50.000 URLs und 50 MB unkomprimiert. Eine Firmenseite mit zweihundert Seiten kommt dieser Grenze nie nahe. Ein Shop mit tiefem Katalog, ein Nachrichtenportal mit Archiv oder ein Immobilienmarkt reißt sie mühelos, und dann muss die Datei geteilt werden.

Der Unterschied zu einer gewöhnlichen Sitemap steckt im Inhalt jedes Eintrags. In einer normalen Sitemap beschreibt jedes url-Element eine Seite der Website, und sein loc enthält die Adresse dieser Seite. In einem Index beschreibt jedes sitemap-Element eine Datei, und sein loc enthält die Adresse dieser Datei. Der Crawler arbeitet dadurch in zwei Schritten: Er lädt zuerst den Index und danach jede der gelisteten Sitemaps.

Alles Übrige ist gleich. Derselbe XML-Namensraum, dieselbe Pflicht zu UTF-8, dieselben Regeln für maskierte Entitäten. Google sagt es ohne Umschweife: Was für eine Sitemap gilt, gilt auch für einen Index. Deshalb scheitert ein fehlerhafter Index genauso wie eine fehlerhafte Sitemap, und deshalb greift die Grenze von 50 MB auch für die Indexdatei selbst.

Der Aufbau ist knapp. Wurzel ist sitemapindex, jede gelistete Datei steht in einem sitemap, und nur loc ist Pflicht. Die Angabe lastmod ist optional und nennt den Zeitpunkt, zu dem die zugehörige Sitemap-Datei zuletzt geändert wurde, im W3C-Datetime-Format.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns=
"http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
  <loc>https://ejemplo.com/sitemap-1.xml</loc>
  <lastmod>2026-08-18</lastmod>
  </sitemap>
  <sitemap>
  <loc>https://ejemplo.com/sitemap-2.xml</loc>
  <lastmod>2026-07-30</lastmod>
  </sitemap>
</sitemapindex>

Die Grenzen wiederholen die einer normalen Sitemap: Ein Index darf bis zu 50.000 Dateien listen und 50 MB unkomprimiert nicht überschreiten, also 52.428.800 Bytes. Beide Obergrenzen zusammen ergeben bis zu 2,5 Milliarden URLs unter einem einzigen Index. Die Search Console nimmt zusätzlich bis zu 500 Indexdateien je Website an, womit der praktische Spielraum weit über dem liegt, was fast jedes Projekt braucht.

Eine Einschränkung überrascht viele: Ein Index darf keinen weiteren Index listen. Google weist diese Konstruktion mit einem eigenen Fehler zurück, „Nested sitemap indexes“, und verlangt, Einträge auf Indexdateien zu entfernen. Braucht ein Projekt mehr Kapazität, werden mehrere Indizes getrennt eingereicht.

Auch der Ablageort bestimmt mit. Die referenzierten Sitemaps müssen auf derselben Website liegen wie der Index und im selben Verzeichnis oder darunter. Ein Index in der Domainwurzel deckt die ganze Website ab; einer unter /public/ erreicht nur diesen Ordner und seine Unterverzeichnisse. Um Sitemaps auf einem anderen Host zu listen, braucht es die hostsübergreifende Einreichung, die sich auf die robots.txt des Zielhosts oder die passende Property in der Search Console stützt.

Die Entscheidung, die an dieser Datei hängt, ist der Zuschnitt der Sitemaps, und dieser Zuschnitt bestimmt, was später messbar ist. Die Search Console berichtet je Sitemap: gefundene URLs, Lesefehler und, im Abgleich mit dem Bericht zur Seitenindexierung, wie viele dieser URLs aufgenommen wurden. Reist der ganze Katalog in einer einzigen Riesendatei, kommt diese Zahl nur als Summe an und sagt kaum etwas.

Ein Zuschnitt nach Inhaltstyp ändert die Diagnose. Ein Index, der auf je eine Sitemap für Produktseiten, Kategorien, Artikel und Rechtstexte zeigt, macht sichtbar, dass die Kategorien zu 95 % indexiert sind, während die Produktseiten bei 40 % hängen bleiben. Dieser Kontrast zeigt das Problem, bevor irgendetwas angefasst wird.

Wie weit das Werkzeug reicht, gehört dazu. Eine Sitemap einzureichen ist nur ein Hinweis an die Suchmaschine: Es verpflichtet sie weder zum Herunterladen noch garantiert es, dass die gelisteten URLs gecrawlt oder indexiert werden. Ein Index beschleunigt das Auffinden auf großen Websites und ordnet die Diagnose, und dort endet seine Wirkung. Über das Ergebnis entscheiden weiterhin die Qualität der Seiten und die interne Verlinkung.

• Lege den Index in die Domainwurzel, etwa unter https://ejemplo.com/sitemap_index.xml, damit seine Reichweite die ganze Website umfasst.
• Trage seine Adresse in der robots.txt mit der Direktive Sitemap: ein und reiche ihn zusätzlich in der Search Console ein.
• Schneide nach Inhaltstyp zu, statt in willkürliche Blöcke zu 50.000 URLs zu trennen: So beantwortet jede Zahl im Bericht eine konkrete Frage.
• Halte lastmod lebendig und ehrlich. Google nutzt den Wert, wenn er stimmig und überprüfbar ist, und verlässt sich nicht mehr darauf, wenn jede Neuerzeugung das heutige Datum in alle Dateien stempelt.
• Nimm nur kanonische URLs auf, die 200 liefern und indexierbar sind; eine Weiterleitung oder ein noindex in einer Sitemap ist Rauschen, das gegen dich arbeitet.
• Komprimiere große Kind-Sitemaps mit gzip und behalte im Kopf, dass die Grenze von 50 MB an der unkomprimierten Datei gemessen wird.

• Indizes verschachteln. Ein Index, der auf einen weiteren Index zeigt, löst den Fehler „Nested sitemap indexes“ aus und lässt alles ungelesen, was an diesem Eintrag hängt.
• Den Index in einem Unterverzeichnis ablegen und Sitemaps listen, die in der Hierarchie darüber liegen. Diese Einträge fallen aus seiner Reichweite.
• Hosts oder Protokolle mischen. Ein Index auf einer Domain darf ohne verifizierte hostsübergreifende Einreichung keine Sitemaps einer anderen listen.
• Die Datei jede Nacht neu erzeugen und in alle lastmod das Tagesdatum schreiben. Das Signal verliert seinen Wert, und die Suchmaschine zieht es nicht mehr heran.
• Nach einer Migration tote URLs darin stehen lassen. Der Index validiert weiterhin, und der Bericht füllt sich mit Fehlern, die die echten Probleme zudecken.