How to Make a Website Agent-Ready — and what 100 in the IsItAgentReady really proves

What's the measure?

There is one robots.txt valid and it does not prevent access to content.

How to implement

A text file at the root, with at least one group User-agent and the Directive Sitemap pointing to the absolute index.

In this project

/robots. txt — versioned on public/robots.txt, served as it is.

How to validate

curl -s https://seu-site/robots.txt

What's the measure?

There is one sitemap.xml reachable, with absolute URLs.

The principle

The sitemap is the inventory of what you either to be consumed. The list of exclusions is as important as that of inclusions: administrative area, test pages and internal utilities are not invitations.

In this project

Generated in build by vite-plugin-sitemap, with explicit list of exclusions in vite.config.js. Never handwritten — a manually maintained sitemap differs from the site on the new front page.

How to validate

curl -sI https://seu-site/sitemap.xml you must respond 200 and application/xml.

What's the measure?

The site announces related features in HTTP headerNot just in the body of the document.

The principle

This is the cheapest layer for the agent and the most ignored by the implementer. One HEAD in any URL already delivers the map: no download of page, no HTML parser, no convention to guess. It's also the only layer that works for features that are not HTML.

In this project

Seven relationships in every response, applied by a leader policy in the CDN — I mean, outside the repository. If your website runs in Vercel, Netlify, nginx or Cloudflare, the recipe is that of your stack; the content is the same.

link: </.well-known/api-catalog>; rel="api-catalog",
      </.well-known/ai-catalog.json>; rel="service-desc"; type="application/json",
      </llms.txt>; rel="service-doc"; type="text/plain",
      </llms-full.txt>; rel="describedby"; type="text/plain",
      </cv-for-ai.md>; rel="service-doc"; type="text/markdown",
      </cv.json>; rel="describedby"; type="application/json",
      </.well-known/oauth-protected-resource>; rel="oauth-protected-resource"
vary: Accept

How to validate

Generic example shell

curl -sI https://seu-site/ | grep -i '^link\|^vary'

What's the measure?

The domain publishes DNS records that point to agentic entry points — and the response is validated by DNSSEC.

The principle

Discovered before the first HTTP package. An agent who solves _index._agents. domain already knows where to search without loading Nothing. And here's a rule that documentation implies: No DNSSEC validation does not pass. The record published without a chain of trust is, for the evaluator, a record that any solver on the way could have I made it up.

In this project

Three names (_index, _mcp, _a2a) under _agents., with the area signed. Publication script lives in scripts/setup-dns-aid-route53.sh and the operation in docs/DNS_AID_SETUP.md.

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=_index._agents.seu-site&type=HTTPS&do=1'

AD: true It's the authenticated answer. If you come false, a DNSSEC chain does not close — and no record adjustment solves this.

What's the measure?

A request with Accept: text/markdown receives Markdown; a browser receives HTML. Same URL, different formats.

The principle

Content negotiation is a 1996 mechanism that almost nobody used, and it is Just what the agent needs. The common alternative — publish /pagina.md as separate URL — works, but forces the agent to guess convention and fragment resource identity: two URLs for the same content, two canonical, two places to outdate.

How to implement

A function at the edge of the CDN inspects the header Accept and rewrites Way. Two traps: compare quality values q (a browser sends text/html,…,*/*;q=0.8 and no can receive Markdown), and issue Vary: Accept — without it the CDN delivers the wrong cached version to the wrong client.

In this project

infra/cloudfront-functions/viewer-request.js, with the companies .md generated in public/ by the same pipeline that generates the metadata.

function prefersMarkdown(acceptHeader) {
  if (!acceptHeader) return false;

  var markdownQ = -1;
  var htmlQ     = -1;

  acceptHeader.split(',').forEach(function (part) {
    var tokens = part.trim().split(';');
    var type   = tokens[0].trim().toLowerCase();
    var q      = 1.0;

    for (var i = 1; i < tokens.length; i++) {
      var param = tokens[i].trim();
      if (param.indexOf('q=') === 0) {
        var parsed = parseFloat(param.slice(2));
        q = isNaN(parsed) ? 0 : parsed;
        break;
      }
    }

    if (type === 'text/markdown') {
      markdownQ = q;
    } else if (type === 'text/html') {
      if (q > htmlQ) htmlQ = q;
    }
  });

  return markdownQ > 0 && markdownQ >= htmlQ;
}

How to validate

Generic example both sides of the negotiation need to be tested.

# o agente pede Markdown → deve receber text/markdown
curl -s -H 'Accept: text/markdown' -o /dev/null \
  -w '%{content_type}\n' https://seu-site/pagina

# o navegador NÃO pode receber Markdown → deve receber text/html
curl -s -H 'Accept: text/html,application/xhtml+xml,*/*;q=0.8' -o /dev/null \
  -w '%{content_type}\n' https://seu-site/pagina

This document responds to the same negotiation: /agent-ready. md is the same content without layout.

What's the measure?

If robots.txt treats AI bots — by specific rule or by a joker that reaches them.

Honest Reading

Check here with the message "No AI-specific bot rules; wildcard rules apply to all crawlers including AI bots". That means he passes. for absence of blockage, not for the presence of a rule. Understand this difference is worth more than celebrating the green — if your policy is to be different by agent, you need to write it; the joker doesn't decide anything for you.

In this project

User-agent: * with Allow: /, and exclusions restricted to internal directories.

What's the measure?

Presence of the Directive Content-Signal in robots.txt, declaring the permitted uses of the content.

The principle

robots.txt responds if the bot can fetch. Content Signals responds what he can do after he's searched — three decisions independent: appear in search, be used as source of response, be used to train model. They are different questions and deserve different answers.

In this project

Index yes, serve as input for yes answer, train no.

User-agent: *
Allow: /
Content-Signal: ai-train=no, search=yes, ai-input=yes

Sitemap: https://mauricio.issei.com.br/sitemap.xml
Agentmap: https://mauricio.issei.com.br/.well-known/ai-catalog.json
LLMs: https://mauricio.issei.com.br/llms.txt
LLMs-full: https://mauricio.issei.com.br/llms-full.txt

What's the measure?

Whether the site publishes a key directory that allows checking cryptographically the identity of a bot by HTTP message signature.

The principle

O User-Agent is a string that any client writes. Web Bot Auth replaces statement by proof: bot signs request, and site validates against the published key. It's the difference between say who is a known agent and demonstrate It is.

State here

Neutral — not implemented. Makes sense to the needy distinguish legitimate bot from copycat and apply different policy to each. For a public content site, whose Content Signal is already the same for everyone, Doesn't change any decisions. A neutral check does not penalize the note — and it is precisely That's why he doesn't vouch for anything. View the score limits.

The principle

One linkset: for each resource (anchor), which links typed people exist. A machine-readable specification (service-desc), prose documentation (service-doc), the state (status). The agent finds out API and how to understand it in a single request.

{
  "linkset": [
    {
      "anchor": "https://seu-site/dados.json",
      "service-desc": [
        { "href": "https://seu-site/openapi.json",
          "type": "application/openapi+json;version=3.0" }
      ],
      "service-doc": [
        { "href": "https://seu-site/dados.md", "type": "text/markdown" }
      ]
    }
  ]
}

The principle

Agent authentication has two faces. A host needs metadata: which authorization server, which scopes, where is the policy of privacy. O agent need instructions in prose — auth.md is literally this: a Markdown document describing the flow, to be read by those who reason in natural language.

It goes for anonymous access, too. "No credentials are required, and these are the available scopes" is a useful statement — prevents the agent from trying a flow that doesn't exist.

{
  "resource": "https://mauricio.issei.com.br",
  "authorization_servers": ["https://mauricio.issei.com.br"],
  "scopes_supported": ["cv:read", "projects:read", "profile"],
  "bearer_methods_supported": ["header"],
  "resource_documentation": "https://mauricio.issei.com.br/cv-for-ai.md",
  "resource_policy_uri": "https://mauricio.issei.com.br/privacidade"
}

The authorization document of this website declares anonymous identity explicitly. The exact format — and why it cost three iterations of deploy — is in the case of agent_auth.

The principle

One skill It is a procedure, not given: "how to make X in this domain", written to be loaded in the context of an agent. The index points to each SKILL.md and brings the digest SHA-256 file — Agent checks that he carried what the index promised, not something exchanged in Way. Instruction entering the context of a model is the surface of attack; digest is what makes it verifiable.

In this project

Two skills — conventions from this repository and access to structured curriculum data — each with digest.

{
  "$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
  "skills": [
    {
      "name": "cv-data-access",
      "type": "skill-md",
      "description": "How to retrieve and parse structured CV data…",
      "url": "https://mauricio.issei.com.br/.well-known/agent-skills/cv-data-access/SKILL.md",
      "digest": "sha256:95a3d61a86da45cae9037e0f4f7d41a64a37cc4f2a61567791b95c2f5a2178ec"
    }
  ]
}

The principle

The other eight layers are static: published documents that the agent reads from Out. WebMCP is the only in execution time — the page records tools in the browser, and an agent running in there can invoke them with user session, without intermediate server.

It is proposed in evolution, so the record goes after a test of existence. No navigator.modelContextNothing happens and the page is identical.

if (typeof navigator.modelContext !== 'undefined') {
    const controller = new AbortController();
    const signal = controller.signal;

    navigator.modelContext.registerTool({
        name: 'get_cv_data',
        description: 'Retrieve the full structured curriculum vitae in JSON format.',
        inputSchema: { type: 'object', properties: {} },
        execute: async () => {
            const response = await fetch('/cv.json');
            return await response.json();
        }
    }, { signal });
}