¿Qué es el análisis de logs?

El análisis de logs consiste en leer el registro que el servidor escribe cada vez que alguien pide algo: una página, una imagen, un PDF, un archivo que ya no existe. Cada petición deja una línea, y esas líneas juntas cuentan lo que realmente pasó, no lo que se supone que pasa.

La diferencia con cualquier herramienta de analítica web es de origen. La analítica necesita que el navegador ejecute un script; el registro se escribe antes, en el servidor, sin pedir permiso a nadie. Por eso ve lo que la otra no puede ver.

Y lo que no puede ver es justo lo que interesa en SEO técnico: el paso del rastreador. Googlebot no ejecuta el script de medición, así que en la analítica no existe. En el registro deja huella de cada visita, con la hora, la URL exacta y el código que recibió.

Conviene decir desde el principio qué NO es. No es una herramienta de marketing ni una fuente de ideas sobre contenido: el registro no sabe qué buscaba nadie, no conoce palabras clave y no distingue una visita satisfecha de una decepcionada. Responde a una sola familia de preguntas, la técnica, y ahí no tiene rival.

Tampoco es un invento del SEO. El registro existe desde que existen los servidores, y se escribe igual tanto si alguien lo lee como si no. Lo único que aporta esta disciplina es la costumbre de mirarlo con una pregunta concreta en la mano en lugar de abrirlo cuando algo ya se ha roto.

Apache y nginx escriben por defecto el mismo formato, llamado combined. Una línea trae cinco datos que valen la pena, y aprender a leerlos de un vistazo es la mitad del trabajo: quién pidió, cuándo, qué pidió, qué recibió y qué dice ser.

Ese último campo, el agente de usuario, es el que más confusión genera. Es una cadena de texto que el cliente elige libremente, así que cualquiera puede declararse Googlebot. Antes de contar esas visitas hay que comprobar la IP contra los rangos oficiales, o el informe medirá a quien copia la web, no a quien la indexa.

El registro también recoge las peticiones que no son páginas: hojas de estilo, imágenes, fuentes, y los archivos que solo se controlan con el X-Robots-Tag. Es la forma más directa de descubrir qué parte del presupuesto de rastreo se va en cosas que no son contenido.

Dos campos más aparecen en la línea y se pasan por alto con facilidad. El tamaño de la respuesta en bytes distingue una página completa de un error servido con plantilla ligera, y una caída repentina en ese número suele delatar una plantilla rota antes de que nadie la reporte.

El otro es el referente, la URL desde la que se llegó. En el tráfico de navegadores da pistas sobre enlaces entrantes; en el del rastreador suele venir vacío, y eso mismo informa: el buscador no llegó siguiendo un enlace de esa sesión, sino desde su propia lista de URLs conocidas. Cuando sí trae valor, indica qué página interna llevó hasta allí, y eso se lee junto al enlazado interno.

Hay preguntas que solo el registro contesta con hechos. La primera: ¿qué páginas rastrea Google y con qué frecuencia? Casi siempre aparece un desequilibrio incómodo, con secciones importantes visitadas una vez al mes y URLs sin valor visitadas a diario.

La segunda: ¿qué encuentra cuando llega? Aquí salen los errores 404 que nadie reportó, los errores 500 intermitentes que ocurren de madrugada y las cadenas de redirecciones que el rastreador recorre entera cada vez.

Y la tercera, la que más sorprende: ¿qué URLs pide que tú no sabías que existían? Combinaciones de parámetros GET, versiones con y sin barra final, rutas de una migración de hace dos años. Todas consumen rastreo, y ninguna aparece en un listado de páginas publicadas.

Hay una cuarta pregunta que rara vez se plantea y que el registro contesta mejor que nadie: ¿a qué hora está lento el servidor? Agrupando el tiempo de respuesta por franjas horarias se ve si el rastreo coincide con la copia de seguridad nocturna o con el proceso pesado de las tres de la madrugada. Cuando coincide, el TTFB que mide el buscador no es el que miden tus visitantes.

Y una quinta, útil después de cualquier cambio grande: ¿cuánto tarda Google en enterarse? Publicada una sección nueva, el registro muestra el día exacto en que empezó a pedirla y con qué frecuencia volvió. Es una medida directa de si el descubrimiento funciona, sin depender del retraso con que informa Search Console.

Lo primero es conseguir los archivos, y suele ser la parte más lenta. Están en el servidor, se rotan y comprimen cada pocos días, y si nadie los guarda desaparecen. Antes de analizar nada conviene asegurarse de que se conservan al menos un mes.

Después se filtra: quedarse con las peticiones de buscadores verificados y separar páginas de recursos. Con eso ya se pueden responder las preguntas de arriba agrupando por URL, por día y por código de respuesta. Una hoja de cálculo aguanta un sitio pequeño; a partir de cierto tamaño hace falta una herramienta hecha para ello.

Y conviene cruzarlo con lo que ya se tiene: el sitemap, el informe de cobertura de Search Console y el tráfico real. Una URL que Google rastrea a diario, no pasa a indexación y no recibe visitas es una pregunta concreta; el registro solo la hace visible.

Un detalle sobre el filtrado que ahorra conclusiones falsas: hay que decidir pronto qué se considera «una página». Si las peticiones de imágenes, hojas de estilo y fuentes se cuentan junto a las de contenido, cualquier proporción sale torcida, porque una sola página arrastra veinte peticiones de recursos.

Y una recomendación sobre cómo presentar el resultado. Una lista de URLs ordenada por número de peticiones impresiona y no dice nada; lo que se entiende es el reparto por secciones, la evolución semanal y la lista corta de URLs que reciben rastreo sin producir nada. En una auditoría de SEO técnico esas tres vistas caben en una página y sostienen las decisiones.

El más caro es tratar el registro como un dato anónimo. Una dirección IP identifica a una persona con bastante frecuencia, así que un archivo de logs es un fichero de datos personales en el sentido del RGPD: tiene plazo de conservación, base legal y obligación de acceso restringido. Exportarlo entero a una hoja compartida es un problema, no un atajo.

El segundo es contar como buscador lo que solo lo dice. Sin verificar la IP, el informe mezcla el rastreo real con el de quien copia el catálogo, y las conclusiones sobre frecuencia de visita salen infladas.

Y el tercero es mirar un solo día. El rastreo es irregular por naturaleza: un martes cualquiera no dice nada, mientras que cuatro semanas seguidas muestran un patrón. Sacar conclusiones de una muestra corta es el equivalente a decidir el clima por la ventana de la mañana.

Un cuarto error, más silencioso: confundir «Google no lo rastrea» con «Google no puede rastrearlo». Que una URL no aparezca en cuatro semanas de registro puede significar que está bloqueada en el robots.txt, que nadie enlaza hacia ella, o simplemente que al buscador no le ha parecido prioritaria. Son tres causas distintas con tres arreglos distintos, y el registro por sí solo no dice cuál es.

Y el último, el más común de todos: analizar sin haber decidido antes qué se quiere saber. Un archivo de varios millones de líneas da respuestas a cualquier pregunta que se le haga, incluidas las que no importan. Escribir la pregunta antes de abrir el archivo es lo que separa un informe útil de una colección de gráficos.