A few weeks ago I wrote about why this site tends to score well in PageSpeed Insights.
That post was about performance discipline: small static pages, minimal JavaScript, and very little third-party drag.
This post is about a different scoreboard.
isitagentready.com does not ask whether a site is fast for humans. It asks whether a software agent can figure out what the site is, what it exposes, and how to consume it.
The first time I ran it against daliso.com, the result came back as 23.
A few focused sessions later, the same check came back as 92, Level 5: Agent-Native.
The score moved because I added truthful machine-readable surfaces, not because I optimized frontend performance. That distinction matters.
Why 23 Was Not a Surprise
I was not especially surprised by the starting point. I had already seen the same pattern elsewhere: decent content hygiene, weak agent-discovery surfaces.
In my own work, more discovery is starting inside AI assistants rather than a classic search page. That changes the question from “can a human browse this?” to “can a program understand this without improvising?”
This site already had some of the older web basics in place. What it lacked was the newer layer: machine-readable entry points, discovery metadata, and an explicit policy about how AI systems may use the content.
Two Scoreboards, Two Very Different Questions
PageSpeed asks whether a browser can render the page quickly and cleanly.
Agent-readiness asks whether a client landing on the domain can discover the site’s content, policy, and interfaces without a human driving.
A site can be excellent at the first and mute on the second.
That is where this site started.
What the 100s Were Quietly Covering Even at 23
The interesting thing about the 23 is that two of the four sub-scores were already at 100 from the start.
Discoverability: 100. Content: 100.
Those were not the product of any recent agent-specific work. They came from earlier habits that were already useful for accessibility and SEO.
The site has a real sitemap.xml, generated from the blog pipeline rather than hand maintained. It has a canonical URL on every page. It has a valid robots.txt. It has a PWA manifest. It has structured data in the markup, not bolted on via a plugin. It has semantic HTML, skip links, labeled controls, alt text, and a document that reads sensibly in the absence of CSS.
The same authoring discipline that helps screen readers and search engines also helps agents.
The overall score of 23 was not because the site was invisible. It was because the machine-readable layer around the content was still thin.
The Build That Moved the Number, 23 to 83
The jump from 23 to 83 was not a single trick. It came from adding a real set of agent-facing surfaces.
First, I added cleaner content representations:
llms.txtandllms-full.txt- Atom and JSON feeds for the blog
/api/projects.jsonas a structured project ledger- per-post
plaintext.txtendpoints - Markdown representations generated alongside the HTML
Second, I added discovery metadata so those surfaces were actually findable:
- a richer JSON-LD graph on the homepage
/.well-known/api-catalog/.well-known/agent-skills/index.jsonand four concreteSKILL.mdentries/.well-known/mcp/server-card.json/.well-known/oauth-protected-resourceLinkheaders in_headersadvertising the important endpoints
Third, I tightened the agent-facing affordances:
- named AI crawlers with explicit
Allowrules inrobots.txt - WebMCP tools exposed on the homepage via
navigator.modelContext.provideContext()
That was the substantive part of the work. It raised the discovery and API-facing surfaces of the site because agents now had structured places to start, not just HTML to scrape.
Just as important, each of those files points at something real. If an agent follows the catalog, link headers, or skills index, it reaches a valid resource rather than placeholder metadata.
The One Line That Closed the Gap, 83 to 92
The sub-score that moved last was Bot Access Control, 50 to 100.
The change was one line in robots.txt:
Content-Signal: ai-train=yes, search=yes, ai-input=yes
That line, in the Content Signals proposal, says three things explicitly.
It says search engines are welcome to index the content. It says AI systems can use it as live input for answering a user’s question, with attribution. It says AI systems are also welcome to train on this content.
For this site, that is the honest policy. It is a public portfolio and writing surface meant to be read, indexed, and cited.
That will not be the right policy for every domain. Some sites should absolutely choose more restrictive defaults. The point is not permissiveness for its own sake. The point is to publish the policy that matches the actual intent of the site.
Before this line existed, the site said nothing explicit about AI use. The checker treated that silence as an unresolved gap.
The Remaining 8 Points, Honestly
The only sub-score still short is API, Auth, MCP and Skill Discovery, sitting at 5 of 6. The specific check that fails is OAuth or OIDC discovery metadata: the checker wants /.well-known/openid-configuration or /.well-known/oauth-authorization-server.
There isn’t one.
This site has no login, no token issuer, no session state, no accounts, and no protected API. The Protected Resource document already says so. Publishing discovery metadata anyway would advertise endpoints and trust relationships that do not exist.
If this site later grows an authenticated surface, that metadata becomes worth adding. Until then, the missing file is the correct file to be missing.
Agent-readiness is a measurement, not a checklist to game. A truthful 92 with one standards-compliant gap is better than a 100 patched together with metadata that lies about what is there.
How This Compares to the PageSpeed Write-Up
The previous post made a simple argument: performance wins often start with what you choose not to build.
PageSpeed rewards restraint. Less JavaScript, fewer third parties, smaller payloads, simpler DOM. You score well by doing less of the wrong things.
Agent-readiness rewards articulation. The site has to say what it is, in a form a machine can parse. Sitemaps. Structured data. Canonical URLs. Feeds. API catalogs. Skill indexes. Content preferences. Discovery documents where relevant. You score well by saying more of the right things, in the right format, but only when those things are true.
The two scoreboards are not in conflict. The restraint that keeps PageSpeed high, static pages, clean markup, no hydration, very little third-party noise, also makes the site easier for an agent to parse in the first place.
But they are not identical either. A site can score 100 on PageSpeed and still be invisible to agents, because rendering fast is not the same as being understood.
The effort curve is different, though. Most of the journey from 23 to 83 was substantive work: new files, new endpoints, and real structured metadata. Once that was in place, a single line in robots.txt closed the last visible gap and added nine points.
What This Means for Everyone Else
If you are running a small site, especially a personal one, there are a few straightforward takeaways.
Most of the “baseline” work to become agent-ready is already done if you have been doing SEO and accessibility properly. You almost certainly have a sitemap. You almost certainly have a robots.txt. You probably have canonical URLs and some structured data. That is what kept daliso.com’s Discoverability and Content sub-scores at 100 even while the overall score was 23.
The next layer is not magical. It is mostly about publishing honest, structured surfaces: llms.txt, feeds, machine-readable ledgers, /.well-known discovery files, link headers, and an explicit policy instead of silence.
The harder rule is the more important one: do not publish metadata for systems you do not actually run. Discovery documents are promises. Broken promises are worse than missing ones.
Final Thought
Going from 23 to 92 was not about gaming a checker. It was about making the site more legible without lying about its capabilities.
Most of the improvement came from publishing real machine-readable surfaces. The last jump came from stating the content policy plainly. The remaining gap is there because the site does not do auth, and saying otherwise would be false.
That is the lesson I trust here.
Build something small. Describe it clearly. Do not pretend.