Verificar Googlebot y otros rastreadores: cómo saber quién llama de verdad

Escribir Googlebot en el user-agent cuesta diez caracteres, así que tus registros mezclan al buscador que te indexa con scrapers que se hacen pasar por él. Verificar Googlebot no consiste en leer ese encabezado: consiste en comprobar de dónde viene la petición.

El error clásico tiene dos caras y las dos cuestan caro. Un firewall puede estar cerrando la puerta al Googlebot real porque le pareció sospechoso, mientras un scraper entra tranquilo porque copió el nombre. Ambas caras se arreglan con el mismo método, y conviene aplicarlo antes de tocar cualquier regla de bloqueo.

Por qué el user-agent no prueba nada

El encabezado User-Agent es texto libre que elige el cliente. Escribir Googlebot/2.1 no requiere permiso ni certificado: se copia de cualquier tutorial y se pega en la petición. Por eso el user-agent sirve solo como pista para saber qué lista de direcciones consultar, nunca como prueba de identidad.

Conviene separar dos preguntas que casi todos los tutoriales mezclan. Verificar responde quién llama; decidir responde si quieres que entre. La primera es técnica y vive en el DNS y la IP; la segunda es de negocio. Un Googlebot auténtico también puede rastrear de más, y eso se corrige ajustando el ritmo, no dudando de su identidad.

Las tres familias de solicitudes de Google

Google no tiene un rastreador, tiene tres familias, y cada una responde distinto a robots.txt. Los rastreadores habituales, donde vive Googlebot, respetan siempre las reglas en los rastreos automáticos y usan la máscara crawl-***-***-***-***.googlebot.com o su variante geográfica geo-crawl-***.geo.googlebot.com, con rangos en common-crawlers.json.

Los casos especiales, como AdsBot, pueden o no respetar robots.txt y se resuelven como rate-limited-proxy-***.google.com. La tercera familia son los sistemas activados por un usuario: alguien pidió esa acción, así que ignoran robots.txt y aparecen como ***.gae.googleusercontent.com o google-proxy-***.google.com. Ese orden importa: si vas a bloquear, averigua primero en qué familia cae la petición.

La máscara de DNS invertida

La resolución inversa de la IP tiene que terminar en googlebot.com, google.com o googleusercontent.com. Un PTR que diga otra cosa no es Google, por impecable que sea el user-agent que trae al lado.

Verificación manual: cómo verificar Googlebot en tres pasos

Primero buscas la IP en tu registro de accesos y le haces una resolución inversa con host. Segundo compruebas que el nombre devuelto pertenece a uno de esos tres dominios de Google. Tercero haces una resolución normal sobre ese nombre y confirmas que devuelve la misma IP que tenías enfrente.

El tercer paso es el que casi todos omiten y el que sostiene la verificación. La comprobación es de ida y vuelta: si solo miras el PTR, un atacante crea su propio registro inverso con el texto que quiera y pasa el filtro. Los ejemplos oficiales sirven de referencia: 66.249.66.1 resuelve como crawl-66-249-66-1.googlebot.com y vuelve a la misma IP; 35.247.243.240 como geo-crawl-35-247-243-240.geo.googlebot.com; y 66.249.90.77 como rate-limited-proxy-66-249-90-77.google.com. Detalle completo en la documentación de verificación de solicitudes de Google.

Verificación automática: los rangos de IP y su nueva dirección

Google publica listas en JSON con los prefijos en formato CIDR, una por familia más goog.json. Esas listas son la fuente de verdad; el user-agent solo decide cuál consultar. En 2026 cambiaron de sitio: desde el 11 de febrero viven en /crawling/ipranges/, y la ruta antigua aún responde pero conviene actualizar los enlaces.

El archivo common-crawlers.json trae hoy una marca de creación del 10 de noviembre de 2026 y 317 prefijos entre IPv4 e IPv6. No es una lista de copiar y olvidar: se regenera. Guárdala en tu WAF o compárala en el pipeline de análisis de logs, y anota la fecha del archivo para saber con qué versión comparaste.

El caso nuevo: agentes de IA y Web Bot Auth

En marzo de 2026 Google añadió el user-agent Google-Agent, que usan sus agentes alojados en infraestructura propia para navegar y actuar a pedido del usuario. Trae rangos aparte en user-triggered-agents.json. En mayo publicó la guía de Web Bot Auth, un protocolo experimental basado en firmas de mensajes HTTP: en vez de confiar en el nombre y la IP, el agente firma la petición.

Se reconoce por el encabezado Signature-Agent con el valor g="https://agent.bot.goog", la firma viaja en Signature y Signature-Input según el RFC 9421, y las claves públicas se publican en el directorio .well-known de ese mismo dominio. Tres límites que la documentación reconoce: es experimental, no todas las solicitudes de un agente van firmadas, y la verificación por user-agent e IP sigue siendo el estándar de facto. Si tu WAF ya lo soporta, actívalo; si no, no cambies nada esta semana.

Los bots que no son Google: qué publica cada proveedor

El patrón se repite: un user-agent declarado y una lista de IP propia. El caso mejor documentado es OpenAI, con cuatro agentes que se controlan por separado. OAI-SearchBot alimenta la búsqueda de ChatGPT; si lo bloqueas, el sitio deja de mostrarse en esas respuestas, aunque puede seguir apareciendo como enlace de navegación. GPTBot recoge contenido que puede usarse para entrenar modelos. ChatGPT-User ejecuta acciones que inicia una persona, así que robots.txt puede no aplicar. Y OAI-AdsBot valida páginas de destino de anuncios sin entrenar con esos datos.

Dos detalles valen oro. Los cuatro archivos de IP responden hoy, y gptbot.json trae 18 prefijos con fecha de septiembre de 2026. Además, esos rangos no son espacio propio de OpenAI: varios bloques están registrados a nombre de Microsoft, algo que confirma el RDAP. Por eso bloquear "la nube de Microsoft" entera se lleva por delante al rastreador de OpenAI y a media internet. Un cambio en robots.txt puede tardar unas 24 horas en reflejarse.

Cómo decidir a quién dejas entrar

Con la identidad resuelta quedan tres preguntas. ¿Quiero que me rastree un buscador? Casi siempre sí. ¿Quiero que me cite un asistente? Es una decisión de visibilidad. ¿Quiero que mi contenido entrene modelos? Es una decisión editorial, no de SEO, y merece una respuesta explícita en lugar de un bloqueo por reflejo.

Googlebot, siempre permitido: si hay un pico, se regula el ritmo. Los bots de búsqueda de asistentes, permitidos si quieres ser citado, como explica la guía de GEO. Los de entrenamiento son tu decisión, y conviene saber que Google-Extended no tiene user-agent propio: es solo un token de robots.txt y no afecta a la inclusión ni al posicionamiento en la Búsqueda de Google. Los fetchers activados por un usuario no se bloquean con robots.txt; si hay que frenarlos, es del lado del servidor.

Lo que viene en 2027

Google anunció que prevé admitir la señal compartida y legible por máquinas AIPREF, con el token __usage_ai-training, a comienzos de 2027. Es un anuncio, no algo disponible hoy.

Los cuatro errores que sí cuestan tráfico

El primero es bloquear por user-agent creyendo que verificas: el scraper sigue entrando y tú te quedas con la sensación de haber hecho algo. El segundo es bloquear por ASN o por proveedor de nube, porque los rangos de Google y de OpenAI comparten espacio con servicios de terceros y se tira lo bueno con lo malo. El tercero es cerrar el paso a Googlebot desde el WAF durante un pico, justo cuando más importan las páginas nuevas.

El cuarto es el más caro y el más frecuente. Google lo dice con todas las letras: no se deben usar los códigos 401 y 403 para limitar la frecuencia de rastreo, porque los 4xx salvo el 429 no tienen ningún efecto sobre esa frecuencia y, además, los rastreadores informan al siguiente sistema de que el contenido no existe. Un 403 defensivo no frena: puede sacar páginas del índice.

Si de verdad hay que frenar: 429 o 503 con Retry-After

Para una urgencia de horas o un par de días, Google documenta devolver 500, 503 o 429 en lugar de 200 y adjuntar Retry-After con segundos o una fecha UTC absoluta. Con honestidad: sostener 5xx o 429 conserva las URLs indexadas un tiempo y acaba retirándolas. Es para una urgencia, no para vivir así. Los detalles están en la guía de errores 5xx y 429.

Cómo comprobarlo en tu sitio esta semana

Son tres comprobaciones baratas. En el log, cuenta las peticiones cuyo user-agent dice Googlebot y calcula qué porcentaje resuelve a googlebot.com en el DNS inverso: lo que no resuelva es imitación, y vale la pena saber cuánto pesa. Después descarga common-crawlers.json y compara con las IPs que ves, guardando la fecha. Por último, revisa las estadísticas de rastreo en Search Console y usa la API de Inspección de URL después de cualquier cambio en WAF o CDN.

El cierre es de proceso, no de herramienta: escribe una política con quién entra, quién no y con qué código se frena, y revísala dos veces al año y cada vez que un proveedor cambie su lista. Nada de esto sube posiciones. Evita perderlas por accidente, que es otra cosa y también cuenta.