Der Unterschied zwischen Sitemap-Index und Sitemap liegt in der jeweiligen Aufgabe. Eine normale sitemap.xml ist eine flache Liste Ihrer tatsächlichen Seiten-URLs. Ein Sitemap-Index ist eine Liste von Sitemaps, nicht von Seiten. Sobald eine Website 50.000 URLs oder eine unkomprimierte Dateigröße von 50 MB überschreitet, ist eine einzelne sitemap.xml nicht mehr gültig, und Sie verteilen Ihre URLs auf mehrere Sitemap-Dateien, auf die eine Indexdatei verweist. Diese Anleitung behandelt genau, wann dieser Wechsel erzwungen wird, die genaue Syntax, wie Sie eine große Website logisch aufteilen und wie Sie den Index bei Google einreichen, damit es effizient crawlt.
Die meisten Seiten zu diesem Thema bleiben bei Googles einzeiliger Spezifikation ("50.000 URLs und 50 MB pro Datei") stehen und überlassen Ihnen den Rest. Die praktischen Fragen, die niemand beantwortet, sind: wie man aufteilt, wie die Indexdatei tatsächlich aussieht und wo hreflang- und Bild-Sitemaps hineinpassen. Diese Lücke füllt dieser Artikel.
Sitemap-Index vs. Sitemap: Der wesentliche Unterschied#
Eine Sitemap und ein Sitemap-Index sind zwei verschiedene Dateitypen mit unterschiedlichen Wurzelelementen. Diese Verwechslung ist der häufigste Fehler, und Suchmaschinen lehnen die Datei ab, wenn Sie die Elemente falsch verschachteln.
- Eine Sitemap verwendet das Wurzelelement
<urlset>und enthält<url>-Einträge. Jeder Eintrag steht für eine echte, indexierbare Seite Ihrer Website. - Ein Sitemap-Index verwendet das Wurzelelement
<sitemapindex>und enthält<sitemap>-Einträge. Jeder Eintrag verweist auf den Speicherort einer anderen Sitemap-Datei, nicht auf eine Seite.
Betrachten Sie den Index als Inhaltsverzeichnis. Er listet nicht direkt Ihre Artikel oder Produktseiten auf, sondern die kleineren Sitemap-Dateien, die wiederum die Seiten enthalten. Suchmaschinen rufen zuerst den Index ab und durchsuchen dann jede darin referenzierte Sitemap.
Wichtige Regel: Ein Sitemap-Index kann nur auf Sitemaps verweisen. Sie können keine Seiten-URLs und Child-Sitemap-URLs in derselben Datei mischen. Die Vermischung der beiden Wurzelelemente ist ungültig und führt in der Search Console zu einem Validierungsfehler.
Warum die zweistufige Struktur existiert#
Der Grund für diese Struktur ist die harte Obergrenze einer einzelnen Datei. Das sitemaps.org-Protokoll (dem Google, Bing und andere folgen) begrenzt jede Sitemap auf:
- Maximal 50.000 URLs pro Datei.
- Maximale Dateigröße von 50 MB (unkomprimiert).
Wird einer dieser Grenzwerte überschritten, entspricht die Datei nicht den Vorgaben. Große Websites überschreiten ständig die 50.000-URL-Marke, daher erlaubt das Protokoll die Veröffentlichung mehrerer Sitemap-Dateien, die über einen Index verbunden werden. Ein einzelner Sitemap-Index kann selbst bis zu 50.000 Sitemaps referenzieren, was eine theoretische Obergrenze von 50.000 x 50.000 = 2,5 Milliarden URLs ergibt. Ihnen werden die Seiten ausgehen, lange bevor die Sitemap-Kapazität erschöpft ist.
Wann Sie von einer einzelnen Sitemap zu einem Sitemap-Index wechseln sollten#
Der Wechsel ist keine Stilfrage. Er wird durch Grenzen erzwungen, und es gibt drei Auslöser. Der erste, der erreicht wird, entscheidet.
| Auslöser | Die Grenze | Was passiert, wenn Sie sie ignorieren |
|---|---|---|
| URL-Anzahl | Mehr als 50.000 URLs in einer Datei | Suchmaschinen hören am Limit auf zu lesen; zusätzliche URLs werden stillschweigend fallen gelassen |
| Dateigröße | Mehr als 50 MB unkomprimiert | Die Datei wird als ungültig abgelehnt; nichts darin wird zuverlässig gecrawlt |
| Logische Organisation | Keine harte Grenze, aber sinnvoll ab einigen tausend URLs | Crawl-Probleme sind schwerer zu debuggen und Abdeckungsberichte pro Bereich schwerer zu lesen |
Hier ist die praktische Einschätzung zu jedem Punkt.
Die URL-Anzahl ist der häufigste Grund. Mit mehr als 50.000 veröffentlichten, indexierbaren URLs müssen Sie aufteilen. Es gibt keinen Schalter oder ein Kontingent, das erhöht werden kann. Sie teilen entweder in mehrere Sitemaps unter einem Index auf, oder die URLs ab Nummer 50.000 werden nie eingereicht.
Die Dateigröße betrifft Seiten mit langen URLs. Sie können die 50-MB-Grenze vor 50.000 URLs erreichen, wenn Ihre URLs sehr lang sind oder Sie viele <image:image>- und <xhtml:link>-Einträge (hreflang) pro URL einfügen. Jedes zusätzliche Element erhöht die Bytes, und mehrsprachige Seiten mit hreflang-Anmerkungen blähen schnell auf.
Die logische Organisation ist der unterschätzte Grund. Selbst bei 8.000 URLs ist die Aufteilung in thematische Sitemaps sinnvoll. Wenn die Search Console meldet, dass eine Sitemap Indexierungsprobleme hat, zeigt Ihnen eine Aufteilung pro Bereich sofort, ob das Problem in Ihrem Blog, den Produkten oder den Kategorieseiten liegt. Eine einzige riesige Datei sagt Ihnen nichts.
Praktischer Tipp: Wenn Sie sich in der Nähe von 40.000 URLs befinden, bauen Sie die Indexstruktur jetzt auf, nicht erst nachdem Sie 50.000 überschritten haben. Eine Nachrüstung unter Druck, wenn Seiten aus dem Index fallen, ist weitaus stressiger als eine frühzeitige Einrichtung.
Die exakte Sitemap-Index-Syntax (mit Beispiel)#
Dies ist der Teil, den die knappen Spezifikationen auslassen. Ein Sitemap-Index ist eine kleine XML-Datei. Hier ist ein vollständiges, gültiges Beispiel, das auf drei untergeordnete Sitemaps verweist.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-posts.xml</loc>
<lastmod>2026-06-25T09:00:00+00:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-products.xml</loc>
<lastmod>2026-06-24T14:30:00+00:00</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-pages.xml</loc>
<lastmod>2026-06-20T08:15:00+00:00</lastmod>
</sitemap>
</sitemapindex>
Drei Details sind hier wichtig.
<loc>muss eine absolute URL sein. Verwenden Sie den vollständigen Pfadhttps://example.com/..., nicht einen relativen wie/sitemap-posts.xml. Relative URLs sind in Sitemaps ungültig.<lastmod>ist das einzige weitere erlaubte Kindelement. Jeder<sitemap>-Eintrag akzeptiert<loc>und optional<lastmod>. Es gibt kein<changefreq>oder<priority>auf Indexebene (Google ignoriert diese selbst in normalen Sitemaps).<lastmod>sollte ehrlich sein. Setzen Sie es auf den letzten Zeitpunkt, an dem sich eine URL in dieser untergeordneten Sitemap tatsächlich geändert hat. Ein<lastmod>, das immer "heute" anzeigt, trainiert Crawler, es zu ignorieren, während ein genaues Datum dem Crawler hilft, zu entscheiden, welche untergeordneten Sitemaps zuerst erneut abgerufen werden sollen.
Jede untergeordnete Sitemap ist einfach eine normale <urlset>-Datei:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://example.com/blog/first-post</loc>
<lastmod>2026-06-25T09:00:00+00:00</lastmod>
</url>
<url>
<loc>https://example.com/blog/second-post</loc>
<lastmod>2026-06-22T11:00:00+00:00</lastmod>
</url>
</urlset>
Sie können diese für eine kleine Aufteilung manuell bearbeiten, aber für alles Ernsthafte werden sie generiert. Ein kostenloser XML-Sitemap-Generator übernimmt die Aufteilung, die Indexdatei und die absolute URL-Formatierung, sodass Sie keinen Tippfehler einführen, der das Crawlen leise unterbricht.
So teilen Sie eine große Website logisch auf#
Sie können willkürlich aufteilen („URLs 1 bis 50.000 hier, 50.001 bis 100.000 dort“), aber das ist eine vertane Chance. Eine Aufteilung nach Abschnitt oder Inhaltstyp macht Ihre Sitemaps zu einem Diagnosewerkzeug, nicht nur zu einem Compliance-Kästchen.
Aufteilung nach Inhaltstyp oder Abschnitt#
Das sauberste Muster ist eine Sitemap pro logischer Gruppe, die alle von einem einzigen Index referenziert werden:
sitemap-posts.xmlfür Blog- oder Artikel-URLssitemap-products.xmlfür Produkt- oder Listenseitensitemap-categories.xmlfür Taxonomie- und Kategorieseitensitemap-pages.xmlfür statische Seiten (Über uns, Kontakt, Impressum)
Wenn die Search Console nun meldet „sitemap-products.xml: 4.200 eingereicht, 3.100 indexiert“, wissen Sie genau, wo Sie nachforschen müssen. Bei einer einzigen monolithischen Datei wüssten Sie nur, dass irgendwo etwas nicht indexiert ist.
Halten Sie jede untergeordnete Sitemap deutlich unter dem Limit#
Packen Sie jede untergeordnete Datei nicht bis auf 49.999 URLs voll. Streben Sie ein paar tausend bis etwa 10.000 bis 20.000 URLs pro Datei an. Kleinere Dateien werden schneller abgerufen und erneut abgerufen, wenn sich nur ein Abschnitt ändert, und Sie bleiben sicher unter der 50-MB-Größenobergrenze, wenn die URLs wachsen.
Entscheiden Sie zwischen separaten und kombinierten Sitemaps#
Sie haben die Wahl zwischen dedizierten spezialisierten Sitemaps und der Kombination aller Elemente pro URL.
| Ansatz | Wann verwenden | Abwägung |
|---|---|---|
| Bilder und Hreflang in die Haupt-URL-Sitemaps integrieren | Die meisten Websites | Einfachere Struktur; achten Sie auf das 50-MB-Limit |
| Separate Bild-Sitemap | Bildlastige Websites (Galerien, Stockfotos, E-Commerce) | Sauberere Berichterstattung zur Bildindexierung, aber mehr Dateien zu pflegen |
| Separate Hreflang/Sprachverwaltung | Große mehrsprachige Websites | Vermeidet Aufblähen einer Datei; erfordert gegenseitige Annotationen |
Für die meisten Websites sind weniger Dateien besser. Greifen Sie nur dann zu separaten spezialisierten Sitemaps, wenn ein Abschnitt so groß ist, dass die Kombination eine Datei an die Größenobergrenze bringen oder Ihre Berichterstattung trüben würde.
Wo Hreflang und Bild-Sitemaps in ein Index passen#
Dies ist der Teil, den fast kein anderer Artikel behandelt, und der bei großen internationalen und medienlastigen Websites für Verwirrung sorgt.
Hreflang innerhalb eines Sitemap-Index#
Hreflang-Anmerkungen befinden sich innerhalb der <url>-Einträge einer normalen Sitemap, unter Verwendung des xhtml:link-Elements. Sie verändern die Indexdatei selbst nicht. Der Index listet weiterhin nur die untergeordneten Sitemaps auf. Eine untergeordnete Sitemap mit Hreflang sieht so aus:
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>https://example.com/page</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/page"/>
<xhtml:link rel="alternate" hreflang="es" href="https://example.com/es/page"/>
<xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/page"/>
</url>
</urlset>
Zwei Dinge sind zu beachten. Erstens müssen Hreflang-Anmerkungen reziprok sein: Wenn die englische Seite auf die spanische Version verweist, muss die spanische Seite zurückverweisen. Zweitens fügt jedes xhtml:link Bytes hinzu, sodass Hreflang-lastige Sitemaps das 50-MB-Limit bei weit weniger als 50.000 URLs erreichen. Genau das ist der Fall, in dem das Aufteilen in mehrere untergeordnete Sitemaps unter einem Index notwendig wird, selbst bei einer moderaten URL-Anzahl.
Bild-Sitemaps innerhalb eines Index#
Bildeinträge befinden sich ebenfalls innerhalb des <url>-Blocks der Seite, unter Verwendung des image:image-Namespace, nicht im Index. Sie können Bilder entweder an die URLs in Ihren Haupt-Sitemaps anhängen oder eine dedizierte Bild-Sitemap erstellen und als weiteren <sitemap>-Eintrag im Index hinzufügen.
Für eine Website mit Tausenden von Bildern pro Abschnitt hält eine separate Bild-Sitemap Ihre Haupt-Sitemaps schlank und bietet eine saubere Zeile in der Search Console für die Bildindizierung. Für alles andere ist das Anhängen von Bildern an vorhandene URL-Einträge einfacher und funktioniert gut.
So reichen Sie einen Sitemap-Index bei Google ein#
Sobald Ihr Index erstellt ist, reichen Sie nur eines ein: die Indexdatei. Sie reichen nicht jede einzelne Untersitemap separat ein. Google entdeckt die Untersitemaps durch das Lesen des Index.
Schritt 1: Den Index in der robots.txt referenzieren#
Fügen Sie eine Sitemap:-Zeile in Ihre robots.txt ein, die auf die absolute URL der Indexdatei verweist. Dadurch kann jeder Crawler sie entdecken, nicht nur Google.
Sitemap: https://example.com/sitemap-index.xml
Sie können bei Bedarf mehrere Sitemap:-Zeilen auflisten, aber mit einem korrekten Index benötigen Sie nur eine. Wenn Sie auch steuern müssen, auf welche Pfade Crawler zugreifen können, erstellen Sie eine saubere Datei mit einem kostenlosen robots.txt-Generator, damit die Direktiven und der Sitemap-Verweis korrekt formatiert sind.
Schritt 2: Den Index in der Google Search Console einreichen#
Öffnen Sie in der Search Console den Sitemaps-Bericht für Ihre Property und geben Sie den Pfad zu Ihrer Indexdatei ein (z.B. sitemap-index.xml). Reichen Sie sie ein. Google liest den Index und stellt dann jede Untersitemap in die Warteschlange. Sie sehen den Index aufgelistet, und in den folgenden Tagen werden die Erkennungs- und Indexierungszahlen pro Sitemap angezeigt.
Schritt 3: Überprüfen, ob jede Untersitemap gelesen wurde#
Nachdem Google den Index verarbeitet hat, zeigt der Sitemaps-Bericht jede referenzierte Untersitemap an. Bestätigen Sie, dass die Anzahl der eingereichten URLs Ihren Erwartungen pro Abschnitt entspricht. Wenn eine Untersitemap null URLs oder einen Fehler anzeigt, hat diese Datei ein Problem (eine fehlerhafte <loc>, ein Syntaxfehler oder eine Größenüberschreitung), und Sie beheben diese eine Datei, nicht die gesamte Struktur.
Schritt 4: Überwachen und lastmod aktuell halten#
Eine erneute Einreichung ist selten erforderlich, sobald ein Index vorhanden ist. Google ruft den Index und die Untersitemaps in seinem eigenen Rhythmus erneut ab. Das Nützlichste, was Sie tun können, ist, <lastmod> sowohl in den Indexeinträgen als auch in den Untersitemaps genau zu halten, damit Crawler die Abschnitte priorisieren, die sich tatsächlich geändert haben. Während Sie die technischen SEO-Signale verbessern, lohnt es sich, Ihre Sitemap mit strukturierten Daten zu kombinieren: Unser Schema-Markup-Generator hilft Ihren wichtigsten Seiten, nach dem Crawlen Rich Results zu erzielen.
Häufige Sitemap-Index-Fehler, die Sie vermeiden sollten#
Einige wenige Fehler sind für die meisten defekten Sitemaps großer Websites verantwortlich.
- Verschachtelung eines Index in einem Index. Ein Sitemap-Index kann nicht auf einen anderen Sitemap-Index verweisen, sondern nur auf reguläre Sitemaps. Es gibt nur eine Indexierungsebene.
- Mischen von
<url>- und<sitemap>-Einträgen. Eine Datei ist entweder ein<urlset>oder ein<sitemapindex>, niemals beides. - Relative URLs in
<loc>. Immer absolut, immer mit dem korrekten Protokoll und Host. - Auflisten derselben URL in mehreren untergeordneten Sitemaps. Jede URL sollte im gesamten Satz nur einmal vorkommen. Duplikate verschwenden Crawl-Budget und verwirren die Berichterstattung.
- Einreichen untergeordneter Sitemaps einzeln nach Einreichen des Index. Überflüssig und verstopft Ihren Sitemaps-Bericht. Reichen Sie nur den Index ein.
Das Fazit zu Sitemap-Index vs. Sitemap#
Die Entscheidung zwischen Sitemap-Index und Sitemap hängt von Ihrer URL-Anzahl und Dateigröße ab, nicht von Vorlieben. Bei unter 50.000 URLs und 50 MB reicht eine einzelne sitemap.xml. Überschreiten Sie eine dieser Grenzen, müssen Sie Ihre Seiten auf mehrere untergeordnete Sitemaps aufteilen, die durch eine einzige <sitemapindex>-Datei verbunden sind, und dann nur diesen Index bei Google einreichen.
Richtig umgesetzt, ist die Aufteilung mehr als nur Compliance. Die Aufteilung nach Bereichen verwandelt Ihre Sitemaps in ein Dashboard für die Crawl-Gesundheit, hält hreflang- und bildlastige Dateien unter der Größenobergrenze und zeigt Ihnen genau, wo Indexierungsprobleme auftreten. Wenn Sie keine einzige Zeile XML von Hand schreiben möchten, erstellt ein kostenloser XML-Sitemap-Generator den Index und die untergeordneten Dateien, formatiert die absoluten URLs und erspart Ihnen die Tippfehler, die auf einer großen Website leise das Crawling stören.
Häufig gestellte Fragen#
Was ist der Unterschied zwischen einer Sitemap und einem Sitemap-Index?
Eine Sitemap (<urlset>) listet die tatsächlichen Seiten-URLs Ihrer Website auf. Ein Sitemap-Index (<sitemapindex>) listet andere Sitemap-Dateien, keine Seiten. Suchmaschinen lesen zuerst den Index und crawlen dann jede darin referenzierte untergeordnete Sitemap. Sie verwenden einen Index, sobald Sie mehr Sitemap-Dateien haben, als eine einzelne aufnehmen kann.
Wann benötige ich einen Sitemap-Index anstelle einer einzelnen sitemap.xml? Sie müssen wechseln, wenn eine einzelne Datei 50.000 URLs oder 50 MB unkomprimiert überschreitet, je nachdem, was zuerst eintritt. Mehrsprachige Websites mit Hreflang oder bildreiche Websites können das 50-MB-Limit bereits weit vor 50.000 URLs erreichen. Viele Teams teilen auch früher, bereits bei einigen tausend URLs, allein für eine sauberere, abschnittsbezogene Berichterstattung in der Search Console.
Kann ein Sitemap-Index auf einen anderen Sitemap-Index verweisen?
Nein. Ein Sitemap-Index kann nur auf reguläre Sitemaps (<urlset>-Dateien) verweisen, nicht auf andere Indexdateien. Sie haben genau eine Indexierungsebene. Wenn Sie viele Sitemaps organisieren müssen, gruppieren Sie sie logisch unter einem einzigen Index, anstatt zu versuchen, Indizes zu verschachteln.
Wie viele URLs kann ein Sitemap-Index insgesamt verarbeiten? Ein einzelner Sitemap-Index kann bis zu 50.000 untergeordnete Sitemaps referenzieren, und jede untergeordnete Sitemap kann bis zu 50.000 URLs enthalten. Das ergibt eine Obergrenze von etwa 2,5 Milliarden URLs aus einem Index, was weit mehr ist, als jede reale Website benötigt.
Muss ich jede untergeordnete Sitemap bei Google einreichen oder nur den Index? Reichen Sie nur die Indexdatei in der Google Search Console ein und referenzieren Sie sie einmal in der robots.txt. Google liest den Index und entdeckt automatisch jede untergeordnete Sitemap. Das separate Einreichen untergeordneter Sitemaps ist überflüssig und verstopft nur Ihren Sitemaps-Bericht.
Wo gehören Hreflang- und Bildeinträge in einem Sitemap-Index hin?
Sie gehören niemals in die Indexdatei selbst. Hreflang- (xhtml:link) und Bild- (image:image) Annotationen befinden sich innerhalb der <url>-Einträge der regulären untergeordneten Sitemaps. Der Index listet nur die Speicherorte der untergeordneten Sitemaps auf. Da diese Annotationen die Dateigröße erhöhen, erreichen Hreflang- oder bildreiche untergeordnete Sitemaps das 50-MB-Limit bei weniger URLs, was oft der Grund für die Aufteilung ist.
