hello@datascale.de+49 89 921 35 623cookiefrei getrackt · /openDEEN

Suchen Sie nach Leistungen, Integrationen und Blog-Beiträgen.

DatascaleRessourcenChecksrobots.txt

Check · C06 · Security & Bots

robots.txt prüfen: erreichbar und ohne pauschale Sperre

Der Check holt die robots.txt und liest die Gruppe für alle Crawler. Nicht erreichbar oder ein pauschales Disallow ist „zu prüfen“.

Was wird geprüft

Der Scan ruft /robots.txt auf, zuerst mit seiner eigenen Kennung, bei einer Fehlantwort noch einmal als Browser. Antwortet die Datei nicht mit 200, ist die Zeile „zu prüfen“. Dann liest er die Gruppe User-agent: * und sucht ein Disallow: /, das allein auf einer Zeile steht. Findet er es, sperrt die Datei alle Crawler aus, ebenfalls „zu prüfen“. Alles andere ist „ok“.

Was der Scan nicht bewertet: einzelne gesperrte Pfade, Regeln für einzelne Bots, den Sitemap:-Verweis und Syntaxfehler. Eine Antwort mit 200 und HTML statt Regeln, wie manche Hoster sie für jede unbekannte URL liefern, gilt als erreichbar. Die Regeln für AI-Crawler stehen im eigenen Befund AI-Bot-Policy.

Warum ist das wichtig

Ein Disallow: / ist die kürzeste Art, eine Website aus Google zu entfernen. Es steht auf jedem Staging-System, und es geht öfter mit live, als man denkt: Der Relaunch ist durch, das Team feiert, und drei Wochen später bricht in der Search Console der Traffic ein. Ein Tracking-Check prüft die Datei, weil danach jedes Dashboard falsch aussieht, obwohl das Tracking selbst in Ordnung ist. Erst die Ursache, dann die Messung.

Häufige Ursachen

  • Ein Disallow: / aus der Staging-Phase ist mit live gegangen.
  • Die Datei liefert einen Fehler oder einen Redirect auf die Startseite. Google behandelt Serverfehler wie eine Sperre, bis die Datei wieder antwortet.
  • Ein CDN oder eine Bot-Abwehr beantwortet Anfragen ohne Browser-Kennung mit 403. Der Scan versucht es dann als Browser; scheitert auch das, gilt die Datei als nicht erreichbar.
  • Der Sitemap-Verweis fehlt oder zeigt auf eine tote URL.

So beheben

Eine robots.txt im Web-Root mit einer Gruppe User-agent: *, darin nur die Pfade, die wirklich niemand crawlen soll, plus eine Zeile Sitemap: mit der absoluten URL. Das pauschale Disallow: / gehört ausschließlich auf Staging. Besser noch: Staging per Passwortschutz sperren statt per robots.txt, dann kann kein Deploy die Sperre mit auf die Live-Domain nehmen. Nach dem Deploy die Datei einmal im Browser aufrufen. Zehn Sekunden, die drei Wochen Search-Console-Rätsel sparen.

Erst selbst prüfen

Der Tracking-Check testet diesen Punkt zusammen mit allen anderen in Sekunden.

Tracking-Check starten →
Unsere robots.txt fehlt (404). Ist das ein Problem?

Für Google nicht: Ohne Datei crawlt der Bot alles. Der Scan meldet die Zeile trotzdem „zu prüfen“, weil damit auch der Sitemap-Verweis und jede Regel für AI-Crawler fehlen. Ein Serverfehler (5xx) ist die schlimmere Variante, dann stoppt Google das Crawling, bis die Datei wieder antwortet.

Wir sperren nur /wp-admin/ und /checkout/. Warum zählt das als ok?

Weil der Scan nur das pauschale „Disallow: /“ in der Gruppe für alle Crawler als Sperre wertet. Einzelne Pfade sind normal und bleiben unbewertet. Ob die richtigen Pfade drinstehen, ist eine SEO-Frage, keine Tracking-Frage.

Der Scan sagt ok, aber Google indexiert Seiten nicht. Woran liegt es dann?

Die robots.txt regelt nur das Crawlen. Ein noindex im Meta-Tag oder im X-Robots-Tag-Header, ein Canonical auf eine andere URL oder eine Sperre für einzelne Pfade hält Seiten trotzdem aus dem Index. Der Befund Meta-Tags zeigt das Robots-Meta der geprüften Seite.

Behebung

Verdrahtet in Tagen, nicht in Sprints.

Befunde aus dem Tracking-Check gehen im Audit Sprint in eine Reihenfolge mit Aufwand, jeder Baustein mit Abnahmekriterium.