Wie diese Prüfung funktioniert
Scanaris lädt deine /robots.txt herunter und prüft zuerst, dass es eine echte robots-Datei ist: Sie antwortet mit 200, ist kein HTML und enthält mindestens eine Direktive (User-agent, Disallow, Allow oder Sitemap). Dann geht er jede Disallow:-Zeile durch und schaut, ob der Pfad einen dieser Indikatoren enthält: wp-admin, phpmyadmin, /admin, backup, .git, .env, /private, /secret, dump, .sql, password oder credential. Trifft einer zu, öffnet er einen Befund mit niedrigem Schweregrad und den gefundenen Pfaden. Die Liste ist absichtlich kurz: Wörter wie test, old, tmp oder logs stehen in völlig legitimen robots-Dateien und erzeugten Fehlalarme.
Warum das wichtig ist
robots.txt ist per Definition öffentlich: Jeder kann sie lesen, und tatsächlich ist sie eine der ersten Dateien, die ein Aufklärungswerkzeug anschaut. Wenn du Disallow: /backups/ oder Disallow: /alter-admin/ schreibst, versteckst du diese Pfade nicht; du zeigst sie demjenigen, der sie sucht, mit der zusätzlichen Garantie, dass sie dir wichtig sind. Google wird sie nicht crawlen, aber ein Angreifer liest robots nicht, um ihr zu gehorchen, sondern um zu wissen, wohin er gehen soll. Es ist ein Befund mit niedrigem Schweregrad, weil ein gelisteter Pfad nicht automatisch erreichbar ist; das Problem entsteht, wenn der gelistete Pfad außerdem ungeschützt ist.
So behebst du es
- Entferne aus robots.txt die Pfade, die du nicht ankündigen willst. Wenn Google einen privaten Bereich nicht indexieren soll, ist der richtige Weg, dass dieser Bereich einen Login verlangt; was hinter einer Authentifizierung liegt, wird ohnehin nicht indexiert.
- Wenn eine erreichbare Seite aus den Suchmaschinen bleiben soll, ohne sie anzukündigen, nutze den Header
X-Robots-Tag: noindexoder dasrobots-Meta auf dieser Seite. Suchmaschinen respektieren das, und es steht in keiner öffentlichen Datei. - Schütze den Pfad wirklich. Ein Panel unter
/adminbraucht Authentifizierung, keine Zeile in robots. Ein Ordner/backups/sollte gar nicht im öffentlichen Verzeichnis liegen; die Prüfungen sensible Dateien und Verzeichnisauflistung decken diese Fälle ab. - WordPress: Die virtuelle robots, die es erzeugt, enthält standardmäßig
Disallow: /wp-admin/. Das ist nicht schlimm, weilwp-adminbereits einen Login verlangt undnoindexsendet; du kannst es lassen oder robots durch eine eigene Datei ohne diese Zeile ersetzen. Wichtig ist, dass der Login starke Passwörter, ein Versuchslimit und, wenn möglich, einen zweiten Faktor hat.
Eine gesunde robots.txt ist meist kurz: ein User-agent: *, vielleicht ein paar Disallow für die interne Suche oder Parameter, und die Zeile Sitemap:. Hat deine zwanzig Zeilen „privater" Pfade, erledigt sie die Arbeit eines Berechtigungssystems, und zwar schlecht.
Prüf, ob es behoben ist
curl -s https://deinedomain.de/robots.txt | grep -iE "^disallow:.*(admin|phpmyadmin|backup|\.git|\.env|private|secret|dump|\.sql|password|credential)"Es darf nichts herauskommen. Und für jeden entfernten Pfad prüfst du, dass er wirklich eine Authentifizierung verlangt oder 404 zurückgibt:
curl -s -o /dev/null -w "%{http_code}\n" https://deinedomain.de/admin/Häufige Fragen
Wenn ich /admin aus robots.txt entferne, indexiert Google es dann?
Wenn /admin einen Login verlangt, sieht Google nur den Anmeldebildschirm, und der trägt normalerweise noindex. Verlangt es keinen Login, ist das Problem nicht die Indexierung, sondern dass dein Panel offen ist.
Kann ich alles sperren und nur das Öffentliche auflisten?
Für eine Seite, die organischen Traffic will, nein: Alles mit Disallow: / zu sperren wirft sie aus den Suchmaschinen. Wenn du das Crawling steuern willst, stellt die Prüfung robots und Sitemap sicher, dass du dich nicht selbst aussperrst.
Und die KI-Bots?
GPTBot, ClaudeBot und Co. zu sperren oder zuzulassen ist eine eigene Geschäftsentscheidung und gehört in dieselbe Datei. Mit dieser Prüfung hat das nichts zu tun; sie schaut nur auf sensible Pfade.