robots.txt verstehen: Leitfaden für Website-Betreiber

Die robots.txt ist eine einfache Textdatei, die im Stammverzeichnis Ihrer Domain liegt und Webcrawlern wie Googlebot mitteilt, welche Pfade sie crawlen dürfen. Kein Sicherheitstool, kein Zugriffsschutz. Nur ein Hinweisprotokoll, das kooperative Bots respektieren. Drei Dinge sollten Sie jetzt sofort tun:

Datei prüfen: Rufen Sie https://ihredomain.de/robots.txt direkt im Browser auf. Ist die Datei erreichbar und sinnvoll befüllt?
Kritische Regeln kontrollieren: Steht dort versehentlich Disallow: /? Das sperrt Ihre gesamte Domain für Googlebot.
CSS und JavaScript freigeben: Blockierte Stylesheets und Skripte verhindern, dass Google Ihre Seite korrekt rendert, was das Ranking direkt beeinflussen kann.

Den robots.txt-Tester in der Google Search Console sollten Sie für jeden Test nutzen, bevor Änderungen live gehen.

Wichtige Erkenntnisse

Die robots.txt steuert das Crawling von Webcrawlern, schützt aber keine sensiblen Daten und verhindert allein keine Indexierung.

Thema	Details
Datei im Stammverzeichnis	Die robots.txt muss unter `/robots.txt` liegen, sonst wirkt sie nicht.
Crawling ≠ Indexierung	`Disallow` sperrt den Crawler, nicht den Suchergebnis-Eintrag; für Letzteres brauchen Sie `noindex`.
Kein Sicherheitstool	Die Datei ist öffentlich lesbar; sensible Bereiche brauchen echten Zugriffsschutz.
Testen vor Deployment	Den Google Search Console robots.txt-Tester für jede Regeländerung nutzen, bevor sie live geht.
Einfach-sichtbar	Bietet robots.txt-Audits und technische SEO-Checks für KMU in der Bodenseeregion an.

Inhaltsverzeichnis

Was ist die robots.txt, und wozu dient sie wirklich?
Wo muss die robots.txt liegen, und was passiert bei falscher Platzierung?
Wie ist die robots.txt aufgebaut, und welche Direktiven gibt es?
Praktische Beispiele: robots.txt-Snippets zum direkten Verwenden
Was leistet die robots.txt nicht? Grenzen und häufige Missverständnisse
Wie interpretieren Googlebot, bingbot und andere Crawler die robots.txt?
Schritt für Schritt: robots.txt erstellen, deployen und prüfen
Checkliste: Diese Fehler kosten Sie Rankings
Wie Einfach-sichtbar robots.txt bei Website-Erstellung und Relaunch handhabt
Wann lohnt sich eine robots.txt, und wann reicht die Standardkonfiguration?
Technische SEO für Ihre Website in der Bodenseeregion
Quellen

Was ist die robots.txt, und wozu dient sie wirklich?

Die robots.txt steuert, welche Bereiche Ihrer Website ein Crawler besuchen darf. Nicht mehr. Das klingt simpel, wird aber regelmäßig missverstanden.

Das zugrundeliegende Regelwerk heißt Robots Exclusion Protocol. Es ist kein technischer Standard mit Erzwingungsmechanismus, sondern eine Konvention: Seriöse Crawler wie Googlebot oder bingbot halten sich daran. Bösartige Bots ignorieren die Datei schlicht.

Der entscheidende Unterschied, den viele SEO-Einsteiger übersehen: robots.txt steuert Crawling, nicht Indexierung. Eine Seite, die Sie per Disallow sperren, kann Google trotzdem in den Suchergebnissen anzeigen, wenn externe Links auf sie verweisen. Wer eine Seite aus dem Index entfernen will, braucht dafür einen noindex-Meta-Tag oder einen X-Robots-Tag im HTTP-Header, nicht eine robots.txt-Regel. MDN Web Docs erklärt diesen Unterschied präzise: noindex funktioniert nur, wenn der Bot die Seite überhaupt crawlen kann.

Google Search Central beschreibt die Datei als Hinweisprotokoll, das primär dazu dient, Crawling-Traffic zu steuern und Server nicht unnötig zu belasten.

Wo muss die robots.txt liegen, und was passiert bei falscher Platzierung?

Kurze Antwort: im Stammverzeichnis, nirgendwo sonst.

Die Datei muss unter https://ihredomain.de/robots.txt erreichbar sein. Eine Datei unter /unterverzeichnis/robots.txt wird von keinem Crawler gefunden und hat keinerlei Wirkung. Das klingt offensichtlich, ist aber einer der häufigsten Fehler bei Relaunches.

Wichtige Regeln zur Platzierung:

Jede Subdomain braucht eine eigene Datei. Die robots.txt von www.example.de gilt nicht für shop.example.de. Wer das übersieht, gibt ungewollt Bereiche frei oder sperrt sie.
Pfade auf anderen Hosts werden nicht beeinflusst. Regeln in Ihrer robots.txt wirken nur auf Ihrer eigenen Domain.
Staging-Domains separat absichern. Eine Staging-Umgebung wie staging.example.de sollte eine eigene robots.txt mit Disallow: / haben, damit Testinhalte nicht indexiert werden. Beim Produktiv-Deployment darf diese Datei nicht versehentlich die Produktions-robots.txt überschreiben.
Groß-/Kleinschreibung beachten. Der Dateiname muss exakt robots.txt lauten, alles kleingeschrieben.

Profi-Tipp: Prüfen Sie nach jedem Deployment mit curl -I https://ihredomain.de/robots.txt, ob die Datei einen HTTP-200-Status zurückgibt. Ein 404 bedeutet, dass kein Crawler Ihre Regeln liest.

Wie ist die robots.txt aufgebaut, und welche Direktiven gibt es?

Die Datei ist zeilenbasiert. Jeder Block beginnt mit einer User-agent-Zeile, gefolgt von einer oder mehreren Disallow– oder Allow-Zeilen. Kommentare starten mit #. Eine Leerzeile trennt Blöcke voneinander.

Direktive	Funktion	Crawler-Unterstützung
`User-agent`	Gibt an, für welchen Crawler die Regeln gelten (`*` = alle)	Alle
`Disallow`	Sperrt einen Pfad für den genannten Crawler	Alle
`Allow`	Gibt einen Pfad explizit frei, auch wenn ein übergeordneter Pfad gesperrt ist	Googlebot, bingbot
`Sitemap`	Verweist auf die XML-Sitemap der Website	Googlebot, bingbot
`Crawl-delay`	Gibt eine Wartezeit zwischen Anfragen vor	bingbot (nicht Googlebot)
`Host`	Gibt die bevorzugte Domain an	Selten, nur Yandex

Wildcards und Sonderzeichen verdienen besondere Aufmerksamkeit. Das Sternchen * steht für beliebige Zeichenfolgen. Das Dollarzeichen $ verankert eine Regel am Zeilenende, sodass /seite.pdf$ nur exakt diese URL sperrt, nicht aber /seite.pdf?version=2. Das Fragezeichen ? wird von Googlebot als Literal behandelt, nicht als Wildcard. Nicht alle Crawler interpretieren diese Zeichen gleich.

Zur Dateigröße: Google empfiehlt eine maximale Größe von 500 KiB. Größere Dateien werden möglicherweise nur teilweise geparst. Wer viele Regeln braucht, sollte prüfen, ob sich manche Pfade zusammenfassen lassen.

Praktische Beispiele: robots.txt-Snippets zum direkten Verwenden

Hier sind die häufigsten Anwendungsfälle mit fertigen Codeblöcken.

Alles erlauben (Standard für Produktivseiten):

User-agent: *
Allow: /
Sitemap: https://ihredomain.de/sitemap.xml

Sinnvoll für die meisten öffentlichen Websites. Der Sitemap-Eintrag hilft Crawlern, alle relevanten Seiten zu finden. Cloudflare bestätigt, dass Sitemaps direkt in der robots.txt verlinkt werden können.

Alles sperren (für Staging-Umgebungen):

User-agent: *
Disallow: /

Nur für Entwicklungs- und Testumgebungen. Niemals auf der Produktivdomain einsetzen.

Einzelnes Verzeichnis sperren:

User-agent: *
Disallow: /admin/
Allow: /
Sitemap: https://ihredomain.de/sitemap.xml

Sperrt /admin/ für alle Crawler, gibt den Rest frei. Kein Sicherheitsschutz, da die Datei öffentlich lesbar ist.

PDF-Dateien und Medien ausschließen:

User-agent: *
Disallow: /*.pdf$
Disallow: /wp-content/uploads/
Allow: /

Nützlich, um Crawl-Budget auf Inhaltsseiten zu konzentrieren. Achtung: $ wird nicht von allen Crawlern als Zeilenende-Anker erkannt.

Query-Parameter blockieren:

User-agent: *
Disallow: /*?
Allow: /

Verhindert das Crawlen von URLs mit Parametern. Riskant, wenn wichtige Seiten über Parameter erreichbar sind. Vor dem Einsatz gründlich testen.

Snippets immer zuerst im Google Search Console robots.txt-Tester prüfen, bevor sie live gehen.
Regeln auf Subdomains separat kontrollieren.

Was leistet die robots.txt nicht? Grenzen und häufige Missverständnisse

Die robots.txt ist öffentlich lesbar. Jeder kann https://ihredomain.de/robots.txt aufrufen und sehen, welche Verzeichnisse Sie gesperrt haben. Das macht die Datei zum denkbar schlechtesten Ort, um sensible Bereiche zu verstecken. Wer vertrauliche Inhalte schützen will, braucht Passwortschutz oder serverseitige Zugriffskontrolle, keine robots.txt-Regel.

Wichtig: Eine Seite, die per Disallow gesperrt ist, kann trotzdem in den Suchergebnissen erscheinen, wenn externe Links auf sie zeigen. Google zeigt dann eine URL ohne Seitenbeschreibung an, bekannt als „Indexed, though blocked“. Das ist kein Fehler, sondern das erwartete Verhalten.

Das Zusammenspiel von Disallow und noindex ist eine klassische Falle. Wer eine Seite per Disallow sperrt und gleichzeitig hofft, dass der noindex-Meta-Tag wirkt, irrt: Googlebot kann den Meta-Tag nicht lesen, wenn er die Seite nicht crawlen darf. MDN Web Docs erklärt diesen Mechanismus klar: noindex setzt voraus, dass der Crawler die Seite besucht. Wer eine Seite aus dem Index entfernen will, muss sie crawlbar lassen und stattdessen noindex setzen.

Bösartige Bots und Scraper ignorieren die robots.txt vollständig. Das Protokoll funktioniert nur bei kooperativen Crawlern. Für Sicherheitsmaßnahmen ist es schlicht nicht gedacht.

Wie interpretieren Googlebot, bingbot und andere Crawler die robots.txt?

Nicht alle Crawler lesen die Datei gleich. Das ist in der Praxis relevanter, als viele denken.

Googlebot ignoriert Crawl-delay vollständig. Wer die Crawling-Frequenz für Google drosseln will, muss das in der Google Search Console über die Crawling-Rate-Einstellungen tun. bingbot hingegen respektiert Crawl-delay, was bei stark frequentierten Servern nützlich sein kann.

Per-Bot-Regeln sind möglich und sinnvoll. Statt alle Crawler mit User-agent: * gleich zu behandeln, lassen sich für einzelne Bots separate Blöcke definieren:

User-agent: Googlebot
Disallow: /intern/

User-agent: bingbot
Disallow: /intern/
Crawl-delay: 10

Die offiziellen Dokumentationen von Google Search Central und MDN Web Docs sind die verlässlichsten Quellen für aktuelle Verhaltensregeln. Undokumentierte Direktiven sollten Sie meiden, da deren Unterstützung nicht garantiert ist.

Schritt für Schritt: robots.txt erstellen, deployen und prüfen

Ein strukturierter Ablauf verhindert die meisten Fehler.

Backup anlegen. Sichern Sie die bestehende robots.txt, bevor Sie Änderungen vornehmen. Bei einem Fehler können Sie sofort zurückrollen.
Datei lokal erstellen. Verwenden Sie UTF-8-Kodierung ohne BOM. Zeilenenden sollten Unix-Format (LF) sein, Windows-Zeilenenden (CRLF) können Parsing-Probleme verursachen.
Pfade lokal testen. Prüfen Sie die Syntax manuell oder mit einem lokalen Validator, bevor Sie deployen.
Deployment ins Stammverzeichnis. Die Datei muss unter /robots.txt erreichbar sein, nicht in einem Unterordner.
Google Search Console robots.txt-Tester nutzen. Geben Sie einzelne URLs ein und prüfen Sie, ob Googlebot sie crawlen darf oder nicht. Das Tool zeigt auch, welche Regel greift.
curl-Check durchführen. curl -I https://ihredomain.de/robots.txt bestätigt den HTTP-Status. Ein 200 ist korrekt, alles andere ist ein Problem.
Sitemap und Fetch prüfen. Nach Änderungen an der robots.txt sollten Sie in der Search Console eine erneute Indexierung wichtiger Seiten anstoßen und die Sitemap neu einreichen.

Monitoring nach Änderungen ist kein optionaler Schritt. Beobachten Sie in den Server-Logs, ob wichtige Bots weiterhin 200-Antworten für relevante Pfade erhalten. Ein plötzlicher Rückgang des Crawlings ist ein Warnsignal. SE Ranking beschreibt diesen Monitoring-Ansatz als Teil eines vollständigen robots.txt-Audits.

Beim Rollback gilt: CDN-Caches und Edge-Cacher können eine veraltete robots.txt zwischenspeichern. Nach dem Ersetzen einer fehlerhaften Datei sollten Sie den Cache aktiv leeren, damit Crawler sofort die korrigierte Version sehen.

Checkliste: Diese Fehler kosten Sie Rankings

Vor jedem Deployment lohnt ein kurzer Check dieser Punkte.

Rote Flaggen, die Sie sofort beheben müssen:

Disallow: / in der Produktions-robots.txt: sperrt die gesamte Domain für alle Crawler.
Blockierte CSS- und JavaScript-Dateien: Google kann Ihre Seite dann nicht korrekt rendern, was die Bewertung verschlechtert. MDN Web Docs warnt explizit vor dieser Falle.
Staging-robots.txt auf der Produktivdomain: passiert häufig bei Relaunches, wenn Dateien ohne Prüfung übertragen werden.
Fehlerhafte Wildcard-Regeln: Disallow: /* sperrt alles, Disallow: /*/ nur Pfade mit Schrägstrich. Der Unterschied ist erheblich.
robots.txt in einem Unterverzeichnis statt im Root: wirkt schlicht nicht.
Falsche Zeichenkodierung oder Windows-Zeilenenden: können dazu führen, dass Teile der Datei nicht geparst werden.

Praktische Tests vor dem Deployment:

Testen Sie jede neue Regel im Google Search Console robots.txt-Tester mit konkreten URLs. Prüfen Sie mindestens drei Szenarien: eine Seite, die gecrawlt werden soll, eine, die gesperrt sein soll, und eine CSS- oder JS-Datei. Geben Sie das Ergebnis an Ihr Hosting-Team weiter, damit Dateiberechtigungen und Encoding stimmen.

Wie Einfach-sichtbar robots.txt bei Website-Erstellung und Relaunch handhabt

Der Workflow, den Einfach-sichtbar bei jedem Projekt einsetzt, folgt einem klaren Prinzip: Staging sperren, Produktion freigeben, und die Umschaltung kontrolliert dokumentieren.

Konkret bedeutet das: Jede neue Website startet auf einer Staging-Domain mit Disallow: /. Erst wenn Entwickler, SEO und Hosting-Team gemeinsam grünes Licht geben, wird die Produktions-robots.txt mit den finalen Regeln deployt. Dieser Schritt ist Teil der Relaunch-Checkliste, die sicherstellt, dass keine Testinhalte indexiert werden und keine wichtigen Seiten versehentlich gesperrt bleiben.

Profi-Tipp: Wenn Ihre Website hinter einem CDN wie Cloudflare läuft, kann der Edge-Cache eine veraltete robots.txt ausliefern, selbst nachdem Sie die Datei auf dem Server aktualisiert haben. Leeren Sie den Cache nach jeder Änderung aktiv, und prüfen Sie mit curl direkt am Origin-Server, ob die neue Version angekommen ist.

Hosting-Aspekte spielen ebenfalls eine Rolle: Dateiberechtigungen müssen so gesetzt sein, dass der Webserver die robots.txt ausliefern kann (typischerweise 644). Ein falsch gesetztes Recht führt zu einem 403-Fehler, den Googlebot als „nicht erreichbar“ wertet.

Zum Datenschutz: Die robots.txt ist kein Mittel zum Schutz personenbezogener Daten. Wer DSGVO-konform arbeiten will, muss sensible Bereiche mit echtem Zugriffsschutz absichern, nicht mit einer robots.txt-Regel. Mehr dazu, wie Datenschutz auf Ihrer Website technisch korrekt umgesetzt wird, erklärt der DSGVO-Guide zur Datenschutzerklärung.

Wann lohnt sich eine robots.txt, und wann reicht die Standardkonfiguration?

Kleine, statische Websites mit wenigen Seiten brauchen selten komplexe robots.txt-Regeln. Eine einfache Datei, die alles erlaubt und die Sitemap verlinkt, ist für die meisten lokalen Unternehmensseiten vollkommen ausreichend. Der Aufwand für ausgefeilte Regeln steht dort in keinem Verhältnis zum Nutzen.

Anders sieht es bei Online-Shops, Portalen mit vielen dynamischen Parametern oder Websites mit umfangreichen Medienarchiven aus. Dort kann eine durchdachte robots.txt das Crawl-Budget gezielt auf relevante Seiten lenken und verhindern, dass Googlebot Zeit mit Filterseiten, Druckversionen oder internen Suchergebnissen verschwendet. Wer Hunderte von URL-Varianten durch Parameter erzeugt, sollte robots.txt und Sitemaps aktiv verwalten.

Externe Unterstützung lohnt sich bei Relaunches, wenn sich die URL-Struktur ändert, bei CDN-Setups mit komplexem Caching-Verhalten und bei Websites, die nach einer Migration plötzlich weniger gecrawlt werden. Das sind die Situationen, in denen ein Fehler in der robots.txt schnell zu messbaren Ranking-Verlusten führt.

Technische SEO für Ihre Website in der Bodenseeregion

Wer eine Website neu aufbaut oder einen Relaunch plant, hat mit der robots.txt eine der wenigen technischen Stellschrauben, die direkt das Crawling-Verhalten von Google beeinflusst. Falsch konfiguriert, kostet sie Rankings. Richtig eingesetzt, schont sie Serverressourcen und lenkt Googlebot auf die Seiten, die zählen.

Einfach-sichtbar übernimmt für kleine und mittlere Unternehmen in Konstanz und der Bodenseeregion genau diesen Teil: robots.txt-Audit, technische SEO-Checks beim Relaunch und Monitoring-Setup, damit nach dem Go-live keine bösen Überraschungen warten. Kein generisches Paket, sondern ein Blick auf Ihre konkrete Domain, Ihre Verzeichnisstruktur und Ihre Hosting-Umgebung. Nehmen Sie jetzt Kontakt auf und lassen Sie Ihre robots.txt von Einfach-sichtbar prüfen: Webdesign & SEO Konstanz.

Quellen

Offizielle Dokumentation und Testwerkzeuge, die Sie direkt nutzen können: