How we audited index365 for AI legibility
We build a website findings platform, so the obvious question is whether our own site passes its own scan. On July 31, 2026 we ran the AI-Readiness scan against index365.co from the terminal, the same way any user runs it. The scan scored index365.co at 99/100 and returned six open findings.
Both halves of that sentence matter. This post walks through the exact terminal flow, what a 99 does and does not mean, and the fix we shipped on our own site because of it.
One command
The whole audit is one command. The scan waits by default and prints the score when it finishes.
index365 scan index365.co
The scan streams its stages and ends on the score card:
Scanning https://index365.co/ (AI-Readiness)Completed - score 99/100.
No configuration, no crawler setup, no export step. The run is now history attached to the project, so the next scan has something to compare against.
What 99/100 does not tell you
A report that stops at the score is a screenshot for a slide deck. The score is a summary statistic. The findings are the work.
Our 99 arrived with six findings across crawlability and structure. A score that high with open findings is not a contradiction. It means the site is broadly legible to AI readers while specific, fixable gaps remain, and the gaps are enumerated instead of hidden inside a rounded number. If we had read only the score, we would have learned nothing actionable. Reports stop at the score. Findings carry the fix.
Reading the findings
The findings list is the actual audit output. No run ID needed: findings reads your latest run and says which run it resolved.
index365 findings
The list prints one numbered line per finding plus a severity summary. Excerpted, the line that mattered most to us:
3 medium crawlability llms.txt guidance6 findings.
Five of the six stay unnamed here; they spread across crawlability and structure and were queued the same way. The one we will walk through is the llms.txt finding, because it changed our own site.
From Finding to fix prompt
Each Finding carries its evidence and a copy-pasteable fix prompt. That prompt is the handoff point to a coding agent. The number is the ordinal from the list above.
index365 findings get 3
The command prints the Finding and then the fix prompt block:
Fix prompt:Fix this website finding: llms.txt guidanceAffected URLs: https://index365.co/llms.txtRemediation: extend llms.txt so AI readers get the current product inventory and agent entry points, and generate it from application code so it cannot drift from the live site.Apply the remediation, then re-scan to confirm the finding is resolved.
We pasted that prompt to a coding agent working in our own project. The agent used the Finding to fix the page: it rewrote the llms.txt route, added the agent entry points, and shipped the change through our normal review. index365 did not ship the fix. The coding agent did, with the Finding as its spec, which is the entire division of labor the product is built around.
What we fixed
The honest part of dogfooding is publishing the result. Because of this scan, index365.co now generates its llms.txt and llms-full.txt from application code, with the product inventory and agent instructions kept current by the same deploy that changes the site. Our own site had the exact class of gap we scan other sites for, and the scan is why it is closed.
After the change, the loop closes the same way it does for any user: re-run to confirm, and the Finding is resolved against a fresh run instead of a promise.
Run this on your own site
Everything above works the same on yoursite.com. The checks behind the score are the ones documented in the GEO audit checklist and the AEO audit checklist, run mechanically instead of by hand. The AI-Readiness scan returns the score, the findings, and a fix prompt your coding agent can act on in your own project, and the CLI is the fastest way to run it from a terminal.