# Web Bot Auth: qué es y cómo firma un bot sus peticiones > Qué es Web Bot Auth, el borrador del IETF para que bots y agentes de IA firmen sus peticiones HTTP, quién lo usa ya y cómo se verifica una firma. URL: https://clione.ai/es/glosario/web-bot-auth/ Lang: es Hoy un bot se presenta con su [_user agent_](/es/glosario/user-agent/), un nombre que escribe él mismo. Por eso Google explica cómo verificar a sus [rastreadores](/es/glosario/rastreador/): para el caso de que alguien acceda a tu sitio **haciéndose pasar por Google**.[^google-verify] Web Bot Auth es la propuesta para cerrar ese hueco con criptografía: el bot firma cada petición y tu servidor, o tu CDN, comprueba la firma. A una tienda le importa por una razón práctica: la decisión de a quién dejar entrar la toma cada vez más un cortafuegos, y un agente que compra por un cliente y un _scraper_ que se disfraza de él no deberían recibir el mismo trato. ## Cómo funciona La base es un estándar ya publicado, el RFC 9421 (febrero de 2024), que describe cómo crear, codificar y verificar firmas digitales sobre partes de un mensaje HTTP. Define dos cabeceras: `Signature-Input`, que dice qué partes del mensaje cubre la firma y con qué parámetros, y `Signature`, que lleva la firma. Su objetivo es **dar integridad y autenticidad de extremo a extremo** a esas partes, incluso cuando el mensaje pasa por intermediarios.[^rfc9421] Web Bot Auth es un perfil de ese estándar para el tráfico automatizado. El documento del grupo de trabajo, _HTTP Message Signatures for automated traffic_, firmado por Thibault Meunier (Cloudflare) y Sandor Major (Google), describe un protocolo para que los clientes HTTP automatizados se identifiquen criptográficamente, y añade tres piezas:[^ietf-httpsig-bots] - **La cabecera `Signature-Agent`**, que apunta a una URL HTTPS donde están las claves del firmante. - **Un directorio de claves** en formato JWKS (_JSON Web Key Set_), publicado en `/.well-known/http-message-signatures-directory` del dominio del firmante, servido por HTTPS y solo con un 200. Es una ruta del [directorio .well-known](/es/glosario/well-known/). - **Unas reglas para la firma**: la etiqueta `tag="web-bot-auth"`, la firma tiene que cubrir al menos el dominio de destino (`@authority` o `@target-uri`), y lleva fecha de creación, fecha de caducidad (se recomienda **un máximo de 24 horas**) y el identificador de la clave. Un `nonce` opcional protege contra la reutilización de una petición firmada. Para verificar, quien recibe la petición lee `Signature-Agent`, descarga el directorio de claves, busca la clave por su identificador y comprueba la firma según el RFC 9421.[^ietf-httpsig-bots] ### En qué punto está El IETF creó un grupo de trabajo, webbotauth, para estandarizar métodos que autentiquen criptográficamente a los clientes automatizados y den más información sobre quién los opera. Su carta deja fuera, entre otras cosas, autenticar al usuario final de un agente, **seguir a los bots o asignarles reputación**, y distinguir de las personas a los bots que no participan. El calendario preveía las especificaciones de autenticación para el 30 de abril de 2026.[^ietf-wg-charter] El documento de grupo llegó después: es la versión 00, del 1 de septiembre de 2026, y caduca el 5 de marzo de 2027. Los dos borradores individuales que lo precedieron, el de arquitectura y el del directorio, figuran como sustituidos, con su última versión del 2 de marzo de 2026.[^ietf-wg-docs][^ietf-httpsig-bots] Y es un _Internet-Draft_: un documento de trabajo válido seis meses como máximo, que **puede actualizarse, sustituirse o quedar obsoleto en cualquier momento**.[^ietf-httpsig-bots] ## Quién lo usa ya - **Google.** Firma con Web Bot Auth una parte de las peticiones de Google-Agent, el agente que usan los sistemas alojados en la infraestructura de Google para navegar por la web y hacer acciones a petición de un usuario. Lo marca como experimental, porque la especificación es un borrador que puede cambiar, y recomienda **seguir comprobando también la IP, el DNS inverso y el _user agent_** mientras extiende el tráfico firmado.[^google-wba] Como recogedor activado por usuarios, Google-Agent por lo general no sigue las reglas de [robots.txt](/es/glosario/robots-txt/).[^google-user-fetchers] - **Cloudflare.** Usa Web Bot Auth como uno de los métodos para verificar bots y agentes firmados, exige claves Ed25519 y permite al operador del bot registrar su directorio de claves desde el panel. Según su documentación, **el dueño del sitio no tiene que hacer nada**: Cloudflare valida las firmas de los bots registrados.[^cloudflare-wba] Su documentación clasifica los bots verificados según cómo se operan: directamente o a través de un intermediario.[^cloudflare-signed-agents] ## En una tienda Así llegaría una petición firmada de Google-Agent a la ficha de una tienda **ejemplo ficticio**. La estructura sigue el ejemplo del borrador y el valor de `Signature-Agent` es el que documenta Google; las fechas, el identificador de la clave y la firma son inventados:[^ietf-httpsig-bots][^google-wba] ```http GET /productos/moka-inox-6 HTTP/1.1 Host: cafeteras-ejemplo.es User-Agent: Mozilla/5.0 (X11; Linux x86_64) ... (compatible; Google-Agent) Signature-Agent: g="https://agent.bot.goog" Signature-Input: g=("@authority" "signature-agent";key="g");created=1791273600;expires=1791277200;keyid="ejemplo-clave";tag="web-bot-auth" Signature: g=:ZmlybWEtZGUtZWplbXBsbw==: ``` Línea a línea: `User-Agent` es lo que el bot dice ser y no prueba nada. `Signature-Agent` dice dónde están sus claves: `https://agent.bot.goog/.well-known/http-message-signatures-directory`.[^google-wba] `Signature-Input` dice que la firma cubre el dominio de la tienda y la propia cabecera `Signature-Agent`, con una validez de una hora. Si alguien copia la petición para otra web, la firma deja de valer, porque cubría `cafeteras-ejemplo.es`. Si alguien inventa la firma, no la puede generar sin la clave privada. Tratar Web Bot Auth como un estándar terminado y quitar el resto de comprobaciones. Es un borrador del IETF,[^ietf-httpsig-bots] Google solo firma una parte de las peticiones de un agente y pide **mantener la verificación por IP, DNS inverso y _user agent_**.[^google-wba] Un bot que no firma no es por eso un impostor: la firma es una prueba más, todavía parcial. ## Cómo comprobarlo 1. **Pregunta a tu CDN o a tu plataforma si verifica Web Bot Auth.** Si estás detrás de Cloudflare, la verificación la hace Cloudflare con los bots registrados.[^cloudflare-wba] 2. **Busca la cabecera `Signature-Agent`** en los registros de tu servidor o de tu CDN, si guardan las cabeceras de la petición. Su valor te dice qué firmante declara la petición. 3. **Abre un directorio de claves**, por ejemplo el de Google en `https://agent.bot.goog/.well-known/http-message-signatures-directory`, para ver qué publica un firmante.[^google-wba] 4. **Mantén la verificación por DNS inverso y rangos de IP** para [Googlebot](/es/glosario/googlebot/) y el resto de rastreadores de Google.[^google-verify] 5. **Consulta el estado del borrador en el Datatracker del IETF** antes de construir nada a medida: la versión vigente es la 00, de septiembre de 2026.[^ietf-wg-docs] ## Concepto cercano: user agent El _user agent_ es una declaración; Web Bot Auth es una prueba. Los dos viajan en la misma petición y responden a la misma pregunta, quién llama, con distinto grado de confianza: el primero lo escribe el cliente, la segunda solo la puede producir quien tiene la clave.[^rfc9421] Ninguno de los dos decide qué hace tu tienda con esa visita. Eso sigue siendo cosa de tu `robots.txt`, de tus reglas de [bloqueo de bots de IA](/es/glosario/bloqueo-de-bots-de-ia/) y de tu [negociación de contenido](/es/glosario/negociacion-de-contenido/), que decide qué versión recibe. Para seguir, la entrada sobre [caché y CDN para bots](/es/glosario/cache-cdn-bots/) explica qué pasa con esas peticiones antes de llegar a tu servidor, y la [ruta de lectura](/es/aprender/rastreo-e-indexacion/) de rastreo e [indexación](/es/glosario/indexacion/) ordena el resto de términos.