Everything You Need to Know About Agentic Navigation

Agentic Navigation is a new category (which you've probably already noticed) that's being used in Google's Pagespeed Insights and - obviously - in the Lighthouse library too. This is a watershed moment for this analysis engine, because before the focus was exclusively on the human user's experience, and now there's a (for now) small space to measure how "readable" your site is to artificial intelligence agents.

Real case: A client called me in the morning and told me he was surprised, because he went to do a quote for a structural renovation at someone's house, and during the interview they asked her if she had gotten any referral. The answer was surprising and funny: Claude.

Yes, just like that, "Claude". As if it were a mutual friend. This shows we're on a no-return path, either you keep up, or you might lose important business.

What does this have to do with Agentic Navigation? I have no idea, but that it's a very funny fact, it is.

Okay, back to the subject! This new analysis category has four pillars:

WebMCP

Does the site expose structured tools to agents?

Here we have the core of this whole change, WebMCP is the standard proposed by Google, which will allow developers to expose the site's features directly to the AI. Your site will walk up to the AI and say "hey, buddy! No need to scrape, the treasure map is right here...".

According to the official documentation, "WebMCP can help close the gap between web applications and agents, improving efficiency, reliability, and task completion by providing rules for interaction. Instead of an agent parsing the element, like a button or a field, to understand its purpose, the site declares the element's purpose, so that it's used correctly.".

The site will explicitly declare its capabilities to the agents, via json schema or declarative html (the same way Schema.org does). This will make it easier for the agent to perform tasks without going crazy (aka. hallucinating) and getting everything wrong. Like in the simple and rudimentary example below:

// Registering a tool via JS
document.modelContext.registerTool({
  name: 'search_flights',
  description: 'Searches available flights between two cities on specific dates.',
  inputSchema: {
    type: 'object',
    properties: {
      origin: { type: 'string', description: 'IATA code of the origin city (e.g. GRU)' },
      destination: { type: 'string', description: 'IATA code of the destination (e.g. JFK)' },
      date: { type: 'string', format: 'date' },
      class: { type: 'string', enum: ['economy', 'business', 'first'] }
    },
    required: ['origin', 'destination', 'date']
  },
  execute: async ({ origin, destination, date, class: travelClass }) => {
    // Site's internal logic to call your backend API
    const results = await myFlightsApi(origin, destination, date, travelClass);
    return JSON.stringify(results); // Structured return for the AI
  }
});

Interesting things in this js:

• inputSchema uses the JSON Schema standard to validate the AI's input even before the function runs, reducing processing errors.
• execute is an async function, the return is sent back to the AI's "thinking".

In this lifecycle, you can use an AbortController to disable the tool dynamically (when the user logs off, for example).

And look, you can do it right in the html, like in the example below:

<form 
  toolname="requestSupport" 
  tooldescription="Submits a technical support ticket to the team."
  toolautosubmit="true"
  action="/api/support"
>
  <label for="type">Issue Type:</label>
  <select name="type" toolparamdescription="Technical issue category.">
    <option value="login">Access Issue</option>
    <option value="payment">Billing Error</option>
  </select>
  <label for="msg">Description:</label>
  <textarea name="msg"></textarea>
  <button type="submit">Submit Ticket</button>
</form>

Interesting things in this form:

• toolname and tooldescription identify the tool to the AI model.
• toolparamdescription helps the AI understand what each form field expects, increasing fill-in accuracy
• toolautosubmit, if set to true, tells the AI it can fill in and submit the form without human intervention (useful for fully autonomous tasks).

You can also react when an AI interacts, using the toolactivated event:

window.addEventListener('toolactivated', (event) => {
  console.log(`A ferramenta ${event.toolName} foi ativada por um Agente de IA.`);
});

On the official site you can get to know it in much greater depth, read all the parameters, as well as learn the security concepts to prevent the AI from performing malicious actions.

Important Notice!

WebMCP is still experimental — it doesn't run "for free" in PageSpeed Insights. WebMCP support is experimental, requires Chrome 150 or later, and the WebMCP audits only work if you register your origin for the origin trial. To enable it, you need a token. The flow is the same as any Chrome origin trial, grab the token generated for your origin, and drop it into a meta tag in the <head> of every page:

<meta http-equiv="origin-trial" content="{YOUR TOKEN HERE}">

To play around locally without a token, you can flip the flag at chrome://flags/#enable-webmcp-testing. Is all this hassle worth it? Absolutely, it's not just promising: it's the natural direction, and the race has already started. Better to be ready ahead of time.

The llms.txt file

Is there a context guide for the AI at the domain root?

Having a robots.txt isn't enough anymore, now you need an llms.txt, which will serve as a map for the AI to understand your site without getting lost along the way. Take a look at this official example:

# Title

> Optional description goes here

Optional details go here

## Section name

- [Link title](https://link_url): Optional link details

## Optional

- [Link title](https://link_url)

The documentation makes it clear: "While sitemaps list all pages for search engines, llms.txt offers a curated overview for LLMs" and "robots.txt and llms.txt have different purposes—robots.txt is generally used to let automated tools know what access to a site is considered acceptable ... On the other hand, llms.txt information will often be used on demand when a user explicitly requests information about a topic, such as when including a coding library’s documentation in a project, or when asking a chat bot with search functionality for information".

Your llms.txt will be a context file, a usage guide and a curation of your site's content. There's a complete example from FastHTML, which you can read in full.

The most ironic part is that the project uses a .txt that writes .md. Counterintuitive, right? Definitely, but there's a reason for it: the infrastructure spread across the web is absurdly legacy, using .txt is a way to bring universal compatibility and ease of configuration on those servers from Dante's era.

Accessibility tree

Does the accessibility structure allow navigation by machines?

Agents need accessibility too! The good news is that if you already follow the best practices of the accessibility tree, your site should already be 100% adjusted for this: semantic tags in the right place, organization of titles and subtitles, forms with declared labels, and so on.

I'll be honest with you: this pillar and the next one don't have much to cover. They're two fields that already existed and were already documented well before Agentic Navigation showed up, they're nothing new. I'm mentioning them because they're part of the category, but I'm not going to dive deep into them - that would be reinventing the wheel.

Cumulative Layout Shift

Is the layout stable enough for an agent to click with precision?

As I warned up above, nothing changes here either! If your site has a good CLS for a human, it'll be good for the agent too! One less thing to worry about.

Conclusion

Looking at the four pillars together, you can notice an important thing: two of them you already get for free if you already do frontend well. Accessibility tree and CLS are old homework, if you take care of the human user's experience, the agent inherits that without you lifting a finger.

The llms.txt is an afternoon's work, at most (I'm building a generator to have less work with this 🫣). The real game changer is WebMCP, and that's where it's worth investing energy right now.

The web is starting (or forcing, which doesn't matter, if the result is going to be the same) to treat agents as first-class citizens, not as "scrapers we tolerate". In a few years, having a well-designed WebMCP will be as basic as having a robots.txt is today - and whoever gets there first will reap the rewards of agents that choose your site because it's the easiest to use.