Findings · 2026-09-01 · By VSNARY | Emmanuel Orta
A Worker cannot fetch its own host: the sameAs profile we called dead
A customer's schema pointed at a page on our own domain. From outside it answered 200. From inside the scanner it answered nothing, and we reported it dead.
One of the sites we operate declared its founder as a Person node and listed two profiles for corroboration: a personal domain, and the author page on this site. The corroboration check fetched both. The personal domain came back corroborated: it links the business back. The author page on crawlcheck.io came back dead: no response.
From a laptop the author page answers 200 in under a second. From the scanner it cannot answer at all, and the reason is structural: this scanner is a Cloudflare Worker, and a Worker cannot make a subrequest to a route the same Worker serves. The request never leaves the isolate. It is the same limit that stops the scanner grading crawlcheck.io from inside, which we have published before. What we had not done was carry that limit into the corroboration check, which fetches whatever URL a customer's schema names.
Dead is an accusation. Unverifiable is a fact about us.
The three outcomes that check can return are deliberately not interchangeable. Corroborated means the target links back. Unreciprocated means the target is reachable and does not. Unverifiable means we could not read the target, so we know nothing, and the report must not pretend otherwise. Dead means the target did not answer, which reads to a customer as: your schema points at a page that does not exist.
For a target on our own host, dead was false and unverifiable was true. Any customer whose schema mentions crawlcheck.io, which is exactly the kind of customer we want, would have been told their profile was broken. The fix is one branch, placed before the fetch: a target on the scanner's own host is unverifiable from this vantage point, with the reason stated in the row. The same guard now sits in the citation checker, which fetches directory listings the same way.
Why this keeps happening, and the rule it reinforces
Every false accusation this scanner has shipped has had the same origin: a fetch failed for a reason on our side, and the code read the failure as a fact about the site. A truncated profile body became nothing points back. A challenge page became reachable and empty. A subrequest that could never leave the Worker became dead. The general rule is the one we keep writing down: separate the site refusing us from our own fetch failing, and never let the second one score.
If you run any tool that fetches links on other people's behalf, the question to ask of every failure path is whether the failure could be yours. Timeouts, egress blocks, DNS on your resolver, credentials you never had, and routes you serve yourself are all yours. None of them is evidence about the site.
How to check a corroboration claim by hand
Open the sameAs target from a client that is not the tool making the claim, and search the page source for your domain:
curl -sL https://profile.example/you | grep -c 'yoursite.com'A count above zero is a reciprocated link. Zero on a page you can read is unreciprocated. A page you cannot read from that client is unverifiable, and the honest report says so. Reciprocated sameAs and unverifiable are defined in the glossary; the entity SEO guide explains why the distinction is worth the bother.
Every figure above came out of this scanner.
Point it at your own domain and see the same measurements, free.
Questions this post answers
Why can a Cloudflare Worker not fetch its own host?
A Worker cannot make a subrequest to a route the same Worker serves; the request never leaves the isolate. Any URL on the scanner's own host is therefore unreachable from inside a scan, which is a fact about the scanner, not about the site being scanned.
What is the difference between dead and unverifiable?
Dead means the target did not answer, which accuses the site of pointing at a page that does not exist. Unverifiable means the scanner could not read the target for a reason on its own side. Only the second is true for a target on the scanner's own host.