robots.txt

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

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

Diese Datei ist der Türsteher deiner 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 deine gesamte Website für Suchmaschinen unsichtbar machen. Umgekehrt kann eine fehlende Konfiguration dazu führen, dass dein 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 du typische WordPress-Fallen vermeidest und welche Regeln wirklich sinnvoll sind. Wir schauen uns an, wie du sicherstellst, dass Google genau das crawlt, was du willst – 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 deine 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 du eine Seite aus dem Google-Index entfernen willst, 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 du eine Seite per robots.txt sperrst, kann Google den noindex-Tag auf dieser Seite nicht lesen. Du erinnerst dich: Der Bot darf ja nicht „rein“. Er sieht also nicht, dass du im HTML-Code <meta name="robots" content="noindex"> hinterlegt hast.

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

Wenn du also willst, dass Google Inhalte wirklich versteht oder eben nicht indexiert, musst du den Unterschied zwischen Crawling und Indexierung verinnerlicht haben. Nur so setzt du die richtigen Hebel in Bewegung.

Lies 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. Du musst kein Programmierer sein, um das zu verstehen.

Hier sind die drei wichtigsten Befehle, die du kennen musst:

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 deine XML-Sitemap? (Optional, aber sehr empfohlen).

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

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

In den meisten Fällen willst du, dass Suchmaschinen deine Inhalte finden. Du möchtest 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://deine-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 hast du 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, du definierst 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 verhinderst du, dass Bots sich im Suchlabyrinth verlieren. Aber Achtung: Prüfe vorher genau, ob deine interne Suche wirklich diese URL-Muster nutzt.

Was du nicht tun solltest: Versuchen, über komplexe Regex-Regeln das „Crawl Budget“ mikrozumanagen, wenn deine 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 du unbedingt prüfen solltest.

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: „Hau ab!“ 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 deine Seite wie ein moderner Browser. Dazu braucht der Bot Zugriff auf CSS-Dateien (für das Layout) und JavaScript (für Funktionen).

Wenn du /wp-content/ sperrst, sieht Google deine Seite „kaputt“ – ohne Design, vielleicht nicht mobilfreundlich. Da „Mobile Friendliness“ ein Rankingfaktor ist, kann das deine Positionen direkt negativ beeinflussen.
Faustregel: Blockiere 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 wolltest du nur den Ordner /private/ sperren (mit Slash am Ende). Ohne den Slash am Ende sperrst du alles, was mit diesem Wort beginnt. Solche Tippfehler können ganze Kategorien unsichtbar machen, ohne dass du es sofort merkst.

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 (deinedomain.de/robots.txt). Wenn du dort geheime Pfade einträgst (Disallow: /geheimes-projekt-b/), präsentierst du sie neugierigen Blicken oder Hackern quasi auf dem Silbertablett. Schütze solche Bereiche per Passwort (Server-seitig), nicht per robots.txt.

5. Mehrere Versionen oder Protokolle

Die robots.txt muss exakt im Hauptverzeichnis (Root) liegen.
deinedomain.de/robots.txt ist gültig.
deinedomain.de/shop/robots.txt wird von Google ignoriert (außer für Subdomains, aber das ist ein anderes Thema).
Prüfe auch, ob deine 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, musst du dein Ziel kennen. Wenn du das falsche Werkzeug nimmst, erreichst du oft das Gegenteil von dem, was du willst.

Wir unterscheiden drei klassische Szenarien:

1. Szenario A: „Die Seite soll nicht in den Google-Index.“
   • Dein Ziel: Die Seite existiert für Nutzer (z.B. Impressum, Danke-Seite), soll aber nicht in der Suche auftauchen.
   • Lösung: Nutze 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.“
   • Dein Ziel: Du hast das gleiche Produkt in drei Kategorien und willst Duplicate Content vermeiden.
   • Lösung: Nutze das canonical-Tag.
   • Warum: Du sagst Google: „Ich weiß, das ist doppelt, bitte bewerte 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.“
   • Dein Ziel: Crawl-Effizienz.
   • Lösung: Nutze 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:
Du hast eine PDF-Datei „AGB-2020.pdf“, die nicht mehr in der Suche auftauchen soll. Da du in ein PDF kein HTML-Tag (noindex) schreiben kannst, 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)

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

Checkliste vor dem Release (Live-Gang):

1. Staging-Regeln entfernt? Prüfe, 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? Teste 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, solltest du 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?

Dokumentiere deine Änderungen. Wenn in zwei Wochen Rankings einbrechen, willst du wissen, ob es an der robots.txt lag, die du heute bearbeitet hast.

FAQ: Häufige Fragen zur 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. Konzentriere dich lieber auf gute Inhalte und saubere interne Links. Erst bei sehr großen Shops wird die robots.txt zum wichtigen Performance-Tool.

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.

Vermeide Überoptimierung. Nutze 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 du dir unsicher bist, ob deine aktuelle Datei Google blockiert oder unnötig offen ist, schau genau hin.

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