AI agents are becoming a real audience for institutional websites, and they do not see your visual design. They read structure: semantic HTML, heading hierarchy, labeled forms, and the accessibility tree, the same machine-readable layer assistive technology uses. You do not need an “agent experience” redesign. The work that makes a site legible to agents is the work that serves humans and accessibility, and for public institutions it is already on a regulatory timeline.
The agentic web is showing up in vendor decks and conference keynotes, usually attached to the suggestion that everything about your website must change. AI agents that browse on a user’s behalf, fill out forms, compare options, complete tasks. Google and Microsoft are building the standards for it. The pitch writes itself: your site was designed for people, and your next visitor will not be one.
Something real is happening here. And the response it calls for has been on your list for years.
What an agent actually sees
Agents do not experience your brand. They read structure. According to Google’s own guidance for building agent-friendly websites, agents view sites in three ways: screenshots, raw HTML, and the accessibility tree.
The third one deserves your attention. The accessibility tree is the browser’s machine-readable summary of a page: the roles, names, and states of every meaningful element, stripped of visual styling. It exists because screen readers and other assistive technology need it. Agents use it for the same reason assistive technology does: it is the version of the page that says what things are.
This is now stated policy at the major platforms. OpenAI’s publisher documentation says ChatGPT’s browsing agent uses ARIA tags, the same labels and roles that support screen readers, to interpret page structure, and directs publishers to follow WAI-ARIA best practices. Microsoft’s browser automation tooling feeds agents accessibility snapshots rather than screenshots. Google’s developer guidance frames the whole project of agent-readiness as a reason to recommit to well-structured, semantic, accessible websites.
Consider what that means for a typical program page. The hero video, the carefully chosen photography, the brand color system: invisible to this audience. What the agent gets instead: your headings, your links as labeled paths, your request-information form as a set of fields that either have real names or do not. A <button> tells an agent what it is. A <div> styled to look like a button tells it nothing.
The question behind the question of UX and the agentic web
So, do you need to rethink UX for the agentic web?
Mostly, no. You need to finish the UX work you already had on your to-do list.
Semantic markup. Logical heading order. Labeled forms. Meaningful link text. Structured data. These have been web fundamentals for two decades and accessibility requirements for nearly as long. What changed is the audience: the same machine-readable layer now serves three groups at once. People, assistive technology, and agents.
Institutions that treated accessibility as a compliance checkbox are about to discover it was also their agent-readiness program. One audience’s requirement is another audience’s protocol.
For public institutions, this convergence has a date attached. The Department of Justice extended the ADA Title II web accessibility deadlines this spring: public entities serving populations of 50,000 or more, which includes most public colleges and universities, must conform to WCAG 2.1 Level AA by April 26, 2027, with smaller entities following in 2028. The technical standard did not change, only the dates. Public institutions are, on a regulatory timeline, already doing the structural work the agentic web rewards.
WebMCP, briefly
The clearest signal of where this is heading came at Google I/O 2026, where Google and Microsoft proposed WebMCP, a standard now incubating with the W3C that lets websites expose actions directly to browser agents: search this catalog, start this inquiry, book this visit.
The design detail that matters for this argument: WebMCP’s simpler path works by annotating existing HTML forms. The standard assumes well-structured markup as its foundation. A site with semantic, labeled forms is halfway to agent-actionable before writing a line of new code. A site where every interaction is custom JavaScript on unlabeled elements is not.
WebMCP is experimental: Chrome-first, with other browsers participating in the standards process but uncommitted. The same discipline we applied to llms.txt applies here. Do not rebuild anything for a standard still in trial. Notice, instead, what the standard’s architecture is telling you about which existing investments will carry forward.
Agents do not experience your brand. They read structure.
What this means for page structure
Concretely, structure affects agent legibility in five places, and every one of them also serves your human visitors:
Heading hierarchy. Your H1-to-H4 structure is the agent’s outline of the page, the same way it is a screen reader user’s outline and a search engine’s. A page with one clear H1 and headings that nest logically can be summarized and navigated. A page with five H1s for visual effect cannot. (The same argument as our guide to H1 tags, extended to a new audience.)
Self-contained sections. Agents extract. A section that makes sense lifted out of the page, with its own heading and complete information, survives extraction. A section that only works in visual context does not.
Forms with real labels. Every field in your RFI form, application starter, and visit scheduler either has a programmatic label or it does not. Placeholder text that disappears on focus is not a label, for a screen reader or for an agent trying to complete the form on a family’s behalf.
Structured data. Schema markup is the explicit version of what your markup implies: this is a degree program, this is its cost, this is the deadline. Agents, like AI search, prefer not to guess.
Content models that express relationships. A program page that links its outcomes, faculty, and student stories in a traversable way gives an agent (and an AI search engine) a map. A site of one-off pages gives it a pile.
Institutions that treated accessibility as a compliance checkbox are about to discover it was also their agent-readiness program.
What not to do
Do not commission an “agent experience” redesign. The agentic web is being built in public and arriving unevenly, and nobody can tell you yet which patterns will matter in two years.
No need to build agent-specific parallel content. Serving machines a different version of your site than humans see is a maintenance burden at best and a cloaking risk at worst.
Don’t turn your entire site into markdown files. Every worthwhile move in this post serves your current human visitors first. That is what makes them no-regrets: if the agentic web arrives slower than its builders hope, you have a faster, more accessible, better-structured site. If it arrives on schedule, you are ready for it.
Every worthwhile move here serves your current human visitors first.
A five weekly questions
Run this against your own site this week. Each question is answerable with free tools in about an hour.
- Does every page have one H1 and a heading hierarchy that nests logically? Check with any heading-outline browser extension.
- Do your key forms (RFI, application, visit) have programmatic labels on every field? Tab through them with a screen reader, or inspect the accessibility tree in Chrome DevTools.
- Do your program pages carry structured data? Test with Google’s Rich Results tool.
- When was your last accessibility audit, and did it cover structure, not just contrast? If the answer is “before the Title II rule,” it is due.
- Can a section of your most important page be lifted out and still make sense? Copy a section into a blank document. If it needs the rest of the page to be intelligible, an agent has the same problem.
Mostly yes: your site is in better agentic-web shape than most.
Mostly no: the to-do list is the same one accessibility and SEO have been handing you, now with a third reason attached.
The visitor is changing. The fundamentals are not.
Your next website visitor may be an agent acting for a student or a parent. It will not see the design your committee debated. It will see the structure underneath: the headings, the labels, the markup, the relationships. The institutions in the best position for that visitor are not the ones that chased a new discipline. They are the ones that finished the old one.
That structural layer is what we examine in accessibility and UX work with institutions, and it is the same layer that determines AI search visibility. Three audiences, one investment. Build it once, clearly named and clearly structured, and all three can read it.
Not Sure Where Your Institution Stands?
iFactory’s AI Search Readiness Audit evaluates whether tools like ChatGPT, Perplexity, Google AI Overviews, and Claude can find, understand, and recommend your institution to prospective students.
Frequently asked questions about what AI agents see
One. The best practice is a single H1 per page, naming the page’s main topic. HTML5 technically allows multiple H1s inside separate sectioning elements, and Google has said it can handle them without penalty, but multiple H1s are not a goal. For higher education pages, one clear H1 keeps the topic unambiguous for search engines, screen readers, and AI systems.
The H1 appears on the page itself; the title tag appears as the clickable headline in search results and the browser tab. They should be similar in topic but not identical. The title tag often carries a little more, such as the institution name or location. If your H1 is “Nursing programs,” your title tag might be “Boston Nursing Programs | College Name.”
Yes. The H1 is one of the clearest signals a page gives search engines about its topic, which helps the page rank for relevant queries. It also helps visitors confirm in seconds that they are on the right page, and that engagement reinforces the page’s relevance. A page whose content strays from its H1 tends to rank lower and lose visitors back to search results.
You can, and Google will not penalize you for it, but it is not recommended. Multiple H1s blur the signal of what the page is primarily about. If a page seems to need two H1s, that often means it is really two topics and would serve users better as two focused pages. Note that some page builders and CMS templates emit a stray H1 in a header or banner without anyone noticing, so it is worth checking your template.
They form a hierarchy that acts as an outline of the page. The H1 is the main topic, H2s are the major sections beneath it, and H3s are subsections within those. Used in order without skipping levels, this structure lets search engines, screen readers, and AI systems follow the page the way a person skims it. Headings should be chosen for structure, not for making text bigger, which is a styling decision.
