Los logs de servidor son uno de los recursos más infravalorados del SEO técnico. No porque sean difíciles de entender, sino porque requieren acceso al servidor —que el cliente muchas veces no facilita— y porque históricamente su lectura requería herramientas específicas y cierta experiencia técnica. Con IA, esa barrera ha bajado considerablemente: hoy se puede volcar un archivo de log en un modelo y obtener un análisis estructurado en minutos.
Un artículo reciente de Kaspar Szymanski en Search Engine Land, ex miembro del equipo de Search Quality de Google, repasa qué información revelan los logs que las herramientas habituales de SEO no muestran. Vale la pena detenerse en los puntos más relevantes.
Qué ven los logs que Search Console y los crawlers no ven
Search Console, Google Analytics y herramientas como Screaming Frog trabajan con muestras, datos agregados o simulaciones de rastreo. Los logs de servidor, en cambio, registran cada petición real que cualquier bot hace a tu infraestructura: URL solicitada, código de respuesta, tiempo de respuesta, user agent y timestamp exacto.
Eso significa que los logs muestran lo que realmente ocurrió, no una estimación de lo que ocurrió. En webs grandes, esa diferencia puede ser enorme: páginas que Search Console marca como indexadas pero que Googlebot no visita desde hace meses, secciones que absorben una proporción desproporcionada del crawl budget, redirects que se convirtieron en cadenas después de una migración y que nadie detectó.
Desde mi experiencia, los casos donde los logs han resultado más útiles son precisamente esos: migraciones donde algo no funcionó como esperaba, auditorías donde el comportamiento real de Googlebot no coincidía con lo que el cliente creía, y análisis de crawl budget en sitios con muchas URLs indexables.
La distinción que el artículo no hace: rastreo para entrenamiento vs. acceso en tiempo real
Szymanski menciona que los logs permiten identificar el comportamiento de crawlers de IA como GPTBot o Applebot de forma separada a Googlebot. Es correcto, pero hay una distinción importante que conviene aclarar porque cambia completamente la interpretación.
Los principales sistemas de IA utilizan user agents diferenciados según el propósito del acceso. OpenAI, por ejemplo, usa GPTBot cuando rastrea para entrenar sus modelos y ChatGPT-User cuando accede en tiempo real para responder una query de un usuario. Anthropic hace lo mismo: ClaudeBot para entrenamiento, Claude-User para acceso en tiempo real. Google diferencia entre Googlebot para indexación tradicional y GoogleOther para entrenamiento de modelos.
Esto significa que en tus logs puedes saber no solo si los sistemas de IA visitan tu web, sino por qué lo hacen. Ver GPTBot en tus logs indica que OpenAI está entrenando con tu contenido. Ver ChatGPT-User indica que alguien hizo una pregunta a ChatGPT y el sistema accedió a tu página para construir la respuesta. Son dos situaciones radicalmente distintas: la primera afecta a cómo los modelos te conocen a largo plazo, la segunda indica que ya te están teniendo en cuenta para responder preguntas de usuarios ahora mismo.
Para cualquier profesional que quiera entender su visibilidad real en sistemas de IA, esta es probablemente la información más valiosa que pueden extraer de un análisis de logs hoy.
El problema del crawl budget desperdiciado
Los buscadores no rastrean todas las páginas de un sitio con la misma frecuencia ni con la misma profundidad. Asignan recursos en función de señales de calidad, estructura de enlaces internos, velocidad de respuesta del servidor y relevancia percibida del contenido. Los logs revelan exactamente cómo se distribuye ese presupuesto de rastreo.
Un patrón frecuente en sitios de ecommerce: Googlebot dedica una proporción desproporcionada de visitas a URLs generadas por filtros de navegación facetada —combinaciones de color, talla, precio— mientras las páginas de producto estratégicas reciben visitas esporádicas. Otro patrón habitual: URLs de una migración antigua que siguen recibiendo tráfico de crawler años después porque los redirects no se limpiaron correctamente.
Identificar estos patrones permite tomar decisiones concretas: bloquear secciones que no aportan valor indexable, limpiar redirects acumulados, priorizar el enlazado interno hacia las páginas que realmente importan.
Páginas que devuelven 200 pero no dicen nada
Szymanski dedica una sección a lo que llama soft 404s a escala. Vale la pena una aclaración terminológica: Google usa el término soft 404 habitualmente para referirse a páginas que han sido redirigidas hacia destinos sin relación —una URL de producto que ya no existe y redirige a la home— y que el buscador interpreta como una 404 enmascarada. Lo que Szymanski describe es algo diferente, lo que Google denomina más precisamente thin content o páginas sin contenido: URLs que devuelven un código 200 OK pero sirven contenido vacío, mínimo o sin valor real.
Ambos problemas consumen crawl budget sin aportar nada. En ecommerce aparecen con frecuencia en páginas de producto sin stock que siguen activas, resultados de búsqueda interna vacíos, o plantillas de categoría que se generaron automáticamente sin contenido. Los logs permiten identificarlos a escala analizando el tamaño de las respuestas: un grupo de miles de URLs devolviendo respuestas de tamaño casi idéntico y muy pequeño suele indicar que todas sirven la misma plantilla vacía.
La solución no es técnicamente compleja —noindex, canonical, eliminar las URLs o añadir contenido real— pero primero hay que saber que el problema existe, y los logs son la forma más directa de detectarlo.
Una herramienta más accesible de lo que parece
El principal freno para el análisis de logs no es técnico sino operativo: conseguir el acceso al servidor, extraer los archivos y procesarlos. En hosting compartido o con clientes que no gestionan directamente su infraestructura, ese acceso no siempre está disponible.
Donde sí está disponible, el análisis es hoy más sencillo que nunca. Un archivo de log volcado en un modelo de IA con las preguntas correctas puede producir en minutos el tipo de análisis que antes requería herramientas especializadas y horas de trabajo. La barrera de entrada ha bajado, y con ella el argumento de que los logs son territorio exclusivo del SEO técnico más avanzado.
