So prüfen Sie robots.txt auf blockierte Seiten

Wo robots.txt liegen muss

Sie muss an der Wurzel des Hosts liegen, als /robots.txt, in reinem UTF-8-Text. Sie gilt für genau ein Schema, einen Host und einen Port, https://example.com/robots.txt regelt also nichts auf https://shop.example.com und nichts auf der http-Version desselben Hosts. Jede Subdomain, die Sie steuern wollen, braucht ihre eigene Datei.

Der Statuscode, den die Datei zurückgibt, ist ebenso wichtig wie ihr Inhalt. Ein 404 wird als "keine Einschränkungen, alles crawlen" gelesen, was ein vollkommen gültiger Zustand ist. Ein wiederholter 5xx wird als vorübergehender Fehler gelesen, und Google pausiert das Crawlen des Hosts möglicherweise, statt anzunehmen, es dürfe weitermachen. Ein 403 verhält sich für diesen Zweck wie ein Serverfehler. Ist robots.txt unzuverlässig, wird das Crawlen mit ihr unzuverlässig.

Die Syntax, in fünf Zeilen

User-agent: *
Disallow: /admin/
Allow: /admin/public-page.html
Disallow: /*?sessionid=
Sitemap: https://example.com/sitemap.xml

User-agent eröffnet eine Gruppe. Disallow sperrt ein Pfadpräfix, Allow schneidet eine Ausnahme aus einer Sperre heraus, * passt auf eine beliebige Zeichenfolge und $ verankert das Ende einer URL. Sitemap ist unabhängig von jeder Gruppe und nimmt eine absolute URL. Das Format ist als RFC 9309 standardisiert, das hier beschriebene Verhalten ist also nicht herstellerspezifisch.

Zwei Auflösungsregeln entscheiden, was tatsächlich passiert. Ein Crawler nutzt nur die spezifischste Gruppe, die ihn namentlich nennt, und ignoriert die *-Gruppe vollständig, sobald ihn eine Gruppe direkt nennt. Innerhalb dieser Gruppe gewinnt die am längsten passende Regel, und bei Gleichstand gewinnt Allow.

Die Fehler, die eine ganze Website blockieren

• Ein von einem Staging-Deployment übrig gebliebenes Disallow: /. Ein Zeichen, die ganze Website blockiert. Es gelangt genau so in die Produktion wie ein Staging-noindex: eine Konfigurationsdatei, die mit einem Release befördert wird.
• CSS und JavaScript blockieren. Google rendert Seiten, ein blockiertes Asset-Verzeichnis kann eine Seite für den Crawler also kaputt aussehen lassen, obwohl sie für Sie gut aussieht.
• Erwarten, dass robots.txt eine Seite aus der Suche entfernt. Das kann sie nicht. Eine blockierte URL kann weiterhin über externe Links gelistet werden, meist ohne Snippet, und weil der Crawler sie nicht abrufen kann, wird ein noindex auf dieser Seite nie gesehen. Um eine Seite zu entfernen, erlauben Sie das Crawlen und liefern Sie noindex aus.
• noindex: als Anweisung innerhalb von robots.txt verwenden. Das war nie Teil des Standards, und Google hat am 1. September 2019 aufgehört, es zu berücksichtigen. Es wird heute stillschweigend ignoriert.
• Eine Gruppe für einen namentlich genannten Bot hinzufügen und erwarten, dass die Wildcard-Regeln weiterhin gelten. Das tun sie nicht. Sobald User-agent: Googlebot existiert, liest Googlebot nur diese Gruppe und sonst nichts, jede geteilte Regel muss also darin wiederholt werden.
• Eine leere Zeile innerhalb einer Gruppe. Eine leere Zeile beendet die Gruppe, die Regeln danach gehören also zu nichts, bis zur nächsten User-agent-Zeile.
• Private Pfade auflisten. Die Datei ist öffentlich. /internal-admin/ darin zu nennen veröffentlicht den Ort des Dings, das Sie zu verstecken versuchen.

So testen Sie einen einzelnen Pfad

Rufen Sie die Datei ab und lesen Sie zuerst die für Sie geltende Gruppe:

curl -s https://example.com/robots.txt

Wenden Sie dann die Längste-Übereinstimmung-Regel von Hand auf den fraglichen Pfad an. Mit Disallow: /blog/ und Allow: /blog/public/ ist die URL /blog/public/post erlaubt, weil die passende Allow-Regel länger ist. Für eine Ihnen gehörende Property zeigt der robots.txt-Bericht in der Search Console die abgerufene Datei, wann sie zuletzt geholt wurde, und etwaige Parse-Fehler, was der schnellste Weg ist zu bestätigen, dass der Crawler liest, was Sie denken, dass er liest.

Bestätigen, dass sie von überall erreichbar ist

Eine robots.txt, die von Ihrem Schreibtisch aus lädt, kann für einen Crawler trotzdem fehlschlagen. Bot-Schutzregeln, Rate-Limits und geografische Sperren geben Rechenzentrums-Adressbereichen routinemäßig 403 zurück, während sie private Besucher normal bedienen, und das Ergebnis ist ein Host, den Google aus Gründen verlangsamt oder zu crawlen aufhört, die nichts in Ihren Protokollen als Fehler bezeichnet.

Der Weg, es zu sehen, ist, die Datei von einem Ort anzufragen, der nicht Ihr Büro ist. Richten Sie das kostenlose HTTP-Check-Tool auf https://example.com/robots.txt und lesen Sie den von Prüfpunkten in verschiedenen Ländern zurückgegebenen Statuscode. Ein 200 überall ist die gesunde Antwort; ein 200 zu Hause und ein 403 aus drei Regionen ist der Befund. Um zu testen, ob die Regeln eine bestimmte Seite blockieren, prüft der kostenlose robots.txt-Tester eine URL gegen die Gruppe für alle Crawler und meldet, ob sie in der Sitemap aufgeführt ist. Robots.txt existiert außerhalb der Seite, deshalb liest die Indexability-Option eines HostTracker-HTTP-Monitors sie nicht: Sie beobachtet die noindex- und Canonical-Tags auf der Seite selbst, während der geplante Crawl, in Beta, jede gecrawlte Seite mit der robots.txt abgleicht. SEO-Monitoring erklärt, was jeweils abgedeckt wird.