El análisis de logs SEO consiste en revisar los registros de tu servidor para ver qué URLs pidió de verdad Googlebot (y el resto de los bots), cuándo las pidió y qué le respondió tu sitio. Suena a tarea de TI, y en parte lo es, pero para el SEO es la única forma de saber lo que pasó en tu sitio sin depender de lo que una herramienta resume.
Un ejemplo inventado, para que se vean los números. Un ecommerce recibe 800.000 visitas de Googlebot al mes. Suena como una muy buena noticia, hasta que alguien abre los logs y descubre que 300.000 de esas visitas fueron a filtros de color y talla que nadie quiere ver en Google. Mientras, la colección nueva lanzada hace diez días no recibe ni una visita.
Mi lectura es que los logs se leen por plantilla y por tipo de bot, porque así se ve qué parte del rastreo llega a las páginas que venden y qué parte se pierde. Acá te cuento qué contiene un archivo de log, dónde conseguirlo, cómo hacer el análisis paso a paso y qué mirar, incluidos los bots de IA que hoy pasan por tu sitio sin aparecer en ningún panel.
¿Qué es el análisis de logs SEO?
Cada vez que alguien pide una página, el servidor anota una línea en un archivo: quién pidió, qué URL, cuándo y qué respondió. Eso es un log de acceso. Lo anota para personas, para Googlebot, para ChatGPT y para el scraper que alguien dejó corriendo en su casa.
El análisis de logs SEO toma ese archivo, filtra las visitas de los buscadores y contesta preguntas concretas: ¿qué secciones rastrea Google y cuáles ignora?, ¿cuántas veces recibe un error?, ¿cuánto demora en llegar a una página nueva? Es una pieza clásica de la auditoría técnica de un sitio grande, porque trabaja con hechos.
En un sitio de 300 URLs esto rara vez cambia tu plan de SEO técnico. En uno de 200.000, con filtros y búsqueda interna, los logs del servidor suelen ordenar el roadmap de los próximos meses.
¿Qué contiene un archivo de log?
Una línea típica de un servidor Apache o Nginx (en el formato combinado que usan casi todos) se ve así:
66.249.66.1 - - [10/Nov/2026:08:14:22 -0300] "GET /zapatillas/running/ HTTP/1.1" 200 18342 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Parece un jeroglífico, pero tiene pocas piezas:
| Campo | En el ejemplo | Para qué te sirve |
|---|---|---|
| IP | 66.249.66.1 | Verificar si la visita es del bot que dice ser |
| Fecha y hora | 10/Nov/2026 08:14 | Ver frecuencia y cuánto demora en llegar a lo nuevo |
| Método y URL | GET /zapatillas/running/ | Agrupar por sección o plantilla |
| Código de estado | 200 | Ver errores, redirecciones y páginas que no existen |
| Bytes | 18342 | Detectar respuestas vacías o sospechosamente livianas |
| User-agent | Googlebot/2.1 | Saber qué bot dice ser |
Para el análisis de logs SEO, los campos que más trabajan son la IP, la URL, el código de estado, la fecha y el user-agent. Hay uno que casi nunca viene por defecto y que vale la pena pedir: el tiempo de respuesta (en Nginx es $request_time; en Apache, %D). Sin él no puedes ver qué URLs le responden lento a Google.
¿En qué se diferencia de Search Console y de un rastreador?
La pregunta es razonable, porque Search Console ya tiene un informe de Estadísticas de rastreo (en Configuración) con los últimos 90 días. Y un rastreador como Screaming Frog recorre tu sitio como si fuera Google. Las tres sirven al SEO, pero responden cosas distintas:
| Fuente | Qué te muestra | Qué no te muestra |
|---|---|---|
| Estadísticas de rastreo de Search Console | Totales de solicitudes, tiempo promedio, códigos y tipos de archivo, con ejemplos | Todas las URLs una por una, y cualquier bot que no sea de Google |
| Rastreador (Screaming Frog, Ahrefs) | Cómo se puede recorrer tu sitio siguiendo enlaces | Lo que Google hizo de verdad |
| Logs del servidor | Cada visita real de cada bot, con su URL y su respuesta | Por qué Google decide lo que decide |
Para una auditoría yo partiría siempre por Search Console, porque es gratis y ya está ahí. Si ves algo raro (picos de errores, muchas solicitudes a URLs que no esperabas), los logs son el siguiente paso para encontrar dónde está el problema.
¿Dónde consigues los logs del servidor?
Acá viene la parte menos glamorosa del SEO: casi siempre hay que pedirle los archivos a alguien, y dónde están depende de cómo esté montado tu sitio.
-
Servidor propio (Apache o Nginx). Normalmente viven en una carpeta tipo
/var/log/y alguien de TI los puede exportar comprimidos. -
Hosting administrado. Algunos los muestran en el panel; en otros hay que pedirlos a soporte.
-
Detrás de un CDN. Si usas Cloudflare u otro CDN, muchas visitas se responden desde la caché y nunca llegan a tu servidor de origen. En ese caso necesitas los logs del CDN además de los del origen (y no todos los planes los entregan completos).
Al pedirlos, yo dejaría por escrito tres cosas: al menos 30 días, todos los subdominios y los campos que mencioné arriba, sin filtrar. Si el equipo de TI se preocupa por las IPs de usuarios (con razón, son datos personales), puedes pedir solo las líneas de bots o las IPs de personas anonimizadas: para el SEO alcanza.
¿Cómo hacer un análisis de logs paso a paso?
Este es el método que usamos en la auditoría de SEO técnico de un sitio grande. En un sitio chico puedes hacer lo mismo con una hoja de cálculo.
-
Junta 30 días de logs. Con menos, una semana rara (un lanzamiento, una caída) te puede engañar.
-
Verifica los bots. Quédate solo con las visitas que son de Googlebot de verdad (más abajo te explico cómo) y separa los bots de IA en su propio grupo.
-
Agrupa las URLs por plantilla. Fichas de producto, categorías, filtros, parámetros, paginación, búsqueda interna, artículos. Es la parte que más rinde, porque 40.000 fichas juntas muestran patrones que URL por URL se pierden.
-
Cruza con lo que debería pasar. Compara las URLs que el bot visitó con tu sitemap y con un rastreo de tu sitio. Las diferencias son el diagnóstico.
-
Prioriza por lo que vende. Ordena los hallazgos por cuánto rastreo se pierde y por cuánto afecta a páginas comerciales.
-
Vuelve a medir. Después de cada cambio, saca logs nuevos a las dos o cuatro semanas y compara la distribución por plantilla.
La clave está en el paso 3, porque así el análisis de logs te muestra lo que pasó, que no siempre es lo que el sitemap dice que debería pasar. Si te interesa el presupuesto de rastreo, en el artículo de crawl budget explico cuándo ese rastreo merece un proyecto propio.
¿Cómo saber si una visita es de Googlebot de verdad?
Cualquiera puede escribir "Googlebot" en el user-agent de un script, así que ese campo solo no prueba nada. Google documenta dos formas de verificarlo:
-
DNS inverso y directo. Para verificar, haces una búsqueda de DNS inverso con la IP del log, revisas que el nombre termine en googlebot.com, google.com o googleusercontent.com, y después haces la búsqueda directa de ese nombre para confirmar que vuelve a la misma IP.
-
Rangos de IP publicados. Google publica archivos JSON con los rangos que usan sus rastreadores (por ejemplo,
common-crawlers.jsonpara Googlebot) y puedes comparar las IPs contra esa lista.
Las herramientas de logs hacen esta verificación de forma automática. Una pista rápida (esto sale de la experiencia; Google no lo documenta): si tus logs muestran mucho más "Googlebot" del que aparece en las Estadísticas de rastreo de Search Console, buena parte de esas visitas probablemente son de impostores.
¿Qué buscar en los logs?
Con los bots verificados y las URLs agrupadas, yo miraría cuatro cosas, en este orden.
¿A dónde se va el rastreo?
Suma las visitas de Googlebot por plantilla y calcula qué porcentaje se lleva cada una. Es el número que más le sirve al análisis de logs, porque muestra la frecuencia con que el bot vuelve a cada tipo de página. En los sitios con navegación facetada, el patrón se repite bastante: los filtros y las combinaciones de parámetros (color, talla, orden por precio) generan miles de URLs, y Google las va descubriendo y visitando.
Volvamos al ejemplo inventado. Si esas 300.000 visitas (el 38% del rastreo) se van a filtros con noindex o con canonical a la categoría, Google está rastreando harto; el problema está en qué le estás dejando recorrer. Ahí las decisiones son de plantilla: qué filtros generan URLs enlazables, cuáles se bloquean en el robots.txt y cuáles se consolidan.
¿Qué códigos de estado recibe Googlebot?
Agrupa las respuestas por código. Lo sano es que la gran mayoría sean 200 (página OK) o 304 (no cambió desde la última visita). Algunas guías dan umbrales, como menos de 10% de redirecciones y menos de 5% de 404; sirven como referencia de quien las publica (Google no da umbrales). Lo que yo buscaría:
-
Muchas redirecciones 301. Suelen venir de enlaces que apuntan a URLs viejas o de cadenas que quedaron de una migración.
-
Muchos 404. Categorías o productos eliminados sin redirigir que Google sigue visitando (más sobre esto en el error 404 que escribí para Ahrefs en Español).
-
Errores 5xx en horarios específicos. Un error 500 o un error 503 que aparece justo cuando Googlebot pasa en ráfaga puede no verse en tu monitoreo, porque el monitoreo revisa una vez por minuto y el bot pide decenas de páginas seguidas.
¿Qué páginas importantes no visita?
Este es mi favorito. Toma la lista de páginas que importan para el negocio (o tu sitemap completo) y compárala con las URLs que Googlebot visitó en los 30 días. Las que no aparecen ni una vez son, para efectos prácticos, huérfanas desde el punto de vista de Google.
Y para cada página nueva que vende, mide cuántos días pasaron entre que la publicaste y la primera visita de Googlebot. Si una ficha nueva demora semanas mientras un filtro se visita todos los días, ya tienes un problema medido en algo que le importa al negocio. Muchas veces la solución es acercarla a la home con enlaces internos desde páginas que el bot visita seguido (en indexar una página en Google hay más detalle de qué revisar después).
¿Qué tan rápido responde el servidor?
Si pediste el tiempo de respuesta, ordena las URLs de la más lenta a la más rápida. Google ajusta su ritmo de rastreo a lo que tu servidor aguanta: si responde lento o con errores, baja la velocidad. Una plantilla que tarda más de un segundo en responder de forma constante (suelen ser listados con muchos filtros) merece una conversación con desarrollo.
¿Qué bots de IA aparecen en los logs?
Esta es la parte nueva del SEO técnico, y la razón por la que hoy pediría los logs incluso en sitios medianos. Los bots de IA no aparecen en Search Console ni en Google Analytics, porque no ejecutan el código de medición. Donde sí quedan es en los logs del servidor, en las mismas líneas donde aparece Googlebot.
OpenAI, por ejemplo, documenta sus bots y cada uno hace algo distinto:
| Bot | Para qué visita tu sitio | Qué decides con eso |
|---|---|---|
| GPTBot | Rastrear contenido para entrenamiento de modelos | Si quieres que tu contenido entrene modelos |
| OAI-SearchBot | Que tu sitio aparezca en la búsqueda de ChatGPT | Si quieres aparecer en esas respuestas |
| ChatGPT-User | Visitas que hace ChatGPT cuando un usuario le pide algo | Qué páginas están leyendo las respuestas |
La tercera fila es la que más me interesa. Las visitas de ChatGPT-User son lo más parecido que tienes a ver qué páginas tuyas lee ChatGPT para contestarle a alguien, así que vale la pena revisar con lupa en qué URLs caen. Otras empresas tienen los suyos (ClaudeBot, PerplexityBot), y conviene agruparlos igual: entrenamiento, búsqueda y usuario.
Un detalle práctico: algunos CDN y firewalls ya bloquean bots de IA por defecto. Si en tus logs no aparece ni una visita de OAI-SearchBot, revisa la configuración antes de concluir que a ChatGPT no le interesa tu sitio. Para decidir qué dejar pasar, en robots.txt y entrenamiento de IA explico la señal nueva, y en tráfico de ChatGPT en Google Analytics cómo medir las visitas humanas que llegan después.
¿Qué herramientas sirven para analizar logs?
Las herramientas se eligen por volumen, porque la lógica del análisis de logs es la misma para todas:
-
Hoja de cálculo. Para unos pocos miles de líneas, filtras por user-agent y haces una tabla dinámica por carpeta y código de estado.
-
Screaming Frog Log File Analyser. Lee logs de Apache, Nginx e IIS, verifica bots y te muestra URLs más y menos rastreadas. Se cruza con Screaming Frog SEO Spider, así que ves lo rastreable y lo rastreado en una pantalla.
-
Herramientas de SEO técnico para sitios enterprise. Oncrawl, Botify, JetOctopus o Seolyzer reciben logs de forma continua y los cruzan con rastreos y Search Console. Tienen sentido cuando el sitio tiene millones de URLs y Googlebot pasa a diario.
-
BigQuery o una pila ELK. Cuando el equipo de datos ya trabaja ahí y los archivos de log pesan varios GB al día.
Para empezar, Screaming Frog con 30 días de logs alcanza en muchos de los sitios que vemos.
¿Cada cuánto vale la pena hacer un análisis de logs?
Depende del tamaño del sitio y de cuánto cambia:
-
Sitios de más de 10.000 URLs o con catálogo que cambia seguido: una vez por trimestre, y además después de cada cambio grande de plantilla.
-
Antes y después de una migración: siempre. Es la forma más directa de comprobar que Google encontró las URLs nuevas y que las redirecciones funcionan.
-
Sitios chicos y estables: una revisión al año, o cuando la frecuencia de rastreo cambie de golpe en las Estadísticas de rastreo.
Si tu sitio tiene pocas páginas y Google las indexa sin demora, el análisis de logs no va a ser tu proyecto SEO de mayor impacto, y está bien dedicarle ese tiempo a otra cosa.
Lo que revisaría esta semana
Si nunca has mirado tus logs, haría solo esto: pide a TI 30 días de logs del servidor (o del CDN), quédate con Googlebot verificado y suma las visitas por tipo de página. Con esa tabla vas a saber si el rastreo va a las páginas que venden o a los filtros, que es lo que más le importa a tu SEO.
De pasada, busca "ChatGPT-User" y "OAI-SearchBot" en el mismo archivo. Si no aparecen, ya tienes una pregunta concreta para el equipo que administra el CDN.