Nunca verás a GPTBot en Google Analytics. GA4 y la mayoría de las herramientas de analítica de terceros registran una visita cuando el navegador ejecuta JavaScript, pero GPTBot no ejecuta JS ni activa ese código de seguimiento. Si quieres demostrar que el rastreador de OpenAI visitó una página, saber qué contenido solicitó y qué respuesta recibió, la única evidencia fiable es el registro de acceso original del servidor.
Por qué los registros del servidor son la única fuente fiable
Los rastreadores de IA y los usuarios reales siguen recorridos distintos. Una persona abre el navegador, carga la página, ejecuta JS y activa un evento de GA4; por eso la visita aparece en el panel. Un rastreador como GPTBot se limita a enviar una solicitud HTTP, recopilar el HTML devuelto y marcharse. Como no ejecuta el código de seguimiento, las herramientas de analítica no registran su actividad. Los registros del servidor funcionan de otra manera: ante cada solicitud entrante, ya proceda de una persona, Googlebot o GPTBot, Nginx o Apache anota la IP de origen, la hora, la ruta solicitada, el código de estado de la respuesta y el User-Agent. El frontend no puede bloquear este registro, que tampoco desaparece porque el visitante no ejecute JS.
Primero distingue los tres rastreadores de OpenAI: no te limites a GPTBot
Es habitual pensar que OpenAI solo utiliza un rastreador y buscar únicamente GPTBot en los registros. El resultado es una estimación muy inferior a la visibilidad real. OpenAI cuenta con al menos tres rastreadores, cada uno con una finalidad y un User-Agent diferentes. Conviene identificarlos y contabilizarlos por separado.
- GPTBot: obtiene contenido para entrenar y mejorar modelos. Su User-Agent contiene "GPTBot". Respeta robots.txt y sus IP de origen se publican en openai.com/gptbot.json.
- OAI-SearchBot: crea el índice utilizado por la función de búsqueda de ChatGPT. Su User-Agent contiene "OAI-SearchBot". Es el rastreador más directamente relacionado con la posibilidad de que tu contenido aparezca citado en las respuestas de ChatGPT.
- ChatGPT-User: se activa cuando un usuario pide a ChatGPT que consulte un enlace. Su User-Agent contiene "ChatGPT-User". Cuando aparece, significa que una persona real está accediendo a tu página a través de ChatGPT.
- Un paso más: en el mismo registro suelen aparecer otros rastreadores de IA, como PerplexityBot, ClaudeBot o Google-Extended. El método para analizarlos es exactamente el mismo.
Paso 1: localiza las huellas de GPTBot en el registro de acceso
En el formato combined habitual de Nginx, cada línea del registro incluye la IP de origen, la hora, "GET /blog/geo-audit HTTP/1.1", el código de estado 200, el número de bytes devueltos y, al final, la cadena del User-Agent. En las solicitudes de GPTBot, el User-Agent termina con compatible; GPTBot/1.2; +https://openai.com/gptbot. Esa firma permite analizar su actividad con apenas unas líneas de comandos.
- Localiza todas las solicitudes de GPTBot: grep -i "GPTBot" /var/log/nginx/access.log
- Cuenta cuántas veces ha accedido hoy: grep -ic "GPTBot" access.log
- Consulta la distribución de los códigos de estado de respuesta (en el formato combined, la columna 9 contiene el código de estado HTTP): grep -i "GPTBot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
- Identifica las páginas que rastrea con mayor frecuencia (la columna 7 contiene la ruta solicitada): grep -i "GPTBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
- Compara de una vez el volumen de rastreo de los tres bots: grep -c "GPTBot" access.log; grep -c "OAI-SearchBot" access.log; grep -c "ChatGPT-User" access.log
El resultado te permitirá evaluar de inmediato tres aspectos: la frecuencia —cuántas veces accede al día y en qué horarios—, la cobertura —si rastrea tus principales páginas de producto y artículos o se limita a la página de inicio— y el estado de las respuestas —si casi todas devuelven un código 200—. Si grep no devuelve ningún resultado, GPTBot no accedió durante el periodo analizado. En ese caso, comprueba si robots.txt o el firewall lo están bloqueando.
Paso 2: confirma que se trata del GPTBot auténtico
La cadena del User-Agent se puede falsificar con facilidad. Cualquier rastreador, incluido el tráfico malicioso, puede incluir "GPTBot" en la cabecera para suplantarlo, eludir determinadas reglas o consumir recursos del servidor. Por eso, después de localizar una solicitud, debes comprobar su autenticidad. Hay dos métodos y ambos ofrecen un alto grado de fiabilidad.
- Contrasta la IP con las listas oficiales: OpenAI publica los rangos de IP de origen de cada rastreador en openai.com/gptbot.json, openai.com/searchbot.json y openai.com/chatgpt-user.json. Compara la IP del registro con el rango correspondiente y contabilízala solo si está incluida.
- Verifica el DNS inverso: ejecuta una consulta PTR —con host o dig -x— sobre la IP de origen. Un GPTBot auténtico debe resolverse a un dominio de OpenAI. Después, realiza una consulta directa de ese dominio y confirma que devuelve la misma IP, un proceso conocido como forward-confirmed rDNS. Solo puedes confiar en la solicitud si ambas comprobaciones coinciden.
Paso 3: comprueba qué contenido obtiene y qué códigos de estado recibe
Que el rastreador llegue a tu sitio no significa que consiga acceder al contenido. Lo que realmente influye en la posibilidad de que ChatGPT use tu página como referencia es la respuesta que recibe en cada solicitud. Estos son los cuatro indicadores que debes vigilar.
- Código de estado: lo ideal es que todas las respuestas sean 200. Una gran cantidad de códigos 403 suele indicar que Cloudflare o el WAF bloquean a GPTBot por considerarlo tráfico sospechoso; los 404 señalan que el sitemap o los enlaces internos apuntan a URL no válidas; una sucesión de errores 5xx indica que el servidor falla cuando llega el rastreador.
- Páginas cubiertas: revisa la lista de rutas solicitadas para comprobar si incluye las páginas de precios, las páginas de planes y los artículos especializados con mayor potencial de ser citados. Si solo rastrea la página de inicio y algunos artículos antiguos, tu contenido principal permanece invisible para la IA.
- Solicitudes de llms.txt y robots.txt: el registro permite comprobar si el rastreador solicita /llms.txt y /robots.txt. Si has publicado llms.txt pero nunca lo consulta, ese rastreador no utiliza actualmente este estándar. No conviene sobrestimar su función.
- Frecuencia y actualización del rastreo: compara la fecha de publicación o revisión del artículo con las visitas posteriores de GPTBot para saber cada cuánto vuelve a rastrearlo. Si el intervalo es demasiado largo, tu contenido nuevo tardará más en incorporarse a la información que procesa el modelo.
Analiza los registros antes de hablar de optimización
Antes de dedicar tiempo a redactar llms.txt, corregir el marcado Schema o reescribir contenido, invierte diez minutos en analizar el registro de acceso con grep. Tenten se hizo cargo de un proyecto en el que tanto llms.txt como Schema estaban bien implementados. Al revisar los registros, descubrimos que el WAF llevaba seis meses devolviendo un 403 a GPTBot en cada solicitud: todo el trabajo de optimización anterior había sido inútil. Los registros te muestran sin ambigüedades si GPTBot llegó, qué intentó rastrear y dónde quedó bloqueado. Es el paso más económico y más importante de cualquier optimización técnica para GEO. Si quieres identificar qué carencias de visibilidad esconden tus registros y cuáles conviene resolver primero, puedes solicitar un diagnóstico GEO de 30 minutos. Revisaremos directamente el estado del rastreo y te indicaremos las mejoras más viables.
