Qué implica Web Bot Auth si ya bloqueas los rastreadores de IA

TL;DR: Web Bot Auth aplica las firmas de mensajes HTTP de la RFC 9421 al tráfico de los rastreadores. Los bots firman sus solicitudes con una clave privada, publican las claves públicas en un directorio .well-known y te permiten verificar la firma en lugar de fiarte de la cabecera User-Agent. Google publica las claves en agent.bot.goog para su agente de navegación con IA; el Googlebot tradicional aún no firma. El trabajo para 2026 es añadir una ruta de verificación de firma sin arrancar el reverse-DNS, porque la mayor parte del tráfico que dice ser de Google sigue sin firmar y lo estará, como mínimo, un año más.

Un operador con el que colaboro escribió en 2024 una regla WAF en Cloudflare. Bloquea todo lo cuyo UA contenga GPTBot, ClaudeBot o PerplexityBot y permite todo lo cuyo UA contenga Googlebot. La regla aguantó dos años. Luego, en la primavera de 2026, apareció en los registros de acceso un nuevo agente de usuario, Google-Agent, con tres cabeceras desconocidas: Signature-Agent, Signature-Input y Signature. La norma de 2024 no opinaba sobre esas cabeceras; solo miraba el UA. Ese hueco entre reglas escritas con el modelo de verificación antiguo y el tráfico que llega con el nuevo es de lo que trata este artículo. No va de “qué es robots.txt” ni de “si deberías bloquear rastreadores de IA”. Es la pieza de integración para operadores que ya mantienen un conjunto de reglas de bot-policy y necesitan saber qué cambia Web Bot Auth.

Qué es realmente Web Bot Auth

Web Bot Auth es un perfil adaptado a bots de las firmas de mensajes HTTP RFC 9421. El bot firma cada solicitud saliente con una clave privada. El sitio recupera la clave pública del bot desde una URL .well-known/http-message-signatures-directory en un dominio que controla el bot. El sitio verifica que la firma de la solicitud entrante se haya generado con la clave privada correspondiente. Si encaja, el origen de la petición queda atestado criptográficamente. Si no, la solicitud es falsa.

El trabajo lo hacen tres cabeceras nuevas. Signature-Agent apunta al directorio de claves del bot. Signature-Input enumera lo que se firma más metadatos: keyid, marcas de tiempo created y expires, algoritmo y la cadena literal tag="web-bot-auth" que indica que es una firma de bot (no otro caso de uso de la RFC 9421). Signature porta los bytes criptográficos.

"This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message." — A. Backman, J. Richer, M. Sporny, RFC 9421 (HTTP Message Signatures, abstract)

El perfil de bot sobre la RFC es lo que convierte esto en Web Bot Auth y no simplemente firmas de mensajes HTTP. El borrador IETF draft-meunier-web-bot-auth-architecture fija las convenciones: la cadena tag="web-bot-auth" en el input, la forma de la URL del directorio well-known, los componentes recomendados a cubrir (al menos @authority y signature-agent) y la expectativa de que el directorio se almacene en caché según su propia cabecera Cache-Control. Nada de eso está en la RFC 9421. La RFC es el álgebra; Web Bot Auth, el caso de uso.

Por qué la verificación UA + IP dejó de ser suficiente

La pila de verificación tiene tres capas, cada una con un fallo conocido. User-Agent es texto; cualquiera puede ponerlo. El reverse DNS funciona para Googlebot, pero es incómodo para agentes más nuevos que salen por infra generalista. Las listas de IP son frágiles porque los rangos de egress en la nube cambian sin aviso.

Johannes Ullrich, del SANS Internet Storm Center, resumió el problema de suplantar el UA de manera tajante:

"Users have long figured out that setting your user agent to 'Googlebot' may get you past some paywalls." — Johannes Ullrich, SANS Internet Storm Center, septiembre 2025

El allowlist de IP tiene un problema distinto pero relacionado. Thibault Meunier y Mari Galicer, de Cloudflare, artífices de la propuesta Web Bot Auth en la IETF, lo plantearon así en mayo de 2025: "connections from the crawling service might be shared by multiple users, such as in the case of privacy proxies and VPNs, and these ranges, often maintained by cloud providers, change over time." Un rango válido el lunes puede no serlo el viernes.

El cambio hacia el tráfico de agentes agrava la pila antigua. Cuando un rastreador actúa en nombre de un usuario dentro de un chat, el perfil de origen se fragmenta. Cloudflare lo señaló directamente: "Bots are no longer directed only by the bot owners, but also by individual end users to act on their behalf."

La verificación criptográfica es la única vía que sobrevive a los tres fallos. No le importa la IP de origen, no confía en el UA y no necesita lookup de reverse-DNS. Solo le importa la clave.

Cómo se ve una petición firmada de Googlebot

Una solicitud firmada del agente de Google sigue la forma documentada en las guías de Cloudflare y Google. Formato aproximado, con el keyid abreviado:

GET /article/example HTTP/1.1
Host: yoursite.com
User-Agent: Mozilla/5.0 (compatible; Google-Agent/1.0; ...)
Signature-Agent: g="https://agent.bot.goog"
Signature-Input: sig=("@authority" "signature-agent")
 ;created=1735689600;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U"
 ;alg="ed25519";expires=1735693200;tag="web-bot-auth"
Signature: sig=:MEQCIBmw...truncated...:

Leído de izquierda a derecha. Signature-Agent indica dónde obtener la clave pública. El literal g="https://agent.bot.goog" lleva a https://agent.bot.goog/.well-known/http-message-signatures-directory. Signature-Input describe lo atestado: en este caso el componente derivado @authority (el host) y la cabecera signature-agent, firmados en created y válidos hasta expires. El keyid es la huella JWK que selecciona una clave del directorio. Signature porta los bytes ed25519.

Semántica de cada parámetro, en tabla, porque aquí es donde más se equivocan los operadores:

Google avisa de una salvedad: "Not all Google user agents are using Web Bot Auth." En mayo de 2026, el agente que firma de forma constante es Google-Agent, el rastreador de navegación con IA. Googlebot, el rastreador de indexación que genera la mayor parte del tráfico orgánico, aún no firma. Planifica tus reglas en consecuencia.

El flujo de verificación, de extremo a extremo

La ruta de verificación tiene cuatro pasos, ninguno costoso. Las piezas móviles son la caché del directorio y la librería de algoritmo, no las matemáticas.

Paso uno. Llega la solicitud. Busca la cabecera Signature-Agent. Si falta, la petición no va firmada y caes al camino de verificación heredado (reverse DNS, UA, IP). En 2026, la mayoría está aquí.

Paso dos. Analiza Signature-Input. Extrae keyid, created, expires, alg y tag. Rechaza si tag no es exactamente web-bot-auth. Rechaza si expires ha pasado. Ambos chequeos antes de tocar la clave.

Paso tres. Obtén el directorio de claves públicas en la URL dada por Signature-Agent. Respeta su Cache-Control; el de Google lo trae. Mete el directorio en caché (memoria o Redis), reféscalo al expirar y elimina claves retiradas (rotación). Saca la clave cuya huella JWK coincida con keyid.

Paso cuatro. Verifica la firma contra los componentes listados en Signature-Input. Si pasa, la solicitud viene del poseedor de la clave privada. Si falla, trátala como falsa.

La caché del directorio es donde más fallan los operadores. Toma la cabecera Cache-Control como autoridad. No sobre-caches (un directorio obsoleto acepta claves revocadas) ni infra-caches (refrescar por petición añade latencia y castiga al endpoint). Si falla la descarga con caché expirada, vuelve al camino sin firmar. No bloquees por un fallo transitorio.

Qué cambia en tus reglas de bloqueo de bots de IA

La pregunta central. Tenías reglas. El protocolo cambió. ¿Qué hacer?

Buenas noticias primero. Las reglas que bloquean por “UA contiene GPTBot, ClaudeBot o PerplexityBot” siguen igual. La petición sigue llegando con un UA reconocible, y un GPTBot falso siempre fingió ser el bot que querías bloquear. Si tus reglas también bloquean al GPTBot legítimo firmado, es una decisión de política ya tomada.

Las noticias menos buenas. Las reglas que permiten por “UA contiene Googlebot” ahora están infra-especificadas. Un suplantador con UA Googlebot las pasa. La solución no es reescribir de golpe (la cuota firmada es pequeña), sino añadir una ruta paralela: verifica la firma en el tráfico Google firmado y trata el resto sin firmar con reverse-DNS. El equipo de verified-bots de Cloudflare resumió así la brecha:

"Existing identification methods rely on a combination of IP address range (which may be shared by other services, or change over time) and user-agent header (easily spoofable). These have limitations and deficiencies." — Cloudflare verified-bots team, julio 2025

El modelo de dos pilas es la imagen correcta. Un conjunto maneja el tráfico firmado, verifica la firma, comprueba el keyid contra una lista de confianza, valida expires y enruta según la identidad verificada. El otro maneja el tráfico sin firmar, haciendo el reverse-DNS + UA + IP como hoy. No borres las reglas heredadas. A mediados de 2026, la mayoría del tráfico real de Google pasa aún por ellas.

Verificar firmas en tu origen (si no usas Cloudflare)

Si estás detrás de Cloudflare, el trabajo es mínimo. Cloudflare valida las firmas en el edge y expone el resultado vía cf.verified_bot_category en WAF Custom Rules y Transform Rules. Tu regla se reduce a “si cf.verified_bot_category es la categoría deseada, actúa”, y la cripto es problema de otro.

Si no estás en un CDN que verifique, lo haces en tu origen. Se implementa como un pequeño middleware delante de nginx o de tu servidor de aplicaciones. Intercepta solicitudes con Signature-Agent, descarga el directorio .well-known la primera vez (y lo cachea), verifica según RFC 9421 y añade una cabecera interna X-Verified-Bot para que tus reglas lean.

El equipo de investigación de Cloudflare publicó el código de verificación en cloudflareresearch/web-bot-auth. El crate de Rust y el paquete npm de TypeScript (ambos web-bot-auth) contienen la lógica, y el repo incluye plugin para Caddy y ejemplos en Workers. Nada de esto está auditado (lo dice el README), pero la superficie es pequeña y la alternativa es implementar la RFC tú mismo.

Consejo práctico: en Cloudflare, la vía del edge es obvia. Fuera de Cloudflare, instala el middleware, apúntalo a los agentes que quieras verificar (el directorio de Google hoy, y los que vengan) y lee su cabecera de confianza en tus reglas. En ambos casos, no incrustes la verificación en lógica de negocio. Manténla en la capa frontal para poder auditarla y sustituirla.

El fallback de reverse DNS no va a desaparecer

Insisto en “no borres las reglas viejas” porque la cuota firmada sigue siendo pequeña. En mayo de 2026, el rastreador de indexación Googlebot no firma. Solo firma el agente de navegación Google-Agent. Para la mayoría de los sitios, la navegación IA es un dígito del total de tráfico Google. La indexación que da visibilidad orgánica está sin firmar hoy y, probablemente, hasta 2027.

Google lo dice claro. La misma documentación que introduce Web Bot Auth pide a los operadores "seguir confiando en direcciones IP, reverse DNS y cadenas user-agent" junto al nuevo protocolo. No es un matiz, es el modelo operativo. Web Bot Auth es un rail; la pila heredada es otro. Corren en paralelo y, en 2026, la pila antigua pesa más.

Cadencia de auditoría. Trimestralmente, extrae una muestra del tráfico que dice ser de Google, sepáralo en firmado y sin firmar y calcula el porcentaje firmado. Cuando cruce 30-40 %, la verificación de firma empezará a dominar. Cuando cruce 70 %, la regla de UA Googlebot sin firmar merece una revisión seria; los suplantadores serán visibles ahí. Hasta entonces, mantén ambos rails y trata el criptográfico como aditivo.

Un antipatrón: no escribas hoy una regla que bloquee tráfico Googlebot sin firmar. Te des-indexarás en un ciclo de rastreo.

Qué hacer realmente este trimestre

Lista de cuatro acciones, sin necesidad de proveedor.

Primero, inventaría tus reglas de bots actuales. Etiqueta cada una por lo que verifica: UA, reverse DNS, IP o firma. La mayoría de auditorías revela reglas duplicadas o obsoletas. Limpia antes de añadir.

Segundo, añade la ruta de verificación de firma. En Cloudflare, activa la validación verified-bots y crea una regla basada en cf.verified_bot_category. En tu origen, instala el middleware WBA, apúntalo a agent.bot.goog (y los demás que importen) y expón una cabecera de confianza para tus reglas.

Tercero, conserva la ruta de reverse DNS para el gran volumen de tráfico Google sin firmar. No la endurezcas ni la reemplaces. Ejecútala junto a la ruta de firma.

Cuarto, programa la auditoría trimestral: cuota firmada del tráfico que dice ser de Google, cuota firmada del tráfico de agentes IA y porcentaje de suplantadores detectados por la firma que las reglas antiguas no pillaron. Las cifras se moverán lento en 2026 y más rápido en 2027. Tu estructura de reglas debe moverse con ellas.

Si tu equipo también gestiona la política de rastreadores IA, el playbook de rastreadores IA y la guía para desactivar el bloqueo de bots de IA en Cloudflare son lecturas complementarias sobre allow/block. Este artículo es la parte de identidad.

Lo que ESTO NO resuelve

Web Bot Auth es identidad, no autorización. La firma certifica que la solicitud proviene de un bot concreto. No dice si ese bot puede leer la URL. Un Google-Agent verificado puede raspar tu contenido de pago si tus reglas lo permiten. La política sigue siendo tuya.

Tampoco opina sobre robots.txt. Un bot firmado que ignore robots sigue violando robots; firmar no da acceso extra. Si quieres que el agente IA firmado evite tu sección de pago, indícaselo en robots y haz cumplir la regla.

Y no decide entre routing para búsqueda IA y para búsqueda tradicional. Web Bot Auth dice "esto es realmente Google-Agent". Decidir si Google-Agent recibe el mismo contenido que Googlebot o algo distinto es tu política. La pieza sobre optimizar para Perplexity, ChatGPT Search y Google AI Mode cubre ese routing.

Resumen sincero: esto es un rail de una pila de tres. Firma para identidad, reverse DNS para verificación heredada y política robots para autorización. El nuevo rail refuerza el primero. Los operadores que triunfan en 2026 tratan los tres como críticos.

Cadencia de auditoría a medida que crece la adopción

La línea a seguir en 2026-2027 es la cuota firmada del tráfico que dice ser de Google. Hoy, en la mayoría de sitios, es un solo dígito. Cuando cruce 30-40 %, el camino de verificación pesará en tus decisiones. Cuando cruce 70 %, la regla de UA Googlebot sin firmar necesita revisión.

Re-haz el inventario cada seis meses y relee la documentación de Google cuando lo hagas; está cambiando. La forma del directorio y la lista de componentes firmados son las partes más propensas a cambiar. Dos veces al año basta.

Para el contexto base de Googlebot, nuestro explicador sobre qué es Googlebot es el punto de partida. Para el tráfico de agentes, cómo crear un sitio amigable para agentes expone la integración.

FAQ

¿Googlebot ya firma sus solicitudes? No a mediados de 2026. El despliegue actual de Web Bot Auth cubre el agente de navegación Google-Agent. Googlebot, el rastreador de indexación que impulsa el tráfico orgánico, sigue autenticando vía reverse DNS y rangos IP documentados. Diseña reglas separadas.

¿Web Bot Auth sustituye robots.txt? No. Responden a cosas distintas. Web Bot Auth atesta “esta petición es realmente de Google”. Robots.txt declara “esta URL se puede o no rastrear”. Ambos aplican, y un bot firmado que ignore robots sigue infringiéndolo.

¿Qué algoritmo de firma usa Web Bot Auth? La RFC 9421 admite varios. Los ejemplos de Cloudflare y el directorio de Google usan ed25519 (EdDSA sobre Curve25519). Tu verificador necesita una implementación ed25519; la tienen Go, Rust, Node, Python, etc.

¿Qué pasa si el directorio de claves públicas de Google no responde? Cachéas el directorio según su Cache-Control. Si la caché está fresca, verificas con ella. Si está expirada y la descarga falla, vuelves al camino sin firmar (reverse DNS, UA, IP). No bloquees por un fallo transitorio; podrías des-indexarte si el directorio de Google sufre un bache.

¿Debo eliminar la verificación reverse DNS para Googlebot? Aún no, y probablemente no en 2026. La cuota firmada es demasiado pequeña. Reverse DNS es tu defensa real contra suplantadores UA Googlebot, porque Googlebot aún no firma. Re-evalúa trimestralmente conforme suba la cuota firmada. El momento de endurecer el camino sin firmar es cuando sea minoría, no mayoría.