robots.txt & XML-Sitemaps einrichten

Die robots.txt steuert, was gecrawlt werden darf, die XML-Sitemap sagt, welche Seiten es gibt – zwei Dateien mit klar getrennten Aufgaben, die man nicht gegeneinander austauschen kann. Die wichtigste Konsequenz daraus: Disallow verhindert das Crawlen, nicht das Indexieren; wer eine Seite aus dem Index halten will, braucht noindex auf der Seite selbst – und darf sie dann gerade nicht per robots.txt sperren.

Beide Dateien sind winzig, unscheinbar und erstaunlich fehleranfällig. Ein falsch gesetzter Schrägstrich in der robots.txt kann eine komplette Website aus dem Index kippen, und eine Sitemap voller weitergeleiteter URLs untergräbt genau das Vertrauen, das sie eigentlich aufbauen soll. Auf dieser Seite geht es deshalb um die Details, die in kurzen Anleitungen meist fehlen: wie Pfad-Muster wirklich matchen, welche Regel bei Widerspruch gewinnt, was Google an Angaben schlicht ignoriert – und wie sich beide Dateien so erzeugen lassen, dass sie gar nicht erst veralten.

Das Wichtigste in Kürze

• Disallow ≠ noindex. Die häufigste und teuerste Verwechslung im technischen SEO.
• Google kennt genau vier Felder: user-agent, disallow, allow, sitemap. crawl-delay wird ignoriert, noindex in der robots.txt ebenfalls.
• Die längste passende Regel gewinnt – bei Gleichstand die erlaubende.
• Die robots.txt gilt nur für ihren Host, ihr Protokoll und ihren Port.
• Google ignoriert <priority> und <changefreq> in Sitemaps vollständig.
• lastmod wirkt nur, wenn es nachweislich stimmt – gefälschte Daten schaden mehr, als sie nützen.
• Grenzen: robots.txt 500 KiB, Sitemap 50 MB oder 50 000 URLs.

Die robots.txt

Die Datei liegt im Wurzelverzeichnis und steuert das Crawlen. Ein typischer, offener Aufbau:

User-agent: *
Allow: /
Disallow: /suche.html

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

Wo sie liegen muss – und wofür sie gilt

/robots.txt im Wurzelverzeichnis, sonst wird sie ignoriert. Weniger bekannt ist der zweite Teil der Regel: Sie gilt exakt für ihren Host, ihr Protokoll und ihren Port. https://example.de/robots.txt regelt also weder https://www.example.de/ noch http://example.de/ noch https://example.de:8080/. Wer Subdomains betreibt, braucht für jede eine eigene Datei.

Die vier Felder, die Google kennt

Alles andere wird von Google ignoriert – und das betrifft zwei Angaben, die in Beispielen aus dem Netz auffällig oft auftauchen:

• Crawl-delay wertet Google nicht aus. Wenn dein Server unter der Crawl-Last leidet, ist das eine Sache der Server-Konfiguration, nicht der robots.txt.
• Noindex: /pfad/ in der robots.txt ist wirkungslos. Es hat nie zum offiziellen Standard gehört und wird seit 2019 ausdrücklich nicht mehr unterstützt.

Nebenbei: User-agent-Namen werden ohne Rücksicht auf Groß- und Kleinschreibung verglichen, Pfadangaben dagegen mit. /Intern/ und /intern/ sind zwei verschiedene Pfade.

Pfad-Muster: * und $

Google unterstützt zwei Platzhalter, und beide werden regelmäßig missverstanden:

• * steht für null oder mehr beliebige Zeichen.
• $ markiert das Ende der URL.

User-agent: *
Disallow: /*.pdf$          # alle PDFs
Disallow: /*?sort=          # alle Sortier-Parameter
Disallow: /intern/
Allow: /intern/oeffentlich/

Zwei Feinheiten dazu: Ein Platzhalter am Ende eines Pfades ist wirkungslos – /fish* ist identisch mit /fish, weil Pfade ohnehin als Präfix verglichen werden. Und $ bezieht sich auf die ganze URL: /*.php$ trifft /datei.php, aber nicht /datei.php?id=3. Wer Parameter mitsperren will, braucht eine zweite Regel.

Welche Regel gewinnt?

Das ist der Punkt, an dem sich Fehler am hartnäckigsten halten – viele nehmen an, die zuletzt notierte oder die restriktivste Regel setze sich durch. Tatsächlich gilt: Die Regel mit dem längsten passenden Pfad gewinnt. Sind zwei gleich lang und widersprechen sich, gewinnt die erlaubende.

Das ist auch der Grund, warum das Allow-Feld überhaupt existiert: Es erlaubt, aus einem gesperrten Verzeichnis gezielt einzelne Unterbereiche wieder freizugeben.

Grenzen und Fehlerfälle

Ein paar harte Zahlen, die man kennen sollte:

• 500 KiB Maximalgröße; alles darüber wird ignoriert.
• UTF-8, Zeilenumbrüche als CR, LF oder CRLF; ein Byte Order Mark wird überlesen.
• Bis zu 24 Stunden Cache. Eine gerade korrigierte robots.txt wirkt also nicht sofort.
• Statuscodes entscheiden mit:
  • 2xx – Datei wird verwendet.
  • 3xx – bis zu fünf Weiterleitungen werden verfolgt, danach wie 404 behandelt.
  • 4xx (außer 429) – als keine robots.txt gewertet, es wird alles gecrawlt.
  • 5xx – Google stoppt das Crawlen für rund 12 Stunden und greift bis zu 30 Tage auf die zwischengespeicherte Fassung zurück.

Der letzte Punkt ist der unterschätzte: Ein Server, der bei Überlast 503 auf die robots.txt liefert, bremst nicht nur diese eine Datei aus, sondern das Crawlen der ganzen Website.

Randnotiz – Disallow ist nicht Noindex. Das ist die häufigste Verwechslung: Disallow verhindert das Crawlen, nicht zwingend das Indexieren. Eine gesperrte, aber anderweitig verlinkte URL kann trotzdem im Index landen – dann typischerweise ohne Beschreibung, mit dem Hinweis, dass keine Informationen verfügbar sind. Wenn eine Seite nicht erscheinen soll, gehört <meta name="robots" content="noindex"> in den <head> – und die Seite darf dann nicht per robots.txt gesperrt sein, sonst liest der Bot das Noindex nie. Genau deshalb warnt Google auch davor, die robots.txt zur Kanonisierung einzusetzen.

Die XML-Sitemap

Die Sitemap ist eine maschinenlesbare Liste deiner URLs – eine Einladung, alles Wichtige zu finden, besonders bei vielen, neuen oder schlecht verlinkten Seiten. Sie ersetzt keine gute interne Verlinkung, sondern ergänzt sie.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.de/seo-und-ki/robots-txt-und-sitemaps.html</loc>
    <lastmod>2026-07-26</lastmod>
  </url>
</urlset>

Was Google liest – und was nicht

Von den vier möglichen Angaben pro URL nutzt Google zwei:

Dass priority und changefreq wirkungslos sind, ist seit Jahren offiziell – trotzdem generieren viele Plugins sie weiterhin fleißig. Sie schaden nicht, sie tun nur nichts.

Bei lastmod lohnt der genaue Blick, weil hier ein echtes Missverständnis lauert: Google verwendet den Wert nur dann, wenn er über die Website hinweg konsistent und überprüfbar korrekt ist. Als Änderung zählt eine Aktualisierung des Hauptinhalts, der strukturierten Daten oder der Links – nicht ein neues Copyright-Jahr im Footer und schon gar nicht ein nächtlicher Cron-Job, der alle Daten auf „heute“ setzt. Wer das tut, entwertet die Angabe für die gesamte Domain.

Technische Anforderungen

• UTF-8 als Kodierung.
• Absolute URLs mit Protokoll und Host – /seite.html ist ungültig.
• XML-Entities maskieren: & wird zu &, was besonders bei Parameter-URLs zählt.
• Formate: XML ist der Standard; RSS/Atom und eine einfache Textdatei mit einer URL pro Zeile funktionieren ebenfalls, können aber kein lastmod.

Grenzen und der Sitemap-Index

Eine einzelne Sitemap fasst 50 000 URLs oder 50 MB unkomprimiert – je nachdem, was zuerst erreicht wird. Darüber teilst du auf und bündelst die Teildateien in einem 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-0.xml</loc></sitemap>
  <sitemap><loc>https://example.de/sitemap-1.xml</loc></sitemap>
</sitemapindex>

Einreichen

Zwei Wege, die sich ergänzen: der Sitemap:-Verweis in der robots.txt (findet jede Suchmaschine von selbst) und die Einreichung in der Google Search Console. Letztere lohnt sich, weil du dort siehst, wie viele der eingereichten URLs tatsächlich indexiert wurden – die Sitemap wird damit zum Diagnosewerkzeug statt nur zur Liste.

Was in die Sitemap gehört – und was nicht

Die Faustregel: Nur URLs, die du tatsächlich im Index sehen willst. Konkret nicht hinein gehören:

• URLs mit Status 404 oder 410
• weitergeleitete URLs (die Sitemap listet das Ziel, nicht die Weiche)
• Seiten mit noindex
• per robots.txt gesperrte Seiten
• Nicht-kanonische Varianten – die Sitemap ist selbst ein Kanonisierungssignal, wenn auch ein schwaches, und widersprüchliche Einträge schwächen es zusätzlich

Wie diese Website es macht

Beide Dateien entstehen beim Build aus derselben Datenquelle wie die Canonicals – sie können also gar nicht auseinanderlaufen:

• Die robots.txt wird aus einer TypeScript-Route erzeugt. Sie erlaubt allen klassischen Suchmaschinen alles außer der Suchergebnisseite und listet die KI-Crawler namentlich als ausdrücklich willkommen – eine bewusste Entscheidung, die dadurch im Quelltext sichtbar bleibt.
• Die Sitemap wird aus der Content-Sammlung generiert; das lastmod jeder Seite stammt aus dem updatedDate im Frontmatter, nicht aus dem Build-Zeitstempel. Genau das ist die „nachweislich korrekte“ Angabe, die Google verlangt.
• Die Suchseite ist per noindex markiert und aus der Sitemap gefiltert – der Disallow-Eintrag ist hier eine zusätzliche Bequemlichkeit, keine Indexsperre.

Häufige Fehler

• Mit Disallow: / versehentlich die ganze Seite sperren – der klassische Launch-Unfall, wenn die Staging-robots.txt mitwandert.
• Disallow statt Noindex nutzen, um Seiten aus dem Index zu halten.
• noindex-Seite zusätzlich per robots.txt sperren – die Anweisung wird nie gelesen.
• Crawl-delay setzen und glauben, Google halte sich daran.
• $ vergessen bei Dateiendungen – /*.pdf sperrt auch /report.pdf.html.
• robots.txt nicht im Wurzelverzeichnis oder nur auf einer von mehreren Subdomains.
• Sitemap mit gesperrten, weitergeleiteten oder 404-URLs füllen.
• lastmod fälschen – Google ignoriert die Angabe dann für die gesamte Website.
• Relative URLs in der Sitemap – ungültig, wird komplett verworfen.

Häufige Fragen

Brauche ich überhaupt eine robots.txt?

Nicht zwingend – fehlt sie (Status 404), wird alles gecrawlt. Sinnvoll ist sie für den Sitemap-Verweis und um einzelne Bereiche oder Bots gezielt zu steuern. Wichtig ist nur, dass sie entweder korrekt vorhanden ist oder sauber mit 404 antwortet; ein 500er ist der schlechteste aller Zustände.

Wie groß darf eine Sitemap sein?

Bis zu 50 000 URLs beziehungsweise 50 MB unkomprimiert pro Datei. Darüber teilst du auf und bündelst die Teile in einer Sitemap-Index-Datei. Gzip ist erlaubt; das 50-MB-Limit bezieht sich auf die entpackte Größe.

Wird meine Seite ohne Sitemap gefunden?

Ja, über interne und externe Links. Die Sitemap beschleunigt und vervollständigt das Auffinden – ein Sicherheitsnetz, besonders bei neuen, sehr großen oder schlecht verlinkten Websites. Bei einer sauber verlinkten Seite mit 200 URLs ist ihr Effekt gering.

Sollte ich Bilder und Videos in die Sitemap aufnehmen?

Nur wenn sie sonst schwer auffindbar sind – etwa per JavaScript nachgeladene Galerien. Bilder, die normal im HTML stehen, findet der Crawler ohnehin; wichtiger ist dort sauberes Bild-SEO.

Wie schnell wirkt eine Änderung an der robots.txt?

Nicht sofort. Google speichert die Datei bis zu 24 Stunden zwischen. Wer eine versehentliche Komplettsperre entdeckt, korrigiert sie sofort und muss dann trotzdem Geduld haben – ein erneutes Abrufen lässt sich in der Search Console anstoßen.

Fazit

Die robots.txt steuert das Crawlen und verweist auf die Sitemap; die XML-Sitemap listet deine Seiten samt ehrlichem lastmod. Beide sind schnell geschrieben und genauso schnell falsch.

Die drei Sätze, die den meisten Ärger ersparen: Disallow ist nicht Noindex. Die längste passende Regel gewinnt. Und lastmod wirkt nur, solange es stimmt. Wer beide Dateien automatisch aus der Inhaltsquelle erzeugt, hält sie mühelos korrekt – und ergänzt das mit sauberen Canonicals und, für die KI-Sichtbarkeit, einer llms.txt.

Quellen

• Robots.txt-Spezifikation (Google Search Central – unterstützte Felder, Platzhalter, Regel-Vorrang, Größenlimit und Statuscode-Verhalten)
• Sitemap erstellen und einreichen (Google Search Central – Formate, Limits, lastmod-Bedingungen und ignorierte Felder)