innovaorigen tech Agenda una llamada
Agenda una llamada

Inicio/Glosario/Análisis de logs

SEO técnico

Análisis de logs

El análisis de logs es la disciplina del SEO técnico que examina los registros del servidor (access logs de Apache o Nginx) para observar el rastreo real de los bots, línea a línea, en lugar de datos estimados o muestreados.

Qué es

Cada vez que un crawler (Googlebot, Bingbot o bots de IA como GPTBot o ClaudeBot) solicita una URL, el servidor escribe una línea de log con la IP de origen, la fecha y hora, la URL pedida, el código de estado HTTP, los bytes transferidos, el referrer y el user-agent. El análisis de logs lee ese registro completo para reconstruir qué bot pide qué, cuándo, con qué frecuencia y con qué respuesta del servidor. Es la mirada más directa al rastreo e indexación tal como lo ejecuta el bot, sin la capa de estimación que se interpone en otras fuentes.

La diferencia con Google Search Console es de naturaleza, no de grado. Search Console entrega datos agregados, muestreados y limitados a los bots de Google. Los logs son el registro íntegro y en tiempo real de todo el rastreo: no estiman, registran. Por eso se consideran la fuente más fiel del comportamiento del rastreador.

A partir de ahí se diagnostica la frecuencia y distribución del rastreo (qué URLs visita el bot a menudo y cuáles ignora), se localizan páginas huérfanas (URLs que el servidor sirve con 200 y el bot rastrea, pero sin enlaces internos, detectables cruzando los logs con un crawl propio), se ven las cadenas y bucles de redirección tal como los recorre el bot, se auditan los códigos de estado reales y se distinguen los bots verdaderos de los que falsifican el user-agent.

Qué cuentan los logs
El rastreo real, no estimado
Qué URLs rastrea Googlebot de verdadLog
Frecuencia y códigos de respuestaLog
Páginas huérfanas y buclesLog
Bots reales frente a falsosLog

Por qué importa

Los logs muestran el rastreo tal como ocurre, no como se estima. Eso permite ver dónde se consume crawl budget (presupuesto de rastreo) sin valor (parámetros, filtros de navegación facetada, paginaciones, duplicados que delatan problemas de canonicalización y duplicados, redirecciones largas que apuntan a una limpieza pendiente de redirecciones 301 y migraciones, o errores 5xx) y qué URLs relevantes el bot apenas visita. Es un diagnóstico, no una palanca de posiciones: nadie puede garantizar ranking, y menos en un entorno de búsqueda cambiante sujeto a las actualizaciones del algoritmo (core updates).

Según la propia documentación de Google, el presupuesto de rastreo importa sobre todo en sitios grandes (más de un millón de páginas con cambios semanales) o medianos (más de diez mil con cambios diarios). En webs pequeñas y estables, el rastreo rara vez es el cuello de botella; ahí el problema suele ser de calidad o estructura, no de crawl, y el trabajo se desplaza hacia la arquitectura web y el enlazado interno que reparte el rastreo.

También expone un dato ausente por completo en Search Console: qué bots de IA (GPTBot, ClaudeBot, Amazonbot) acceden de verdad al sitio. Útil para decidir reglas de acceso en servidor o CDN —complemento de lo que ya declara el robots.txt— y para entender la exposición ante la búsqueda generativa, terreno propio de la GEO · Generative Engine Optimization. Conviene recordar que, bajo el RGPD, las IPs de los logs son dato personal: anonimización y límites de retención son parte del trabajo.

En profundidad

Anatomía de una línea de log

En el formato típico de Nginx, una línea incluye remote_addr, remote_user, time_local, request, status, body_bytes_sent, http_referer y http_user_agent. De esos campos salen las preguntas básicas: qué IP, qué bot, qué URL, qué código de estado y cuándo. Un análisis elemental es posible incluso con utilidades Unix (awk, sort, uniq); el análisis a escala se apoya en herramientas dedicadas, en la práctica un pequeño ejercicio de ETL / pipelines de datos que normaliza, filtra y agrega esas líneas antes de leerlas.

CampoPregunta que responde
remote_addrQué IP origina la petición
http_user_agentQué cliente o bot la hace
requestQué URL y método se pide
statusQué código de estado devolvió el servidor
time_localCuándo ocurrió

Verificación de bots reales frente a falsos

El método oficial de Google es el DNS inverso sobre la IP de origen: el nombre debe resolver a googlebot.com, google.com o googleusercontent.com, y se confirma con un DNS directo de vuelta a la misma IP. Como alternativa, se coteja la IP contra los rangos CIDR que Google publica en common-crawlers.json y special-crawlers.json. El user-agent por sí solo no prueba nada.

1
IP de origen
Se parte de la remote_addr de la línea de log, no del user-agent
2
DNS inverso
El nombre debe resolver a googlebot.com, google.com o googleusercontent.com
3
DNS directo de vuelta
Resolver ese nombre debe devolver la misma IP de origen
4
Alternativa: rangos CIDR
Cotejar la IP contra common-crawlers.json y special-crawlers.json

Detección de páginas huérfanas

Una página huérfana es una URL que el servidor sirve con 200 y el bot rastrea, pero a la que no apunta ningún enlace interno. No se ve en el log aisladamente: se descubre cruzando los eventos del log con un crawl propio del sitio. Si la URL aparece en el log pero no en el mapa de enlaces, es huérfana —un fallo de enlazado interno que el rastreador delata antes que cualquier auditoría visual—, y conviene contrastarla también con el Sitemap XML para saber si al menos se está declarando.

URL aparece en el log con 200El servidor la sirve y el bot la rastrea
URL aparece en el mapa de enlaces del crawlNingún enlace interno apunta a ella
Resultado: página huérfanaSolo emerge al cruzar log con un crawl propio del sitio

Rastreo de bots de IA y lectura para GEO

Los logs registran el acceso de GPTBot, ClaudeBot, Amazonbot y otros crawlers de IA, algo que Search Console no refleja. Esa lectura sirve para decidir reglas de acceso (servidor o CDN) y para entender qué partes del sitio quedan expuestas a la búsqueda generativa, sin estimaciones: es el sustrato técnico de la GEO · Generative Engine Optimization y un primer paso hacia la medición de la visibilidad en IA, que sin estos registros se queda en conjeturas sobre quién accede al contenido.

Crawler de IALectura en el log
GPTBotAcceso registrado; no se ve en Search Console
ClaudeBotAcceso registrado; no se ve en Search Console
AmazonbotAcceso registrado; no se ve en Search Console
UsoDecidir reglas de acceso en servidor o CDN y ver qué queda expuesto a la búsqueda generativa

Qué observar

Las señales que importan.

Sitio grande o de alta frecuencia de cambio

Más de un millón de URLs con cambios semanales, o más de diez mil con cambios diarios. Es el escenario donde Google sitúa el presupuesto de rastreo como factor real y donde el log aporta más.

Muchas URLs en "Detectada, actualmente sin indexar"

Cuando Search Console acumula URLs detectadas pero no rastreadas, el log revela si el bot está gastando su capacidad en otras URLs sin valor.

Sospecha de rastreo desperdiciado

Parámetros, filtros facetados, paginaciones, duplicados o redirecciones largas que el bot recorre sin aportar nada. El log mide el coste real de cada patrón.

Duda sobre la identidad del bot

El user-agent Googlebot se falsifica con frecuencia. La verificación oficial es por DNS inverso sobre la IP de origen, confirmado con DNS directo o cotejado contra los rangos CIDR publicados por Google.

Interés por el rastreo de bots de IA

Saber si GPTBot, ClaudeBot o Amazonbot acceden al sitio es información que Search Console no ofrece y que solo aparece en los logs del servidor.

Conceptos clave

El vocabulario del término.

Access log
Registro que el servidor web (Apache, Nginx) escribe con cada petición recibida: IP de origen, timestamp, URL, código de estado, bytes, referrer y user-agent.
Crawl budget (presupuesto de rastreo)
Según Google, el conjunto de URLs que el motor puede y quiere rastrear. Resulta de combinar el crawl capacity limit (conexiones paralelas que el sitio soporta) y la crawl demand (interés según popularidad, frescura e inventario).
Página huérfana
URL que el servidor sirve con 200 y los bots rastrean, pero que no recibe ningún enlace interno. Se detecta cruzando los logs con un crawl del propio sitio.
Verificación por DNS inverso
Método oficial para confirmar que un bot es real: se resuelve la IP de origen a un nombre, que debe pertenecer a dominios de Google (googlebot.com, google.com, googleusercontent.com), y se valida con un DNS directo de vuelta a la misma IP.
Rango CIDR
Bloque de direcciones IP. Google publica los suyos en common-crawlers.json y special-crawlers.json para cotejar si una IP pertenece de verdad a sus crawlers.
Cadena de redirección
Secuencia de saltos 3xx que el bot recorre antes de llegar al destino final. En los logs se ven los hops reales; las cadenas de tres o más saltos y los bucles atrapan al rastreador.
Soft 404
Página que responde con código 200 pero cuyo contenido equivale a un error o a una página vacía. Google la considera rastreo malgastado.

Dónde lo aplicamos

Casos de uso · Análisis de logs[PENDIENTE]

Aún no mostramos casos.

No inventamos resultados. Cuando tengamos casos reales —anonimizados y medibles— donde este concepto marcó la diferencia, vivirán aquí.

Una pieza del glosario.

Forma parte del glosario de SEO, analítica e IA de InnovaOrigen Tech: un mapa de conceptos definidos con criterio y fuentes. Si quieres llevarlo a tu caso, lo vemos sin compromiso.