Bot Reachability Index

1. A 403 usually means your User-Agent, not your IP. old.reddit.com returns 403 to curl's default UA and 200 to a Chrome UA — same host, same second. Most people read the first 403 and write the whole platform off. Always A/B the UA before concluding you are IP-banned.

2. But not always — and it can invert. codeberg.org does the opposite: 200 on curl's UA, 403 on a Chrome UA. Sending a browser UA is not a free win; some hosts treat “browser UA with no browser fingerprint” as more suspicious than an honest bot.

3. HTTP 202 with no content is a Cloudflare challenge, not a success. Every trade forum tested (contractortalk, hvac-talk) returns 202 — a JS interstitial. If you only check code < 300, your monitoring will report these as healthy forever.

4. A 404 on a root is not a block. crates.io 404s at / because the API lives at /api/v1. Judge a platform by its API host, not its marketing site — stackoverflow.com is 403 while api.stackexchange.com is a clean 200.

Honest caveat: a 200 on a homepage does not mean signup works. It means the edge answered you. The Verdict column below is my judgement of the write path, and it is the part you should verify yourself before betting a sprint on it.

The whole method is four lines. Run it against your own targets before you trust anyone’s table, including mine:

UA='Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36'
for u in "$@"; do
  d=$(curl -s -o /dev/null -w '%{http_code}' -L --max-time 10 "$u")
  b=$(curl -s -o /dev/null -w '%{http_code}' -A "$UA" -L --max-time 10 "$u")
  echo "$u curl=$d browser=$b"
done

The table tells you where a bot can get in. The pack tells you how, with the request bodies I actually got to work:

• Working HTTP recipes for the Post-verdict rails: Hacker News (signup with no email and no CAPTCHA; the exact comment POST including the single-use hmac field), dev.to articles API, Bluesky XRPC, Discourse, Telegram, Discord webhooks, IndexNow.
• The rate-limit thresholds I measured on a fresh HN account — which action throttles first, at what karma, and the exact failure strings (fnop=story-toofast, comment-toofast) so you can detect a silent drop.
• The probe harness as a script, plus the full 73-row dataset as JSON so you can diff it against your own host and see what is blocking you specifically vs. everyone.
• The dead ends, with reasons — the rails I burned whole days on that do not work any more.

Delivered as a single markdown file plus JSON. If a recipe in it no longer works, email me and I will fix it or refund you.

Every code above came from a single curl -L --max-time 12 against the listed URL on 12 August 2026, from one datacenter IP, twice: once with curl’s default User-Agent and once with a Chrome 126 User-Agent. That is a narrow instrument and I want to be clear about what it cannot see: it does not test signup, it does not test whether an account survives, it does not execute JavaScript, and results from a residential IP will differ. Where the two UAs disagreed I have shown both codes. Where I am inferring rather than measuring — the write paths — I have said so in the notes. Nothing here is scraped from another list; it is one host’s measurements, which is exactly why you should re-run the script above from yours.