Hosting firewall: we cannot tell whether it lets AI robots in

Three gates stand between a website and an AI assistant: robots.txt (measured by ACC-01 and ACC-10), the network in front of the site, typically Cloudflare (ACC-09), and the hosting firewall. The last one cannot be measured from outside. Our crawler comes from our own addresses, not from OpenAI's or Anthropic's, and we refuse to pretend to be someone else's robot. From the inside it is possible, though: the application on the server sees every request that reached it.

The Torumata plugin for WordPress (from version 0.3.0, once the site admin turns counting on) therefore counts requests by their User-Agent header and sends us daily totals once a day: how many requests introduced themselves as GPTBot, ClaudeBot, Googlebot and the other robots on our list, when the last one came and what status the site returned. Plus one number per day: how many other requests there were. The finding works with the last 30 days (config/bot-visits.json).

• A robot arrived: the hosting firewall let those requests through. The finding lists the count, the date of the last request and the response status.
• No robot that robots.txt allows arrived, and the site has normal traffic (at least 300 other requests and 14 days with data, config/bot-visits.json#absence_signal): this is a signal, not proof of a block.
• Too little data or traffic: the finding says that nothing can be concluded.
• The plugin sent nothing: the hosting firewall is an open question, not "all clear".

What the check does not do:

• It does not verify that a real robot sent the request. The User-Agent can be faked with a single parameter, so we count requests carrying the name. A request with a GPTBot header arriving proves the firewall let that request through; it does not prove it lets OpenAI's addresses through.
• It cannot see requests answered by a cache in front of WordPress (server cache, CDN, caching plugin). On a site with such a cache the counts are lower than reality and silence is less conclusive.
• It does not read IP addresses, page addresses or anything about visitors. The plugin sends only daily totals, which is also why it does not verify robots by address (reverse DNS).
• It never changes the score. The finding is informational, weight zero: the data comes from the customer's site, not from our measurement.

As with ACC-09, the label fits only halfway. The consequence the finding points to is a necessary condition: a robot the firewall does not let in cannot fetch the page, and a Googlebot blocked by the firewall cannot index the site. Google states in its own documentation that a page can appear in AI Overviews or AI Mode only if it is indexed and eligible to be shown with a snippet.

To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet. There are no additional requirements.Google Search Central, AI features

Whether it applies to you, we only know as well as the plugin data allows. Hence the informational severity and the distinction between "arrived" (an observation), "nobody arrived" (a signal) and "no data" (an open question). That hosting providers block addresses by reputation, AI services included, we documented with the Czech provider Forpsi, which confirmed it in writing on 16 September 2026; how common it is elsewhere we have not measured.

What to do depends on what the finding showed:

1. No data: on WordPress, install the Torumata plugin 0.3.0+, turn on counting of AI robot requests in Settings → Torumata and create an API key in the Torumata dashboard with the "Download files" and "Sending AI robot visits" scopes. You will see the result in the next audit, ideally after two to four weeks of traffic.
2. A robot gets 403 or 503: the request passed the hosting firewall and the site refused it. Look for a security plugin (Wordfence, All In One WP Security) or a rule in .htaccess.
3. An allowed robot did not arrive: ask your hosting provider in writing whether its firewall blocks addresses by reputation (for example from AbuseIPDB), whether that also applies to the officially published addresses of OpenAI, Anthropic and Google robots, and whether an exception can be made for your server.

Without WordPress, what remains is asking the hosting provider and reading your own server access log: look for requests with GPTBot, ClaudeBot or Googlebot in the User-Agent header.