hello@datascale.de+49 89 921 35 623tracked cookie-free · /openDEEN

Search services, integrations and blog posts.

DatascaleResourcesChecksrobots.txt

Check · C06 · Security & bots

robots.txt check: reachable and without a blanket block

The check fetches robots.txt and reads the group for all crawlers. Unreachable or a blanket Disallow is "to review".

What we check

The scan requests /robots.txt, first with its own identifier and, on an error response, once more as a browser. If the file does not answer with 200, the line is "to review". Then it reads the User-agent: * group and looks for a Disallow: / standing alone on a line. If it finds one, the file locks out every crawler, also "to review". Anything else is "ok".

What the scan does not rate: individual blocked paths, rules for individual bots, the Sitemap: reference and syntax errors. A 200 response carrying HTML instead of rules, which some hosts return for every unknown URL, counts as reachable. The rules for AI crawlers live in the separate AI bot policy finding.

Why it matters

A Disallow: / is the shortest way to remove a website from Google. It sits on every staging system, and it goes live more often than you would think: the relaunch is done, the team celebrates, and three weeks later the traffic drops off in Search Console. A tracking check tests the file because afterwards every dashboard looks wrong even though the tracking itself is fine. Cause first, then measurement.

Common causes

  • A Disallow: / from the staging phase went live with the site.
  • The file returns an error or a redirect to the homepage. Google treats server errors as a block until the file answers again.
  • A CDN or bot defence answers requests without a browser identifier with 403. The scan then retries as a browser; if that fails too, the file counts as unreachable.
  • The sitemap reference is missing or points to a dead URL.

The fix

A robots.txt at the web root with one User-agent: * group, containing only the paths that really nobody should crawl, plus a Sitemap: line with the absolute URL. The blanket Disallow: / belongs on staging only. Better still: lock staging with password protection instead of robots.txt, then no deploy can carry the block over to the live domain. After the deploy, open the file once in the browser. Ten seconds that save three weeks of Search Console puzzling.

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →
Our robots.txt is missing (404). Is that a problem?

Not for Google: without the file the bot crawls everything. The scan still reports the line as "to review", because the sitemap reference and any rule for AI crawlers are missing with it. A server error (5xx) is the worse variant; then Google stops crawling until the file answers again.

We only block /wp-admin/ and /checkout/. Why does that count as ok?

Because the scan only treats the blanket "Disallow: /" in the group for all crawlers as a block. Individual paths are normal and stay unrated. Whether the right paths are in there is an SEO question, not a tracking question.

The scan says ok, but Google does not index our pages. What else could it be?

robots.txt only governs crawling. A noindex in the meta tag or in the X-Robots-Tag header, a canonical pointing at another URL, or a block on individual paths keeps pages out of the index regardless. The meta tags finding shows the robots meta of the scanned page.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.