Sitemap erstellen 2026: XML-Sitemap Schritt für Schritt, mit echten Crawler-Daten und einem Fehler in unserer eigenen

Eine Sitemap zu erstellen ist meistens keine Arbeit mehr. Fast jedes CMS und jedes Framework erzeugt die Datei automatisch, und viele Anleitungen hören an genau dieser Stelle auf: Plugin installieren, URL in der Search Console eintragen, fertig. Wir wollten für diesen Artikel wissen, was danach passiert. Also haben wir die Sitemap von getmind.io auseinandergenommen und 17 Tage Server-Logs (151.296 Zugriffe) danach ausgewertet, wer sie wirklich abruft.

Dabei kam ein Fehler heraus, den wir selbst gebaut hatten. Unsere Sitemap enthielt 234 Adressen und kein einziges Änderungsdatum. Die Datei war gültig, lieferte Statuscode 200 und wurde von Google, Bing und mehreren anderen Crawlern regelmäßig abgeholt. Sie sagte aber niemandem, welche der 234 Seiten neu war. Für Google ist das Feld lastmod die einzige Angabe in einer Sitemap, die neben der Adresse überhaupt noch zählt. Wir haben das heute Morgen behoben und zeigen dir weiter unten den Code dafür.

In dieser Anleitung lernst du, wie eine XML-Sitemap aufgebaut ist, wie du sie in WordPress, Shopware, Astro, Next.js oder ganz ohne CMS erstellst, wie du sie bei Google und Bing einreichst und was sie leistet und was nicht. Alle Zahlen stammen aus unseren eigenen Logs vom 3. bis 20. Oktober 2026 und aus Tests vom 20. Oktober 2026.

Das Video von Seokratie (Nora Taubert) stammt von 2023 und ist damit älter als unsere übliche Grenze von sechs Monaten. Wir haben es trotzdem gewählt, weil es die Grundlagen auf Deutsch sauber erklärt und sich am Format seitdem nichts geändert hat. Was fehlt, ist die Abschaltung des Sitemap-Pings und IndexNow. Dazu weiter unten mehr.

Was ist eine Sitemap?

Eine Sitemap ist eine Datei, die alle Seiten deiner Website auflistet, die in Suchmaschinen auftauchen sollen. Sie ist ein Inhaltsverzeichnis für Crawler, also für die Programme, mit denen Google, Bing und andere Dienste das Web abgrasen.

Wenn heute jemand von einer Sitemap spricht, meint er fast immer die XML-Sitemap nach dem Protokoll von sitemaps.org. Google, Bing, Yahoo und Ask haben es 2006 gemeinsam eingeführt, und seitdem hat es sich kaum verändert. Daneben gibt es zwei Dinge, die ähnlich heißen:

• HTML-Sitemap: eine normale Webseite für Menschen, die alle Bereiche einer Website verlinkt, meist im Footer. Sie hilft beim Navigieren, für Suchmaschinen ist sie nur eine weitere Seite mit vielen Links.
• Andere Sitemap-Formate: Google akzeptiert auch einen RSS- oder Atom-Feed und eine einfache Textdatei mit einer URL pro Zeile. Beides ist erlaubt, aber weniger flexibel als XML.

Die XML-Sitemap ersetzt keine gute interne Verlinkung. Google findet Seiten weiterhin hauptsächlich über Links. Die Sitemap ist der zweite Weg, und genau bei den Seiten wichtig, die über Links schlecht erreichbar sind.

Braucht meine Website überhaupt eine Sitemap?

Die ehrliche Antwort: nicht jede. Google schreibt in seiner eigenen Dokumentation, dass kleine Websites mit bis zu etwa 500 Seiten, die gut intern verlinkt sind, eine Sitemap nicht unbedingt brauchen. Wer zehn Seiten hat und alle im Menü verlinkt, bekommt durch die Sitemap keinen messbaren Vorteil.

Sinnvoll oder sogar wichtig ist eine Sitemap, wenn

• deine Website groß ist, also Hunderte oder Tausende Seiten hat, zum Beispiel ein Shop mit vielen Produkten,
• deine Seiten schlecht verlinkt sind, etwa Archivseiten, die nur über Paginierung oder interne Suche erreichbar sind,
• deine Website neu ist und kaum Links von außen hat,
• du regelmäßig neue Inhalte veröffentlichst, wie bei einem Blog oder Newsportal,
• du Bilder, Videos oder News hast, die du gezielt bei Google einreichen willst,
• du mehrere Sprachversionen hast und die Zuordnung zusätzlich absichern willst.

Für getmind.io treffen gleich mehrere Punkte zu: täglich ein neuer Artikel, zwei Sprachen, 234 Adressen. Schaden kann eine korrekte Sitemap nie. Darum ist unsere Empfehlung: Wenn dein System sie ohnehin erzeugt, lass sie an und sorg dafür, dass sie stimmt.

Wie ist eine XML-Sitemap aufgebaut?

Eine minimale 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.de/</loc>
    <lastmod>2026-10-20</lastmod>
  </url>
  <url>
    <loc>https://example.de/blog/erster-artikel/</loc>
    <lastmod>2026-10-14</lastmod>
  </url>
</urlset>

Mehr braucht es nicht. Die einzelnen Bausteine:

Die letzten beiden Zeilen überraschen viele. In älteren Anleitungen steht noch, man solle der Startseite priority 1.0 geben und Blogartikeln changefreq daily. Google sagt seit Jahren offen, dass beide Werte ignoriert werden. Bing behandelt sie ähnlich. Du kannst sie weglassen, und du solltest keine Zeit mehr damit verbringen, sie fein abzustimmen.

lastmod: das einzige Feld, das wirklich zählt

lastmod gibt an, wann der Inhalt einer Seite zuletzt wesentlich geändert wurde. Erlaubt ist das W3C-Datumsformat, also 2026-10-20 oder mit Uhrzeit 2026-10-20T07:00:00+00:00.

Google nutzt den Wert, um zu entscheiden, welche Seiten erneut gecrawlt werden sollen. Das gilt aber nur, solange der Wert glaubwürdig ist. Setzt eine Website lastmod bei jedem Build oder jedem Seitenaufruf auf „jetzt“, merkt Google das und hört auf, dem Feld zu vertrauen. Ein geänderter Copyright-Hinweis im Footer oder eine neue Sidebar ist keine wesentliche Änderung. Eine neue Version des Artikels, korrigierte Fakten oder ein neuer Abschnitt sind es.

Daraus folgen zwei Regeln:

1. Nie das Build-Datum oder das Dateidatum nehmen. Bei statischen Seiten ändert sich das bei jedem Deploy für alle Seiten gleichzeitig.
2. Lieber kein lastmod als ein falsches. Ein fehlendes Feld kostet dich einen Hinweis, ein falsches kostet dich das Vertrauen in alle anderen Werte.

Grenzen: 50.000 URLs und 50 MB

Eine einzelne Sitemap darf höchstens 50.000 URLs enthalten und unkomprimiert höchstens 50 MB groß sein. Wird es mehr, teilst du sie auf mehrere Dateien auf und verbindest sie über einen Sitemap-Index:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.de/sitemap-produkte-1.xml</loc>
    <lastmod>2026-10-20</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.de/sitemap-blog.xml</loc>
  </sitemap>
</sitemapindex>

Wie viel Platz das in der Praxis ist, zeigt unsere eigene Datei: 234 URLs mit lastmod belegen 23.620 Byte, also etwa 100 Byte pro Eintrag. Mit gzip schrumpft die Datei auf 2.577 Byte. Hochgerechnet wären 50.000 Einträge rund 5 MB. Die 50-MB-Grenze erreicht praktisch niemand, die 50.000 URLs dagegen große Shops schnell.

Sitemaps dürfen auch gzip-komprimiert als sitemap.xml.gz ausgeliefert werden. Nötig ist das selten. Unser Webserver komprimiert die Datei beim Ausliefern ohnehin automatisch, über die Leitung gingen bei unserem Test nur 2.049 Byte.

Was gehört in die Sitemap und was nicht?

In die Sitemap gehören nur URLs, die du in Google sehen willst. Konkret heißt das, jede URL in der Sitemap muss

• den Statuscode 200 liefern (keine Weiterleitungen, keine 404),
• kanonisch sein, also auf sich selbst als Canonical zeigen,
• indexierbar sein (kein noindex),
• nicht per robots.txt gesperrt sein.

Nicht hinein gehören Weiterleitungen, Filter- und Suchergebnisseiten, Login- und Warenkorbseiten, Testseiten, Duplikate mit Parametern und alles, was auf noindex steht.

Wir haben unsere eigene Sitemap am 20. Oktober 2026 genau daraufhin geprüft: Alle 234 von 234 URLs lieferten 200. Bei einer Stichprobe von 40 zufälligen Seiten zeigte das Canonical jedes Mal exakt auf die URL aus der Sitemap, und keine einzige der 234 Seiten trug noindex. Zwei Adressen hatten wir schon früher bewusst ausgeschlossen, weil sie nur noch weiterleiten (ein alter Tool-Pfad und ein zurückgezogener Artikel). Das ist genau die Art Pflege, die eine Sitemap braucht: Sobald eine Seite weiterleitet, fliegt sie raus.

Sitemap erstellen: die Wege im Überblick

Wie du die Sitemap erstellst, hängt davon ab, womit deine Website läuft. Für fast alle verbreiteten Systeme gibt es eine eingebaute Lösung oder ein Standard-Plugin.

WordPress

Seit Version 5.5 (August 2020) erzeugt WordPress selbst eine Sitemap unter /wp-sitemap.xml. Du musst dafür nichts installieren. Wir haben das an einem WordPress-Testcontainer nachgeprüft:

Auffällig ist die letzte Zeile. Die Kern-Sitemap von WordPress listet auch die Autorenseiten, und deren URL enthält den Benutzernamen. Bei unserem Testsystem stand dort /author/admin/. Damit kennt jeder, der die Sitemap aufruft, den Login-Namen des Administrators. Ein Geheimnis ist das ohnehin nicht, WordPress verrät Benutzernamen auch über andere Wege. Wer aber nur einen Autor hat, braucht diese Unter-Sitemap ohnehin nicht. Per Code lässt sie sich abschalten:

add_filter( 'wp_sitemaps_add_provider', function ( $provider, $name ) {
    return ( 'users' === $name ) ? false : $provider;
}, 10, 2 );

Installierst du ein SEO-Plugin wie Yoast SEO, Rank Math oder SEOPress, ersetzt dessen Sitemap die eingebaute. Yoast liefert sie unter /sitemap_index.xml aus und blendet automatisch alles aus, was auf noindex steht. Welches Plugin wir für welchen Fall empfehlen, steht in unserem Vergleich der WordPress-SEO-Plugins. Wichtig ist nur: Nimm genau eine Sitemap. Zwei parallel laufende Sitemaps sind kein Fehler, verwirren aber jeden, der später nachsieht, welche eigentlich eingereicht ist.

Shopware 6

Shopware 6 erzeugt die Sitemap selbst, pro Verkaufskanal und Domain. Du findest die Einstellungen unter Einstellungen → Shop → Sitemap. Dort legst du fest, ob die Sitemap live beim Aufruf, per geplanter Aufgabe oder manuell erzeugt wird. Bei großen Katalogen ist die geplante Aufgabe die beste Wahl, manuell geht es per Konsole:

bin/console sitemap:generate

Die fertige Datei liegt dann unter https://dein-shop.de/sitemap.xml. Bei vielen Produkten teilt Shopware automatisch in mehrere komprimierte Dateien auf. Weitere Shopware-spezifische Punkte, von Produktvarianten bis zu Filterseiten, haben wir im Artikel zu Shopware SEO gesammelt.

Astro

Unsere eigene Website läuft mit Astro. Die offizielle Integration @astrojs/sitemap erzeugt beim Build einen Index (sitemap-index.xml) und die eigentlichen Dateien (sitemap-0.xml und weitere). Die Grundeinrichtung ist kurz:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://example.de',
  integrations: [sitemap()],
});

Genau hier steckte unser Fehler. Ohne weitere Einstellungen schreibt die Integration kein lastmod. Sie kennt nur die fertigen URLs, nicht deine Inhalte. Es gibt zwar die Option lastmod, die setzt aber für alle Seiten dasselbe Datum, und das ist genau die Art lastmod, die Google ignoriert. Unsere Lösung liest das Datum aus dem Frontmatter der Artikel und hängt es nur an die passenden URLs:

import fs from 'node:fs';
import path from 'node:path';

// Datum aus dem Frontmatter: updatedDate, sonst pubDate.
// Bewusst NICHT das Build-Datum.
function readArticleDates() {
  const map = new Map();
  const dirs = [['src/content/blog', '/blog/'], ['src/content/blog-de', '/de/blog/']];
  for (const [dir, prefix] of dirs) {
    for (const f of fs.readdirSync(dir)) {
      if (!f.endsWith('.mdx')) continue;
      const head = fs.readFileSync(path.join(dir, f), 'utf8').split('\n---')[0];
      const pick = (k) => (head.match(new RegExp('^' + k + ':\\s*["\']?(\\d{4}-\\d{2}-\\d{2})', 'm')) || [])[1];
      const d = pick('updatedDate') || pick('pubDate');
      if (d) map.set(prefix + f.replace(/\.mdx$/, '') + '/', d);
    }
  }
  return map;
}
const DATES = readArticleDates();

// in integrations:
sitemap({
  serialize(item) {
    const d = DATES.get(new URL(item.url).pathname);
    if (d) item.lastmod = d;
    return item;
  },
}),

Nach dem Build hatten 182 der 234 URLs ein lastmod, nämlich alle Artikel in beiden Sprachen. Die übrigen 52 sind Startseiten, Kategorie-, Tool- und Rechtsseiten. Für sie haben wir kein ehrliches Änderungsdatum, also bekommen sie auch keins. Dazu kam ein neues, optionales Feld updatedDate im Frontmatter. Wird ein Artikel wesentlich überarbeitet, tragen wir dort das Datum ein, und die Sitemap übernimmt es.

Next.js

Im App Router von Next.js legst du eine Datei app/sitemap.ts an. Next.js erzeugt daraus /sitemap.xml:

// app/sitemap.ts
import type { MetadataRoute } from 'next';
import { getAllPosts } from '@/lib/posts';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const posts = await getAllPosts();
  return [
    { url: 'https://example.de/', lastModified: new Date('2026-10-01') },
    ...posts.map((p) => ({
      url: `https://example.de/blog/${p.slug}/`,
      lastModified: new Date(p.updatedAt ?? p.publishedAt),
    })),
  ];
}

Die häufigste Falle ist hier dieselbe wie bei uns, nur andersherum: lastModified: new Date() sieht harmlos aus, setzt aber bei jedem Aufruf jede Seite auf „gerade eben geändert“. Für mehr als 50.000 URLs gibt es generateSitemaps(), das automatisch mehrere Dateien anlegt. Für dynamische Routen haben wir das ausführlicher im Artikel zu Next.js Dynamic Routes beschrieben. Welcher der beiden Ansätze für einen Blog besser passt, zeigt unser Benchmark Astro vs. Next.js.

Ohne CMS: von Hand oder per Skript

Hast du eine kleine statische Website ohne CMS, kannst du die Sitemap auch von Hand schreiben. Bei mehr als einer Handvoll Seiten ist ein kleines Skript sicherer. Dieses Beispiel liest alle HTML-Dateien aus einem Ordner und nimmt das Änderungsdatum aus Git, nicht aus dem Dateisystem:

#!/usr/bin/env bash
# sitemap.sh — erzeugt sitemap.xml aus allen index.html-Dateien in ./public
BASE="https://example.de"
{
  echo '<?xml version="1.0" encoding="UTF-8"?>'
  echo '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">'
  find public -name index.html | sort | while read -r f; do
    path="${f#public}"; path="${path%index.html}"
    date=$(git log -1 --format=%cs -- "$f")
    echo "  <url><loc>${BASE}${path}</loc>${date:+<lastmod>$date</lastmod>}</url>"
  done
  echo '</urlset>'
} > public/sitemap.xml

Das Datum aus Git (%cs = Datum des letzten Commits, der die Datei geändert hat) ist deutlich besser als mtime, weil ein frischer Checkout auf dem Server sonst alle Dateien auf „heute“ setzt. Wenn dir Git noch fremd ist, hilft unsere Einführung Was ist Git?.

Online-Generatoren

Tools wie xml-sitemaps.com oder der Screaming Frog SEO Spider crawlen deine Website und erzeugen daraus eine Sitemap zum Herunterladen. Für eine einmalige Bestandsaufnahme ist das praktisch. Als Dauerlösung taugt es nicht. Die Datei ist ein Schnappschuss und veraltet mit jeder neuen Seite. Außerdem findet ein Crawler genau die Seiten nicht, die schlecht verlinkt sind, also die, für die du eine Sitemap eigentlich brauchst. Eine Sitemap sollte aus deinen Daten entstehen, nicht aus einem Crawl.

Sitemap prüfen, bevor du sie einreichst

Bevor du die Sitemap irgendwo einreichst, solltest du sie einmal selbst prüfen. Mit drei Befehlen auf der Kommandozeile geht das schnell:

# 1. Ist die Datei erreichbar und gültiges XML?
curl -s https://example.de/sitemap.xml | xmllint --noout - && echo "XML ok"

# 2. Liefern alle URLs Status 200?
curl -s https://example.de/sitemap.xml | grep -oP '(?<=<loc>)[^<]+' \
  | xargs -P 16 -I{} curl -s -o /dev/null -w "%{http_code} {}\n" {} \
  | sort | grep -v '^200' || echo "alle 200"

# 3. Wie viele Einträge haben ein lastmod?
curl -s https://example.de/sitemap.xml | grep -o '<lastmod>' | wc -l

Bei der dritten Zeile sind wir selbst kurz hereingefallen. Unser erster Versuch war grep -c '<lastmod>'. Das ergab 1, obwohl 182 Einträge da waren. grep -c zählt Zeilen, nicht Treffer, und unsere Sitemap besteht aus einer einzigen langen Zeile. Erst grep -o … | wc -l zählt jeden Treffer einzeln. Hätten wir der ersten Zahl geglaubt, hätten wir einen funktionierenden Fix für kaputt gehalten.

Achte bei der Prüfung außerdem auf den Content-Type. Er sollte application/xml oder text/xml sein. Unsere Datei kommt mit text/xml; charset=utf-8. Und schau, ob die URLs in der Sitemap exakt zu deiner kanonischen Domain passen: mit oder ohne www, mit oder ohne Schrägstrich am Ende. Eine Sitemap voller http://-Adressen auf einer https://-Website besteht aus lauter Weiterleitungen.

Sitemap einreichen: Google, Bing und robots.txt

Eine Sitemap, von der niemand weiß, bringt nichts. Es gibt drei Wege, sie bekannt zu machen, und du solltest alle drei nutzen.

1. In der robots.txt eintragen

Der einfachste Weg funktioniert für alle Suchmaschinen gleichzeitig, auch für die, bei denen du kein Konto hast. Eine Zeile in der robots.txt genügt:

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

Die URL muss vollständig sein, also mit https:// und Domain. Mehrere Sitemap-Zeilen sind erlaubt. Wie die restliche robots.txt aussehen sollte und welche Fallstricke es dort gibt, steht in unserer Anleitung robots.txt erstellen. Unsere eigene robots.txt verweist auf den Sitemap-Index, nicht auf die einzelnen Dateien. Das reicht, Crawler folgen dem Index von selbst.

2. In der Google Search Console einreichen

1. Öffne die Google Search Console und wähle deine Property.
2. Klicke links auf Indexierung → Sitemaps.
3. Trage unter „Neue Sitemap hinzufügen“ den Pfad ein, zum Beispiel sitemap.xml oder sitemap-index.xml.
4. Klicke auf Senden.

Danach zeigt Google den Status an. „Erfolgreich“ heißt nur, dass Google die Datei lesen konnte. Es heißt nicht, dass alle Seiten indexiert sind. Ob und wie viele Seiten im Index landen, siehst du im Bericht Seitenindexierung. Den reichst du übrigens nur einmal ein. Danach holt Google die Sitemap von selbst regelmäßig ab.

Das Video von Being George (Juli 2026) zeigt das Einreichen in der Search Console Klick für Klick. Es ist auf Englisch, die Oberfläche ist aber dieselbe wie in der deutschen Version, nur die Menünamen sind übersetzt.

3. In den Bing Webmaster Tools einreichen

Bei Bing läuft es fast genauso: In den Bing Webmaster Tools unter Sitemaps auf „Sitemap übermitteln“ klicken und die URL eintragen. Hast du die Search Console schon eingerichtet, kannst du deine Website in Bing direkt von dort importieren, inklusive Sitemap. Warum sich Bing für eine kleine Website mehr lohnt, als viele denken, haben wir im Artikel Bing SEO beschrieben, unter anderem, weil Copilot und andere KI-Assistenten auf den Bing-Index zugreifen.

Der Sitemap-Ping ist tot

Viele ältere Anleitungen und Plugins nennen noch einen vierten Weg: eine URL wie https://www.google.com/ping?sitemap=… aufrufen, damit Google die Sitemap sofort neu lädt. Google hat diesen Ping-Endpunkt im Juni 2023 für veraltet erklärt und Ende 2023 abgeschaltet. Er liefert heute nur noch einen Fehler. Bing hat seinen Ping ebenfalls aufgegeben und verweist auf IndexNow. Wenn ein Plugin oder ein Deploy-Skript noch pingt, kannst du diese Zeile löschen.

Wer liest unsere Sitemap wirklich?

Hier wird es spannend, denn das steht in kaum einer Anleitung. Wir haben alle Zugriffe auf getmind.io vom 3. Oktober 13:19 Uhr bis zum 20. Oktober 07:02 Uhr (UTC) ausgewertet, insgesamt 151.296 Anfragen. Die Zuordnung zu Crawlern erfolgte über den User-Agent. Den kann jeder fälschen, die Zahlen sind also eine Annäherung. Für Google haben wir zusätzlich die IP-Adressen angesehen: Sie stammen aus den Bereichen 66.249.x.x und 192.178.x.x, die Google für den Googlebot nutzt.

Drei Dinge fallen auf.

Erstens: Google holt die Sitemap etwa einmal am Tag. 20 Abrufe in knapp 17 Tagen, meistens nachts, und fast immer direkt die Datei sitemap-0.xml, nicht den Index. Google merkt sich also die eigentliche Datei, nachdem es den Index einmal gelesen hat.

Zweitens: ClaudeBot liest nur das Inhaltsverzeichnis. Der Crawler von Anthropic hat den Sitemap-Index 177-mal abgerufen, die Datei mit den eigentlichen URLs aber kein einziges Mal. Er erfährt also aus unserer Sitemap nur, dass es eine weitere Datei gibt, und schaut nie hinein. Die Artikel findet er trotzdem, nur eben über Links. Wer seine Sitemap für KI-Crawler optimiert, optimiert bei diesem Crawler für einen Leser, der den Inhalt gar nicht öffnet.

Drittens: Viele Crawler ignorieren die Sitemap komplett. PerplexityBot, Applebot und OAI-SearchBot holten zusammen 182-mal die robots.txt ab, aber nie die Sitemap. Sie verlassen sich offenbar vollständig auf Links.

Daneben gab es 30 Anfragen auf /sitemap.xml, eine Adresse, die bei uns gar nicht existiert, weil Astro die Datei anders nennt. 25 davon bekamen eine 404. Dazu kamen Anfragen auf /wp-sitemap.xml, /sitemap_index.xml, /sitemap.php und sogar /sitemaps/.env. Das sind keine Suchmaschinen, sondern Scanner, die nach bekannten Pfaden von WordPress und anderen Systemen suchen. Eine Sitemap unter einem ungewöhnlichen Namen ist also kein Problem, solange sie in der robots.txt steht. Ein Crawler, der nur /sitemap.xml probiert, ist meistens ohnehin keiner, den du brauchst.

Wie schnell finden Crawler einen neuen Artikel?

Für die sechs Artikelpaare vom 14. bis 19. Oktober haben wir gemessen, wie viele Stunden nach der Veröffentlichung jeder Crawler die neue Seite zum ersten Mal abgerufen hat:

Ein Strich bedeutet: bis zum 20. Oktober 07:02 Uhr kein Abruf.

Bing war bei allen zwölf Seiten innerhalb von Minuten da. Das liegt nicht an der Sitemap, sondern an IndexNow. Wir melden jeden neuen Artikel direkt nach dem Deploy über das IndexNow-Protokoll, und bingbot kommt sofort. Die Sitemap holt Bing zwar auch regelmäßig, aber dann sind die neuen Seiten längst gecrawlt.

Google brauchte zwischen 2,6 und 19,4 Stunden, und bei fünf von zwölf Seiten kam der Googlebot innerhalb des Messzeitraums überhaupt nicht. Das gilt, obwohl alle zwölf URLs in der Sitemap standen und Google sie täglich abgeholt hat. Hier zeigt sich auch die Wirkung des fehlenden lastmod: Unsere Sitemap sagte Google nicht, dass es neue Seiten gab, sie standen nur irgendwo zwischen 233 anderen. Ob der Fix daran etwas ändert, messen wir in den nächsten Wochen nach.

Eine Sitemap ist also keine Garantie für schnelles Crawlen und schon gar nicht für die Indexierung. Sie ist ein Hinweis, den Google gewichtet. Für frische Artikel ist der schnellste Weg zu Google weiterhin die URL-Prüfung in der Search Console mit „Indexierung beantragen“. Für Bing, Yandex, Seznam und Naver ist es IndexNow.

Spezielle Sitemaps: Bilder, Videos, News und Sprachen

Das Sitemap-Protokoll lässt sich erweitern. Die vier wichtigsten Erweiterungen:

Bilder-Sitemap. Mit dem Namensraum image kannst du zu jeder URL die Bilder auflisten, die darauf vorkommen. Das lohnt sich, wenn Bilder per JavaScript nachgeladen werden und Google sie sonst nicht findet. Bei normalen <img>-Tags findet Google die Bilder auch ohne.

Video-Sitemap. Für selbst gehostete Videos kannst du Titel, Beschreibung, Vorschaubild und Länge mitliefern. Bei eingebetteten YouTube-Videos bringt das wenig, weil Google das Video ohnehin bei YouTube kennt.

News-Sitemap. Nur für Websites, die in Google News auftauchen. Sie enthält ausschließlich Artikel der letzten zwei Tage.

Sprachversionen (hreflang). Hast du eine Website in mehreren Sprachen, kannst du die Zuordnung der Übersetzungen auch in der Sitemap angeben:

<url>
  <loc>https://example.de/de/blog/sitemap-erstellen/</loc>
  <xhtml:link rel="alternate" hreflang="de" href="https://example.de/de/blog/sitemap-erstellen/"/>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.de/blog/create-sitemap/"/>
</url>

Das ist eine Alternative zu hreflang-Tags im HTML-Kopf, keine Pflicht zusätzlich. Wir setzen hreflang im HTML und prüfen bei jedem Build automatisch, dass jeder deutsche Artikel sein englisches Gegenstück findet und umgekehrt. Doppelt angeben schadet nicht, solange beide Angaben übereinstimmen. Widersprechen sie sich, wird es schwierig.

Die häufigsten Fehler beim Sitemap erstellen

1. lastmod fehlt oder lügt. Entweder gar kein Datum (unser Fehler) oder bei jeder Seite das Datum des letzten Builds. Beides nimmt Google den einzigen nützlichen Hinweis.
2. Weiterleitungen in der Sitemap. Typisch nach einem Umzug von http auf https oder nach dem Umbenennen von URLs. Jeder Eintrag sollte direkt 200 liefern.
3. noindex-Seiten in der Sitemap. Damit sagst du Google gleichzeitig „bitte ansehen“ und „bitte nicht aufnehmen“. Die Search Console meldet das als Problem.
4. Gesperrte URLs. Seiten, die in der robots.txt gesperrt sind, haben in der Sitemap nichts verloren.
5. Falsche Domain-Variante. www statt ohne, http statt https, mit statt ohne Schrägstrich am Ende. Nur die kanonische Variante gehört hinein.
6. Zwei Sitemaps nebeneinander. Die eingebaute WordPress-Sitemap und die eines Plugins, oder eine alte statische Datei neben der neuen dynamischen.
7. Veraltete Sitemap. Ein einmal erzeugter Export, der seit Monaten nicht aktualisiert wurde, während neue Seiten dazukamen.
8. Ping-Code, der ins Leere läuft. Harmlos, aber ein Zeichen, dass niemand mehr nachsieht.
9. Zu viele Einträge in einer Datei. Ab 50.000 URLs oder 50 MB muss aufgeteilt werden, sonst wird die Datei abgelehnt.
10. Falsch gezählt. Wie bei uns mit grep -c: Ein Prüfbefehl, der die falsche Einheit zählt, kann einen funktionierenden Zustand als kaputt melden oder einen kaputten als gesund.

Fazit: Eine Sitemap erstellen ist leicht, eine gute pflegen ist die Arbeit

Eine Sitemap zu erstellen ist in fünf Minuten erledigt, und bei den meisten Systemen passiert es von allein. Der Unterschied zwischen einer Sitemap, die nur existiert, und einer, die hilft, liegt in drei Punkten: Es stehen nur kanonische, indexierbare 200er-URLs darin, jede Seite hat ein ehrliches lastmod, und die Datei ist in der robots.txt sowie in der Search Console und den Bing Webmaster Tools eingetragen.

Unsere Logs zeigen außerdem, wo die Grenzen liegen. Google liest die Sitemap täglich, crawlt neue Seiten trotzdem erst nach Stunden oder gar nicht. KI-Crawler wie ClaudeBot, PerplexityBot und OAI-SearchBot öffnen sie praktisch nie. Bing kommt am schnellsten, aber wegen IndexNow, nicht wegen der Sitemap. Wer möchte, dass neue Inhalte schnell gefunden werden, braucht die Sitemap als Grundlage, dazu gute interne Links und für frische Seiten zusätzlich die URL-Prüfung in der Search Console und IndexNow.

Und prüf deine eigene Sitemap einmal mit den drei Befehlen von oben. Wir hätten es ohne diesen Artikel nicht gemerkt.

Häufige Fragen zum Sitemap erstellen

Wie erstelle ich eine Sitemap?

Am einfachsten über dein CMS: WordPress erzeugt seit Version 5.5 automatisch /wp-sitemap.xml, SEO-Plugins wie Yoast oder Rank Math ersetzen sie durch eine eigene. Shopware, Astro (@astrojs/sitemap) und Next.js (app/sitemap.ts) haben eingebaute Lösungen. Ohne CMS schreibst du eine XML-Datei mit <urlset>, einem <url>-Eintrag pro Seite und <loc> mit der vollständigen URL, idealerweise per Skript.

Was muss in eine XML-Sitemap?

Pflicht sind nur <urlset>, <url> und <loc>. Empfehlenswert ist <lastmod> mit dem Datum der letzten wesentlichen Inhaltsänderung. <changefreq> und <priority> ignoriert Google, du kannst sie weglassen. Aufnehmen solltest du nur kanonische URLs, die Status 200 liefern, nicht auf noindex stehen und nicht per robots.txt gesperrt sind.

Wo finde ich meine Sitemap?

Meist unter /sitemap.xml, /sitemap_index.xml (Yoast), /wp-sitemap.xml (WordPress ohne Plugin) oder /sitemap-index.xml (Astro). Am zuverlässigsten ist ein Blick in deine robots.txt unter https://deine-domain.de/robots.txt: Dort sollte eine Zeile Sitemap: stehen.

Wie reiche ich eine Sitemap bei Google ein?

In der Google Search Console unter Indexierung → Sitemaps den Pfad eintragen und auf Senden klicken. Zusätzlich die Zeile Sitemap: https://deine-domain.de/sitemap.xml in die robots.txt schreiben. Einmal einreichen reicht, danach ruft Google die Datei regelmäßig selbst ab. Den früheren Ping-Endpunkt gibt es seit Ende 2023 nicht mehr.

Wie viele URLs darf eine Sitemap enthalten?

Höchstens 50.000 URLs und unkomprimiert höchstens 50 MB pro Datei. Bei mehr Seiten teilst du sie auf mehrere Dateien auf und verbindest sie über einen Sitemap-Index, der selbst wieder bis zu 50.000 Sitemaps enthalten darf. In der Praxis belegt ein Eintrag etwa 100 Byte, die URL-Grenze ist also fast immer die erste, an die man stößt.

Braucht jede Website eine Sitemap?

Nein. Kleine, gut verlinkte Websites mit bis zu etwa 500 Seiten kommen laut Google auch ohne aus. Wichtig wird sie bei großen Websites, Shops, neuen Domains ohne externe Links, Seiten mit schlecht verlinkten Bereichen und Websites, die regelmäßig neue Inhalte veröffentlichen. Schaden kann eine korrekte Sitemap nie.

Wie oft sollte ich meine Sitemap aktualisieren?

Immer dann, wenn sich Seiten ändern, und am besten automatisch. Die Sitemap sollte aus deinem System erzeugt werden, nicht als einmaliger Export daliegen. Erneut in der Search Console einreichen musst du sie nicht, Google holt sie selbst. Bei unserer Website waren das 20 Abrufe in 17 Tagen, also etwa einer pro Tag.

Was ist der Unterschied zwischen HTML- und XML-Sitemap?

Die XML-Sitemap ist eine maschinenlesbare Datei für Suchmaschinen und wird Besuchern nicht angezeigt. Die HTML-Sitemap ist eine normale Webseite mit Links zu allen Bereichen, gedacht für Menschen. Für SEO ist die XML-Sitemap das Werkzeug, eine HTML-Sitemap ist allenfalls eine Navigationshilfe.

Ist lastmod in der Sitemap wichtig?

Ja, es ist das einzige optionale Feld, das Google tatsächlich nutzt, aber nur, wenn es zuverlässig stimmt. Setzt du es bei jedem Build auf das aktuelle Datum, lernt Google, dem Wert nicht zu vertrauen. Nimm das Datum der letzten echten Inhaltsänderung, zum Beispiel aus dem Frontmatter, der Datenbank oder dem Git-Verlauf. Lieber kein lastmod als ein falsches.

Warum werden Seiten aus meiner Sitemap nicht indexiert?

Eine Sitemap ist eine Empfehlung, kein Befehl. Google entscheidet selbst, was gecrawlt und indexiert wird. Häufige Gründe für fehlende Indexierung sind dünne oder doppelte Inhalte, ein abweichendes Canonical, noindex, Sperren in der robots.txt oder schlicht fehlende Priorität bei neuen Websites. Den genauen Grund zeigt der Bericht Seitenindexierung in der Search Console.

Hilft eine Sitemap bei KI-Suchmaschinen wie ChatGPT oder Perplexity?

Nach unseren Logs kaum. PerplexityBot und OAI-SearchBot haben unsere Sitemap in 17 Tagen nie abgerufen, ClaudeBot nur den Index, nie die eigentlichen URLs. Diese Crawler finden Seiten über Links. Indirekt hilft die Sitemap trotzdem: Copilot und andere Assistenten greifen auf den Bing-Index zurück, und Bing nutzt die Sitemap. Mehr dazu in unserer Auswertung der KI-Crawler in unseren Logfiles.