¿Qué es Web Bot Auth y cómo firma un bot sus peticiones?

Hoy un bot se presenta con su user agent, un nombre que escribe él mismo. Por eso Google explica cómo verificar a sus rastreadores: para el caso de que alguien acceda a tu sitio haciéndose pasar por Google.⁠^{[1]Google Search Central. Verifying Googlebot and other Google crawlers} 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.⁠^{[2]IETF, RFC Editor (febrero de 2024). RFC 9421: HTTP Message Signatures}

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:⁠^{[3]IETF, grupo de trabajo webbotauth (Meunier y Major, 1 de septiembre de 2026). HTTP Message Signatures for automated traffic (draft-ietf-webbotauth-httpsig-protocol-00)}

• 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.
• 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.⁠^{[3]IETF, grupo de trabajo webbotauth (Meunier y Major, 1 de septiembre de 2026). HTTP Message Signatures for automated traffic (draft-ietf-webbotauth-httpsig-protocol-00)}

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.⁠^{[4]IETF Datatracker. Web Bot Auth (webbotauth): carta del grupo de trabajo}

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.⁠^{[5]IETF Datatracker. Web Bot Auth (webbotauth): documentos del grupo de trabajo}⁠^{[3]IETF, grupo de trabajo webbotauth (Meunier y Major, 1 de septiembre de 2026). HTTP Message Signatures for automated traffic (draft-ietf-webbotauth-httpsig-protocol-00)} 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.⁠^{[3]IETF, grupo de trabajo webbotauth (Meunier y Major, 1 de septiembre de 2026). HTTP Message Signatures for automated traffic (draft-ietf-webbotauth-httpsig-protocol-00)}

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.⁠^{[6]Google Crawling Infrastructure. Authenticate requests with Web Bot Auth (experimental)} Como recogedor activado por usuarios, Google-Agent por lo general no sigue las reglas de robots.txt.⁠^{[7]Google Crawling Infrastructure. Google's user-triggered 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.⁠^{[8]Cloudflare, documentación de Bots. Web Bot Auth} Su documentación clasifica los bots verificados según cómo se operan: directamente o a través de un intermediario.⁠^{[9]Cloudflare, documentación de Bots. 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:⁠^{[3]IETF, grupo de trabajo webbotauth (Meunier y Major, 1 de septiembre de 2026). HTTP Message Signatures for automated traffic (draft-ietf-webbotauth-httpsig-protocol-00)}⁠^{[6]Google Crawling Infrastructure. Authenticate requests with Web Bot Auth (experimental)}

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.⁠^{[6]Google Crawling Infrastructure. Authenticate requests with Web Bot Auth (experimental)} 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.

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.⁠^{[8]Cloudflare, documentación de Bots. Web Bot Auth}
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.⁠^{[6]Google Crawling Infrastructure. Authenticate requests with Web Bot Auth (experimental)}
4. Mantén la verificación por DNS inverso y rangos de IP para Googlebot y el resto de rastreadores de Google.⁠^{[1]Google Search Central. Verifying Googlebot and other Google crawlers}
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.⁠^{[5]IETF Datatracker. Web Bot Auth (webbotauth): documentos del grupo de trabajo}

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.⁠^{[2]IETF, RFC Editor (febrero de 2024). RFC 9421: HTTP Message Signatures} 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 y de tu negociación de contenido, que decide qué versión recibe.

Para seguir, la entrada sobre caché y CDN para bots explica qué pasa con esas peticiones antes de llegar a tu servidor, y la ruta de lectura de rastreo e indexación ordena el resto de términos.