Robots.txt und Sitemap.xml verständlich erklärt: was in beide Dateien gehört, was nicht, welche SEO-Mythen dich Sichtbarkeit kosten und wie du die Indexierung in der Search Console prüfst.
Viele SEO-Probleme sind keine Text-Probleme, sondern Indexierungs-Probleme: Google findet die wichtige Leistungsseite nicht, zeigt stattdessen eine Filter-Variante, hängt in Bereichen fest, die keinen Kunden interessieren, oder hat nach dem Relaunch die halbe Website aus dem Index geworfen. Dahinter stecken zwei unscheinbare Dateien, die auf fast jeder Website existieren und trotzdem regelmäßig falsch eingesetzt werden: die robots.txt und die sitemap.xml.
Du bekommst:
- eine Kurzantwort, was beide Dateien tun und was sie nicht können
- den Unterschied zwischen Crawling und Indexierung, der die meisten Missverständnisse auflöst
- Tabellen, was in robots.txt und Sitemap gehört und was nicht
- sieben verbreitete Mythen mit der Wahrheit dahinter
- eine Schritt-für-Schritt-Prüfung in der Google Search Console inklusive Erklärung der wichtigsten Meldungen
- die Unterschiede bei WordPress, Shopify und Next.js und eine monatliche Zehn-Minuten-Routine
Der Artikel ist für Inhaber und Marketing-Verantwortliche geschrieben, die ihre Agentur oder ihren Entwickler mit den richtigen Fragen konfrontieren wollen. Technik-Abschnitte sind knapp gehalten.
Kurzantwort: Was robots.txt und Sitemap.xml wirklich tun
Die robots.txt ist eine Textdatei im Hauptverzeichnis deiner Domain, die Suchmaschinen sagt, welche Bereiche sie nicht abrufen sollen. Sie steuert das Crawlen, nicht die Indexierung: Eine blockierte Seite kann trotzdem in Google erscheinen, wenn sie von außen verlinkt ist. Die sitemap.xml ist eine Liste der Seiten, die du in den Suchergebnissen sehen willst, mit Adresse und Änderungsdatum. Sie ist eine Empfehlung an Google, keine Garantie für Indexierung, und sie ersetzt keine internen Links. Beide Dateien gehören zusammen: Die robots.txt hält Crawler aus Bereichen ohne Suchwert heraus, die Sitemap zeigt die Seiten mit Suchwert, und die Google Search Console zeigt dir, ob beides zusammenpasst. Der häufigste Fehler ist, die robots.txt als Werkzeug zum Verstecken von Seiten zu benutzen. Dafür ist sie nicht gemacht, dafür gibt es das noindex-Tag.
Was Indexierung für dein Unternehmen bedeutet
Eine Seite, die nicht im Google-Index ist, existiert für Suchende nicht. Das klingt banal, hat aber konkrete Folgen. Drei typische, vereinfachte Situationen, wie sie in Website-Checks immer wieder auftauchen:
- Ein Handwerksbetrieb in Magdeburg hat eine gute Seite zu „Badsanierung“, aber sie steht seit dem Relaunch auf noindex, weil das Häkchen aus der Testumgebung übernommen wurde. Anfragen für Bäder kommen nur noch über Empfehlung.
- Ein Onlineshop hat ein Vielfaches seiner Produkte als Filter- und Sortier-Varianten im Index. Google verbringt seine Zeit mit den Varianten, neue Produkte werden erst spät aufgenommen.
- Eine Praxis hat die Sitemap einer alten Domain eingereicht. Google meldet Fehler, das Team ignoriert die Search Console, und ein echtes Problem mit der Terminbuchungsseite fällt nicht auf.
Indexierung ist deshalb keine technische Fußnote, sondern die Voraussetzung dafür, dass Texte, Design und Werbebudget überhaupt wirken können. Gut ist: Die Prüfung dauert zehn Minuten, und die Werkzeuge sind kostenlos.
Crawling und Indexierung: der Unterschied in einer Minute
Diese beiden Begriffe zu trennen, löst die Hälfte aller Missverständnisse rund um robots.txt:
- Crawling heißt: Der Googlebot ruft eine URL ab und liest den Inhalt. Die robots.txt steuert das.
- Indexierung heißt: Google nimmt die URL in seinen Index auf, sodass sie in Suchergebnissen erscheinen kann. Das steuern das noindex-Tag, Canonical-Tags, Statuscodes und Googles eigene Qualitätsbewertung.
Daraus folgt eine Regel, die auf den ersten Blick widersprüchlich wirkt: Wenn du eine Seite aus Google entfernen willst, darfst du sie nicht per robots.txt blockieren. Google muss die Seite abrufen können, um das noindex-Tag zu sehen. Blockierst du sie, sieht Google das Tag nicht, behält die Seite im Index und zeigt sie ohne Beschreibung an, mit dem Hinweis „Für diese Seite sind keine Informationen verfügbar“.
Die zweite Regel: Wenn dieselbe Seite unter mehreren Adressen erreichbar ist, entscheidet nicht die Sitemap, welche zählt, sondern der Canonical-Tag und Weiterleitungen. Wie du das sauber löst, steht im Artikel zu Canonicals, Redirects und www.
Robots.txt erklärt: Aufbau und ein sauberes Beispiel
Die Datei liegt immer unter deinedomain.de/robots.txt, gilt nur für genau diesen Host (eine Subdomain braucht ihre eigene) und besteht aus wenigen Anweisungen. Ein Beispiel, das für die meisten Unternehmenswebsites passt:
User-agent: *
Disallow: /wp-admin/
Disallow: /suche/
Disallow: /warenkorb/
Disallow: /*?sortierung=
Allow: /wp-admin/admin-ajax.php
Sitemap: https://www.deinedomain.de/sitemap.xml
Was die Zeilen bedeuten:
- User-agent benennt den Crawler, für den die folgenden Regeln gelten. Der Stern steht für alle.
- Disallow sperrt einen Pfad. Alles, was mit diesem Pfad beginnt, wird nicht abgerufen. Der Stern in der Mitte ist ein Platzhalter, so lassen sich zum Beispiel Sortier-Parameter ausschließen.
- Allow hebt eine Sperre für einen Unterpfad wieder auf.
- Sitemap nennt die Adresse deiner Sitemap, mit vollständiger Domain.
Drei Dinge, die Google in der robots.txt nicht beachtet, obwohl sie oft dort stehen: eine Anweisung noindex (wird seit 2019 ignoriert), Crawl-delay (Google ignoriert es, Bing nicht) und Kommentare als Anweisungen. Groß- und Kleinschreibung in Pfaden ist relevant.
Tipp: Eine leere robots.txt oder gar keine ist besser als eine falsche. Wenn deine Website keine Bereiche hat, die Crawler meiden sollen, reicht eine Datei mit der Sitemap-Zeile. Blockiere nur, was du aus gutem Grund nicht gecrawlt haben willst.
Was in die robots.txt gehört und was nicht
| Gehört hinein | Gehört nicht hinein | Warum |
|---|---|---|
| Interne Suchergebnisseiten | Die Startseite oder ganze Bereiche mit Leistungsseiten | Suchergebnisseiten sind unendlich viele URLs ohne eigenen Wert; Leistungsseiten sind dein Umsatz |
| Filter- und Sortier-Parameter im Shop | Produktseiten und Kategorien | Filterkombinationen erzeugen tausende Duplikate; Produkte und Kategorien sollen ranken |
| Warenkorb, Kasse, Kundenkonto | Bilder, CSS- und JavaScript-Dateien | Ohne Stylesheets und Skripte kann Google die Seite nicht so rendern, wie Nutzer sie sehen |
| Admin-Bereiche und technische Endpunkte | Seiten, die du aus dem Index entfernen willst | Dafür ist noindex zuständig, blockierte Seiten bleiben im Index |
| Die Sitemap-Zeile | Testumgebungen (besser: Passwortschutz) | Eine Staging-Seite hinter Passwort ist sicher, eine per robots.txt geschützte nicht |
Ein besonders teurer Fehler ist die Sperre von Bildern, Stylesheets oder Skripten. Manche alten Anleitungen empfehlen, den Ordner mit Themes oder Uploads zu blockieren. Google rendert Seiten wie ein Browser und braucht diese Dateien, um Layout, Inhalte und mobile Tauglichkeit zu bewerten.
Sitemap.xml erklärt: was rein, was raus
Die Sitemap ist keine Liste aller URLs, sondern eine kuratierte Liste der Seiten, die Google indexieren soll. Technische Eckdaten: Eine Sitemap darf bis zu 50.000 URLs und 50 Megabyte unkomprimiert enthalten, größere Websites teilen auf mehrere Dateien mit einer Index-Sitemap. Jede URL wird vollständig angegeben, mit https und der richtigen Host-Variante (mit oder ohne www, so wie deine Website tatsächlich läuft).
| Gehört in die Sitemap | Gehört nicht in die Sitemap | Begründung |
|---|---|---|
| Leistungsseiten, Standortseiten, Über-uns | Impressum, Datenschutz, AGB | Rechtsseiten sollen erreichbar sein, aber niemand soll sie über Google finden |
| Blogartikel und Ratgeber | Danke-Seiten nach Formularen, Bestätigungsseiten | Diese Seiten haben ohne Kontext keinen Sinn und stehen meist auf noindex |
| Produkte und Kategorien im Shop | Filter-, Sortier- und Parameter-Varianten | Duplikate schwächen die Hauptseite |
| Case Studies, Referenzen | Weiterleitungen, 404-Seiten, gelöschte Inhalte | Jede URL in der Sitemap muss mit Statuscode 200 antworten |
| Nur die kanonische Version jeder Seite | Seiten mit noindex, Seiten, die per robots.txt blockiert sind | Widersprüchliche Signale: Google soll eine Seite indexieren, darf sie aber nicht lesen |
| Ein korrektes Änderungsdatum (lastmod) | Prioritäten und Änderungshäufigkeit (priority, changefreq) | Google nutzt lastmod, wenn es zuverlässig ist, und ignoriert priority und changefreq |
Zum Änderungsdatum: Google hat mehrfach erklärt, dass lastmod berücksichtigt wird, solange es stimmt. Eine Sitemap, in der jede Seite bei jedem Build das aktuelle Datum bekommt, macht das Signal wertlos. Wenn dein System das Datum nicht sauber pflegen kann, ist es besser, es wegzulassen.
Und noch einmal, weil es der wichtigste Punkt ist: Eine Sitemap ersetzt keine internen Links. Google bewertet Seiten, die nur in der Sitemap stehen, aber von keiner anderen Seite verlinkt sind, als unwichtig. Die Sitemap ist die Einladung, die Verlinkung ist der Beweis, dass die Seite zu deiner Website gehört. Wie du das strukturiert angehst, steht im Artikel zu internen Links und Topic Clustern.
Sieben Mythen zur Indexierung
| Mythos | Wahrheit |
|---|---|
| „Was in der robots.txt gesperrt ist, erscheint nicht bei Google.“ | Gesperrte Seiten werden nicht gecrawlt, können aber über externe Links in den Index kommen und erscheinen dann ohne Beschreibung. |
| „Ich setze noindex in die robots.txt.“ | Google ignoriert diese Anweisung seit 2019. Noindex gehört als Meta-Tag in die Seite oder in den HTTP-Header. |
| „Je mehr URLs in der Sitemap, desto besser.“ | Eine Sitemap voller Duplikate, Filter und Weiterleitungen verwässert das Signal. Kuratiert schlägt vollständig. |
| „Sitemap eingereicht, also wird alles indexiert.“ | Die Sitemap ist ein Hinweis. Google entscheidet nach Qualität, Verlinkung und Einzigartigkeit, ob eine Seite in den Index kommt. |
| „Priority 1.0 in der Sitemap pusht meine wichtigste Seite.“ | Google ignoriert priority und changefreq vollständig. |
| „Die Testumgebung ist per robots.txt sicher.“ | Nein. Wer die URL kennt oder verlinkt, bringt sie in den Index. Testumgebungen gehören hinter ein Passwort. |
| „Eine Seite aus dem Index nehmen geht am schnellsten über Disallow.“ | Blockieren verhindert, dass Google das noindex sieht. Richtig: noindex setzen oder löschen, bei Eile das Entfernen-Tool der Search Console. |
Prüfung in der Google Search Console: Schritt für Schritt
Die Search Console ist kostenlos und zeigt dir, was Google tatsächlich von deiner Website hält. Wenn du sie noch nicht eingerichtet hast, ist das der erste Schritt, bevor du irgendetwas an robots.txt oder Sitemap änderst.
- Sitemap prüfen: Menü „Sitemaps“. Steht deine Sitemap dort mit Status „Erfolgreich“? Wie viele URLs wurden gefunden? Stimmt die Zahl ungefähr mit den Seiten überein, die du indexiert haben willst? Wenn dort eine alte Sitemap mit Fehlern steht, entferne sie.
- Indexierungsbericht öffnen: Menü „Seiten“ unter „Indexierung“. Oben siehst du, wie viele Seiten indexiert und wie viele nicht indexiert sind. Darunter listet Google die Gründe für die nicht indexierten Seiten auf.
- Gründe durchgehen: Klicke auf jeden Grund und prüfe die Beispiel-URLs. Sind das Seiten, die du bewusst ausgeschlossen hast, oder wichtige Seiten? Die Tabelle im nächsten Abschnitt hilft bei der Einordnung.
- Wichtige Seiten stichprobenartig prüfen: Gib in das Suchfeld oben deine wichtigste Leistungsseite ein. Die URL-Prüfung zeigt, ob die Seite indexiert ist, welche kanonische URL Google gewählt hat und ob Crawling erlaubt ist. Mit „Live-URL testen“ prüfst du den aktuellen Zustand.
- Robots.txt prüfen: Unter „Einstellungen“ findest du den Bericht zur robots.txt. Er zeigt, welche Version Google zuletzt gelesen hat und ob es Fehler gab.
- Nach Änderungen: Neue oder korrigierte Seiten über die URL-Prüfung mit „Indexierung beantragen“ anstoßen. Das beschleunigt, garantiert aber nichts.
Tipp: Filtere den Bericht „Seiten“ nach „Nur eingereichte Seiten“. Dann siehst du ausschließlich URLs aus deiner Sitemap. Jede davon, die nicht indexiert ist, verdient einen genauen Blick, denn du hast Google ausdrücklich darum gebeten.
Meldungen in der Search Console und was sie bedeuten
| Meldung | Bedeutung | Was du tust |
|---|---|---|
| Durch robots.txt-Datei blockiert | Google darf die Seite nicht abrufen | Wichtige Seite? Regel in der robots.txt korrigieren. Filter- oder Systemseite? Alles in Ordnung. |
| Indexiert, obwohl durch robots.txt-Datei blockiert | Seite ist im Index, aber ohne Inhalt, weil extern verlinkt | Soll sie raus: Sperre aufheben und noindex setzen. Soll sie drin bleiben: Sperre aufheben. |
| Durch noindex-Tag ausgeschlossen | Seite trägt ein noindex | Gewollt bei Danke-Seiten und Rechtsseiten. Bei Leistungsseiten sofort entfernen, oft ein Relaunch-Überbleibsel. |
| Gecrawlt – zurzeit nicht indexiert | Google hat die Seite gelesen und nicht für wertvoll genug befunden | Inhalt ausbauen, klar ausrichten, intern verlinken. Nicht einfach neu einreichen. |
| Gefunden – zurzeit nicht indexiert | Google kennt die URL, hat sie aber noch nicht abgerufen | Bei neuen Seiten normal. Hält es Wochen an: interne Verlinkung stärken, Sitemap prüfen. |
| Duplikat – vom Nutzer nicht als kanonisch festgelegt | Mehrere URLs mit gleichem Inhalt, kein Canonical-Tag | Canonical setzen oder Varianten per Weiterleitung zusammenführen |
| Alternative Seite mit richtigem kanonischen Tag | Seite verweist per Canonical auf eine andere, Google folgt dem | Alles in Ordnung, sofern das Ziel stimmt |
| Seite mit Weiterleitung | URL leitet weiter | Normal nach Umzügen. Weitergeleitete URLs aus der Sitemap entfernen. |
| Nicht gefunden (404) | Seite existiert nicht mehr | Wenn es Ersatz gibt: weiterleiten. Wenn nicht: aus Sitemap und internen Links entfernen. |
| Soft 404 | Seite antwortet mit 200, wirkt aber leer oder wie eine Fehlerseite | Inhalt ergänzen oder echten 404-Status ausliefern |
Die Meldung „Gecrawlt – zurzeit nicht indexiert“ ist die häufigste und die unbequemste, weil sie kein technisches Problem beschreibt. Google sagt damit: Ich habe die Seite gesehen und finde sie nicht gut genug. Die Antwort darauf ist redaktionell, nicht technisch. Wie Texte aussehen, die Google und Kunden überzeugen, steht im Artikel zu Website-Texten, die verkaufen.
So sieht es bei WordPress, Shopify und Next.js aus
| System | Robots.txt | Sitemap | Typische Stolperfalle |
|---|---|---|---|
| WordPress | Wird automatisch erzeugt; anpassbar über Yoast, Rank Math oder eine echte Datei im Hauptverzeichnis | Seit Version 5.5 unter wp-sitemap.xml eingebaut; mit Yoast unter sitemap_index.xml, dort Beitragstypen und Taxonomien gezielt ein- oder ausschließen | Das Häkchen „Suchmaschinen davon abhalten, diese Website zu indexieren“ aus der Entwicklungsphase nach dem Livegang vergessen |
| Shopify | Automatisch erzeugt und bereits sinnvoll (Warenkorb, Kasse, Suche, Sortierungen gesperrt); anpassbar über die Vorlage robots.txt.liquid | Automatisch unter sitemap.xml mit Untersitemaps für Produkte, Kollektionen, Seiten und Blog; nicht manuell editierbar | Shop mit Passwortschutz vor dem Start: Google sieht nichts, bis der Schutz weg ist; ausgeblendete Produkte bleiben über die URL erreichbar |
| Next.js (App Router) | Datei robots.ts im app-Ordner erzeugt die robots.txt aus Code; alternativ statische Datei im public-Ordner | Datei sitemap.ts im app-Ordner erzeugt die Sitemap aus deinen Inhalten, inklusive Änderungsdatum aus dem CMS | Falsche Basis-URL aus der Testumgebung im Build, sodass die Sitemap auf die falsche Domain zeigt |
Bei Next.js lohnt sich der Blick in den Artikel zu Next.js SEO im App Router, dort steht, wie robots.ts, sitemap.ts und die Metadaten zusammenspielen. Bei WordPress und Shopify ist das Wichtigste, die automatisch erzeugten Dateien einmal anzusehen und in der Search Console gegenzuprüfen, statt sich auf „macht das Plugin“ zu verlassen.
Häufige Fehler, die Sichtbarkeit kosten
- Noindex aus der Testumgebung übernommen. Der häufigste Relaunch-Fehler überhaupt. Deshalb gehört die Prüfung in jede Relaunch-Checkliste.
- Disallow für ganze Ordner, in denen wichtige Seiten liegen. Etwa ein Disallow für /blog/, weil jemand einmal Kommentare aussperren wollte.
- Sitemap zeigt auf die falsche Domain. Nach Umzug oder aus der Staging-Konfiguration.
- Sitemap enthält Weiterleitungen und 404-Seiten. Google meldet Fehler, das Vertrauen in die Sitemap sinkt.
- Widersprüchliche Signale. Seite in der Sitemap, aber per robots.txt gesperrt oder auf noindex.
- CSS und JavaScript gesperrt. Google kann die Seite nicht rendern und bewertet sie als kaputt.
- Lastmod, das immer heute ist. Das Signal wird wertlos.
- Search Console nie geöffnet. Alle oben genannten Fehler wären dort seit Monaten sichtbar gewesen.
Monatliche Routine in zehn Minuten
Einmal im Monat, am besten mit festem Termin:
- Search Console, Bericht „Seiten“: Hat sich die Zahl der indexierten Seiten unerwartet verändert? Neue Gründe unter „Nicht indexiert“?
- Bericht „Sitemaps“: Status weiterhin „Erfolgreich“? Zahl der gefundenen URLs plausibel?
- Stichprobe: Die drei wichtigsten Seiten in der URL-Prüfung ansehen. Indexiert, richtige kanonische URL, Crawling erlaubt?
- Robots.txt im Browser öffnen: Steht dort noch, was dort stehen soll? Ein Update von Theme oder Plugin kann sie verändern.
- Neue Seiten des Monats: In der Sitemap enthalten, intern verlinkt, indexiert?
Wer das dauerhaft im Blick behalten will, findet im Artikel zu Monitoring für SEO und Websites eine Anleitung, wie sich Änderungen automatisch melden lassen.
Nächster Schritt
Wenn du es selbst prüfen willst: Öffne deinedomain.de/robots.txt und deinedomain.de/sitemap.xml im Browser, vergleiche sie mit den Tabellen oben und geh danach den Bericht „Seiten“ in der Search Console durch. In den meisten Fällen findest du in einer halben Stunde entweder Entwarnung oder ein bis zwei konkrete Fehler, die du an deine Agentur weitergeben kannst.
Wenn du lieber einmal systematisch prüfen lassen willst, ob Google deine Website so sieht, wie du sie meinst: Im Rahmen unserer SEO-Betreuung schauen wir Indexierung, Varianten, Canonicals, Sitemap und robots.txt komplett durch, beheben die Fehler und priorisieren danach die Inhalte, die Anfragen bringen. Für Unternehmen aus Magdeburg und deutschlandweit.
