robots.txt

Sie haben gerade einen neuen Blogartikel veröffentlicht oder eine wichtige Landingpage gelauncht. Voller Erwartung checken Sie die Google-Suche, aber nichts passiert. Die Seite taucht einfach nicht auf. Oder vielleicht haben Sie das gegenteilige Problem: Der Googlebot durchwühlt unermüdlich unwichtige Archivseiten Ihres Shops und ignoriert dabei Ihre neuen Produkte.

In vielen Fällen liegt die Ursache in einer kleinen, oft übersehenen Textdatei im Hauptverzeichnis Ihrer Website: der robots.txt.

Diese Datei ist der Türsteher Ihrer Website. Sie entscheidet, wer herein darf und wer draußen bleiben muss. Doch viele Website-Betreiber behandeln sie stiefmütterlich oder kopieren blind Regeln aus dem Netz, ohne die Konsequenzen zu verstehen. Das ist riskant. Eine einzige falsche Zeile kann Ihre gesamte Website für Suchmaschinen unsichtbar machen. Umgekehrt kann eine fehlende Konfiguration dazu führen, dass Ihr Server unter der Last unnötiger Bot-Anfragen ächzt.

In diesem Artikel klären wir ein für alle Mal, was die robots.txt wirklich tut (und was nicht), wie Sie typische WordPress-Fallen vermeiden und welche Regeln wirklich sinnvoll sind. Wir schauen uns an, wie Sie sicherstellen, dass Google genau das crawlt, was Sie wollen – und den Rest ignoriert.

Was ist robots.txt (und was macht sie nicht)?

Bevor wir in die Befehle eintauchen, müssen wir ein fundamentales Missverständnis ausräumen, das sich hartnäckig in der SEO-Welt hält und oft zu falschen Entscheidungen führt.

Die robots.txt steuert das Crawling, nicht die Indexierung.

Was bedeutet das genau? Wenn der Googlebot auf Ihre Seite kommt, klingelt er zuerst an der Tür und fragt: „Darf ich hier rein?“ Die robots.txt gibt die Antwort. Wenn sie „Nein“ sagt (Disallow), betritt der Bot den Raum (die URL) nicht. Er liest den Inhalt nicht, er sieht die Bilder nicht und er findet keine neuen Links auf dieser Seite.

Aber – und das ist das große Aber – Google kann die URL trotzdem in den Index aufnehmen.

Wie ist das möglich? Wenn viele externe Websites auf diese gesperrte URL verlinken, weiß Google: „Aha, unter dieser Adresse gibt es etwas Wichtiges.“ Google nimmt die URL dann in die Suchergebnisse auf. Da der Bot den Inhalt aber nie lesen durfte, fehlt ihm der Text für die Beschreibung (Snippet).

Das sieht dann in den Suchergebnissen oft so aus:

Für diese Seite sind keine Informationen verfügbar.

Warum robots.txt keine „Löschung“ ist

Wenn Sie eine Seite aus dem Google-Index entfernen wollen, ist die robots.txt das falsche Werkzeug . Das ist einer der häufigsten Fehler, den wir sehen: Jemand möchte eine Seite aus der Suche entfernen und blockiert sie in der robots.txt.

Das Problem dabei: Wenn Sie eine Seite per robots.txt sperren, kann Google den noindex-Tag auf dieser Seite nicht lesen. Sie erinnern sich: Der Bot darf ja nicht „rein“. Er sieht also nicht, dass Sie im HTML-Code <meta name="robots" content="noindex"> hinterlegt haben.

Das Ergebnis: Sie sperren die Seite aus, aber sie geistert als inhaltsleeres Zombie-Ergebnis weiter durch den Index. Das sieht unprofessionell aus und hilft niemandem.

Wenn Sie also wollen, dass Google Inhalte wirklich versteht oder eben nicht indexiert, müssen Sie den Unterschied zwischen Crawling und Indexierung verinnerlicht haben. Nur so setzen Sie die richtigen Hebel in Bewegung.

Lesen Sie hierzu mehr: Crawling vs. Indexierung: Wo liegt der Unterschied?

Grundstruktur (User-agent, Disallow, Allow) – 3 sichere Beispiele

Die Syntax der robots.txt ist eigentlich simpel. Sie besteht aus Gruppen von Anweisungen, die sich an bestimmte Bots (User-agents) richten. Sie müssen kein Programmierer sein, um das zu verstehen.

Hier sind die drei wichtigsten Befehle, die Sie kennen müssen:

1. User-agent: An wen richtet sich die Regel? (* steht für alle Bots, Googlebot speziell für Google).
2. Disallow: Dieser Pfad darf nicht gecrawlt werden.
3. Allow: Dieser Pfad darf gecrawlt werden (nützlich, um Unterordner in einem gesperrten Verzeichnis explizit freizugeben).
4. Sitemap: Wo liegt Ihre XML-Sitemap? (Optional, aber sehr empfohlen).

Wir setzen auf Minimalismus. Je komplexer Ihre Datei, desto höher die Wahrscheinlichkeit für Fehler. Hier sind drei sichere Muster für den Alltag, mit denen Sie wenig falsch machen können.

Beispiel 1: Das „Standard“-Setup (Sicher für fast alle)

In den meisten Fällen wollen Sie, dass Suchmaschinen Ihre Inhalte finden. Sie möchten lediglich den Admin-Bereich schützen, um keine unnötigen Crawl-Ressourcen zu verschwenden.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://ihre-domain.de/sitemap_index.xml

Hinweis: Bei WordPress ist admin-ajax.php wichtig für manche Frontend-Funktionen, daher erlauben wir diesen spezifischen Pfad explizit wieder, auch wenn /wp-admin/ gesperrt ist.

Beispiel 2: Gezielt Bereiche sperren (Vorsicht!)

Vielleicht haben Sie einen Ordner /temp/, in dem nur Testdateien liegen, oder /downloads/, die Google nicht dauernd scannen soll.

User-agent: *
Disallow: /wp-admin/
Disallow: /temp/
Disallow: /downloads/

Wichtig zu wissen: Alles, was unter /temp/ liegt, wird blockiert. Auch /temp/wichtiges-bild.jpg oder /temp/unterordner/. Der Bot macht hier keine Ausnahmen, es sei denn, Sie definieren ein Allow.

Beispiel 3: Interne Suche blockieren (Best Practice)

Suchergebnisseiten (URLs wie /?s=suchbegriff) sind meist qualitativ minderwertig für den Index. Das nennt man „Thin Content“. Außerdem können Bots hier in endlose Schleifen geraten, wenn sie immer neuen Suchbegriffen folgen. Das verschwendet Crawl-Budget.

User-agent: *
Disallow: /?s=
Disallow: /search/

Damit verhindern Sie, dass Bots sich im Suchlabyrinth verlieren. Aber Achtung: Prüfen Sie vorher genau, ob Ihre interne Suche wirklich diese URL-Muster nutzt.

Was Sie nicht tun sollten: Versuchen, über komplexe Regex-Regeln das „Crawl Budget“ mikrozumanagen, wenn Ihre Seite kleiner als 10.000 URLs ist. Das Risiko, versehentlich wichtige Inhalte zu blockieren, ist viel größer als der Nutzen. Keep it simple.

Die 5 häufigsten Fehler (WordPress/Release)

In unserer Arbeit sehen wir immer wieder die gleichen Fehler, die Rankings zerstören oder Relaunches zum Albtraum machen. Es sind oft kleine Unachtsamkeiten mit großer Wirkung. Hier sind die Top 5, die Sie unbedingt prüfen sollten.

1. Der „Staging“-Unfall

Wenn Entwickler eine neue Website auf einer Testumgebung (Staging) bauen, sperren sie diese oft komplett, damit Google die Baustelle nicht vorzeitig indexiert. Das sieht so aus:

User-agent: *
Disallow: /

Der Slash / bedeutet: Alles ab der Wurzel ist verboten.
Der Fehler: Beim Live-Gang wird oft vergessen, diese Datei zu aktualisieren. Die neue Seite geht live – und sagt Google sofort an der Tür: „Zutritt verboten!“ Das führt zu einem massiven Einbruch der Sichtbarkeit innerhalb weniger Tage. Wir haben schon gesehen, wie Unternehmen dadurch Monate an SEO-Arbeit verloren haben, weil Google die Seiten aus dem Index geworfen hat.

2. Blockierte Ressourcen (CSS/JS)

Früher (vor 2015) war es üblich, Ordner wie /wp-content/ oder /wp-includes/ zu sperren. Man dachte: „Google braucht ja nur den Text.“
Heute rendert Google Ihre Seite wie ein moderner Browser. Dazu braucht der Bot Zugriff auf CSS-Dateien (für das Layout) und JavaScript (für Funktionen).

Wenn Sie /wp-content/ sperren, sieht Google Ihre Seite „kaputt“ – ohne Design, vielleicht nicht mobilfreundlich. Da „Mobile Friendliness“ ein Rankingfaktor ist, kann das Ihre Positionen direkt negativ beeinflussen.
Faustregel: Blockieren Sie niemals Ordner, die Skripte, Stile oder Bilder enthalten, die für die Darstellung der Seite nötig sind.

Mehr dazu: JavaScript SEO: Rendering-Probleme erkennen

3. Zu breite Wildcards

Ein Sternchen * ist mächtig, aber gefährlich.
Ein Eintrag wie Disallow: /private sperrt nicht nur den Ordner /private/. Er sperrt auch /private-fotos, /privatsphaere und /privater-blogbeitrag.
Vielleicht wollten Sie nur den Ordner /private/ sperren (mit Slash am Ende). Ohne den Slash am Ende sperren Sie alles, was mit diesem Wort beginnt. Solche Tippfehler können ganze Kategorien unsichtbar machen, ohne dass Sie es sofort merken.

4. Admin-Bereich falsch verstanden

Viele sperren /wp-admin/. Das ist völlig okay. Aber manche versuchen, Login-Seiten wie /wp-login.php über die robots.txt zu „sichern“.
Die robots.txt ist kein Sicherheitsfeature . Jeder kann sie lesen (ihredomain.de/robots.txt). Wenn Sie dort geheime Pfade eintragen (Disallow: /geheimes-projekt-b/), präsentieren Sie sie neugierigen Blicken oder Hackern quasi auf dem Silbertablett. Schützen Sie solche Bereiche per Passwort (Server-seitig), nicht per robots.txt.

5. Mehrere Versionen oder Protokolle

Die robots.txt muss exakt im Hauptverzeichnis (Root) liegen.
ihredomain.de/robots.txt ist gültig.
ihredomain.de/shop/robots.txt wird von Google ignoriert (außer für Subdomains, aber das ist ein anderes Thema).
Prüfen Sie auch, ob Ihre http und https Versionen sauber weiterleiten, damit Google immer die korrekte Datei findet und nicht versehentlich eine alte Version auf dem unverschlüsselten Protokoll liest.

robots.txt vs Noindex vs Canonical (Entscheidungshilfe)

Hier herrscht oft das größte Chaos. Wann nutze ich was? Um das richtige Instrument zu wählen, müssen Sie Ihr Ziel kennen. Wenn Sie das falsche Werkzeug nehmen, erreichen Sie oft das Gegenteil von dem, was Sie wollen.

Wir unterscheiden drei klassische Szenarien:

1. Szenario A: „Die Seite soll nicht in den Google-Index.“

• Ihr Ziel: Die Seite existiert für Nutzer (z.B. Impressum, Danke-Seite), soll aber nicht in der Suche auftauchen.
• Lösung: Nutzen Sie noindex (Meta-Tag).
• Warum: Das ist das klare Signal „Nicht aufnehmen“. Damit Google das sieht, darf die Seite nicht in der robots.txt gesperrt sein!
• Siehe: Noindex und Nofollow

2. Szenario B: „Die Seite ist ein Duplikat, das Original liegt woanders.“

• Ihr Ziel: Sie haben das gleiche Produkt in drei Kategorien und wollen Duplicate Content vermeiden.
• Lösung: Nutzen Sie das canonical-Tag.
• Warum: Sie sagen Google: „Ich weiß, das ist doppelt, bitte bewerten Sie die andere URL als das Original.“ Auch hier: Die Seite muss crawlbbar bleiben, damit Google das Tag lesen kann.
• Siehe: Canonical Tag

3. Szenario C: „Der Bot verschwendet Zeit auf tausenden unwichtigen URLs.“

• Ihr Ziel: Crawl-Effizienz.
• Lösung: Nutzen Sie die robots.txt.
• Beispiel: Faceted Navigation in Shops (Filter wie ?preis=10-20&farbe=rot&groesse=m…). Hier entstehen Millionen URLs ohne Mehrwert. Ein Disallow: /*?preis= spart Crawl-Ressourcen.
• Warnung: Diese Seiten können als leere Hüllen im Index bleiben, wenn sie von außen verlinkt sind. Aber das Crawling wird gestoppt, was bei großen Shops wichtig ist.
• Siehe: Faceted Navigation

Mini-Beispiel:
Sie haben eine PDF-Datei „AGB-2020.pdf“, die nicht mehr in der Suche auftauchen soll. Da Sie in ein PDF kein HTML-Tag (noindex) schreiben können, hilft hier der X-Robots-Tag im HTTP-Header (Server-Config) – oder notfalls die robots.txt (Disallow). Bei Dateien ist Disallow oft akzeptabel, auch wenn das Risiko des „Zombie-Ergebnisses“ bleibt. Die sauberste Lösung für Dateien ist der X-Robots-Tag.

Quickcheck & Prozess (nach Änderungen)

Ändern Sie niemals „einfach mal so“ die robots.txt. Ein kleiner Fehler hier wirkt global auf Ihre ganze Seite. Wir empfehlen Ihnen dringend, einen QA-Prozess (Quality Assurance) zu etablieren, besonders wenn Sie mit Agenturen oder Freelancern arbeiten.

Checkliste vor dem Release (Live-Gang):

1. Staging-Regeln entfernt? Prüfen Sie, ob das tödliche Disallow: / wirklich gelöscht wurde.
2. Sitemap verlinkt? Ist die URL zur XML-Sitemap aktuell und korrekt eingetragen?
3. Wichtige Pfade frei? Testen Sie stichprobenartig wichtige URLs (Produktseiten, Kategorien) mit einem Tool wie dem „Robots.txt Tester“ in der Google Search Console.
4. Assets frei? Sind CSS-, JS- und Bilder-Ordner für den Bot zugänglich?

Nach dem Release testen & Monitoren

Nachdem die Änderung live ist, sollten Sie in den nächsten Tagen die Google Search Console im Auge behalten.

• Gibt es plötzliche Warnungen im Bereich „Indexierung“?
• Sinkt die Anzahl der gecrawlten Seiten im Statistik-Bericht drastisch?
• Meldet Google blockierte Ressourcen beim URL-Prüfung-Tool?

Dokumentieren Sie Ihre Änderungen. Wenn in zwei Wochen Rankings einbrechen, wollen Sie wissen, ob es an der robots.txt lag, die Sie heute bearbeitet haben.

---

Fazit: Weniger ist mehr

Die robots.txt ist ein mächtiges Werkzeug, aber sie erfordert Respekt. Die Kunst liegt oft nicht darin, möglichst viele clevere Regeln zu schreiben, sondern die Datei so schlank und fehlerfrei wie möglich zu halten.

Vermeiden Sie Überoptimierung. Nutzen Sie sie, um technische Bereiche (Admin) zu schützen und Crawl-Fallen (Interne Suche) zu vermeiden. Für alles andere – Indexierungssteuerung und Duplikate – gibt es bessere Werkzeuge wie noindex und Canonicals.

Wenn Sie sich unsicher sind, ob Ihre aktuelle Datei Google blockiert oder unnötig offen ist, schauen Sie genau hin.

robots.txt Review + Fixliste: Wir prüfen Ihre Konfiguration auf Herz und Nieren und sorgen für einen reibungslosen Release-Prozess.

Häufige Fragen zu robots.txt

Kann Google meine Seite trotz Disallow indexieren?

Ja, absolut. Wenn starke Links von außen auf die Seite zeigen, indexiert Google die URL oft trotzdem – nur eben ohne Inhalt.

Wo gehört die Sitemap hin?

Der Verweis auf die Sitemap (Sitemap: https://...) kann theoretisch überall in der Datei stehen. Best Practice ist es aber, ihn ganz ans Ende der Datei zu setzen, damit er übersichtlich bleibt.

Soll ich mein Crawl Budget über die robots.txt optimieren?

Für kleine und mittlere Seiten (unter 10.000 URLs) ist Crawl Budget selten ein Problem. Hier richtet man mit komplexen Regeln oft mehr Schaden an als Nutzen. Konzentrieren Sie sich lieber auf gute Inhalte und saubere interne Links. Erst bei sehr großen Shops wird die robots.txt zum wichtigen Performance-Tool.