User Agent y SEO

TL;DR — Un agente de usuario es una pequeña línea de texto que cada navegador y cada bot envía con cada solicitud para decir “aquí estoy yo”. El rastreador de Google dice que es Googlebot; el de Bing dice bingbot. En robots.txt no escribes la línea completa — usas un nombre corto (un “token”) como Googlebot. Y aquí está el detalle: esa línea es solo texto, así que cualquiera puede falsificarla. La única forma real de saber que un bot es quien dice ser es verificar de dónde proviene realmente su solicitud.

Qué es un agente de usuario

Cada vez que tu navegador carga una página, envía una etiqueta de texto corta que indica qué es — algo como “Soy Chrome en una Mac”. Esa etiqueta es el agente de usuario, y viaja en un encabezado HTTP en cada solicitud. Los servidores pueden leerla y reaccionar a ella.

Detalle importante desde el principio: el cliente completa esa etiqueta por sí mismo. Nada la verifica. Es una afirmación, no una credencial — así que un agente de usuario que dice “Googlebot” no es lo mismo que una solicitud que realmente está verificada como Googlebot.

Los rastreadores hacen lo mismo. Cuando Googlebot obtiene tu página, envía un agente de usuario que incluye Googlebot. Cuando Bingbot la obtiene, el agente de usuario incluye bingbot. Así es como un bot se anuncia en los registros de tu servidor.

La cadena vs. el nombre corto

Realmente hay dos cosas que la gente quiere decir con “agente de usuario”, y confundirlas causa mucha confusión:

• La cadena de agente de usuario es la línea completa en el encabezado de la solicitud. La de Googlebot es larga y se parece mucho a un navegador.
• El token de agente de usuario es el nombre corto que usas en robots.txt para dirigirte a un bot — como Googlebot o bingbot. El token es solo una parte de la cadena completa, no la totalidad.

Así que cuando escribes una regla en robots.txt, usas el token corto:

User-agent: Googlebot
Disallow: /private/

No pegas la cadena gigante que parece de navegador ahí.

No puedes confiar en la cadena

Esto es lo único que debes recordar. La línea de agente de usuario es texto plano, así que cualquier cosa puede falsificarla. Cualquier script puede afirmar ser Googlebot en una sola línea de código — y muchos lo hacen, para colarse entre los bloqueos. El propio Google dice que el encabezado de Googlebot “a menudo se falsifica”.

Eso significa que nunca deberías decidir quién tiene acceso a tu sitio basándote solo en el agente de usuario. Si realmente necesitas confirmar que un visitante es el Googlebot real (por ejemplo, si estás leyendo tus registros), lo verificas comprobando de dónde proviene la solicitud — no lo que dice ser. La pestaña Avanzado explica exactamente cómo.

Algunos detalles a tener en cuenta

• Los nombres de agente de usuario en robots.txt no distinguen entre mayúsculas y minúsculas — Googlebot y googlebot son lo mismo.
• Bloquear todo con User-agent: * no bloquea todos los bots de Google — sus rastreadores de anuncios y su rastreador de seguridad ignoran el comodín.
• Mostrar una versión de una página a un rastreador y una diferente a personas reales es cloaking, y Google lo trata como spam.

¿Quieres el panorama completo — las tablas de tokens, cada rastreador de Google y Bing, los comandos exactos de verificación y las reglas de cloaking — cambia a la pestaña Avanzado.

TL;DR — Un agente de usuario es el encabezado de solicitud HTTP que cualquier cliente envía para identificarse; es opcional, metadatos proporcionados por el cliente, no una identidad autenticada. Su valor es la cadena de agente de usuario. Aparte de eso está el token de agente de usuario (token de producto) utilizado en robots.txt — RFC 9309 dice que DEBERÍA ser una subcadena de la cadena, una convención sólida con excepciones documentadas (Google-Extended no tiene ninguna cadena de solicitud en absoluto). La coincidencia no distingue entre mayúsculas y minúsculas, los números de versión/comodines en la línea del token se ignoran, el grupo más específico gana, y los grupos con el mismo token se fusionan pero nunca se fusionan con *. La cadena se falsifica trivialmente — Google llama a la suya propia “a menudo falsificada” — así que verifica mediante DNS inverso + directo (detrás de cualquier proxy/CDN, usa la IP real del cliente) contra googlebot.com/google.com/googleusercontent.com para Google o search.msn.com para Bing, o compara rangos de IP publicados — e incluso una solicitud verificada solo demuestra que llegó una solicitud, no que la página fue indexada, recuperada o utilizada para el entrenamiento de IA. AdsBot y Google-Safety ignoran User-agent: *. Chrome también está congelando detalles de las cadenas de UA del navegador (reducción de User-Agent); Client Hints son el reemplazo estructurado pero opcional, y ninguno sustituye la verificación del rastreador. La adaptación del agente de usuario puede ser legítima, pero mostrar de manera engañosa a los rastreadores contenido materialmente diferente puede ser cloaking.

El encabezado, la cadena y el token

Tres cosas, y mantenerlas claras es la mayor parte de este tema.

• El encabezado. User-Agent es un encabezado de solicitud HTTP. Cada cliente lo envía: tu navegador, curl, un rastreador, un bot. Según RFC 9110 (el estándar central de semántica HTTP), es un campo opcional que el cliente completa — metadatos descriptivos proporcionados por el cliente, no una identidad autenticada que el servidor haya verificado.
• La cadena. El valor del encabezado — una línea de formato libre que describe el software, la versión, el motor de renderizado y, a veces, el sistema operativo.
• El token. El identificador corto utilizado en robots.txt, en líneas User-agent:, para dirigirse a un rastreador — Googlebot, bingbot, Google-Extended.

La relación es la parte que confunde a la gente. RFC 9309 (el estándar formal del Protocolo de Exclusión de Robots) dice que el token “SHOULD be a substring of the identification string that the crawler sends… in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” (traducción) «DEBERÍA ser una subcadena de la cadena de identificación que envía el rastreador… en el caso de HTTP, el token de producto DEBERÍA ser una subcadena en el encabezado User-Agent.» Eso es un SHOULD («DEBERÍA»), no un MUST («DEBE»): una convención sólida que el estándar recomienda, no un requisito estricto al que cada rastreador esté mecánicamente obligado. Google-Extended (abajo) es el ejemplo más claro de una excepción documentada. No leas la regla de subcadena como universal solo porque Google la sigue para la mayoría de sus propios tokens. El token es parte de la cadena cuando un proveedor sí proporciona uno; te diriges al token en robots.txt y lees la cadena en tus registros.

El propio marco de Google sobre cómo sus bots se identifican es útil aquí: “Google’s crawlers identify themselves through three things: the HTTP user-agent request header, the source IP address of the request, and the reverse DNS hostname of the source IP.” (traducción) «Los rastreadores de Google se identifican mediante tres cosas: el encabezado de solicitud HTTP user-agent, la dirección IP de origen de la solicitud y el nombre de host DNS inverso de la IP de origen.» Ten en cuenta que el agente de usuario es solo una de las tres — las otras dos son cómo lo verificas realmente.

Google-Extended: un token sin cadena

La ilustración más clara de token ≠ cadena es Google-Extended. Controla si Google puede usar tu contenido para el entrenamiento y la fundamentación de Gemini — y no tiene ninguna cadena de agente de usuario de solicitud HTTP dedicada en absoluto. El rastreo en sí se realiza con cadenas existentes de Googlebot; Google-Extended existe solo como un token de control de robots.txt. Nunca verás “Google-Extended” en un encabezado de solicitud en tus registros.

La consecuencia práctica: bloquear Google-Extended afecta solo al uso de tu contenido para el entrenamiento de IA — no impide que Googlebot rastree e indexe tu sitio para la Búsqueda. Son decisiones separadas controladas por tokens separados. (Para una visión más amplia de los bots que leen tu sitio, consulta rastreadores de IA y rastreador.)

Cadenas de user-agent de Googlebot

Googlebot es “evergreen” — se ejecuta en una versión reciente de Chrome, y la versión de Chrome en su cadena se actualiza periódicamente (lo hace desde diciembre de 2019). Por eso la versión aparece como un marcador de posición W.X.Y.Z:

Googlebot Smartphone (móvil):

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Googlebot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36

Dos cosas que debes internalizar. Primero, no codifiques la versión — W.X.Y.Z cambia, y coincidir con ella se romperá. Coincide con el token estable Googlebot en su lugar. Segundo, no puedes separar móvil de escritorio en robots.txt. Ambas variantes comparten el único token Googlebot, por lo que una regla de robots.txt se aplica a ambas.

Tokens de rastreadores de Google

Google ejecuta toda una familia de rastreadores y buscadores, cada uno con su propio token. Los que encontrarás con más frecuencia:

Y los que rompen las reglas habituales — los rastreadores de casos especiales que ignoran User-agent: *:

• AdsBot (AdsBot-Google) y AdsBot Mobile (AdsBot-Google-Mobile) — no obedecen el comodín. Para bloquearlos debes nombrarlos explícitamente.
• AdSense (Mediapartners-Google) — igual; ignora el * global.
• Google-Safety — se usa para la detección de malware/abuso; ignora robots.txt por completo.

La implicación es la que la gente pasa por alto: User-agent: * no bloquea AdsBot ni Google-Safety. Si “bloqueas todos los bots” con un comodín y asumes que AdsBot ya no está, no es así. (Este es exactamente el tipo de sorpresa que lleva a una página al territorio de indexada aunque bloqueada por robots.txt — consulta robots.txt para la historia completa del control.)

Cadenas de user-agent de Bingbot

Bing reconstruyó la cadena de Bingbot en 2022 para reflejar que se renderiza con Microsoft Edge. Las cadenas actuales:

Bingbot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/W.X.Y.Z Safari/537.36

Bingbot Mobile:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

El token de robots.txt es solo bingbot. Lo que debes vigilar: después de 2022, la cadena de Bingbot se ve casi exactamente como un navegador Chrome/Edge real — la única pista es el fragmento bingbot/2.0 dentro de ella. Si tienes alguna lógica que filtra o detecta bots por UA, ese cambio importa.

Cómo robots.txt realmente coincide con un token

Algunas reglas gobiernan qué grupo de reglas obedece un rastreador (según la especificación de robots.txt de Google y RFC 9309):

• La coincidencia más específica gana. Google “determina el grupo correcto de reglas al encontrar… el grupo con el user agent más específico que coincida con el user agent del rastreador.” Un grupo Googlebot supera a un grupo * para Googlebot.
• Los grupos con el mismo token se fusionan — pero nunca con *. Múltiples grupos que nombran al mismo agente se combinan en uno. Un grupo de agente específico y el grupo * no se fusionan; * es solo el respaldo cuando nada específico coincide.
• No distingue entre mayúsculas y minúsculas. Tanto el nombre del campo como el valor — Googlebot, googlebot, GOOGLEBOT son equivalentes.
• Los números de versión y los comodines en la línea del token se ignoran. Según Google, “tanto googlebot/1.2 como googlebot* son equivalentes a googlebot.” No puedes escribir User-agent: Googlebot* para coincidir con una familia — el * allí no hace nada.

Por lo tanto, una línea User-agent: toma un token y lo compara como una subcadena simple (sin distinción de mayúsculas y minúsculas) de la identidad del rastreador: sin fijación de versión, sin comodines dentro de ella.

Por qué no puedes confiar en la cadena — y cómo verificar

La cadena de user-agent es texto de formato libre. Cualquier cosa puede configurarla. Una línea de curl afirmará ser Googlebot, y muchas herramientas y bots maliciosos hacen exactamente eso para pasar desapercibidos ante los bloqueos. Google lo dice en su propia documentación de Googlebot: “the HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” (traducción) «el encabezado de solicitud HTTP de user-agent utilizado por Googlebot a menudo es suplantado por otros rastreadores». Como lo he expresado en mi guía de Googlebot, “Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.” (traducción) «Muchas herramientas de SEO y algunos bots maliciosos pretenderán ser Googlebot. Esto puede permitirles acceder a sitios web que intentan bloquearlos».

Por lo tanto, nunca tomes una decisión de acceso o contenido basándote solo en la cadena. Verifica en su lugar.

Un requisito previo antes de cualquiera de los dos métodos: obtén la real IP de origen. Si tu sitio está detrás de un proxy inverso, balanceador de carga o CDN, la dirección en tu registro de acceso predeterminado puede ser la IP del proxy, no la del rastreador — necesitas la IP original del cliente (generalmente reenviada en un encabezado como X-Forwarded-For, configurado correctamente en tu proxy) o ninguno de los métodos de verificación a continuación tiene sentido.

Método 1 — DNS inverso + directo (mejor para comprobaciones puntuales). Los dos pasos de Google:

1. “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (traducción) «Realiza una búsqueda DNS inversa en la dirección IP de acceso desde tus registros, usando el comando host. Verifica que el nombre de dominio sea googlebot.com, google.com o googleusercontent.com».
2. “Run a forward DNS lookup on the domain name retrieved in step 1… Verify that it’s the same as the original accessing IP address from your logs.” (traducción) «Realiza una búsqueda DNS directa en el nombre de dominio obtenido en el paso 1… Verifica que sea el mismo que la dirección IP de acceso original de tus registros».

Para Bingbot, el mismo baile de dos pasos, pero el nombre de host debe terminar en search.msn.com (no un dominio con la marca Bing — una sorpresa común). Los comandos están en la pestaña Scripts.

Método 2 — rangos de IP publicados (mejor a escala). Google no publica una lista blanca estática para codificar (“these IP address ranges can change” (traducción) «estos rangos de direcciones IP pueden cambiar»), pero sí publica archivos JSON de CIDR legibles por máquina que puedes comparar (common-crawlers.json y los archivos de rastreadores más amplios). Bing ahora también publica sus rangos. Construí una herramienta de verificación de IP de Googlebot exactamente para esto — pega IPs y las clasifica. Bing Webmaster Tools también tiene una herramienta integrada “Verify Bingbot”.

El DNS es mejor para una verificación puntual de registros; la coincidencia de rangos de IP es mejor para verificar a gran volumen. Usa el que se ajuste — pero usa uno de ellos. Y trata tanto los nombres de host esperados como los archivos de rangos como actuales a día de hoy, no permanentes — Google y Bing han cambiado estas rutas antes (los archivos JSON de rangos de IP se movieron y renombraron desde que se escribió este artículo por primera vez), así que vuelve a consultar el documento de verificación en vivo si una búsqueda que solía funcionar deja de coincidir.

Una coincidencia de UA no es prueba de resultados posteriores

Incluso una solicitud completamente verificada — IP real de Googlebot, DNS inverso confirmado hacia adelante, todo cuadra — solo prueba una cosa: esa solicitud llegó a tu servidor. Es tentador redondear eso en una afirmación mucho más grande, pero cada una de estas es un hecho separado que requiere evidencia separada:

• Solicitud recibida — una solicitud con ese agente de usuario llegó a tu servidor. (Lo que la verificación de registros demuestra realmente).
• Identidad confirmada — la solicitud realmente provino del rastreador que dice ser. (Lo que añade la verificación inversa de DNS / coincidencia de rangos de IP).
• Contenido obtenido y renderizado — el rastreador renderizó la página con éxito (sin errores, sin recursos bloqueados). No está garantizado solo porque llegó una solicitud.
• Indexado — la URL llegó al índice de búsqueda. Una obtención exitosa no garantiza la indexación.
• Usado para recuperación, citación o entrenamiento — especialmente para rastreadores de IA (Google-Extended, GPTBot y demás), un rastreo no es prueba de que tu contenido se haya recuperado para una respuesta específica, se haya citado o se haya usado en el entrenamiento de modelos. Esos son pasos separados, en su mayoría no observables, posteriores al rastreo.

Una visita verificada de Googlebot en tus registros es una señal real, solo que no la estires más allá de lo que realmente muestra.

Autenticación de bots web: hacia dónde se dirige la verificación

En 2026, Google comenzó a experimentar con Web Bot Auth — “un protocolo criptográfico experimental utilizado para autenticar solicitudes enviadas por bots.” La idea es “ir más allá de los encabezados fácilmente falsificables hacia una identidad verificada y desacoplar la identidad del agente de las direcciones IP.” Los bots firman criptográficamente sus solicitudes; los sitios verifican la firma contra las claves públicas publicadas de Google, y las solicitudes firmadas llevan un encabezado Signature-Agent. La advertencia del propio Google importa: “No firmamos cada solicitud de un agente en particular. Asegúrate de recurrir a los métodos establecidos de verificación de bots.” Así que es aditivo, no un reemplazo: el DNS inverso y los rangos de IP siguen siendo tu base hoy.

Los navegadores también son cada vez más difíciles de analizar a partir de la cadena UA

Todo lo anterior trata sobre rastreadores, pero la misma lección de “no confíes demasiado en la cadena” se aplica a los navegadores, y es cada vez más fuerte. Chrome ha estado implementando gradualmente la reducción de User-Agent: congelando o reduciendo la precisión de partes de su cadena UA (versión completa del navegador, versión del sistema operativo, modelo del dispositivo) en lugar de informarlas exactamente, para que la cadena no pueda usarse para identificar a un usuario específico. El propio marco de Google: “La granularidad y abundancia de detalles pueden llevar a la identificación del usuario. La disponibilidad predeterminada de esta información puede llevar a un seguimiento encubierto.” Prácticamente, eso significa que el análisis de la cadena UA para versiones exactas de navegador/SO/dispositivo — análisis, detección de dispositivos, clasificación de errores — es cada vez menos fiable y solo lo será más.

El reemplazo que Chrome recomienda son las User-Agent Client Hints (UA-CH): datos estructurados que el navegador envía solo cuando un servidor los solicita explícitamente. Las sugerencias de baja entropía (marca del navegador, versión principal, indicador móvil) se envían por defecto; las sugerencias de alta entropía (versión exacta, versión de la plataforma, modelo del dispositivo) requieren que el servidor opte por participar mediante un encabezado de respuesta Accept-CH primero — una negociación explícita, no una transmisión. Dos advertencias antes de que confíes en ello: es un mecanismo de la familia Chrome/Chromium, no algo que todos los navegadores envíen, e incluso donde se admite, “el valor puede estar en blanco, no devolverse o poblarse con un valor variable.” Las Client Hints resuelven el problema de la cadena del navegador; no son un mecanismo de verificación de rastreadores — Google y Bing aún verifican sus propios rastreadores mediante DNS y rangos de IP, no mediante Client Hints.

Segmentación por agente de usuario y cloaking

La tentación — “detectar a Googlebot por su UA y servirle algo especial” — es tanto técnicamente frágil como una violación de la política.

Frágil, porque Google no rastrea con un solo UA. Tendrías que manejar correctamente Googlebot (móvil y escritorio), Google-InspectionTool, AdsBot, GoogleOther y más, desde IPs rotativas — prácticamente imposible de incluir en una lista blanca de manera limpia.

Una violación de la política, porque servir contenido diferente a un rastreador que a los usuarios es cloaking: “presentar contenido diferente a los usuarios y a los motores de búsqueda con la intención de manipular los rankings de búsqueda y engañar a los usuarios.” La penalización va desde la degradación algorítmica hasta la desindexación completa. Ten en cuenta la línea: la adaptación legítima (diseños responsivos, negociación de contenido) está bien — es intercambiar el contenido en sí entre bots y usuarios lo que cruza la línea hacia el cloaking.

Para saber dónde se sitúa el agente de usuario en el proceso más amplio, consulta rastreo (el centro) y rastreador. Para controlar qué pueden obtener esos bots, consulta robots.txt.

Resumen de IA

Una versión condensada de la versión avanzada:

• Tres cosas, mantenidas claras: el encabezado de solicitud User-Agent — opcional, metadatos rellenados por el cliente según RFC 9110, no identidad autenticada; su valor, la cadena de agente de usuario; y el token utilizado en robots.txt. Según RFC 9309, el token DEBERÍA ser una subcadena de la cadena — una convención fuerte, no una regla universal.
• Algunos tokens no tienen cadena. Google-Extended es la excepción documentada: existe solo como control de robots.txt (entrenamiento de Gemini); el rastreo utiliza cadenas normales de Googlebot. Bloquearlo no afecta la indexación en Search.
• Las cadenas de Googlebot/Bingbot son perennes — la versión de Chrome se muestra como W.X.Y.Z y cambia; coincide con el token estable (Googlebot, bingbot), nunca con la versión. Googlebot móvil y de escritorio comparten un token. El Bingbot posterior a 2022 parece un navegador real excepto por el fragmento bingbot/2.0.
• Coincidencia de robots.txt: gana el grupo más específico; los grupos con el mismo token se fusionan pero nunca con *; la coincidencia no distingue entre mayúsculas y minúsculas; los números de versión y los comodines en la línea User-agent: se ignoran (Googlebot* = Googlebot).
• AdsBot y Google-Safety ignoran User-agent: * — bloquéalos por nombre o no los bloquees.
• La cadena se falsifica trivialmente (Google llama a la suya “a menudo falsificada”). Obtén primero la IP real del cliente (los proxies/CDN pueden enmascararla en tus registros), luego verifica mediante DNS inverso y directo (googlebot.com/google.com/googleusercontent.com; Bing → search.msn.com) o rangos de IP publicados — archivos que Google ha renombrado/movido antes, así que vuelve a consultar el documento en vivo si una búsqueda deja de coincidir. Nunca confíes en la cadena para el control de acceso.
• Una solicitud verificada aún no es prueba de todo lo posterior. Solicitud recibida, identidad confirmada, contenido renderizado, página indexada y contenido recuperado/citado/entrenado son afirmaciones separadas que requieren evidencia separada — un acierto en el registro prueba lo primero, nada más automáticamente.
• Web Bot Auth (2026, experimental) firma solicitudes criptográficamente — aditivo, con DNS/IP como respaldo.
• Las cadenas UA del navegador también son cada vez más difíciles de analizar: la reducción de User-Agent de Chrome congela el detalle exacto de versión/SO/dispositivo fuera de la cadena; Client Hints son el reemplazo estructurado y opcional — pero son específicos de Chrome y no sustituyen la verificación del rastreador.
• Servir contenido diferente según la UA es cloaking — una violación de la política de spam, y frágil porque Google rastrea con muchas UA.

Documentación oficial

Documentación de fuente primaria de los motores de búsqueda y el estándar.

Google

• Descripción general de los rastreadores y buscadores de Google (agentes de usuario) — las tres señales de identificación y la lista completa de rastreadores.
• Rastreadores comunes de Google — la tabla de token + cadena de agente de usuario.
• Rastreadores de casos especiales de Google — AdsBot, Mediapartners-Google, Google-Safety y las excepciones *.
• Verificar solicitudes de rastreadores y buscadores de Google — el método DNS de dos pasos y los archivos de rangos de IP.
• Qué es Googlebot — las cadenas de Googlebot y la nota de “a menudo suplantado”.
• Cómo interpreta Google la especificación de robots.txt — coincidencia de tokens, insensibilidad a mayúsculas, comodines ignorados.
• Autenticar solicitudes con Web Bot Auth (Experimental) — el protocolo de firma criptográfica.
• Actualización del agente de usuario de Googlebot (2019) — por qué la cadena muestra W.X.Y.Z.
• Políticas de spam: cloaking — la definición y la penalización.

Bing / Microsoft

• Anuncio del cambio de agente de usuario para Bingbot (abril de 2022) — las cadenas actuales de escritorio y móvil (Fabrice Canel).
• Cómo verificar que Bingbot es Bingbot (agosto de 2012) — el método de DNS inverso *.search.msn.com.
• Bing Webmaster Tools: verificar Bingbot — la herramienta de verificación integrada.

El estándar

• RFC 9110 — Semántica HTTP, §10.1.5 User-Agent — la especificación HTTP central: User-Agent es un campo opcional proporcionado por el cliente, no una identidad autenticada.
• RFC 9309: Protocolo de exclusión de robots — la definición formal a nivel de SHOULD («DEBERÍA») del token de producto como subcadena de la cadena de agente de usuario.
• MDN — Cabecera User-Agent — la sintaxis HTTP de la propia cabecera.

Cadenas UA del navegador

• Chrome Privacy Sandbox — Reducción del agente de usuario — qué se congela/coarsifica en la cadena UA de Chrome y por qué.
• Chrome para desarrolladores — User-Agent Client Hints — sugerencias de baja vs. alta entropía y la opción de aceptación Accept-CH.

Citas de la fuente

Declaraciones públicas de Google, Bing y el RFC. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Google — cómo se identifican los rastreadores

• “Google’s crawlers identify themselves through three things: the HTTP user-agent request header, the source IP address of the request, and the reverse DNS hostname of the source IP.” (traducción) «Los rastreadores de Google se identifican mediante tres cosas: la cabecera de solicitud HTTP user-agent, la dirección IP de origen de la solicitud y el nombre de host DNS inverso de la IP de origen.» — Documentación de Google Search Central. Ir a la cita

Google — la cadena es suplantada

• “The HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” (traducción) «La cabecera de solicitud HTTP user-agent utilizada por Googlebot a menudo es suplantada por otros rastreadores.» — Documentación de Google Search Central. Ir a la cita

Google: verificación mediante DNS

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (traducción) «Realiza una búsqueda DNS inversa en la dirección IP de acceso desde tus registros, usando el comando host. Verifica que el nombre de dominio sea googlebot.com, google.com o googleusercontent.com». Ir a la cita
• “Google doesn’t post a public list of IP addresses for website owners to allowlist because these IP address ranges can change.” (traducción) «Google no publica una lista pública de direcciones IP para que los propietarios de sitios web las incluyan en la lista de permitidos porque estos rangos de direcciones IP pueden cambiar». Ir a la cita

Google: coincidencia de tokens en robots.txt

• “All non-matching text is ignored (for example, both googlebot/1.2 and googlebot* are equivalent to googlebot).” (traducción) «Todo el texto que no coincide se ignora (por ejemplo, tanto googlebot/1.2 como googlebot* son equivalentes a googlebot)». — Especificación de robots.txt de Google. Ir a la cita

Google: autenticación de bots web

• “An experimental cryptographic protocol used to authenticate requests sent by bots.” (traducción) «Un protocolo criptográfico experimental utilizado para autenticar solicitudes enviadas por bots». Ir a la cita
• “We don’t sign every request of a particular agent. Be sure that you fall back to the established methods of bot verification.” (traducción) «No firmamos cada solicitud de un agente en particular. Asegúrate de recurrir a los métodos establecidos de verificación de bots». Ir a la cita

Google: cloaking

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (traducción) «El cloaking se refiere a la práctica de presentar contenido diferente a los usuarios y a los motores de búsqueda con la intención de manipular los rankings de búsqueda y engañar a los usuarios». — Google Search Essentials, Políticas de spam. Ir a la cita

RFC 9309: el token es una subcadena de la cadena

• “The product token SHOULD be a substring of the identification string that the crawler sends to the service. For example, in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” (traducción) «El token de producto DEBERÍA ser una subcadena de la cadena de identificación que el rastreador envía al servicio. Por ejemplo, en el caso de HTTP, el token de producto DEBERÍA ser una subcadena en el encabezado User-Agent». Ir a la cita

Patrick Stox: sobre la suplantación

• “Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.” (traducción) «Muchas herramientas de SEO y algunos bots maliciosos se hacen pasar por Googlebot. Esto puede permitirles acceder a sitios web que intentan bloquearlos». — de mi guía de Googlebot en Ahrefs. Leerla

Rastreador → token → cadena → verificar

La tabla de referencia. El token es lo que pones en robots.txt; el hostname de verificación es a lo que una solicitud genuina se resuelve inversamente.

Reglas de coincidencia de robots.txt de un vistazo

Datos rápidos

• Token = subcadena de la cadena UA (RFC 9309). No es la cadena completa.
• Googlebot móvil y de escritorio comparten un token: no puedes separarlos en robots.txt.
• La versión de Chrome en la cadena es W.X.Y.Z — cambia; nunca la codifiques.
• La cadena UA es trivialmente falsificable — verifica por DNS o IP, nunca confíes en la cadena.

Verificar un bot mediante DNS inverso y directo

La cadena de user-agent se puede falsificar en una línea de curl. Confirma que un bot es genuino comprobando la IP de la que realmente proviene. El patrón es el mismo para Google y Bing — solo difiere el nombre de host esperado.

Obtén primero la IP correcta: si las solicitudes pasan por un proxy inverso, balanceador de carga o CDN antes de llegar a tu servidor, tus registros predeterminados pueden mostrar la dirección del proxy, no la del rastreador. Usa la IP real del cliente (de un encabezado de reenvío configurado correctamente) antes de ejecutar cualquiera de las comprobaciones siguientes.

macOS / Linux

# --- Googlebot ---
# 1) Reverse DNS the IP from your logs — must end in googlebot.com, google.com, or googleusercontent.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

# --- Bingbot ---
# Reverse DNS must end in search.msn.com, then forward-confirm back to the IP
host 157.55.39.1
host <the-hostname-it-returned>

Windows

:: Googlebot
nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

:: Bingbot
nslookup 157.55.39.1
nslookup <the-hostname-it-returned>

Si la búsqueda inversa no termina en el dominio esperado — googlebot.com / google.com / googleusercontent.com para Google, search.msn.com para Bing — o la búsqueda directa no coincide con la IP original, no es el bot real, sin importar lo que diga la cadena de user-agent.

Comparar con los rangos IP publicados (a escala)

Para verificar muchas visitas, omite el DNS por solicitud y compara la IP con los rangos CIDR publicados del motor en su lugar. Google publica JSON legible por máquina:

https://developers.google.com/static/crawling/ipranges/common-crawlers.json
https://developers.google.com/static/crawling/ipranges/special-crawlers.json
https://developers.google.com/static/crawling/ipranges/user-triggered-fetchers.json

Descarga el archivo, construye el conjunto CIDR y prueba cada IP registrada para ver si es miembro. (Yo construí una herramienta de verificación de IP de Googlebot que hace esto por ti.) Bing también publica sus rangos, y Bing Webmaster Tools tiene una comprobación integrada de “Verificar Bingbot”.

Lista de verificación de user-agent

Antes de escribir reglas de UA o actuar sobre un bot en tus registros:

• Estás apuntando al token en robots.txt (p. ej., Googlebot), no pegando la cadena UA completa.
• Sin números de versión ni * dentro de la línea User-agent: — se ignoran (Googlebot* no hace nada).
• No has asumido que User-agent: * bloquea a AdsBot o Google-Safety — no lo hace; nómbralos explícitamente si lo necesitas.
• Si bloqueaste Google-Extended, entiendes que solo afecta al uso de entrenamiento de IA — Googlebot aún rastrea e indexa para la Búsqueda.
• No estás basando el control de acceso o el contenido en la cadena UA cruda — es falsificable.
• Cualquier verificación de “¿esto es realmente Googlebot?” pasa por DNS inverso + directo (googlebot.com / google.com / googleusercontent.com) o las gamas de IP publicadas — Bing a través de search.msn.com.
• Sin coincidencia de UA con versión fijada en ningún lugar — la parte Chrome W.X.Y.Z cambia.
• No estás sirviendo contenido diferente a un UA de bot que a los usuarios (eso es cloaking).

Herramientas para trabajar con user agents

Tres de mis propias herramientas gratuitas cubren las tres tareas para las que la gente realmente viene a este tema: confirmar que un bot declarado es real, ver qué user agents están realmente golpeando tu sitio y comprobar qué se les permite hacer a los rastreadores de IA.

Googlebot Verifier — la herramienta para el problema exacto al que este artículo vuelve una y otra vez: la cadena de user-agent es solo texto, así que no puedes confiar en ella por sí sola. Pega una dirección IP de tus registros, elige qué rastreador pretende ser (Googlebot, Bingbot y otros), y ejecuta la verificación de DNS inverso + directo y la coincidencia con las gamas de IP publicadas por ti, luego devuelve un veredicto por niveles — confirmado por DNS inverso, en gamas publicadas, falsificado, no verificable o no es un rastreador conocido. ¿Tienes un día entero de visitas para verificar en lugar de una IP? Pega hasta 500 IPs o líneas de registro crudas en el cuadro de lote.

Log File Analyzer — para la pregunta “¿qué user agents están rastreando realmente mi sitio?” Suelta un registro de acceso del servidor (nginx, Apache, IIS/W3C o JSON) y lo analiza completamente en tu navegador, desglosando la actividad de rastreo por bot y por sección, marcando el desperdicio de códigos de estado, separando los rastreadores de IA de los de búsqueda y — la parte que más importa para este tema — ejecutando un informe de falsificadores que nombra las solicitudes que pretenden ser el token de user-agent de un rastreador conocido sin la IP que lo respalde.

AI-Crawler Access Checker — para la familia más nueva de tokens que no se comportan como Googlebot o bingbot. Introduce una URL y comprueba tu robots.txt contra cada token de user-agent de rastreador de IA importante (GPTBot, ClaudeBot, PerplexityBot, Google-Extended y más), muestra la regla exacta que gana para cada uno y marca si existe un llms.txt. Útil para confirmar que un token como Google-Extended está haciendo lo que crees que está haciendo — ya que, como se cubrió arriba, no tiene una cadena de solicitud propia para detectar en tus registros.

Prompts para tareas de user-agent

Dos prompts construidos alrededor de las trampas específicas que este tema plantea — falsificación y sintaxis de tokens de robots.txt — no relleno genérico de “audita mi SEO”. Pega tus propios datos en los marcadores de posición.

Prompt 1 — triaje de un lote de cadenas de user-agent de tus registros para detectar señales de falsificación

Pega una columna de cadenas de user-agent crudas extraídas de tu registro de acceso (no IPs — este prompt no puede verificar identidad, solo detectar inconsistencias en la cadena misma):

Here is a list of raw User-Agent strings from my server access log, one per
line. For each one:
1. Say which crawler token it claims to be (e.g. Googlebot, bingbot,
   GPTBot), or "no recognizable token" if none.
2. Flag anything internally inconsistent for that claimed crawler — e.g. a
   claimed Googlebot string missing "compatible; Googlebot" or the
   "+http://www.google.com/bot.html" URL, a claimed bingbot string missing
   "bingbot/2.0", or a Chrome version that looks hand-typed rather than a
   real evergreen build.
3. Remind me that this is a text-pattern check only — it cannot confirm
   identity. Real verification requires reverse+forward DNS or matching
   against the crawler's published IP ranges.

[paste user-agent strings here]

Prompt 2 — comprobar un robots.txt para errores de coincidencia de tokens

Pega tu archivo robots.txt completo:

Review this robots.txt file for user-agent token mistakes:
1. Flag any User-agent line that includes a version number or a wildcard
   inside the token (e.g. "Googlebot/1.2" or "Googlebot*") — these are
   ignored, not matched as a family.
2. Check whether User-agent: * is being relied on to block AdsBot-Google,
   AdsBot-Google-Mobile, Mediapartners-Google, or Google-Safety — these
   ignore the wildcard and need their own named group if I want them
   blocked.
3. Note any duplicate groups for the same token that could be merged, and
   confirm token matching here is case-insensitive so I don't need
   near-duplicate groups for casing variants.
4. List which named groups exist and which of Google's/Bing's common
   crawler tokens (Googlebot, Googlebot-Image, Google-Extended, bingbot)
   have no explicit group at all, so I know they're falling through to *.

[paste robots.txt here]

Ponte a prueba: user agent

Cinco preguntas rápidas sobre el encabezado, la cadena, el token y cómo verificar que un bot es real. Elige una respuesta para cada una y luego comprueba.

Recursos que valen tu tiempo

Mis escritos relacionados

• ¿Qué es Googlebot y cómo funciona? — las cadenas de agente de usuario completas de Googlebot, métodos de verificación y mi herramienta de verificación de IP.
• Indexado, aunque bloqueado por robots.txt — donde chocan el bloqueo basado en agente de usuario y el bloqueo por robots.txt.
• Robots.txt y SEO: todo lo que necesitas saber — cómo funcionan realmente los grupos de agentes de usuario y las reglas.
• Conoce a los nuevos rastreadores web: los bots de IA se acercan a los bots de motores de búsqueda — el elenco cambiante de agentes de usuario en tus registros.

Oficial / estándares

• RFC 9110 — Semántica HTTP, §10.1.5 User-Agent — la definición base: metadatos opcionales proporcionados por el cliente.
• RFC 9309: Protocolo de exclusión de robots — la definición formal a nivel de SHOULD del token de producto como subcadena.
• Descripción general de rastreadores y buscadores de Google y Verificar rastreadores de Google.
• Chrome Privacy Sandbox — Reducción de User-Agent y User-Agent Client Hints — por qué las cadenas de agente de usuario del navegador son cada vez más difíciles de analizar y qué las reemplaza.

De otros

• John Mueller — Bots que se hacen pasar por Googlebot — sobre la suplantación y por qué el DNS inverso es la respuesta.
• MDN — Cabecera User-Agent — la vista de la especificación HTTP de la cabecera.
• r/TechSEO — la comunidad para depuración de rastreo y registros.
• Web Bot Auth: el nuevo método experimental de Google para validar bots auténticos (Search Engine Land, Barry Schwartz, mayo de 2026) — el mejor resumen de noticias sobre cómo funciona la firma criptográfica de bots y qué significa en la práctica.
• El agente de usuario Google-Agent identifica el tráfico de agentes de IA en los registros del servidor (Search Engine Land) — cubre el nuevo buscador activado por el usuario que ignora robots.txt y utiliza Web Bot Auth.
• Google está probando un nuevo estándar de autorización de bots (Search Engine Journal) — contexto industrial más amplio sobre el estándar IETF y qué empresas (Amazon, Cloudflare, Akamai, OpenAI) lo respaldan.
• Anuncio de futuros agentes de usuario para Bingbot (Blog de Bing Webmaster, Fabrice Canel, diciembre de 2019) — el anuncio original del cambio de Bingbot a renderizado basado en Edge antes del despliegue de 2022.
• Microsoft publica la lista de direcciones IP de Bingbot (Search Engine Land) — cobertura de la decisión de Bing de publicar rangos de IP para la verificación de bots a escala.

Registro de cambios