DeployRadarBot
Found DeployRadarBot in your logs? Here is what it requests, why it requests it, and how to stop it.
DeployRadarBot never visits your site on a schedule. It runs only when someone types a domain into deployradar.dev, usually the site’s own owner or their agency, checking whether AI systems can read the site. One other token of ours does run on a schedule, and only for sites whose owner asked it to.What one scan requests
- ×1
/robots.txtYour crawler policy. The point of the tool. - ×1
/Fetched as an ordinary browser, the control. - ×5
/One per AI crawler user agent, to catch edge blocking. - ×1
/Headless render, compared against the raw HTML. - ×1
/Under our own name, so an edge block can be told apart from a site that refuses every non-browser client. - 0-3
/sitemap.xmlRead, never crawled, and only when your robots.txt disallows a named AI crawler from a path. If it is an index, its first two child sitemaps are read too.
That is your robots.txt and homepage. We do not follow links, crawl sitemap URLs or submit forms. Requests start at least 250ms apart, with no more than two in flight. An unusable response is retried once, and a refused one is asked once more to check it was not a one-off, both from the same allowance of two.
We read your sitemap when needed, but never crawl the URLs inside it. This lets us measure how much content a robots.txt rule excludes instead of guessing from path names.
Results are cached for 24 hours per domain. Each visitor gets 5 scans an hour, with up to 3 fresh scans per day when something has just changed.
Why you may see GPTBot or ClaudeBot from our IP
Some requests deliberately use the User-Agents of GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot and meta-externalagent. They come from our IP, not the operators’ IPs.
We are not pretending to be those operators. Using their User-Agents lets us answer a different question: does your CDN treat crawler traffic differently from a normal browser? robots.txt alone cannot show that.
We also state the limit clearly. Because our requests do not come from the operators’ verified IP ranges, a successful fetch means “no user-agent-level block detected”, not “allowed”. We never send Googlebot or Bingbot.
The methodology explains how those answers become the verdicts in a report.
How to block us
Add this to your robots.txt:
User-agent: DeployRadarBot
Disallow: /We honour it. Once we see that rule, we stop the scan before requesting pages. The report says that scanning stopped because you asked us to.
The one that does run on a schedule
There is a second token, DeployRadarMonitor, honoured exactly the same way. It is the only thing we run that visits a site without somebody clicking first, and there are two reasons it might reach you:
- It checks deployradar.dev itself every week, because a tool claiming AI access breaks quietly ought to notice when it breaks on its own site.
- Somebody who owns your site asked us to watch it. After a scan you can leave an address and be told when an answer changes; that is what re-checks it, weekly, and it is the only way this token ever arrives at a site that is not ours.
It sends the same handful of requests one scan does, under this name rather than DeployRadarBot, so the two are told apart in your log without reading timestamps. Blocking it is one line, and we stop:
User-agent: DeployRadarMonitor
Disallow: /That is deliberate rather than generous. A rule beats a signup: if somebody who does not run your servers asked us to watch your site, the line above ends it without you having to find out who they were. And a user agent no rule can stop is the behaviour this page exists to argue against, and it would be a poor look to ship one.
If you would rather run the check yourself than be watched by us, the same comparison runs in your own CI and tells us nothing.
Blocking by user agent at your CDN or WAF works too, and needs no trust in us. A blanket User-agent: * disallow does not stop us, deliberately: those rules are aimed at indexing crawlers, and someone running a one-off diagnostic on their own site should not be defeated by their own file.
Contact
Questions, or a complaint about our behaviour on your site: hello@deployradar.dev. If we are causing you a problem, tell us and we will fix it.