Rastreadores de IA

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 Ajustes → Conexiones → Seguimiento del sitio web 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 Control 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 http a secas, y otros lenguajes pueden implementar directamente el protocolo de baliza firmada.

Los fragmentos para Cloudflare, Vercel y servidor propio leen el secreto de firma de una variable de entorno, CITLYZE_SIGNING_SECRET (un secreto cifrado del Worker en Cloudflare), así que el secreto nunca está en código que subas al repositorio o compartas. El plugin de WordPress lo guarda en sus ajustes.

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.

Los colectores informan de lo que pasó con cada petición:

• El Worker de Cloudflare, el middleware de servidor propio y el plugin de WordPress envían el estado HTTP exacto (200, 301, 404, 410, 500, etc.), que alimenta los insights de errores y redirecciones de más abajo. El middleware de Vercel se ejecuta antes de que exista la respuesta, así que no puede; para tener códigos de estado en Vercel, usa el log drain de Vercel en Seguimiento del sitio web → Registros del servidor en lugar del middleware.
• En una redirección, esos mismos tres colectores envían también su destino: la ruta si es una página de tu propio sitio, y solo el dominio si es cualquier otro sitio.
• En las visitas de rastreadores también se envía la query string (por ejemplo ?page=2). La query string de un visitante humano nunca sale de tu sitio.

Los eventos viajan en lotes firmados. Si Citlyze no está disponible un momento, el Worker de Cloudflare y el middleware de servidor propio lo reintentan una vez, y el plugin de WordPress guarda los eventos no entregados en tu base de datos de WordPress hasta un día y sigue reintentando. Un reintento nunca se cuenta dos veces. Cada colector instalado actualiza además su lista de rastreadores conocidos al menos una vez al día, así que un rastreador nuevo se reconoce sin actualizar el fragmento ni el plugin. La página Seguimiento del sitio web te avisa cuando hay una versión más reciente de tu fragmento o plugin.

El plugin de WordPress ve todas las peticiones que llegan a WordPress, incluidas las que otro plugin redirige antes de renderizar la página. No puede ver lo que nunca llega a WordPress: páginas servidas desde una caché de página completa, redirecciones hechas por tu servidor web o tu CDN, y peticiones que un firewall bloquea antes de que cargue WordPress. La página de ajustes del plugin te avisa cuando detecta una caché de página. Para sitios con mucha caché, usa el Worker de Cloudflare o sube los logs de tu servidor. Si WordPress está detrás de un proxy o balanceador de carga que no es Cloudflare, indica en los ajustes del plugin la cabecera de IP del cliente y las direcciones del proxy, para que los rastreadores se verifiquen por su dirección real.

Usa un solo colector por sitio. Si un colector del sitio web y una fuente de logs del servidor informan del mismo dominio, cada visita se cuenta dos veces; la página Seguimiento del sitio web te avisa cuando ocurre.

Servidores propios y otros lenguajes

La pestaña de servidor propio incluye un middleware para Node, pero cualquier stack puede informar: envía peticiones POST HTTPS firmadas a https://app.citlyze.com/api/track con un cuerpo JSON (256 KB como máximo) y Content-Type: application/json. Cada petición lleva un lote de 1 a 50 eventos.

Cabeceras obligatorias:

Cálculo de la firma:

1. 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.
2. Construye el mensaje: "3\n" + timestamp + "\n" + nonce + "\n" + bodyDigest, donde bodyDigest es 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.
3. x-aeo-signature es el HMAC-SHA256 hexadecimal en minúsculas de ese mensaje con la clave de firma del paso 1.

Guarda el secreto de firma en una variable de entorno o en el almacén de secretos de tu plataforma, nunca en el código fuente.

Campos del cuerpo:

• collector: un nombre corto para tu integración, por ejemplo my-app/1.0 (letras, dígitos, ., _, / y -, hasta 64 caracteres).
• events: la lista de eventos. Cada evento tiene estos campos (obligatorios salvo que se indique lo contrario):
  • occurredAt: cuándo ocurrió la petición, en milisegundos desde la época Unix. Los eventos de más de 48 horas se ignoran.
  • host: el nombre de host de la petición sin puerto, o una cadena vacía. Los eventos de un host que no sea el dominio de tu clave de sitio ni uno de sus subdominios se ignoran.
  • 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.
  • query (opcional): la query string sin el ?, solo para peticiones de rastreadores.
  • 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 referrer https:// sin query ni fragmento. Solo tiene sentido para visitas humanas que llegan desde respuestas de IA.
  • utmSource (opcional): el valor de utm_source, cuando una visita desde una respuesta de IA llega sin referrer.
  • status: el estado HTTP de tres dígitos de la respuesta, o unknown si informas antes de que exista la respuesta.
  • method: el método HTTP en mayúsculas.
  • redirectTarget (opcional): en una respuesta 3xx, el Location al que apuntaba.

Informa solo de las peticiones cuyo user agent parezca automatizado o cuyo referrer sea un motor de respuestas de IA, y envía los lotes después de la respuesta, nunca mientras un visitante espera. Si un lote falla con un error de red, un 429 o un 5xx, reinténtalo con el mismo nonce y el mismo cuerpo y una marca de tiempo nueva: un lote que ya llegó se reconoce por su nonce y se cuenta una sola vez. Un 429 incluye una cabecera Retry-After. Cualquier otro 4xx significa que el propio lote no es válido; no lo reintentes.

Opcionalmente, descarga una vez al día la lista actual de identificadores de rastreadores conocidos y hosts de referrer de IA desde GET https://app.citlyze.com/api/track/registry, con tu ID de clave en la cabecera x-aeo-key-id. La cabecera de respuesta x-aeo-registry-signature es el HMAC-SHA256 hexadecimal en minúsculas de "citlyze-registry-1\n" + bodyDigest, con la clave de firma del paso 1; ignora la lista si no coincide.

Para comprobar tu integración, envía un lote con "test": true que contenga un único evento cuyo userAgent empiece por citlyze-connection-test/ y cuyo path sea /citlyze-test. Una prueba correctamente firmada devuelve HTTP 200 y no almacena nada; los lotes reales devuelven 204, acaben o no las visitas 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 cuanto antes CITLYZE_SIGNING_SECRET (o el ajuste del plugin) con el nuevo secreto. Revocar es distinto: desactiva la clave de forma permanente y detiene el seguimiento de ese sitio.

Leer la analítica

La página Diagnosticar → Actividad de rastreadores de IA → Resumen muestra, para el periodo seleccionado:

• tarjetas principales: visitas totales de rastreadores, rastreadores distintos, rastreador principal y tendencia
• visitas de rastreadores a lo largo del tiempo (totales diarios)
• cuándo visitan los rastreadores: visitas por hora del día
• tendencias de rastreadores a lo largo del tiempo (una línea por rastreador)
• desglose por rastreador con organización, propósito, visitas y tendencia
• páginas más rastreadas (top 10, con un enlace a la lista completa)
• bots no reconocidos: user agents con aspecto de bot que no coinciden con ningún rastreador de IA conocido, agrupados bajo «Bot desconocido» para que los rastreadores nuevos aparezcan pronto

Los días y las horas siguen la zona horaria de tu navegador, así que una visita a las 21:00 en Nueva York cuenta en ese día, no en el siguiente. La tabla por página usa días UTC.

Las tendencias comparan solo días completos. Mientras el día de hoy sigue en curso queda fuera de la comparación, y cada día completo se compara con el mismo día un periodo antes. Un rastreador sin visitas en el periodo anterior muestra Nuevo en lugar de un porcentaje, y si el seguimiento empezó después del inicio del periodo anterior, todavía no se muestra tendencia.

Usa los preajustes (7/30/90 días), el rango de fechas personalizado y el filtro de rastreadores para acotar la vista. Los espacios de trabajo que siguen más de un sitio tienen también un filtro de sitio. Las personas que llegaron desde respuestas de IA se cubren en Tráfico de IA.

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:

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

Diagnosticar → Actividad de 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 las visitas, la cuota del tráfico total de rastreadores, la tendencia frente al periodo anterior, los errores, las redirecciones, el rastreador principal y la fecha de la última visita; despliega una fila para ver el reparto por rastreador y los códigos de estado exactos que recibieron los rastreadores.

Cuando procede, aparecen insights encima de la tabla:

• 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 más citable.
• Páginas que devuelven errores: páginas que respondieron a los rastreadores con 4xx/5xx. Una página rota no se puede leer ni citar.
• Páginas que redirigen: URL antiguas que los rastreadores siguen pidiendo y desde las que se les redirige. Apunta tus enlaces internos y tu sitemap a las URL finales.
• Páginas obtenidas por primera vez: páginas que ningún rastreador de IA había obtenido antes de este periodo desde que empezó el seguimiento. Si aparece aquí contenido nuevo, los rastreadores lo han encontrado.

Los códigos de estado y las redirecciones necesitan un colector que los envíe: el Worker de Cloudflare, el middleware de servidor propio, el plugin de WordPress o los logs del servidor.

La tabla se puede descargar como CSV en los planes que incluyen exportación de datos.

Registro de rastreo

Diagnosticar → Actividad de rastreadores de IA → Registro de rastreo lista cada petición que los rastreadores de IA verificados y los agentes firmados hicieron a tu sitio, día a día y en orden, agrupadas en sesiones de rastreo (las peticiones de un rastreador sin pausas de más de 30 minutos). Para cada petición ves la hora, la página y su query string, el código de estado y, en las redirecciones, a dónde apuntaba la redirección y si el rastreador la siguió en la misma sesión. Las páginas obtenidas más de una vez en una sesión aparecen marcadas.

El registro de rastreo guarda solo peticiones de rastreadores verificados y agentes firmados, nunca de otros visitantes, y nunca almacena una dirección IP ni un user agent. Los valores de parámetros de consulta que podrían contener credenciales o datos personales (como token o email) se sustituyen por redacted. Cuántos días puedes consultar depende de tu plan; consulta Planes y límites. El registro de un día se puede descargar 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.