llms.txt

Guía

Cómo preparar un sitio web para agentes de IA

Publicado:

«Listo para agentes» significa tres cosas distintas para tres tipos diferentes de agente de IA — y se apilan. Aquí explicamos exactamente cómo preparamos este validador para agentes, con el código que integramos, para que puedas copiar el patrón.

Hay tres capas independientes. Adopta cualquiera por separado; juntas cubren un crawler que lee tu sitio, un agente que maneja tu UI en el navegador y otro agente que te llama por la red.

Capa 1 — llms.txt: contexto para crawlers

La base. Un llms.txt en texto plano en tu raíz le indica a un crawler de IA qué es tu sitio y qué páginas son relevantes, en orden de prioridad. Se lee en el momento de la solicitud — sin JavaScript, sin protocolo. Empieza aquí: cómo crear uno.

Capa 2 — WebMCP: herramientas para agentes en el navegador

WebMCP permite que una página exponga herramientas invocables a un agente de IA que se ejecuta dentro del navegador, de modo que el agente invoque una acción tipada en lugar de adivinar tu formulario. Hay dos formas, y usamos ambas.

Declarativa — anota un formulario real y el navegador sintetiza una herramienta a partir de él:

<form toolname="open_llms_txt_report"
      tooldescription="Validate a site's llms.txt and open its report.">
  <input name="url" toolparamdescription="Domain or URL to validate">
</form>

Imperativa — registra una herramienta en JavaScript que devuelve datos estructurados directamente:

navigator.modelContext?.registerTool({
  name: "validate_llms_txt",
  description: "Validate a website's llms.txt; returns a 0-100 score and findings.",
  inputSchema: { type: "object", properties: { url: { type: "string" } }, required: ["url"] },
  execute: (input) => fetch("/api/validate?url=" + encodeURIComponent(input.url))
    .then(r => r.json())
    .then(data => ({ content: [{ type: "text", text: JSON.stringify(data) }] }))
});

Protege la llamada imperativa con if (navigator.modelContext) para que sea una operación nula donde WebMCP no esté disponible. Hoy es un origin trial de Chrome, por lo que el alcance real es pequeño — trátalo como una señal de futuro, no como tráfico.

Capa 3 — A2A: un agente invocable por otros agentes

El protocolo Agent2Agent (A2A) permite que otros agentes descubran e invoquen tu servicio. Publicas una tarjeta de agente y la respaldas con un endpoint JSON-RPC:

// GET /.well-known/agent-card.json
{
  "name": "llms.txt Validator",
  "url": "https://llms-txt-validator.dev/a2a",
  "skills": [{ "id": "validate_llms_txt", "name": "Validate llms.txt" }]
}

La url debe apuntar a un endpoint funcional que hable A2A — implementamos el método síncrono message/send, envolviendo la misma lógica de validación como una habilidad. La tarjeta es un contrato, no una metaetiqueta.

La única regla: no publiques una señal que no puedas respaldar

Es tentador colocar una tarjeta de agente vacía o anotaciones de formulario falsas para que una auditoría pase. No lo hagas. Un agente que obtiene tu tarjeta y llama a un endpoint muerto — o invoca una herramienta que no hace nada — pierde la confianza en ti. Cada señal aquí debe resolverse en algo real. Por eso este validador reporta una señal WebMCP o A2A como «presente» solo cuando hay una implementación funcional que la respalda.

Cómo verificar cada capa

Seguir leyendo

Valida tu llms.txt →