Rastreadores de IA
Ve qué rastreadores de IA visitan realmente tu sitio y cómo instalar el seguimiento.
El seguimiento de rastreadores de IA muestra qué motores de IA visitan realmente tu sitio: GPTBot, ClaudeBot, PerplexityBot, Bingbot y más. Complementa las auditorías GEO: las auditorías dicen si los bots pueden llegar a una página; el seguimiento dice si realmente lo hacen.
Por qué captura del lado del servidor
Los rastreadores de entrenamiento de IA no ejecutan JavaScript, así que un píxel de Google Tag Manager o JavaScript nunca ve a GPTBot o ClaudeBot. Citlyze captura las visitas del lado del servidor, donde el User-Agent real es visible, de modo que incluso los rastreadores sin JavaScript se cuentan.
La mitad humana es distinta: los visitantes referidos por respuestas de IA sí ejecutan JavaScript, así que para Tráfico de IA un fragmento de navegador o una instalación con Tag Manager funcionan bien (consulta Instalar el seguimiento de tráfico de IA). Las instalaciones del lado del servidor de esta página capturan ambos tipos a la vez.
Instalar el seguimiento
Ve a Rastreadores de IA → Instalar seguimiento y genera una clave de sitio. La clave tiene dos partes, un ID de clave y un secreto de firma, que se muestran una sola vez; copia ambas. Después añade el fragmento correspondiente a tu plataforma (para una guía clic a clic de cada opción, consulta Instalar el seguimiento de rastreadores de IA):
- Cloudflare (recomendado): pega el fragmento del Worker delante de tu sitio.
- Vercel / proxy inverso: añade el fragmento de middleware.
- WordPress: descarga AI Crawler Tracker by Citlyze, súbelo en wp-admin
→ Plugins y, en sus ajustes, rellena los tres campos: Tracker base URL
(
https://app.citlyze.com), Key ID y Signing secret. Usa Enviar evento de prueba (“Send test event”) para comprobar la entrega. El plugin no informa hasta que rellenas la URL base del tracker. - Servidor propio / Node: para sitios autoalojados (AWS, GCP, Azure, bare
metal, contenedores), añade el fragmento de middleware estilo Express
(Node 20+). Se adapta a Fastify, Koa o
httpa secas, y otros lenguajes pueden implementar directamente el protocolo de baliza firmada.
Cada evento se firma con tu secreto para que el tracker rechace balizas falsificadas. Esa firma demuestra que el informe vino de tu sitio; no dice nada sobre quién fue el visitante. Confirmar que un visitante era realmente GPTBot es un paso aparte, explicado en Cómo funciona la verificación.
Las tiendas Shopify estándar no pueden ejecutar captura del lado del servidor, y Shopify no admite poner un proxy (como Cloudflare) delante de una tienda, así que el seguimiento completo de rastreadores no está disponible en Shopify estándar. Las tiendas headless de Hydrogen u Oxygen ejecutan código del lado del servidor y pueden usar el fragmento de servidor propio. El hosting de Webflow tampoco puede ejecutar código de servidor; en Webflow Enterprise, un proxy inverso autogestionado puede ejecutar el Worker de Cloudflare o el fragmento de servidor propio en la capa del proxy.
El Worker de Cloudflare y el middleware de servidor propio informan del estado HTTP de cada petición rastreada, que alimenta los insights de errores de más abajo. El plugin de WordPress se ejecuta antes de renderizar la página, así que solo distingue los 404 del resto; y el middleware de Vercel se ejecuta antes de que exista la respuesta, así que no puede informar del estado en absoluto.
Las cachés de página completa y las CDN pueden responder sin ejecutar el plugin de WordPress. Para sitios con mucha caché, usa el Worker de Cloudflare.
Servidores propios y otros lenguajes
La pestaña de servidor propio incluye un middleware para Node, pero cualquier
stack puede informar: una baliza es un único POST HTTPS firmado a
https://app.citlyze.com/api/track con un cuerpo JSON (32 KB como máximo) y
Content-Type: application/json.
Cabeceras obligatorias:
| Cabecera | Valor |
|---|---|
x-aeo-schema | La cadena literal 2. |
x-aeo-key-id | Tu ID de clave (el UUID que se muestra al generar la clave de sitio). |
x-aeo-ts | Marca de tiempo Unix en segundos; debe estar a menos de 5 minutos del reloj del tracker. |
x-aeo-nonce | Único por evento: de 16 a 64 caracteres de dígitos hexadecimales y guiones. Sirve un UUID sin los guiones. Cada nonce se acepta una sola vez; las repeticiones se ignoran. |
x-aeo-signature | HMAC en hexadecimal en minúsculas, calculado como sigue. |
Cálculo de la firma:
- Deriva la clave de firma: el SHA-256 hexadecimal en minúsculas de
64 caracteres de tu secreto de firma (la cadena
ctk_...completa). Usa los bytes UTF-8 de esa cadena hexadecimal como clave HMAC; no la decodifiques desde hexadecimal. - Construye el mensaje:
"2\n" + timestamp + "\n" + nonce + "\n" + bodyDigest, dondebodyDigestes el SHA-256 hexadecimal en minúsculas de los bytes exactos del cuerpo que envías. Cualquier reserialización después de firmar invalida la firma. x-aeo-signaturees el HMAC-SHA256 hexadecimal en minúsculas de ese mensaje con la clave de firma del paso 1.
Campos del cuerpo (todos obligatorios salvo que se indique lo contrario):
userAgent: el User-Agent del visitante, hasta 1024 caracteres.path: la ruta de la petición con/inicial y sin query string ni fragmento, hasta 2048 caracteres.visitorIp: la IP del cliente tal como la ve tu servidor. Detrás de un balanceador de carga o un proxy inverso, tómala de la cabecera de reenvío que establece tu propio proxy; este campo es el que comprueba la verificación de identidad de los rastreadores.referrer: una cadena vacía, o una URL de referrerhttps://sin query ni fragmento. Solo tiene sentido para visitas humanas que llegan desde respuestas de IA.status: el estado HTTP de tres dígitos de la respuesta, ounknownsi informas antes de que exista la respuesta.method: el método HTTP en mayúsculas.
Informa solo de las peticiones cuyo user agent parezca automatizado o cuyo referrer sea un motor de respuestas de IA, y envía la baliza después de la respuesta, sin esperar confirmación; una caída del tracker nunca debería ralentizar tu sitio.
Para comprobar tu integración, envía una baliza con "test": true, un
userAgent que empiece por citlyze-connection-test/ y
"path": "/citlyze-test". Un evento de prueba correctamente firmado devuelve
HTTP 200 y no almacena nada; los eventos reales siempre devuelven 204, acabe
o no la visita en tus informes.
Rotar o revocar una clave
Si un secreto de firma pudo filtrarse (por ejemplo, se subió a un repositorio o se compartió en una captura), usa Rotar junto a la clave. La rotación emite un secreto nuevo para la misma clave: el ID, el nombre, el dominio y todo el historial se conservan, pero el secreto anterior deja de funcionar de inmediato, así que actualiza tu fragmento o plugin con el nuevo secreto cuanto antes. Revocar es distinto: desactiva la clave de forma permanente y detiene el seguimiento de ese sitio.
Leer la analítica
La página Rastreadores de IA → Analítica muestra, para el periodo seleccionado:
- mosaicos de cabecera: accesos totales, rastreadores distintos, rastreador principal y tendencia
- visitas de rastreadores en el tiempo (totales diarios)
- tendencias por rastreador en el tiempo (una línea por rastreador)
- desglose por rastreador con organización, propósito, accesos y tendencia
- visitas humanas desde respuestas de IA: visitantes que llegaron desde ChatGPT, Perplexity, Gemini, Copilot y otros, con sus páginas de destino principales; el informe completo de referidos, incluidas las conversiones, está en Tráfico de IA
- páginas más rastreadas (top 10, con enlace a la lista completa)
- bots no reconocidos: user agents de tipo bot que no coinciden con ningún rastreador de IA conocido, agrupados bajo «Bot desconocido» para que los rastreadores nuevos aparezcan pronto
Usa los periodos predefinidos (7/30/90 días), el rango de fechas personalizado y el filtro de rastreador para enfocar la vista. Los espacios que siguen más de un sitio disponen además de un filtro de sitio.
Cómo funciona la verificación
Cualquier cliente puede poner GPTBot en su user agent. Por eso un user agent
es una afirmación, no una prueba, y Citlyze lo trata así: las cifras
principales de rastreadores solo cuentan tráfico que pudimos confirmar de forma
independiente.
Cada visita recibe uno de tres niveles de confianza:
- Verificado: confirmamos la identidad de red del visitante contra algo que el operador publica. Solo estas cuentan para tus totales.
- Probable: hay indicios que lo respaldan, como que tu CDN marque la petición como un bot conocido, pero sin confirmación independiente.
- No verificado: el user agent nombró un rastreador y nada lo contradijo, pero no pudimos confirmarlo. Se muestra aparte y nunca se suma a tus totales.
La verificación usa lo que cada operador admita:
| Método | Qué demuestra |
|---|---|
| Solicitud firmada | La petición llevaba una firma criptográfica que verificamos contra las claves publicadas del operador. La evidencia más fuerte disponible. |
| Rango de IP publicado | La dirección de origen está dentro de un rango que el operador publica para sus rastreadores. |
| DNS inverso | La dirección de origen resuelve al dominio del operador, y ese nombre resuelve de vuelta a la misma dirección. |
| Rango de IP conocido | La dirección de origen está dentro de un rango fijo documentado por el operador. |
| Atestación de CDN | Tu CDN identificó la petición como un bot conocido. Corrobora, pero no es concluyente. |
| Solo user agent | Nada más que el nombre autodeclarado. Siempre sin verificar. |
Los operadores que no publican nada comprobable solo pueden llegar a no verificado. Eso es una característica del rastreador, no un problema de tu configuración, y por eso existen vistas separadas en lugar de una única cifra mezclada.
Dos cosas que conviene saber:
- El tráfico de agentes se cuenta aparte. Las herramientas que las personas manejan, como ChatGPT Agent, aparecen en actividad de agentes y no en los totales de rastreadores: una persona haciendo clic no es la misma señal que un rastreador indexándote.
- A veces no podemos comprobarlo: la lista de IP de un operador puede estar temporalmente inaccesible. Esas visitas quedan como no verificadas en lugar de contarse, así tus totales nunca incluyen algo que no confirmamos.
Páginas rastreadas
Rastreadores de IA → Páginas rastreadas es el detalle completo: cada página que los rastreadores de IA obtuvieron en el periodo seleccionado, con búsqueda, ordenación y paginación. Cada fila muestra accesos, cuota del tráfico total de rastreadores, tendencia frente al periodo anterior, errores, rastreador principal y última visita; despliega una fila para ver el desglose por rastreador.
Dos insights aparecen sobre la tabla cuando son relevantes:
- Rastreadas pero nunca citadas: páginas que los motores de IA obtienen pero nunca citan en tus respuestas seguidas; candidatas a un contenido más claro y citable.
- Páginas que devuelven errores: páginas que respondieron a los rastreadores con códigos 4xx/5xx. Una página rota no puede leerse ni citarse. El rango completo requiere la instalación de Cloudflare o de servidor propio; una instalación de WordPress detecta los 404, pero no los 5xx.
La tabla puede descargarse como CSV en los planes que incluyen exportación de datos.
Acceder a los datos por API y MCP
Las visitas de rastreadores están disponibles de forma programática una vez instalado el seguimiento:
- REST:
GET /api/v1/crawler-events; consulta el recurso AI Crawler Events. - MCP: la herramienta
list_crawler_events; consulta la referencia de herramientas MCP.
Ambos son de solo lectura y están limitados a tu espacio. El recurso REST
filtra por crawler_id, sitio rastreado y path exacto; las visitas humanas
desde respuestas de IA se exponen en GET /api/v1/ai-referrals.