What happens when an AI system can stop reading your site and start doing things on it?

The last post covered llms.txt, a file that tells an AI system what your site is about. There’s another newer convention developing aimed at action instead of description. Nobody has agreed on a name for it yet. Wix calls their version an agentic llms.txt. A separate emerging convention called AGENTS.md does something similar, it lists: the tools an agent can call, the endpoints, the auth requirements, and the rate limits. Another proposal, agents.txt, layers API declarations and MCP server details on top of the same base spec. These are different names for documents with essentially the same goal: to point agents not just at what your site says, but at what it can do.

A descriptive file, llms.txt, is like a table of contents while an action-oriented file would read more like an instruction manual (ie. here’s what an agent can act on, here’s how).

Mastercard already does this with their developer docs, pointing agents straight to the right API endpoint instead of leaving them to guess. Google’s Agent Development Kit does the same for their own coding tools. Both are current and live examples.

For a YMCA, the potential agentic actions could include: find nearby branches, compare membership options, check a class schedule, request counseling information, register for a program, find volunteer opportunities. Right now, a parent walks through those steps themselves, page by page, form by form. Adding an action-oriented layer is what eventually lets an assistant do the finding and the comparing and lead a person straight to the last step: confirming.

The true opportunity in AI is not replacing the person. It is in reducing the friction between “I want this” and “I got this.”

It will happen gradually and purposefully, the same as everything else we’ve talked about: accessible pages, clean structure, sitemaps, schema, and an honest llms.txt. Agents can only act on what they can already read and trust. All the boring, unglamorous groundwork turns out to be the actual prerequisite for the exciting part.

Search engines helped people find a page. What comes next is a system that can complete the task the page was made for.

Post 6, the last in this series. Post 1 introduced AI agents. Post 2 separated ranking, citation, and usability. Post 3 covered UX fundamentals. Post 4 covered sitemaps and schema. Post 5 covered llms.txt. Put together, that’s what “agentic readiness” actually means for a website right now: not a single file or feature, but the whole chain from readable to actionable.

This site is the canonical version. Longer, unedited by a platform’s character limits, and it’ll still be here in five years.

If you found this through a LinkedIn post or a repost somewhere, welcome — this is the source.

How I use this site:

• Full-length articles live here first
• LinkedIn gets the hook and a link back
• Reposts to dev.to / DZone / Hackernoon link back here as the canonical source
• The Press & Reprints page tracks where else things have run

Template note (delete this line and everything below when you publish): copy this file, rename to YYYY-MM-DD-your-post-title.md, update the frontmatter title/date/categories/excerpt, and write below the second ---. Categories currently in use across your content lanes: martech, seo, ai-governance, mission.

Every proposed standard has to earn its adoption. Some do, others sit in limbo for years.

llms.txt is a plain text file, proposed by data scientist Jeremy Howard, that lives at yourdomain.com/llms.txt and gives an AI system a short, markdown-formatted summary of your site: what it is and where to look for more. Instead of the AI guessing at your site’s structure by crawling every page, you hand it a roadmap.

That’s the sales copy. Last year, Google’s John Mueller said no AI system currently uses it. Flavio Longato, LLM strategist at Adobe, audited 30 days of raw server logs across 1,000 domains. GPTBot, ClaudeBot, and PerplexityBot never requested the file. Not once. The traffic that did show up was mostly Google’s crawler and SEO tools, nothing resembling an LLM fetching context.

SEOs argue about this, not always politely. Some call maintaining llms.txt “parroting myths.” Others point out Perplexity doesn’t even respect robots.txt, so expecting it to honor a newer, unofficial file is optimistic. One claim floating around: Claude is the only major LLM that’s actually adopted it, though that doesn’t jibe cleanly with Longato’s own logs.

Here’s the case for it. Crystal Carter at Wix crawled over 1,400 llms.txt files and found real, deliberate use among major players. Anthropic has maintained one since 2024. Google’s Agent Development Kit publishes one so coding tools can use it as context. Weather.com uses one to give agents correct URL structure, and Perplexity has been found citing the file directly, independent of a regular search result.

Broad LLM training crawlers mostly ignore this protocol. Specific agentic tools (some built by the same companies publicly skeptical of it) are actively using it for grounding and instruction.

This is a 600 lb pigeon on a tension wire. We’ve been here before, and the SEO community knows it: everyone said the same thing about robots.txt, right up until suddenly it wasn’t optional anymore.

Not every proposal follows that path. Google Authorship was a real initiative, backed seriously, that died a few years in. And humans.txt, a smaller proposal meant to credit a site’s creators, never became a standard either. It just never went away. You can still find it in the wild with a simple search operator, sitting on sites that adopted it a decade ago and never took it down. llms.txt could go any of those three ways. Nobody knows which yet.

It’s cheap to create and costs nothing to maintain, so there’s little reason not to have one. Treat it as a low-cost bet with genuinely mixed early evidence, running alongside the sitemap and schema work we know matters regardless of how this plays out. But llms.txt is not a strategy.

Post 5 in a series on what AI agents mean for websites. Post 4 covered sitemaps and schema. Next: the agentic version of llms.txt, and what it means to move from machine-readable to machine-actionable.

A sitemap and a schema tag have two different jobs, but most marketers lump them together as “technical SEO stuff.” Let’s pull them apart.

An XML sitemap is a list which tells search engines and AI crawlers which pages exist and when they last changed. Just a URL, and a last-modified date, done.

Without one, some pages just don’t get found. They’re called orphan pages: nothing on the site links to them, so nothing following links ever stumbles onto them. It could be a branch’s holiday hours page or an old program flyer. Invisible to anything crawling by link alone.

A sitemap fixes that by providing a list. It doesn’t replace good internal linking, but it catches what linking misses.

Schema markup does something different. It’s a layer of code that tells a machine what a page actually is, not just what words are on it. This page is a YMCA branch. This one’s a swim lesson program, running on a specific date at a specific location.

Without schema, a machine has to infer all of that from context, the way a human would. With it, the machine is told directly.

That’s more important than it probably sounds. One structured data company found that adding schema and linking entities correctly cut down on a bank’s branches being confused with wrong locations in AI answers. Ambiguous names, shared with other places, kept getting misread. Telling the machine explicitly which entity was which fixed it.

YMCAs have this exact problem. Go to ymca.org and lookup branches named “Downtown,” “Central,” or even “Jefferson.” Without much work you can also find program names that repeat across associations with slightly different meanings each time. A person reading the page in context sorts that out without thinking. A system trying to match an entity to an answer doesn’t have that context to lean on.

One last point here: schema has to match what’s actually on the page. If your markup says a class meets Tuesdays and the visible page says Wednesdays, that mismatch (sometimes called schema drift) teaches the system not to trust your data.

Sitemaps get you found, and schema ensures you’re understood correctly once you are. Neither is new and both deserve a real audit rather than an assumption that they’re already in place.

Post 4 in a series on what AI agents mean for websites. Post 3 covered the UX fundamentals that help both agents and humans. Next: llms.txt, and why it’s worth watching but not overselling.

None of this requires new technology, most of it’s just good practice that’s gone unfinished.

AI agents rely heavily on something called the accessibility tree. It’s the same underlying structure that screen readers use to help blind users navigate a page. Right-click a button on your site, choose Inspect, open the Accessibility tab, and you’ll see exactly what an agent sees. If your “Register” button shows up as a generic, nameless box, that’s the problem.

A lot of the work that makes a site usable for an agent is the same work that makes it usable for a person with a disability, or really, for anyone in a hurry.

Clear, descriptive buttons. Not “Learn More” five times on one page, but something that tells you what happens when you click it.

Form fields with real labels, not placeholder text that vanishes the second you start typing. An agent that sees a blank box with faded gray text can’t tell an email field from a name field once you start typing.

Stable layouts. If a button jumps an inch down the page because a banner loads late, a person recovers without noticing. An agent that already identified a click target at a fixed spot doesn’t. It clicks where the button used to be.

Content that doesn’t depend on JavaScript finishing before it appears. Plenty of sites load the price or the CTA only after a script runs. Some agents render that JavaScript fully. Many don’t, to save time. If it only shows up after the page finishes loading, an agent reading the raw page source never sees it.

Making “Request Information” and “Schedule an Appointment” impossible to miss (I’ve been advocating for this on our mental wellness pages,) instead of buried under three paragraphs of program description. That’s aimed at people who are already anxious and don’t want to hunt for the next step. An agent needs the same clarity: a CTA it can identify without guessing is one it can act on.

Modals that open mid-flow. Maybe a “confirm your session” step or a consent screen appears, and the agent doesn’t register that the page underneath it just changed. It keeps trying to act on a page that isn’t there anymore.

This is all about accessibility and clean UX, the stuff that’s been on every website audit checklist for a decade. None of it is agent-specific advice. The difference now: it costs you an entire category of traffic that can’t route around bad design the way a person can instead of just frustrating a few visitors.

Post 3 in a series on what AI agents mean for websites. Post 1 covered the shift from AI search to AI agents. Post 2 covered why ranking, being cited, and being usable are three different things. Next: making program and location data machine-readable.

A page can rank #1 on Google, get cited by ChatGPT, and still fail once an AI agent tries to use it.

Three definitions. Three different things a website can pass or fail.

SEO means a search engine can crawl the site, understand it, and rank it. It’s been the job for 20-plus years, and most marketing teams have some facility here.

AI visibility means an AI system can understand the organization and cite it as a source. Newer, but teams are starting to pay attention: getting mentioned in a ChatGPT answer or an AI Overview instead of just a search result.

Agentic readiness means an AI agent can use the site to complete a task. And it’s the one almost nobody is testing for yet.

A site can nail the first two and still fail the third.

Picture a YMCA’s swim lesson page. It ranks on page one for “swim lessons near me.” An AI Overview cites it directly, correctly summarizing the age groups and price. By most metrics, that’s a success.

Wix’s AI Search Lab reported a real case just like this: a cookie pop-up sitting on top of the checkout button, and the agent couldn’t work out how to close it.

Now imagine that same failure on the page we just pictured.

It hits a dropdown menu for selecting the child’s age group, one that only populates its options after a specific click. The agent doesn’t click that way. It stalls.

Or the form field itself. A label that says “Participant” with no indication of what that means (the child? the parent? both?). A human infers this from context and photos of families on the page. An agent has none of that context to lean on.

These are small, ordinary pieces of interface friction, built by people, for people, who fill things out on autopilot every day. A person barely notices; they click around, guess, try again. An agent doesn’t have that instinct: it either has a clear path through, or it doesn’t.

SEO and AI visibility are both about being found and understood. Agentic readiness is about being usable, start to finish, by something that can’t ask a human nearby for help.

Most audits check individual pages: does this page load fast, is this page accessible, does this page rank. Fewer walk an entire journey end to end: search, click through, open the form, fill it out, submit, get a confirmation.

Open a browser-based agent such as the Claude Chrome extension, the ChatGPT agent, or Comet (Perplexity). Start clean: no autofill, no saved logins. Give it a plain-language goal, the way a real parent would type it. Don’t help. If it’s going to fail, let it fail, that’s the finding. Note exactly where it hesitates, misclicks, or gives up.

That’s a different kind of audit than most marketing teams have run before. I think it’s the one that’s going to matter more over the next few years.

Post 2 in a series on what AI agents mean for websites. Post 1 covered the shift from AI search to AI agents. Next: which fundamentals matter most for both humans and agents.

For most of internet history, a website’s one job was to help a human find a page.

Search engines became really good at that. You typed in a query, received a ranked list, and then did the reading yourself.

Then AI search showed up as ChatGPT, Perplexity, Google’s AI Overviews, etc. Instead of linking you to a page, these tools read it and hand you a summary. Information in, summary out. The click that used to belong to a website now gets compressed into a paragraph generated somewhere else.

That’s the stage everyone’s talking about right now. I think it’s a warm-up.

AI agents navigate websites. They compare options across sources. They fill in forms and complete transactions, autonomously, without you ever loading the page.

Picture a parent typing this into an assistant:

“Find a swim lesson near me for a six-year-old on Saturday mornings and help me register.”

That’s close to something that already works today. If you run marketing for an organization like a YMCA, that one sentence is worth sitting with, because of everything packed into it.

For an agent to handle this correctly, it has to figure out:

• Which location actually offers swim lessons
• Which class fits a six-year-old (could be “youth,” or “ages 5-12,”)
• Which sessions land on Saturday morning, and whether there’s actual availability
• What eligibility applies: membership status, prerequisite skill level, guardian consent
• Whether the agent can complete registration itself or only start it

Every one of those depends on how clearly an organization’s program, schedule, and eligibility data is structured. That varies a lot across YMCAs today, and most of it was built for a person to scroll through, not a machine to parse.

The marketing question used to be simple: can a parent find a YMCA’s swim lesson page?

Now add this: can an AI system correctly identify the right location, the right class, the right schedule, the right eligibility, and get that parent to registration?

An agent won’t figure out a messy page the way a patient human visitor might. If the age range is buried in a PDF, it stays buried. If three locations describe the same program three different ways, the agent has to guess which one is right, and it might guess wrong.

Ranking well in search results still matters. Being legible to a system that reads your site once, fast, with zero patience for ambiguity, is a newer discipline, and most organizations haven’t started building for it yet.

This is the first post in a series I’m writing on exactly that: what agents need from a website, which fundamentals still matter, how to make program and location data machine-readable, and where this is all heading as agents move from reading pages to acting on them.

Search engines helped people find a page. Agents might soon finish the task the page existed for.

But this is what that meeting should address:

Marketing brings the use case. Not the tool’s marketing copy, the actual task. “We want to draft newsletter content faster” is a use case. “We want to use AI” is not.

IT checks the data path. Where does information go once it enters the tool? Does the vendor store it, train on it, or delete it after the session? This is the question most teams skip, and it’s the one that matters most for tier 3 requests.

Legal checks the exposure. Contracts, data privacy language, anything that touches member consent. For tier 1 requests, this step is negligible. For tier 3, it is core.

The review doesn’t need a monthly meeting. A shared form works: marketing fills in the use case and tier, IT and legal get pinged only when the tier calls for it. Tier 1 never reaches their inbox. Tier 3 always does.

Here we close the gap from my post about the registry spreadsheet. A registry only knows what gets reported to it. Pair it with this review process, and a manager asking their team directly what they’re using twice a year, and the gap starts shrinking.

That’s the framework. A registry that tracks what’s in use. Tiers that sort by risk. A review process that only pulls in legal and IT when the risk calls for it.

This gives your team a place to ask the question before a newsletter goes out with member data in it.

Sorting them into 3 tiers makes the review process fast instead of exhausting.

Tier 1: Low risk. Internal drafting only, first drafts and brainstorming, not the final product. No member data, no financial systems. A staff member using ChatGPT to rough out a newsletter would qualify, since a person still reviews and finalizes it before it goes anywhere. Approval: quick sign-off from a manager, logged in the registry, done.

Tier 2: Medium risk. Member-facing content, no personal data involved. Think social posts, email copy, website text. The output reaches the public, but no names or member records touch the tool. A branch coordinator drafting an Instagram caption sits here. Approval: a short review from marketing leadership before it goes live.

Tier 3: High risk. Anything touching member data, financial systems, or HR records. The newsletter story from post 1 belongs here, member names and complaint details pasted into a tool with no oversight. Approval: sign-off from IT and legal, not just a manager. This tier moves slower on purpose.

The tiers aren’t about slowing everyone down. Most requests land in tier 1, and a quick sign-off clears them the same day. The friction belongs where the risk actually sits.

Next post: how legal, IT, and marketing actually talk to each other before a tool gets approved, and what that conversation looks like in practice.

Skip that. Start with a spreadsheet.

Make these 5 columns:

Tool name. Whatever staff are actually using. ChatGPT, Canva’s AI features, Pet Whisperer AI.

Department. Who’s using it. Marketing, membership, HR, doesn’t matter. If it touches your branch or the org chart, it goes on the list.

Data touched. This is the column that matters most. Member names? Financial info? Nothing at all, just brainstorming copy? Be specific here. “Some data” is not an acceptable answer.

Who approved it. Even if the answer is “no one yet,” write that down. It tells you where the gaps are.

Review date. Decide on a frequency. Set a date to check back as tools change and approvals expire.

That’s it. Just 5 columns on a shared spreadsheet, completed in a single afternoon.

Keep in mind, a registry only tracks what gets entered. It won’t catch a tool that someone starts using, doesn’t report and is never questioned on. That’s a different problem, and it needs a different solution like a manager asking directly or a periodic check of what’s actually installed. Something that doesn’t rely on people volunteering information.

But the registry, unlike a policy document, gives you one place to look when you need an answer fast. And it reveals the gaps once someone finally does ask.

Next post: what to do once you know what’s on the list. Some tools carry more risk than others and treating them all the same is a mistake.