Sitemap-Index

TL;DR — Ein Sitemap-Index ist eine Sitemap der Sitemaps. Eine einzelne Sitemap kann nur 50 000 URLs enthalten, daher teilen große Websites ihre URLs auf mehrere Sitemaps auf und listen diese Sitemaps dann in einer kleinen “Index”-Datei auf. Sie übermitteln nur den Index, und Suchmaschinen folgen ihm zu allen anderen.

Was ein Sitemap-Index ist

Eine normale XML-Sitemap ist eine Liste Ihrer Seiten-URLs. Ein Sitemap-Index ist eine Ebene höher: Es ist eine Datei, die Ihre anderen Sitemaps auflistet, anstatt Seiten aufzulisten. Stellen Sie sich das wie ein Inhaltsverzeichnis vor, das auf mehrere Kapitel verweist, wobei jedes Kapitel eine Sitemap voller URLs ist.

Sie übergeben Suchmaschinen den Index, und sie lesen ihn, um jede darin referenzierte Sitemap zu finden, und lesen dann jede dieser Sitemaps, um Ihre URLs zu finden. Evidence for this claim A sitemap index contains sitemap entries with a required loc value and an optional lastmod value. Scope: Sitemaps.org protocol structure for sitemap index files. Confidence: high · Verified: 2026-07-14 Sitemaps.org: Sitemap index XML tag definitions

Warum Sie einen benötigen

Eine einzelne Sitemap hat harte Grenzen: Sie kann höchstens 50 000 URLs enthalten, und die Datei darf unkomprimiert nicht größer als 50 MB sein. Sobald Sie mehr URLs haben — oder die Datei zu groß wird — müssen Sie sie in mehrere Sitemaps aufteilen. Der Sitemap-Index verbindet diese Teile wieder, sodass Sie nur eine Sache übermitteln.

Sie müssen auch nicht warten, bis Sie das Limit erreichen. Viele große Websites nutzen einen Index nur, um Ordnung zu halten — eine Sitemap für den Blog, eine für Produkte, eine pro Sprache — selbst wenn jeder Teil weit unter 50 000 URLs liegt.

Wie viel kann er abdecken?

Eine Menge. Ein Index kann bis zu 50 000 untergeordnete Sitemaps auflisten, und jede davon kann bis zu 50 000 URLs enthalten. Multiplizieren Sie das, und ein einzelner Index deckt bereits 2,5 Milliarden URLs ab. Egal wie groß Ihre Website ist, Ihnen wird nie die Sitemap-Kapazität ausgehen.

Wie Sie ihn verwenden

• Teilen Sie Ihre URLs auf mehrere Sitemap-Dateien auf (die meisten SEO-Plugins und Frameworks tun das automatisch für Sie).
• Platzieren Sie eine Sitemap-Index-Datei an der Spitze, die jede dieser Sitemaps auflistet.
• Übermitteln Sie nur den Index in Google Search Console und Bing Webmaster Tools. Diese eine Übermittlung deckt alle untergeordneten Sitemaps ab.

Möchten Sie die Anatomie, die genauen Grenzen, die Regel “kein Index in einem Index” und den Aufteilungstrick, der Ihre Sitemaps in ein Indexierungs-Diagnosewerkzeug verwandelt? Wechseln Sie zum Erweitert-Tab.

TL;DR — Ein Sitemap-Index ist eine Sitemap von Sitemaps — eine <sitemapindex>-Datei, die <sitemap>-Einträge (<loc> + optional <lastmod>) anstelle von URLs auflistet. Sie benötigen einen, sobald eine einzelne Sitemap 50 000 URLs oder 50 MB unkomprimiert überschreiten würde, oder um eine große Website mit mehreren Abschnitten/Regionen zu organisieren. Ein Index kann bis zu 50 000 untergeordnete Sitemaps × 50 000 URLs jeweils = 2,5 Milliarden URLs pro Index referenzieren; mit bis zu 500 Index-Dateien pro Website in der Search Console liegt die theoretische Obergrenze bei 1,25 Billionen — eine Zahl, an die keine echte Website herankommt. Untergeordnete Sitemaps bleiben auf derselben Website auf derselben Verzeichnisebene oder tiefer, Sie verschachteln keinen Index in einem Index (kein Tag dafür, keine Tool-Unterstützung), und Sie übermitteln nur den Index. Der Lohn, den es zu verfolgen lohnt: nach Abschnitt/Inhaltstyp aufteilen, damit Sie übermittelte vs. indexierte pro Segment lesen können.

Was eine Sitemap-Index-Datei tatsächlich ist

Ein Sitemap-Index ist eine Sitemap, deren Einträge andere Sitemaps sind. Wo eine reguläre Sitemap <url>-Blöcke in einem <urlset> umschließt, umschließt ein Index <sitemap>-Blöcke in einem <sitemapindex>. Jedes <sitemap> hat ein <loc>, das auf eine Ihrer Sitemap-Dateien zeigt, und optional ein <lastmod>. Das ist die gesamte Struktur — sie enthält keine Seiten-URLs selbst. Evidence for this claim A sitemap index contains sitemap entries with a required loc value and an optional lastmod value. Scope: Sitemaps.org protocol structure for sitemap index files. Confidence: high · Verified: 2026-07-14 Sitemaps.org: Sitemap index XML tag definitions

Sie existiert aus einem Grund: Das Sitemap-Format hat harte Größenlimits, und große Websites überschreiten sie. Also teilen Sie Ihre URLs auf viele Sitemaps auf und verwenden einen Index, um sie Suchmaschinen als eine Einheit zu präsentieren.

Wann Sie eines benötigen

Zwei Auslöser:

1. Sie stoßen an die Größenlimits. Eine einzelne Sitemap erreicht ihr Maximum bei 50 000 URLs oder 50 MB unkomprimiert, je nachdem, was zuerst eintritt. Googles Anleitung ist direkt: “If you have a sitemap that exceeds the size limits, you’ll need to split up your large sitemap into multiple sitemaps.” Evidence for this claim A sitemap index can list up to 50,000 sitemap files, and each sitemap is limited to 50,000 URLs or 50 MB uncompressed. Scope: Google-supported sitemap and sitemap-index limits. Confidence: high · Verified: 2026-07-14 Google Search Central: Manage sitemaps with a sitemap index file (Übersetzung) „Wenn Sie eine Sitemap haben, die die Größenlimits überschreitet, müssen Sie Ihre große Sitemap in mehrere Sitemaps aufteilen.“ Sobald Sie aufgeteilt haben, verbindet ein Index die Teile.
2. Sie möchten eine große Website organisieren – auch unter dem Limit. Websites mit mehreren Bereichen (Blog vs. Produkte vs. Kategorieseiten) und mehrregionale/mehrsprachige Websites sind als separate Sitemaps unter einem Index weitaus einfacher zu verwalten und zu überwachen. Diese organisatorische Nutzung ist meiner Ansicht nach der bessere Grund, einen Index zu verwenden, und ich komme im Tab „Frameworks“ darauf zurück.

Anatomie

Der Index ist klein und bewusst unscheinbar – <sitemapindex>, dann ein <sitemap>-Block pro Kind, jeweils mit einem <loc> und einem optionalen <lastmod>:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemap1.xml.gz</loc>
    <lastmod>2024-08-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap2.xml.gz</loc>
    <lastmod>2024-08-15</lastmod>
  </sitemap>
</sitemapindex>

Wichtige Hinweise:

• Der Namespace ist derselbe sitemaps.org/schemas/sitemap/0.9, den Sie auch bei einer regulären Sitemap verwenden; die Datei ist UTF-8 und <loc>-Werte sind vollständig qualifizierte absolute URLs.
• Kinder können gzipped sein – .xml.gz ist in Ordnung, und das 50-MB-Limit wird auf die unkomprimierte Größe gemessen.
• Das optionale <lastmod> hier beschreibt, wann sich die Kind-Sitemap zuletzt geändert hat, nicht wann sich einzelne Seiten geändert haben.

Wie viele können Sie einreichen – und wie viele Seiten sind das?

Hier unterschätzen viele die Obergrenze. Stapeln Sie die Limits:

• Die Google Search Console akzeptiert bis zu 500 Sitemap-Indexdateien pro Website: “You can submit up to 500 sitemap index files for each site in your Search Console account.” (Übersetzung) „Sie können bis zu 500 Sitemap-Indexdateien für jede Website in Ihrem Search Console-Konto einreichen.“
• Jeder Index kann bis zu 50 000 Kind-Sitemaps auflisten.
• Jede Kind-Sitemap kann bis zu 50 000 URLs enthalten.

Multiplizieren Sie und die theoretische Obergrenze ist 500 × 50 000 × 50 000 = 1,25 Billionen URLs (1 250 000.000.000). Behandeln Sie das als eine Obergrenze, die keine echte Website erreicht, nicht als Ziel – die Erkenntnis ist einfach, dass Ihnen nie die Sitemap-Kapazität ausgehen wird. Und Sie müssen selten mit mehreren Indexdateien ausgefallen umgehen: Ein einzelner Sitemap-Index, ohne andere einzureichen, deckt bereits 50 000 × 50 000 = 2,5 Milliarden URLs ab. Wenn Sie 2,5 Milliarden indexierbare URLs haben, ist Ihre Sitemap-Einrichtung nicht Ihr Problem.

Standortregeln

Die Kind-Sitemaps, auf die ein Index verweist, müssen auf derselben Website wie der Index liegen, und auf der gleichen Verzeichnisebene oder tiefer als die Indexdatei. Ein Index unter https://www.example.com/sitemap-index.xml kann auf https://www.example.com/sitemaps/products.xml verweisen, aber nicht auf eine Sitemap auf einem anderen Host oder oberhalb seines eigenen Pfads. Wenn Sie dies brechen, markiert die Search Console die Kinder als „URL not allowed.“ (Cross-Domain-Verweise sind nur gültig, wenn beide Domains in der Search Console verifiziert sind – aber für einen gewöhnlichen Einzel-Website-Index gehen Sie nicht dorthin.)

Verschachteln Sie keinen Index in einem Index

Ein Sitemap-Index listet Sitemaps auf, keine anderen Indizes. Weder die Live-Protokollseite von sitemaps.org noch Googles Sitemap-Index-Dokumentation sagen dies heute in so vielen Worten – ich habe beide direkt überprüft, anstatt einer älteren Paraphrase zu vertrauen. Was das Protokoll tatsächlich sagt, ist enger: Das <loc>-Tag innerhalb eines <sitemapindex> ist definiert als Identifizierung von „a Sitemap, an Atom file, RSS file or a simple text file“ – eine Indexdatei steht nicht auf dieser Liste, und das Format hat kein Tag zum Verschachteln eines Index unter einem anderen. Jeder Sitemap-Generator, jedes Plugin und jede Suchmaschine, die ich kenne, behandelt Index-von-Indizes auf dieser Grundlage als nicht unterstützt; es ist eine starke Praktiker-Konvention, die in der Struktur des Formats verankert ist, nicht ein einzelner zitierbarer Satz aus einem der Dokumente. Behandeln Sie es als harte Regel: nur eine Indexierungsebene. Wenn Sie das Gefühl haben, einen Index-von-Indizes zu benötigen, haben Sie mit ziemlicher Sicherheit Raum, innerhalb der 2,5-Milliarden-URL-Obergrenze, die ein einzelner Index bereits bietet, neu zu organisieren.

Reichen Sie nur den Index ein

Sie reichen die Indexdatei ein, und diese eine Einreichung zieht alle untergeordneten Sitemaps ein, auf die sie verweist – Sie müssen die untergeordneten Sitemaps nicht einzeln einreichen. John Mueller hat es klar gesagt: “You can submit the individual ones, but you don’t really need to.” (Übersetzung) „Sie können die einzelnen einreichen, aber Sie müssen es nicht wirklich.“ Sowohl den Index als auch seine untergeordneten Sitemaps einzureichen, ist nicht schädlich, nur redundant. Eine saubere Einreichung des Index ist der richtige Weg.

Allerdings ist das Einreichen einer Sitemap – ob Index oder nicht – eine Entdeckungshilfe, keine Garantie für die Indexierung. Der Index hilft Suchmaschinen, Ihre Sitemaps zu finden; er verspricht nicht, dass die darin enthaltenen URLs gecrawlt oder indexiert werden.

Aufteilungsstrategie – für die Berichterstattung, nicht für die Crawl-Effizienz

Hier ist der Teil, der überall sonst unterbelichtet bleibt. Wie Sie Ihre Sitemaps über einen Index aufteilen, ändert nicht, wie Google Ihre Seiten crawlt oder indexiert. Der Grund für eine durchdachte Aufteilung ist die Überwachung. Muellers Formulierung ist die, auf die ich mich stütze: “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually (eg, category pages vs detail pages…). … It doesn’t change how Google crawls & indexes them, it’s really just so that you can track them better on your side.” (Übersetzung) „Ich empfehle im Allgemeinen, eine Sitemap-Datei in logische Teile Ihrer Website aufzuteilen, damit Sie diese Teile einzeln überwachen können (z. B. Kategorieseiten vs. Detailseiten…). … Es ändert nicht, wie Google sie crawlt und indexiert, es dient wirklich nur dazu, dass Sie sie auf Ihrer Seite besser verfolgen können.“

Der praktische Nutzen: Der Sitemaps-Bericht in der Search Console zeigt die Anzahl der eingereichten vs. indexierten URLs pro Sitemap. Teilen Sie Ihren Index nach Abschnitt oder Inhaltstyp auf – Blog, Produkte, Kategorien, Dokumentation, pro Region – und Sie können sehen, welches Segment unterindexiert ist, statt auf eine einzige websiteweite Zahl zu starren. Das ist eine Diagnose, die ich ständig nutze. (Aus demselben Grund behalte ich während einer Migration eine Sitemap mit alten URLs: damit ich in der GSC beobachten kann, wie genau diese Gruppe aus dem Index fällt.)

Teilen Sie also nach dem auf, was Sie messen möchten, nicht nach einem vermeintlichen Crawl-Vorteil. Der Crawl-Vorteil existiert nicht; der Berichtsvorteil ist real.

Wie es zum Rest der Sitemap-Familie passt

Ein Sitemap-Index sitzt über Ihren regulären XML-Sitemaps, und die breitere Sitemaps-Übersicht ist der richtige Einstieg, wenn Sie neu im gesamten Thema sind. Ihre Bild- und Video-Sitemaps sind nur weitere untergeordnete Dateien, auf die ein Index verweisen kann, und die gesamte Apparatur ist Teil davon, wie Suchmaschinen Discovery handhaben. Keine davon muss von hier aus verlinkt werden – sie sind Geschwister im selben Cluster.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Ein Sitemap-Index ist eine Sitemap von Sitemaps – eine <sitemapindex>-Datei, die <sitemap>-Einträge auflistet (<loc> + optional <lastmod>), nicht Seiten-URLs.
• Sie benötigen einen, wenn eine einzelne Sitemap 50 000 URLs oder 50 MB unkomprimiert überschreiten würde, oder wenn Sie eine große Website mit mehreren Abschnitten/Regionen organisieren möchten (der organisatorische Nutzen ist der bessere Grund).
• Die Kapazität ist praktisch unbegrenzt: bis zu 50 000 untergeordnete Sitemaps pro Index × 50 000 URLs jeweils = 2,5 Milliarden URLs pro Index. Mit bis zu 500 Indexdateien pro Website in der Search Console liegt die theoretische Obergrenze bei 1,25 Billionen URLs – eine Zahl, an die keine reale Website herankommt.
• Regeln: Untergeordnete Sitemaps befinden sich auf derselben Website, auf derselben Verzeichnisebene oder darunter; verschachteln Sie keinen Index in einem Index (das Format hat kein Tag dafür, und kein Generator oder keine Suchmaschine unterstützt es); untergeordnete Sitemaps dürfen gzip-komprimiert sein (.xml.gz).
• Reichen Sie nur den Index ein – eine Einreichung deckt alle untergeordneten Sitemaps ab. Auch die untergeordneten Sitemaps einzureichen, ist redundant, nicht schädlich (Mueller: “you don’t really need to”).
• Die Aufteilung dient der Berichterstattung, nicht der Crawl-Effizienz. Sie ändert das Crawling oder die Indexierung nicht; teilen Sie nach Abschnitt/Inhaltstyp auf, damit Sie die eingereichten vs. indexierten pro Segment im Sitemaps-Bericht der Search Console ablesen können.

Offizielle Dokumentation

Primärquellen-Dokumentation zu Sitemap-Indexdateien und den dahinterstehenden Grenzwerten.

Google

• Verwalten großer Sitemaps mit einer Sitemap-Indexdatei — Aufteilung bei Überschreitung der Limits, das Sitemap-Indexformat und das Limit von 500 Indexdateien pro Website.
• Erstellen und Einreichen einer Sitemap — das Limit von 50 000 URLs / 50 MB unkomprimiert, UTF-8 und die Regeln für absolute URLs, die für jede Sitemap gelten.
• Sitemaps-Übersicht — was eine Sitemap ist und die Einordnung als „Entdeckung, keine Garantie für die Indexierung“.

sitemaps.org

• Sitemaps-XML-Protokoll — die maßgebliche Spezifikation: das <sitemapindex>-Format, das Limit von 50 000 Sitemaps / 50 MB für den Index und die Regel, dass „eine Indexdatei keine anderen Indexdateien auflisten kann“.

Zitate aus der Quelle

Öffentliche Aussagen von Google und das sitemaps.org-Protokoll. Jeder Link ist ein Deep Link, der direkt zum zitierten Abschnitt auf der Quellseite springt.

Google — Aufteilungs- und Einreichungslimits

• “If you have a sitemap that exceeds the size limits, you’ll need to split up your large sitemap into multiple sitemaps.” (Übersetzung) „Wenn Sie eine Sitemap haben, die die Größenlimits überschreitet, müssen Sie Ihre große Sitemap in mehrere Sitemaps aufteilen.“ — Google, Verwalten großer Sitemaps. Zum Zitat springen
• “You can submit up to 500 sitemap index files for each site in your Search Console account.” (Übersetzung) „Sie können für jede Website in Ihrem Search Console-Konto bis zu 500 Sitemap-Indexdateien einreichen.“ Zum Zitat springen

sitemaps.org — die Größenlimits des Protokolls (siehe die Fußnote unten zur Quellenangabe der No-Nesting-Regel, die kein eigenständiges Zitat ist)

• “Sitemap index files may not list more than 50,000 Sitemaps and must be no larger than 50MB (52,428,800 bytes) and can be compressed.” (Übersetzung) „Sitemap-Indexdateien dürfen nicht mehr als 50 000 Sitemaps auflisten und müssen nicht größer als 50 MB (52.428.800 Bytes) sein und können komprimiert werden.“ — sitemaps.org-Protokoll. Zum Zitat springen

John Mueller, Google — Aufteilung zur Überwachung und nur den Index einreichen

• “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually (eg, category pages vs detail pages…). … It doesn’t change how Google crawls & indexes them, it’s really just so that you can track them better on your side.” (Übersetzung) „Ich empfehle im Allgemeinen, eine Sitemap-Datei in logische Teile Ihrer Website aufzuteilen, damit Sie diese Teile einzeln überwachen können (z. B. Kategorieseiten vs. Detailseiten…). … Es ändert nicht, wie Google sie crawlt und indexiert, es dient wirklich nur dazu, dass Sie sie auf Ihrer Seite besser verfolgen können.“ Zum Zitat springen
• “You can submit the individual ones, but you don’t really need to.” (Übersetzung) „Sie können die einzelnen einreichen, aber Sie müssen es nicht wirklich.“ Zum Zitat springen

Sitemap-Index — Limits-Spickzettel

Die Zahlen, die Ihre Kapazität definieren

Schnelle Fakten

• Ein Sitemap-Index listet Sitemaps auf, nicht URLs – <sitemapindex> umschließt <sitemap>-Blöcke (<loc> + optional <lastmod>).
• Sie benötigen einen, sobald eine einzelne Sitemap 50 000 URLs oder 50 MB überschreiten würde, oder um eine große Website mit mehreren Abschnitten/Regionen zu organisieren.
• Children müssen sich auf derselben Website befinden, auf derselben Verzeichnisebene oder tiefer als der Index.
• Children können gzipped sein (.xml.gz).
• Verschachteln Sie keinen Index in einem Index (kein Tag dafür, von keinem Generator oder Engine unterstützt).
• Reichen Sie nur den Index ein – er deckt alle Children ab; auch Children einzureichen ist redundant.
• Teilen Sie nach Abschnitt/Inhaltstyp für die Berichterstattung, nicht für die Crawl-Effizienz – es ändert nichts am Crawling/Indexing.

So teilen Sie einen Sitemap-Index (teilen Sie nach dem, was Sie messen)

Das mentale Modell, das hier zählt: Wie Sie teilen, ändert nichts am Crawling – es ändert, was Sie überwachen können. Google crawlt und indexiert dieselben URLs, egal ob sie in einer Sitemap oder in fünfzig stehen. Wählen Sie also Ihre Teilungslinien so, dass sie den Segmenten entsprechen, die Sie unabhängig lesen möchten im Sitemaps-Bericht der Search Console (eingereicht vs. indexiert, pro Sitemap).

Nach Inhaltstyp teilen

• /sitemaps/blog.xml, /sitemaps/products.xml, /sitemaps/categories.xml, /sitemaps/docs.xml.
• Am besten, wenn verschiedene Vorlagen unterschiedliches Indexierungsverhalten haben – z. B. dünne Produktvarianten, die unterindexiert werden, während Ihr Blog durchläuft. Sie sehen genau, welche Vorlage das Problem ist.

Nach Abschnitt teilen

• Eine Child-Sitemap pro Hauptabschnitt oder Unterordner der Website.
• Am besten für große Websites, bei denen Teams verschiedene Abschnitte besitzen – jeder Eigentümer erhält eine saubere Abdeckungszahl für seinen Bereich.

Nach Region / Sprache teilen

• Ein Child pro Locale (/sitemaps/en.xml, /sitemaps/de.xml, …).
• Am besten für internationale Websites: Sie können eine ganze Locale erkennen, die nicht aufgegriffen wird, getrennt von etwaigen hreflang-Problemen.

Die Entscheidungsregel

• Fragen Sie: “Wenn eines dieser Segmente unterindexiert wäre, würde ich es isoliert sehen wollen?” Wenn ja, das ist eine Teilungslinie. Wenn die Antwort lautet “Ich würde das nie separat analysieren”, teilen Sie dort nicht – Sie erstellen nur mehr Dateien, die gepflegt werden müssen.

Ein Migrationsfall, auf den ich mich verlasse

• Während einer Website-Migration behalte ich eine Sitemap der alten URLs im Index für eine Weile – nicht um sie indexieren zu lassen, sondern um zu beobachten, wie sie aus dem Index in GSC herausfallen, während die neuen URLs übernehmen. Die Segment-Berichterstattung ist der ganze Punkt.

Der Crawl-Effizienz-Aspekt, den Menschen vom Teilen erwarten, ist nicht real. Der Berichterstattungs-Aspekt ist es, und es lohnt sich, Ihren Index darum herum zu gestalten.

Ein minimaler gültiger Sitemap-Index

Dies ist die gesamte Form einer Sitemap-Indexdatei – ein <sitemapindex>-Root, dann ein <sitemap>-Block pro Child-Sitemap, jeweils mit einem <loc> und einem optionalen <lastmod>. Children können gzipped sein (.xml.gz); das 50-MB-Limit wird unkomprimiert gemessen.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemaps/blog.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemaps/products.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemaps/categories.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
</sitemapindex>

In diesem Beispiel enthaltene Regeln:

• Root ist <sitemapindex> (nicht <urlset>) im Namespace sitemaps.org/schemas/sitemap/0.9; die Datei ist UTF-8.
• Jedes <loc> ist eine vollständig qualifizierte absolute URL auf derselben Website, auf derselben Verzeichnisebene oder tiefer als dieser Index.
• <lastmod> ist optional und beschreibt, wann sich diese Child-Sitemap geändert hat.
• Fügen Sie keinen <sitemap>-Eintrag hinzu, der auf einen anderen Sitemap-Index zeigt – nur eine Ebene.

So reichen Sie ihn ein

Sie reichen nur diese Indexdatei ein – eine Einreichung, und Suchmaschinen folgen ihr zu jeder Child-Sitemap. Es besteht keine Notwendigkeit, die Children separat einzureichen.

# robots.txt — point engines at the index (the Sitemap: line takes the index URL)
Sitemap: https://www.example.com/sitemap-index.xml

Fügen Sie dann dieselbe Index-URL in der Google Search Console (Sitemaps-Bericht) und in den Bing Webmaster Tools hinzu. Das war’s – die Unterseiten werden automatisch mit übernommen.

Tools zum Erstellen und Prüfen eines Sitemap-Index

• Google Index Checker – Nachdem Sie den Index eingereicht haben, können Sie damit stichprobenartig prüfen, ob bestimmte URLs aus einer Untersitemap tatsächlich in den Google-Index aufgenommen wurden, anstatt auf die aggregierte Zahl in der Search Console zu warten.
• Google Search Console – Sitemaps-Bericht – Der primäre Ort, um einen eingereichten Index zu überwachen: Abrufstatus pro Untersitemap sowie eingereichte vs. indexierte Zahlen, die Sie pro Segment ablesen können, wenn Sie sinnvoll aufteilen.
• Bing Webmaster Tools – Sitemaps – Der entsprechende Bericht für Bing; reichen Sie dort ebenfalls dieselbe Index-URL ein.
• Ihr Sitemap-Generator / CMS-Plugin – Die meisten Frameworks und SEO-Plugins erstellen den Index und die Untersitemap-Dateien automatisch, wenn Ihre URL-Anzahl wächst; das manuelle XML im Skripte-Tab ist für den Fall gedacht, dass Sie die Struktur selbst sehen (oder von Hand erstellen) möchten.

Checkliste vor dem Einreichen eines Sitemap-Index

Gehen Sie diese Punkte durch, bevor Sie die Search Console oder Bing Webmaster Tools auf einen neuen oder umstrukturierten Index ausrichten:

• Jede Untersitemap liegt unter 50 000 URLs und 50 MB unkomprimiert (mit Puffer – bauen Sie nicht bis an die Obergrenze).
• Die Indexdatei listet nur Sitemaps auf, niemals einen weiteren Sitemap-Index.
• Jede <loc> der Untersitemaps befindet sich auf derselben Site, auf derselben Verzeichnisebene oder tiefer als die Indexdatei.
• Index und Untersitemaps sind gültiges XML, UTF-8, mit dem korrekten Wurzelelement (<sitemapindex> für den Index, <urlset> für jede Untersitemap).
• robots.txt enthält eine Sitemap:-Zeile, die auf den Index zeigt, nicht auf eine der Untersitemaps.
• Ihre Aufteilungslinien (Abschnitt, Inhaltstyp oder Region) entsprechen etwas, das Sie tatsächlich separat in der Search Console überwachen möchten – teilen Sie nicht willkürlich auf.
• Nur der Index ist zur Einreichung vorgesehen – Sie müssen nicht auch jede Untersitemap einzeln einreichen.

Häufige Fehler bei einem Sitemap-Index

• Verschachteln eines Index in einem Index. Das Format hat kein Tag dafür – die <loc> eines Sitemap-Index identifiziert nur eine Sitemap, eine Atom-, RSS- oder Textdatei, niemals einen weiteren Index – und kein Generator oder keine Suchmaschine unterstützt dies. Stattdessen: Behalten Sie eine Indexebene bei, und wenn Sie versucht sind, tiefer zu gehen, haben Sie mit ziemlicher Sicherheit Raum, Ihre Aufteilung innerhalb der 2,5-Milliarden-URL-Grenze, die ein einzelner Index bereits bietet, neu zu organisieren.
• Einreichen jeder Untersitemap einzeln zusätzlich zum Index. Nicht schädlich, nur redundant – die Indexeinreichung zieht bereits jede referenzierte Untersitemap mit ein. Stattdessen: Reichen Sie nur den Index in der Search Console und in Bing Webmaster Tools ein.
• Sitemaps aufteilen in der Erwartung eines Crawl-Budget- oder Ranking-Vorteils. Wie Sie aufteilen, ändert nicht, wie Google Ihre Seiten crawlt oder indexiert. Stattdessen: Teilen Sie ausschließlich für die Berichterstattung – wählen Sie Linien, die Sie tatsächlich unabhängig im Sitemaps-Bericht überwachen möchten.
• Eine Untersitemap auf einen anderen Host, eine andere Subdomain oder ein Verzeichnis oberhalb des Index verweisen. Die Search Console kennzeichnet dies als „URL nicht erlaubt.“ Stattdessen: Behalten Sie jede Untersitemap auf derselben Site, auf der Verzeichnisebene des Index oder tiefer.
• Eine Sitemap über 50 000 URLs oder 50 MB unkomprimiert wachsen lassen, anstatt vorher aufzuteilen. Stattdessen: Teilen Sie proaktiv auf, sobald ein Abschnitt sich der Grenze nähert, nicht erst, wenn sie bereits überschritten ist.

Häufige Probleme mit einem Sitemap-Index

Symptom: Die Search Console zeigt „Couldn’t fetch“ beim Index an. Wahrscheinliche Ursache: Die Index-URL liefert 404, läuft in einen Timeout oder wird durch robots.txt blockiert. Behebung: Öffnen Sie die exakte Index-URL in einem Browser (oder im Sitemap Validator) und bestätigen Sie, dass sie 200 mit gültigem XML zurückgibt, bevor Sie erneut einreichen.

Symptom: Der Index wird problemlos abgerufen, aber eine bestimmte untergeordnete Sitemap zeigt einen Fehler. Wahrscheinliche Ursache: Ein <loc>-Eintrag in dieser untergeordneten Sitemap verweist auf eine 404-URL, eine nicht-kanonische URL oder eine URL mit falscher Domain, oder die untergeordnete Sitemap selbst enthält fehlerhaftes XML. Behebung: Öffnen Sie die untergeordnete Sitemap direkt und überprüfen Sie ihre <loc>-Einträge; korrigieren oder regenerieren Sie die Datei und warten Sie dann auf den nächsten Abruf.

Symptom: „Sitemap-Indexdatei kann nicht auf einen anderen Sitemap-Index verweisen“ (oder der Eintrag wird stillschweigend ignoriert). Wahrscheinliche Ursache: Sie haben einen Index in einen anderen Index verschachtelt, was von keinem Generator oder Suchmaschine unterstützt wird – das <loc>-Tag des Formats bietet keine Möglichkeit, auf eine andere Indexdatei zu verweisen. Behebung: Reduzieren Sie auf eine Ebene – der oberste Index sollte nur auf Sitemaps verweisen, die URLs auflisten, nicht auf andere Indizes.

Symptom: „URL nicht erlaubt“ bei einem Eintrag in einer untergeordneten Sitemap. Wahrscheinliche Ursache: Diese untergeordnete Sitemap befindet sich auf einem anderen Host/Subdomain als der Index oder liegt über dem Verzeichnispfad des Index selbst. Behebung: Verschieben Sie die untergeordnete Sitemap auf dieselbe Website, auf derselben Verzeichnisebene oder darunter (domänenübergreifende Verweise funktionieren nur, wenn beide Domains in der Search Console verifiziert sind – und für einen normalen Einzel-Site-Index sollten Sie das nicht benötigen).

Symptom: Ein Index oder eine untergeordnete Sitemap wird wegen Größe abgelehnt. Wahrscheinliche Ursache: Sie überschreitet 50 000 URLs oder 50 MB unkomprimiert für eine Sitemap / 50 MB für die Indexdatei selbst. Behebung: Teilen Sie weiter auf – fügen Sie eine weitere untergeordnete Sitemap hinzu (oder bei einer sehr großen Website einen weiteren Index), anstatt zu versuchen, mehr hineinzupacken.

Nachweisen, dass der neue Sitemap-Index tatsächlich übernommen wurde

Test: Laden Sie die Index-URL direkt (Browser oder curl -I). Erwartetes Ergebnis: HTTP 200, gültiges XML, <sitemapindex>-Wurzelelement. Fehlerinterpretation: Ein 404/Timeout hier bedeutet, dass die Search Console sie ebenfalls nicht erreichen kann – beheben Sie dies zuerst. Überwachungszeitraum: sofort. Rollback-Auslöser: anhaltende Nicht-200-Antwort – stellen Sie das vorherige Sitemap-Setup wieder her.

Test: Reichen Sie den Index im Sitemaps-Bericht der Search Console ein (oder führen Sie ihn zuerst durch den Sitemap-Validator). Erwartetes Ergebnis: Der Status wechselt zu einem erfolgreichen Abruf und Zeilen für jede untergeordnete Sitemap erscheinen. Fehlerinterpretation: „Konnte nicht abgerufen werden“ bedeutet ein URL-, Hosting- oder robots.txt-Problem, noch kein Indexierungsproblem. Überwachungszeitraum: Stunden bis zu einem Tag für den ersten Abruf. Rollback-Auslöser: wiederholte Abruffehler bei erneuten Einreichungen.

Test: Überprüfen Sie die URL-Anzahl jeder untergeordneten Sitemap stichprobenartig gegen das, was Ihre Website tatsächlich für dieses Segment hat. Erwartetes Ergebnis: Die Zahlen liegen in der richtigen Größenordnung für diesen Abschnitt/Inhaltstyp. Fehlerinterpretation: Eine große Abweichung bedeutet normalerweise, dass der Generator veraltete, nicht-kanonische oder doppelte URLs einbezieht. Überwachungszeitraum: sofort, direkt nach der Generierung. Rollback-Auslöser: keiner – korrigieren Sie die Generatorlogik und generieren Sie neu.

Test: Überprüfen Sie die eingereichten vs. indexierten Zahlen pro Sitemap im Sitemaps-Bericht. Erwartetes Ergebnis: Die indexierte Zahl nähert sich im Laufe der Zeit der eingereichten Zahl für jedes Segment an. Fehlerinterpretation: Ein Segment, das deutlich unter seiner eingereichten Zahl bleibt, weist auf ein Problem hin, das spezifisch für dieses Segment ist (dünner Inhalt, Duplikate, versehentlich aktiviertes noindex) und nicht auf den Index selbst. Überwachungszeitraum: 2–4 Wochen, damit der Trend aussagekräftig ist. Rollback-Auslöser: Die indexierte Zahl eines Segments fällt nach der Änderung aktiv, nicht nur stagniert.

Test: Bestätigen Sie, dass robots.txt weiterhin die korrekte Sitemap:-Zeile enthält. Erwartetes Ergebnis: Die Zeile verweist auf die aktuelle Index-URL. Fehlerinterpretation: Eine fehlende oder veraltete Zeile unterbricht die Erkennung für Suchmaschinen, die Ihren Index bereits kennen, entfernt jedoch eines Ihrer Erkennungssignale für alles, was neu gecrawlt wird. Überwachungszeitraum: sofort. Rollback-Auslöser: Zeile fehlt oder verweist auf eine eingestellte Datei – stellen Sie sie wieder her.

Laufende KPIs für einen Sitemap-Index

Metrik: Eingereichte vs. indexierte Anzahl, pro Sitemap-Segment. Was sie Ihnen sagt: welcher Bereich, Inhaltstyp oder welche Region unterindexiert ist, statt einer einzigen gemischten Website-weiten Zahl. So ziehen Sie sie: der Sitemaps-Bericht in der Search Console, gelesen pro eingereichter Sitemap. Benchmark / realistischer Bereich: kein festes Ziel — es gibt hier keine ehrliche universelle Zahl. Gesund sieht so aus, dass die indexierte Anzahl nahe an der eingereichten Anzahl für dieses Segment liegt; eine anhaltende, große Lücke bei einem Segment (und nicht bei den anderen) ist das Signal, dem man nachgehen sollte, nicht ein bestimmter Prozentsatz. Häufigkeit: wöchentlich während einer Migration oder eines großen Rollouts; sonst monatlich.

Metrik: Sitemap-Abrufstatus, pro Index und pro Kind. Was sie Ihnen sagt: ob Suchmaschinen die von Ihnen eingereichten Dateien überhaupt lesen können — eine Voraussetzung für alles andere auf dieser Liste. So ziehen Sie sie: die Statusspalte im Sitemaps-Bericht (oder der Sitemap- Validator für eine Prüfung auf Abruf). Benchmark / realistischer Bereich: dies ist kein Bereich — „Erfolg” ist der einzige akzeptable Zustand; „Konnte nicht abgerufen werden” oder „Hat Fehler” ist ein Fehlerzustand, den Sie sofort beheben müssen, nicht etwas, das Sie mit einer bestimmten Rate tolerieren. Häufigkeit: prüfen Sie, wann immer Sie den Sitemap-Generierungscode ändern oder ein neues Kind hinzufügen; sonst eine monatliche Stichprobenprüfung.

Metrik: URL-Anzahl und Dateigröße pro Sitemap, im Vergleich zu den Grenzwerten. Was sie Ihnen sagt: wie viel Spielraum Sie haben, bevor ein Segment weiter aufgeteilt werden muss. So ziehen Sie sie: die eigenen Zähler Ihres Sitemap-Generators oder der Sitemap- Validator. Benchmark / realistischer Bereich: bleiben Sie komfortabel unter 50 000 URLs und 50 MB unkomprimiert pro Datei — lassen Sie echten Spielraum, statt bis an die Obergrenze zu gehen. Häufigkeit: überwachen Sie, während Ihre URL-Anzahl wächst; teilen Sie ein Segment neu auf, sobald es sich der Grenze nähert, nicht erst, wenn es bereits kaputt ist.

KI-Prompts für einen Sitemap-Index

Prompt: Plausibilitätsprüfung einer geplanten Aufteilung. Fügen Sie eine kurze Beschreibung der Bereiche Ihrer Website ein (ungefähr, wie viele URLs jeder hat) und bitten Sie eine KI, Ihre Aufteilungslinien zu prüfen, bevor Sie den Index erstellen:

I'm building a sitemap index for a site with these sections and approximate
URL counts:
- Blog: <N> URLs
- Product pages: <N> URLs
- Category pages: <N> URLs
- <other sections>

I want to split these into child sitemaps under one sitemap index so I can
read submitted-vs-indexed coverage per section in Google Search Console.
Given these counts, suggest a sensible way to split them into child
sitemaps (staying well under 50,000 URLs and 50MB uncompressed per file),
and flag any section that's small enough it probably doesn't need its own
child sitemap.

Erwartete Antwort: ein vorgeschlagener Gruppierung Ihrer Bereiche in Kind-Sitemaps, mit einem Hinweis auf jeden Bereich, der zu klein ist, um ihn separat zu behandeln.

Prompt: Überprüfung eines bestehenden Sitemap-Index auf strukturelle Fehler. Fügen Sie das rohe XML Ihres Sitemap-Index (oder einen repräsentativen Auszug) ein und bitten Sie um eine strukturelle Überprüfung:

Here is my sitemap index XML:

<paste your <sitemapindex> XML here>

Check it against these rules and flag any violation:
1. The root element is <sitemapindex>, not <urlset>.
2. No <sitemap> entry points at another sitemap index file.
3. Every <loc> is a fully-qualified, absolute URL on the same site as this
   index.
4. No <loc> sits at a directory level above this index's own path.
List any entries that break these rules and explain which rule each one
breaks.

Erwartete Antwort: eine zeilenweise Liste aller Einträge, die gegen die Verschachtelungs- oder Standortregeln verstoßen, damit Sie sie vor dem erneuten Einreichen beheben können.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• When Should You Worry About Crawl Budget? — wo saubere, vollständige Sitemaps in die Crawl-Effizienz auf großen Websites passen.
• Website Migration: The Pre- and Post-Launch Checklist — einschließlich der Aufbewahrung einer Sitemap mit alten URLs, um zu beobachten, wie sie in der GSC aus dem Index fallen.
• Enterprise Technical SEO — automatisierungsorientierte Sitemaps und die eingereicht-vs-indexiert-Diagnose in großem Maßstab.
• The Beginner’s Guide to Technical SEO — wo Sitemaps und Discovery im größeren Bild stehen.

Offiziell

• Google — Manage large sitemaps with a sitemap index file.
• sitemaps.org protocol — die kanonische <sitemapindex>-Spezifikation und -Grenzwerte.

Von anderen

• r/TechSEO — die Community für Sitemap-, Crawl- und Indexierungs-Debugging.
• Bing Webmaster Tools — Sitemap einreichen — Bings Anleitung zum Einreichen von Sitemap-Indexdateien und deren Überprüfung in Bing Webmaster Tools.
• Search Engine Journal — Sitemap-Berichterstattung — enthält wörtliche Berichterstattung über Mueller-Sitemap-Fragen und -Antworten sowie Crawl- und Indexierungsartikel.
• Onely — Sitemap-Ressourcen — technische SEO-Tiefenbohrungen von einer auf Crawling fokussierten Agentur; behandelt groß angelegte Sitemap-Probleme und Indexierungsdiagnosen.

Testen Sie sich: Sitemap-Index

Fünf kurze Fragen dazu, was ein Sitemap-Index ist und wie man ihn verwendet. Wählen Sie für jede eine Antwort aus und überprüfen Sie dann.

Änderungsprotokoll