forked from bchanot/claude
Bastien Chanot
fe93b7945b
entity-seo.md:148 says "sameAs pointing to dead profiles — validate each URL resolves", and STEP 7 asks "does the target resolve and match?". Nothing implemented it: zero curl against a sameAs anywhere in the repo. A dead sameAs is worse than a missing one — it asserts an identity link that fails on follow, in the exact graph AI engines walk to confirm who you are. The naive version of this check is a false-positive generator, which is presumably why it stayed unimplemented. Verified live rather than assumed: 999 linkedin.com/company/anthropic <- blocks non-browsers 200 wikidata.org/wiki/Q108162414 200 x.com/anthropicai 404 <known-dead URL> <- correctly detected So the check classifies by code, not by liveness guess: 404/410 = dead (finding with direction), 401/403/429/999 = bot-blocked (inconclusive, NO finding, never "dead"), 000/5xx = inconclusive. No G2/G6 item may remove a sameAs on anything but 404/410 — same shape as the NAP direction rule: an unreliable signal read confidently is worse than no signal. Note: the spec draft asserted "X/Twitter and Instagram commonly 403" from plausibility. The live test returned 200 for x.com and contradicted it — corrected to classify by observed code, never by platform folklore. Third unverified-plausible claim caught this session (I1, I6, here); the pattern is exactly what these fixes exist to stop. Verified: pipeline exercised end-to-end against real endpoints; make test 35 GREEN / 0 RED.