A captcha answered with 202 is challenged, not served
Hosts such as SiteGround answer a crawler's request with 202 and a captcha page in place of the resource. Those requests now count as challenged on the bots access page and in Start here, and never as a secret path that answered.
SiteGround's anti-bot protection does not redirect a crawler to its captcha path; it answers the requested URL itself with a 202 and the challenge page. A crawler that never runs the script never reaches /.well-known/sgcaptcha/, so the only trace of the challenge is the 202. Until today those answers were read as served, which made a site look as if it served every AI crawler and as if its .env file answered to probes, when every one of those requests had met the captcha.
What changed
- A 202 to a crawler's request counts as challenged on the bots access page, with
challenge_basissayingstatus_202, beside the edge's own action (edge_action) and known captcha paths (known_path). - Start here reads the same rule: the Googlebot answer counts captcha challenges with errors and refusals, the AI crawlers answer says how many requests were challenged, and the exposure answer no longer treats a 202 to a secret path as an answer.
- The public API and MCP carry the same figures (
challengedin the access report and in the Start here figures).