Reach

Most failures happen before your page loads.

The instinct is to write for the model that is reading you. In practice the common failure is that nothing read you at all — the system answered from your domain name, from pages that merely resemble yours, or from a copy it cached weeks ago. None of that is fixable with better copy, and time spent on copy while this is happening is time spent on the wrong problem.

A cautious answer usually means nothing was found

The most misread signal in this whole area. A hedging, non-committal answer feels like a verdict on your site. It is almost always a verdict on an empty result set.

[measured]

Asked whether a live site was legitimate, one assistant returned a cautious “treat with caution” answer with fifteen cited sources, none of which were the site. It had never fetched the page. The caution was about the absence of information, not the presence of anything bad.

Check the sources before you react to the verdict. If the site is not among them, you have a retrieval problem and the text of the answer tells you nothing.

The chatbot and the API are different systems

[measured]

Same question, same day, same site. The developer API found the page and described it accurately. The consumer chat product cited fifteen sources and reached none of them. Test the surface real people use, which is rarely the one that is convenient to automate.

Similar names inherit each other's reputation

If your domain resembles other domains, a system that fails to find you may answer from them — and hand you their reputation.

[measured]

A site was described using scam-checker write-ups and reviews of five unrelated domains with partially matching names. The assessment was inherited wholesale from sites the operator had never heard of.

The tempting fix is to add a section to your own page naming the sites you are not. Do not do this. It puts a permanent list of disreputable domains into your own copy, and it cannot work: the reader who is confused never loaded your page.

[reasoned]

A fix belongs on the layer where the failure happens. On-page content cannot reach a reader who did not arrive.

If it needs JavaScript, you have not published it

A page that assembles itself in the browser is, to most automated fetches, an empty shell. This is most damaging where it is least expected: in the evidence you link to in order to be checkable.

[measured]

A site published careful citations to explorers and indexes so its claims could be verified independently. Fetched without JavaScript, one returned ten characters of visible text. The facts were correct and completely unverifiable.

curl -s https://the-page-you-cite/ | wc -c        # bytes served
curl -s https://the-page-you-cite/ | grep -c "the fact you rely on"

Run that against every source you cite. Publish plain data rather than links to applications.

The best sources are the least reachable

When you try to source a claim properly, you discover that authority and accessibility are close to inversely related.

[measured]

Sourcing a single factual claim, in one sitting:

the auction house that ran the sale     disallowed to the crawler
the project's own website               403, behind a bot check
six reputable trade publications        403
the community-maintained index          200, ten characters of text
a marketplace API                       402, payment required
a mid-tier aggregator                   200, plain HTML, facts in the body

The only citable source was the least authoritative one. That is a fact about the web, not about the claim.

Some of this is not yours to fix

The honest part. Retrieval improves on its own — domains age, indexes refresh, providers change their stacks — and it will improve without your involvement.

[measured]

A site that had been answered with inherited scam signal was re-tested two weeks later, same prompt, same surface. It returned five citations, all five the real domain, and a clean assessment. The fix that had been designed for the problem was never shipped. Nothing on the page had changed that could account for it.

[reasoned]

Improvement is not attribution. If you iterate hard on one thing and the outcome improves, you will credit the thing you iterated on. Separate the axes and test them independently, or say plainly that you do not know.

Next: credence — what to do once systems can actually reach you, and why being read is not the same as being believed.