Most of what I built to make two websites agent-ready has no evidence behind it as a way of getting found. A smaller part is worth doing for whoever turns up, person or agent. And the part I like most, in-browser tools an AI agent can call, has no usage data on either site yet.

The two sites are tallyfy.com and this one. Between September 2025 and October 2026 both picked up llms.txt files, structured data, discovery files under /.well-known/, and WebMCP tools: seven read-only tools here, twelve on tallyfy.com. I wrote up how the Tallyfy build went in June, so I won’t retell it.

This post carries no traffic, citation or crawler numbers for either site. Every verdict below rests on outside studies and on what the two repositories record about themselves.

Sort the parts by evidence first

“Agent-ready” gets sold as one thing, and it’s two. One is being found: whether Google’s AI answers, ChatGPT or Perplexity pick your page up. The other is being used: whether an agent that has already landed on the page can read it and do what it came to do. Tallyfy’s site rules split it the same way, into a discovery side and a functionality side.

Once you hold the two apart, every part falls into one of three piles.

Both sites are Astro builds on Cloudflare Pages, which is how this site got built in the first place. Anything generated at build time costs almost nothing to keep, so “no evidence it helps” and “delete it” are different decisions. I only made the second one where a part was doing harm or costing upkeep.

Does llms.txt work?

As a way of getting found, the evidence says no, and I keep mine anyway.

Google’s own guide to its AI features, last updated in July 2026, is blunt about it: “You don’t need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn’t use them.” The same page says those features are “rooted in our core Search ranking and quality systems”. It’s still SEO, and what ranks now is mostly proof nobody else could fake.

Ahrefs, which sells SEO tools and studied its own customers’ traffic, counted the fetches on 137,210 domains. 28% publish an llms.txt file, and 97% of those files received zero traffic in May 2026. Slobodan Manić went through the same data on his No Hacks podcast and found the irony in it: of the few requests those files did get, around 22% came from SEO audit tools, the same tools that flag you for not having one.

So why keep it? Two reasons. The build generates it, so it costs nothing. And in the same Ahrefs data, Claude Code was one of the three most active AI readers, behind GPTBot. People pointing coding agents at your docs is a real use, even if it does nothing for search, and I’ve written about which agents read which instruction files for that kind of developer reader.

Schema got the same verdict. Ahrefs tracked 1,885 pages that added JSON-LD and matched them against 4,000 control pages: “Adding schema produced no major uplift in citations on any platform.” I keep the Person and article markup on both sites for rich results and for tying my author pages together. What I removed was a line in tallyfy.com’s own rules that claimed JSON-LD gives 2.5 times more AI citations. It went in August 2026, and a second copy that had survived the first sweep went later the same month. Back in January I’d already taken the homepage review markup off tallyfy.com, because reviews a site publishes about itself aren’t eligible for rich results anyway.

The pages written for AI went furthest. tallyfy.com had a /for-ai/ page, deleted in May 2026 a week after Google’s guide said AI-targeted pages aren’t needed. It also had /for-agents/, about 14,000 words and open to search engines, which I took out of the index and both sitemaps in August. Agents find the tools through the page registering them and through the /.well-known/ files. Nothing finds them through search.

This pile also cost me two small embarrassments. From May to August 2026, this site’s own rules said no llms.txt was generated here, while the file had been live since September 2025. And in August, tallyfy.com’s llms.txt was still listing three pages I’d taken out of search, so a file aimed at machines was advertising pages I’d hidden from them.

WebMCP tools and their upkeep

WebMCP is a Chrome origin trial that lets a page register named tools, each with typed inputs, which an AI agent running in the browser can call directly instead of clicking around the page. tallyfy.com has twelve of them (find a template, work out ROI, check an integration, answer a compliance question, book a demo and so on). This site has seven, mostly for finding posts. The tallyfy.com explainer covers what they mean for a business.

Chrome opened an early preview in February 2026, and developers noticed. A Hacker News thread on it in March drew 360 points and 216 comments, and one reply read “Please don’t implement WebMCP on your site. Support a11y / accessibility features instead.” I didn’t take that advice.

On tallyfy.com the first eleven tools were seen registering in a real browser when they shipped, and a test suite of 94 cases covers their logic. What isn’t proven, on either site, is that any AI agent has ever called one. When I published this site’s tool schemas, the pull request said so: “I did not drive Chrome with the origin trial and confirm an agent reads the new manifest.” Chrome’s documentation offers test extensions that call them, and names no shipping agent that does. The request for Claude in Chrome to discover them is an open issue. Apple’s WebKit team is formally opposed, arguing that “an agent acting on a user’s behalf is, in effect, assistive technology” and should use a site the way a person does.

What I can measure is upkeep, and there’s more of it than the launch posts suggest.

The tallyfy.com set grew from four tools in June 2026 to eleven in July and twelve in August. In August the page was registering twelve while both discovery files still described eleven, so I added a check that fails when they drift. While I was building the search tool, a test query of “zzzz nothing” returned four posts, and “middleware is dead” ranked a post about deadlines first. Both were fixed before it shipped.

Then there’s the token. An origin trial needs a token in every page, and it expires. Chrome ignores an expired one silently: the tools stop existing and nothing errors. I’d built a weekly check that reads the live pages, and on 26 October 2026 it went red with 21 days left. Tracing it turned up five pages that each needed a renewed token (tallyfy.com, its docs, the web app, the signup page and this site), and the check had only been reading three of them. The trial itself has been extended to Chrome 162, so renewing is possible. It’s still a manual step in Chrome’s console, followed by a deploy of every site that carries a token.

None of this is a reason not to build tools. AI does tasks, not jobs, and a WebMCP tool is a task with a name. Treat each one like a TLS certificate: something with an owner, a renewal date and a check that tells you before it lapses.

How would you know any of it worked?

You set that up before you build, and I mostly didn’t.

The case study I wrote in June admits the first gap: there was no Lighthouse baseline from before the work. Its agentic browsing audit averaged 90 on five production pages afterwards, and I can’t tell you how much of that the work earned. The second gap is tool usage. tallyfy.com fires an analytics event every time a tool runs, and this post has no number from it. If I were starting again, I’d want three things in place on day one: a before measurement of the pages, a count of tool calls, and server-log counts of which user agents fetch the machine files.

Where the time clearly pays is the work that serves whoever turns up. On tallyfy.com that meant rewriting accessibility labels as facts (the pricing link in the menu says the prices, not just “see pricing”), moving FAQs into native disclosure elements, and adding a CI check so it stays that way. A screen reader and an agent read the same tree, so that work helps people today whether or not agents ever arrive. That HN commenter had a point. I went through what an AI-assisted accessibility audit finds in more detail elsewhere.

The second thing that pays is one facts file. tallyfy.com’s capabilities.json holds the features, integrations and compliance position, including the certifications Tallyfy doesn’t hold. The compliance, integration, pricing and question tools read from it, and so does the FAQ markup. When a price or a certification changes, there’s one file to edit.

The third is the surfaces agents use after someone logs in, which is where the real work happens. For Tallyfy that’s the MCP server, with over 100 tools in 17 categories, plus a command line tool and workflow connectors. Picking between API, MCP and CLI is a more useful question for most companies than any file on the public site. If you’re weighing this for your own company, my door is open.

Before you add the next machine-readable file to your site, write down how you’d know in six months whether it did anything. If you can’t, put the hours into the accessibility tree instead.