Análisis de logs SEO: qué rastrean realmente los bots

El análisis de logs SEO consiste en revisar los registros de acceso (access logs) de tu servidor web para ver qué URL solicitan realmente Googlebot y otros rastreadores, cada cuánto vuelven y qué códigos de estado reciben. El resto de los datos SEO son muestras, llegan con retraso o son simulaciones. Los logs son un registro directo de cada visita de un bot, así que muestran dónde se desperdicia el rastreo y qué páginas se quedan sin visitar.

En esta guía verás cómo conseguir los logs, cómo limpiarlos, cómo comprobar que una visita de "Googlebot" viene de verdad de Google, qué patrones conviene buscar y cómo convertirlos en correcciones.

¿Qué es el análisis de logs del servidor para SEO?

Es el proceso de filtrar el registro de acceso del servidor hasta quedarte solo con las peticiones de buscadores y rastreadores de IA, y medir después qué rastrean. Luego lo comparas con lo que quieres que se rastree: tus páginas indexables e importantes. La diferencia entre ambas cosas es tu lista de tareas.

Cada línea de un log de acceso es una petición HTTP. Una línea típica en el formato habitual "combined" tiene este aspecto:

66.249.66.1 - - [28/Oct/2026:09:14:02 +0000] "GET /shoes/red-runner HTTP/1.1" 200 48213 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

De una sola línea obtienes la IP del cliente, la fecha y hora, el método y la URL, el código de estado, el tamaño de la respuesta, el referer y el user agent. Si multiplicas eso por varias semanas de tráfico, puedes responder preguntas que ninguna herramienta de rastreo resuelve: ¿ha descargado Google la nueva página de categoría? ¿Cuántas peticiones fueron a URL de filtros? ¿Qué bot recibió los errores 500 a las 3 de la madrugada?

¿Qué muestran los logs que no muestran Search Console ni los rastreadores?

Los logs muestran lo que hicieron los bots de verdad, URL por URL. Search Console ofrece datos agregados de Google, y un rastreador de sitios muestra lo que podría rastrearse. Los logs te dan las peticiones exactas, también las de todos los bots que no son de Google, con fecha, hora y respuestas que puedes cruzar con tu propia lista de URL.

La documentación del informe de Estadísticas de rastreo de Google enumera los desgloses que ofrece: total de peticiones, tamaño de descarga, tiempo medio de respuesta, estado del host, respuestas por código de estado, tipo de archivo, finalidad del rastreo (descubrimiento o actualización) y tipo de Googlebot. La misma página llega a recomendar revisar "los registros de tu sitio web" cuando investigas picos en la frecuencia de rastreo. Así que ambos se complementan: Estadísticas de rastreo es la visión general rápida, y los logs aportan el detalle por URL que hay detrás.

¿Quién necesita realmente analizar los logs?

El análisis de logs compensa sobre todo en sitios grandes o que cambian rápido, en sitios con navegación facetada y en sitios que acaban de pasar por una migración. Una web corporativa de 40 páginas rara vez lo necesita: ahí, Search Console y un rastreo suelen bastar.

La guía sobre el presupuesto de rastreo de Google está pensada para sitios con más de 1 millón de páginas únicas que cambian aproximadamente cada semana, o más de 10.000 páginas que cambian a diario. Para el resto, indica que suele bastar con mantener el sitemap actualizado y revisar con regularidad el informe de indexación de páginas. Aun así, los logs ayudan a sitios más pequeños en algunos casos:

• Después de una migración o un rediseño, para confirmar que Googlebot sigue las nuevas redirecciones y llega a las nuevas URL.
• Cuando hay páginas en "Descubierta: actualmente sin indexar" y quieres saber si Google las ha solicitado alguna vez.
• Cuando aparecen errores de servidor o lentitud en Estadísticas de rastreo y necesitas las URL y horas exactas.
• Cuando quieres saber cómo usan tu sitio los rastreadores de IA, ya que Search Console no informa sobre ellos en absoluto.

Si tu principal preocupación es el presupuesto de rastreo, nuestra guía de optimización del presupuesto de rastreo profundiza en las soluciones.

¿Cómo se obtienen y preparan los logs del servidor?

Pide a tu proveedor de hosting o a tu equipo de desarrollo los logs de acceso en bruto de al menos 30 días, de todos los servidores o CDN que sirven HTML. Después fíltralos para quedarte con las peticiones de bots, normaliza las URL y verifica los bots. Un conjunto de datos limpio importa más que una herramienta sofisticada.

Dónde están los logs

• Apache / Nginx: normalmente en archivos access.log, a menudo rotados y comprimidos con gzip cada día.
• Hosting gestionado: suele haber una descarga de "raw access logs" (logs de acceso en bruto) en el panel de control. Algunos proveedores solo guardan unos pocos días, así que activa primero el archivado.
• CDN o proxy inverso: si una CDN sirve páginas en caché, tu servidor de origen nunca ve esas peticiones. Necesitas también los logs de la CDN, o te faltará parte de la información.
• Configuraciones con balanceo de carga: combina los logs de todos los nodos.

Comprueba si el log registra la IP real del cliente o la del proxy. Sin la IP real no puedes verificar los bots.

Limpia los datos

1. Conserva solo los campos que necesitas: IP, fecha y hora, método, URL, estado, bytes, user agent y, si está disponible, el tiempo de respuesta.
2. Filtra por los tokens de user agent (Googlebot, bingbot, GPTBot, OAI-SearchBot, ChatGPT-User, etc.).
3. Verifica las IP (siguiente sección) y descarta las falsas.
4. Normaliza las URL: pasa el host a minúsculas, decide cómo tratar las barras finales y conserva los parámetros de consulta, porque es en ellos donde suele esconderse el rastreo desperdiciado.
5. Cruza el resultado con un rastreo de tu sitio y con tu sitemap XML, para que cada URL lleve etiquetas como "indexable", "canonicalizada", "en el sitemap" y "enlazada internamente".

Para un primer vistazo rápido antes de configurar ninguna herramienta, basta con una línea de shell sobre un log en formato combined:

grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Esto cuenta las peticiones de Googlebot por código de estado. Tómalo como una primera aproximación, porque todavía no está verificado.

¿Cómo verificar que Googlebot es realmente Google?

Haz una búsqueda DNS inversa de la IP, comprueba que el nombre de host termina en googlebot.com, google.com o googleusercontent.com y, después, haz una búsqueda DNS directa para confirmar que resuelve a la misma IP. A gran escala, compara las IP con los archivos de rangos de IP que publica Google.

Este paso es importante porque, como advierte la documentación de Googlebot, otros rastreadores suelen suplantar la cabecera user agent de Googlebot. Los scrapers se hacen pasar por Googlebot para saltarse los bloqueos. Si te saltas la verificación, podrías "corregir" patrones de rastreo que Google nunca generó.

La guía de verificación de Google describe los dos métodos. El manual es la comprobación DNS inversa y luego directa, en cuatro pasos. El automático compara las IP, en formato CIDR, con listas JSON: common-crawlers.json para rastreadores como Googlebot, special-crawlers.json para rastreadores como AdsBot y archivos separados para los fetchers activados por usuarios. La mayoría de las herramientas de análisis de logs pueden hacer esta comprobación por ti. Actívala y no la desactives.

Lo normal es que predomine el rastreo móvil. Google explica que, como indexa principalmente el contenido móvil, la mayoría de las peticiones de rastreo de Googlebot se harán con el rastreador para móviles. Si la mayoría de tus visitas verificadas vienen de Googlebot Desktop, revisa con atención tu versión móvil (consulta nuestra checklist de indexación mobile-first).

¿Qué patrones hay que buscar en los logs?

Busca cuatro cosas. Primero, páginas importantes que los bots rastrean poco o nunca. Segundo, rastreo gastado en URL que no deberían existir, como parámetros, duplicados y redirecciones. Tercero, respuestas con error o lentas. Cuarto, cambios en el volumen de rastreo a lo largo del tiempo. Cada uno apunta a un tipo concreto de corrección.

¿Por qué importan tanto los errores 5xx en los logs?

Los errores de servidor no solo hacen fallar una petición: también frenan el rastreo futuro. La guía de presupuesto de rastreo de Google indica que, cuando un sitio se ralentiza o responde con errores de servidor (códigos de estado HTTP 5xx) o señales de limitación de peticiones (como HTTP 429), el límite baja y Google rastrea menos. Los logs te muestran exactamente cuándo ocurre y en qué URL, a menudo durante picos de tráfico, copias de seguridad o despliegues. Agrupa las respuestas 5xx por hora y por plantilla de URL. Una página de búsqueda lenta o un feed de productos que agota el tiempo de espera son causas habituales, y corregir ese único endpoint puede recuperar el volumen de rastreo de todo el sitio. Revisa también la diferencia entre lo que indica Estadísticas de rastreo y lo que muestran tus logs. La página de ayuda de Estadísticas de rastreo explica que, si el informe muestra una cifra mucho mayor que tus logs, puede deberse a que Google no pudo rastrear porque tu archivo robots.txt estuvo inaccesible demasiado tiempo. Google cuenta esos casos como rastreos potenciales que nunca llegó a hacer.

Frecuencia de rastreo frente a importancia de la página

Ordena tus URL por valor de negocio (páginas que generan ingresos, categorías principales, artículos clave) y añade las visitas verificadas de Googlebot de cada una. Cuando las páginas importantes se rastrean menos que las URL de filtros, es la señal más clara de un problema de arquitectura web o de enlazado interno. Para saber qué 404 importan, consulta errores 404 y SEO.

Los logs muestran lo que hicieron los bots. Para entender por qué, necesitas un rastreo del mismo sitio: qué enlaces apuntan a las redirecciones, qué páginas están huérfanas, qué permite el robots.txt. Una auditoría SEO gratuita de SEORecheck rastrea tus páginas en un navegador real e informa de redirecciones, enlaces rotos, problemas de sitemap y canonical, y del acceso de los rastreadores de IA en robots.txt, con URL de ejemplo. Puedes comparar esos hallazgos directamente con tus datos de logs.

¿Cómo analizar los rastreadores de IA en los logs del servidor?

Filtra por el user agent documentado de cada proveedor de IA, verifica las IP con los rangos que publica cada uno y separa los bots por finalidad (búsqueda, activados por el usuario o entrenamiento). Después comprueba que los bots que quieres reciben respuestas 200 en tus páginas importantes.

La documentación de rastreadores de OpenAI es un buen ejemplo de por qué conviene separar los bots por finalidad. OAI-SearchBot se usa para mostrar sitios web en las funciones de búsqueda de ChatGPT. GPTBot rastrea contenido para entrenar modelos de IA generativa. ChatGPT-User gestiona acciones que inician los usuarios en ChatGPT, y OpenAI aclara que, al ser acciones iniciadas por el usuario, "es posible que no se apliquen las reglas de robots.txt". OpenAI publica una lista de IP distinta para cada uno (searchbot.json, gptbot.json, chatgpt-user.json), así que puedes verificarlos igual que verificas Googlebot.

Google funciona de la misma manera. Su resumen de rastreadores distingue los rastreadores comunes, que siempre respetan las reglas de robots.txt en los rastreos automáticos, de los rastreadores de casos especiales y los fetchers activados por usuarios. Si tus logs muestran que un bot de IA con finalidad de búsqueda recibe errores 403 por una regla del firewall mientras robots.txt lo permite, el bloqueo está en tu servidor, no en robots.txt. Nuestra guía de robots.txt explica cómo definir reglas para cada bot.

Los logs muestran si los rastreadores de IA descargan tus páginas, pero no si esas páginas se citan. Ningún proveedor documenta una relación entre el volumen de rastreo y las citas.

¿Con qué frecuencia conviene analizar los logs?

Haz una revisión completa una vez por trimestre y una comprobación específica tras cualquier migración, despliegue importante o cambio repentino en Estadísticas de rastreo. En sitios grandes, configura un panel que avise de picos de 5xx y de caídas en las visitas verificadas de Googlebot a las plantillas clave.

Una rutina práctica:

• Cada semana (sitios grandes): visitas verificadas de Googlebot por día, porcentaje de respuestas 5xx y 429, patrones de parámetros más solicitados.
• Después de cada lanzamiento: compara los 7 días anteriores y posteriores. Busca nuevos 404, nuevas visitas a redirecciones y nuevos patrones de URL, junto con tus pruebas de regresión SEO.
• Cada trimestre: frecuencia de rastreo frente a importancia de la página, URL huérfanas, acceso de los rastreadores de IA por finalidad.

Añade cada corrección a tu plan con un responsable y una fecha. Después vuelve a revisar los logs entre 30 y 60 días más tarde para confirmar que el patrón ha cambiado, por ejemplo, menos visitas a URL con parámetros y más a las páginas de categoría que enlazaste.

Puntos clave

• Los logs del servidor son el único registro completo de lo que Googlebot y los rastreadores de IA solicitan realmente en tu sitio.
• Verifica los bots con DNS inverso/directo o con los rangos de IP publicados antes de analizar nada, porque el user agent de Googlebot se suplanta con frecuencia.
• Consigue los logs de todas las capas que sirven páginas, incluida la CDN, y conserva al menos 30 días.
• Céntrate en cuatro patrones: páginas importantes que apenas se rastrean, rastreo desperdiciado en parámetros y redirecciones, errores 5xx/429 y cambios de volumen.
• Combina los logs con un rastreo del sitio: los logs muestran lo que hicieron los bots y el rastreo explica por qué.
• Separa los rastreadores de IA por finalidad (búsqueda, activados por el usuario, entrenamiento). Los datos de rastreo no dicen nada sobre las citas.

Para ver cómo una auditoría convierte los hallazgos de rastreo en correcciones priorizadas, echa un vistazo al informe de ejemplo.