Practical Lens 72

AI visible? Got proof?

Your supplier says your website is ready for AI. Ask what AI actually tells a potential customer about your business, and keep the answers as evidence.

Published · By

The short answer

Save answers to three real buyer questions. Check whether your company appears, whether its offer is described accurately and whether the cited sources support the claims. Fix the demonstrated website gaps and repeat the checks. A completed technical task alone does not establish a business outcome.

1. Problem: the report proves the wrong thing

Illustrative situation: a supplier marks AI optimisation complete. Asked which providers suit a customer’s needs, an AI answer omits your company or describes last year’s offer. The completed task does not establish what buyers can discover or whether the description is accurate.

Business consequence: leadership may close the improvement task without knowing whether the offer is discoverable or described correctly.

What this lens means

This is a practical acceptance check for a claim about AI visibility. It separates delivered work, public website evidence and observed answers. The llms.txt file is one example of a technical deliverable: it is a guide to website content for AI tools. Its presence alone does not establish that a business is recommended.

Key terms

llms.txt
A proposed Markdown guide to useful website information and linked content for agents.
Access evidence
What a specific tested client or verified crawler received from a specific page at a recorded time.
Answer evidence
A saved AI response showing a mention, recommendation or citation under recorded test conditions.

Why this happens

A file is easy to check automatically. Visibility is harder to establish: a platform may fetch different pages, select other evidence or answer differently on another run. A completion badge can combine these separate questions into one apparent result.

What this usually indicates

  • The deliverable has been checked, but the promised outcome has not.
  • There is no baseline of buyer questions and saved answers.
  • Content accuracy and access restrictions have no named owner.

2. Verify: begin with the buyer’s questions

  1. Save three answers. Choose three real questions customers ask before buying. Use an AI tool with web search enabled and no internal documents attached. Record exact wording, platform, available model/settings, date, full answers and cited sources. Note any personalisation you cannot disable.
  2. Inspect the evidence. Does your company appear? Is the offer and customer fit accurate? Open each cited source and find the passage supporting the claim. Mark correct, incorrect or not verifiable. A missing mention alone does not diagnose a website defect.
  3. Check relevant public pages. Ask the web owner to inspect readable content, response status, intended crawler rules and security restrictions for three important pages. If an llms.txt guide was delivered, open it and follow three links to current public content. Use relevant platform inspection tools where available.

Expected output: three saved answers, their supporting passages and three page checks. Record the delivered changes separately. Mark missing evidence “not verified”.

3. Fix: repair only the demonstrated gaps

  1. Wrong or missing business facts? Correct outdated offer details on pages you control. Publish the customer fit, important exclusions and supporting evidence in readable text. Keep matching structured data accurate.
  2. Blocked public evidence? Have the web owner correct accidental restrictions for the intended crawler. Keep private routes protected and follow the approved access policy.
  3. Wrong or stale content guide? If llms.txt is part of the delivery, update its summary and links to current public pages. Remove contradictions and broken links. Assign an owner and review date.
  4. Unsupported completion claim? Change the report to show “file delivered”, “page access checked” and “answer outcomes observed” separately. Attach evidence to each.

Do not delete a useful guide solely because a citation test failed. Fix the recorded issue and retain the distinction between implementation and outcome.

4. Retest: define success before rerunning

After a repair, repeat the affected file and page checks. Repeat the same three buyer questions under the same available settings on two separate dates. Save the full outputs and record any model, source or configuration changes.

Implementation success: the documented access or content defect is resolved. Observed answer outcome: the saved responses changed, did not change or are not comparable. Two dates are a starting protocol, not statistical proof of effectiveness.

A before-and-after difference does not establish that llms.txt caused a visibility change. Passing these checks does not guarantee indexing, citation or recommendation.

Example decision record

Illustrative records, not a live site audit
EvidenceFindingAction
FileLinks to retired service pageReplace with current public page
PageOld customer eligibility in body textUpdate approved facts and matching markup
AnswerStill repeats old eligibilitySave response and cited URL; inspect the actual source

Terminal: a basic response check

Open Terminal, paste the example and press Enter. It uses the public VerisAI site as a runnable example. To test your site, replace the base address and the third path with one important public page.

base='https://verisai.eu'
for path in /llms.txt /robots.txt /practical-lens; do
  printf '\n%s\n' "$base$path"
  curl --silent --show-error --location --max-time 20 \
    --output /dev/null \
    --write-out 'HTTP %{http_code} | %{content_type} | %{url_effective}\n' \
    "$base$path"
done

Expected result: a status for each requested address; errors must remain visible. A 200 result requires inspecting the actual response body. A missing llms.txt file alone is not an AI visibility failure.

Business meaning: this checks responses for this client only. It does not validate robots rules, authenticate a crawler, prove indexing or measure AI citations. Do not impersonate a crawler name and treat that as verification.

PowerShell: a basic response check

Open PowerShell, paste the example and press Enter. It uses the public VerisAI site as a runnable example. To test your site, replace the base address and the third path with one important public page.

$base = 'https://verisai.eu'
foreach ($path in @('/llms.txt','/robots.txt','/practical-lens')) {
  $uri = "$base$path"
  try {
    $r = Invoke-WebRequest -Uri $uri -UseBasicParsing -TimeoutSec 20 -ErrorAction Stop
    [pscustomobject]@{ Url=$uri; Status=[int]$r.StatusCode; Type=$r.Headers['Content-Type'] }
  } catch {
    Write-Output "$uri | Review failed request: $($_.Exception.Message)"
  }
}

Expected result: a status for each requested address; errors must remain visible. A 200 result requires inspecting the actual response body. A missing llms.txt file alone is not an AI visibility failure.

Business meaning: this checks responses for this client only. It does not validate robots rules, authenticate a crawler, prove indexing or measure AI citations. Do not impersonate a crawler name and treat that as verification.

Evidence and limitations

  • The llms.txt proposal describes a guide to website content for agents. It distinguishes its role from robots.txt.
  • SE Ranking’s analysis of approximately 300,000 domains reports 10.13% adoption and no meaningful citation association in that dataset. It is observational and model-dependent; it does not prove a universal zero effect. The page currently displays 15 October 2026; that is not proof the underlying research is new this month.
  • Google Search Central says AI Overviews and AI Mode do not require new AI text files or special schema. Its guidance covers Google Search, not every AI platform.

Sources checked 27 October 2026. The checklist is an editorial control, not a platform requirement. No live AI answer experiment is claimed on this page.

Decision rule for leaders

Accept the file as a delivered asset only after its contents and links are checked. Accept a claim about visibility only with a documented method and saved answer evidence. Assign an owner to each defect and keep the outcome “not verified” until the supporting record exists.

About the publisher

VerisAI, founded in 2025, helps B2B services, SaaS, consulting and technology firms in Europe improve how their websites can be read, understood and cited by AI systems. Its AI Readiness Scoring & Monitoring service supports practical website checks. Contact support@verisai.eu.

Frequently asked questions

Does llms.txt guarantee AI citations?

No. Publishing the file does not prove that a platform fetched it, used it or cited your business. In SE Ranking’s studied dataset, its presence had no meaningful association with citation frequency.

Should we delete an existing llms.txt file?

Not automatically. Keep it accurate if it serves a documented use case. Treat it as a content guide, and assess any promised visibility improvement separately.

What should we fix first?

Check three important public pages for unintended access restrictions, missing text and inaccurate business facts. Change only the restrictions that conflict with your approved access policy.

Does an HTTP 200 response prove crawler access?

No. It proves that the tested client received a successful response. A challenge page or empty shell can also return 200. Inspect the content and verify real crawler access through the relevant platform and server evidence.

How should we verify an improvement?

Retain the exact questions, platform, available model and settings, date, full answers and citations before a change. Repeat the same recorded protocol afterwards. Report observations without treating a small before-and-after comparison as causal proof.

AI visible? Show the evidence.

Start with three public pages and three buyer questions.