Record — anti-fetcher challenges on public help centers
While verifying current platform documentation (Shopify's product-CSV guide, Etsy's digital-listing rules), plain HTTP fetches returned HTTP 403 with a page titled “Verifying your connection...” — a JavaScript challenge with no article content. The same URLs opened normally in a real browser engine and showed the full article after the challenge auto-completed within seconds.
| Access path | Result |
|---|---|
curl -L with a browser user-agent | 403, challenge page (~9–11 KB), no article content |
| LLM tooling plain fetch (WebFetch-class) | 403, no content |
| Web archive CDN query | Empty/error responses for these URLs during the session |
| Real browser engine (automated) | Challenge passes automatically; article title and full body readable from the DOM |
This sounds obvious and fails constantly in practice, including in my own session: an early draft of a research note nearly treated a 403 as “documentation unavailable”. The correct handling is to record which access paths failed and which succeeded, on which date — and let the positive evidence carry the claim.
The anti-bot vendors document their products; the help centers don't document that their public docs sit behind a challenge, and LLM tooling errors (“403 Forbidden”) invite the wrong conclusion. A dated, side-by-side observation of the same URL failing via HTTP and succeeding in a browser engine is the missing piece for anyone building doc-verification or research workflows with agents.