Análisis de archivos de log para SEO: Vea lo que Search Console oculta

Si buscas «log file analysis seo» en la primera página encontrarás dos tipos: herramientas que analizan tus logs, e introducciones que definen qué es un archivo de log y terminan con «busca desperdiciar presupuesto de crawl». Ninguna dice lo único que justifica dedicar una tarde a esto: Search Console es el resumen de Google sobre Google. Gráficos agregados, una muestra limitada de URLs de ejemplo, inspección URL por URL — una tarjeta de calificaciones que Google se escribe a sí mismo. El access log de tu servidor es un documento completamente diferente: un registro de primera mano de cada solicitud que Googlebot realmente hizo — cada URL, cada marca de tiempo, cada código de estado, cada visita repetida. El log no resume. Declara.

Esto es un artículo de nicho por diseño — la búsqueda tiene alrededor de setenta registros al mes e incluye una IA Overview — y es la capa más profunda de la auditoría técnica de SEO: debajo del repo, debajo del crawl, hasta lo que el crawler verificablemente hizo. Se encuentra bajo nuestro pilar de SEO agentico, y termina como todo en este sitio — no con una hoja de cálculo de hallazgos, sino con cada hallazgo comprometido con una métrica de Search Console y re-leído tres semanas después de que el fix se lance.

Qué muestran los logs de servidor que Search Console oculta

El informe Crawl Stats de Search Console es genuinamente útil y genuinamente parcial. Muestra totales — solicitudes por código de respuesta, por tipo de archivo, por propósito de crawl — y una lista limitada de URLs de ejemplo. Es a nivel de host, retrasado y curado: ves que Googlebot hizo miles de solicitudes, y una muestra de qué fueron algunas de ellas. La herramienta de inspección de URL va en la otra dirección — exacta, pero URL por URL, bajo demanda, sin forma de hacer la pregunta a nivel de sitio. Entre los dos, la pregunta que realmente importa es imposible de responder: en cada URL que me importa, qué obtuvo Googlebot, con qué frecuencia, y qué ignoró?

El log lo responde exhaustivamente, porque el log no es un informe sobre crawling — es el crawling, escrito tal como sucedió. Qué URLs se obtuvieron ayer. Qué página no ha sido tocada en noventa días a pesar de estar en tu sitemap. Qué variante de parámetro absorbió mil fetches el mes pasado. Qué URL larga y muerta Googlebot aún revisita por hábito. Nada de eso está en ninguna pantalla de Search Console, y todo está en un archivo que tu infraestructura ya está escribiendo.

Search Console es el resumen de Google sobre Google. El access log es la declaración jurada — cada fetch, con marca de tiempo, bajo juramento. Auditas resúmenes; verificas contra declaraciones juradas.

Obtener los logs — y verificar Googlebot

El primer obstáculo práctico es que «el log del servidor» rara vez es un archivo único actualmente. En un servidor de origen clásico es el access log de nginx o Apache. En una pila moderna el registro honesto vive en el borde: el CDN o plataforma de hosting ve cada solicitud, incluyendo los hits en caché que nunca llegan a tu origen — si solo lees el log de origen en un sitio muy cacheado, subestimas Googlebot severamente. Dos reglas antes de cualquier análisis: extrae los logs de la capa más externa que ve tráfico, y activa retención antes de necesitarla — los proveedores edge comúnmente mantienen logs sin procesar durante horas o días por defecto, y la ventana de 90 días que querrás no puede reconstruirse después del hecho.

El segundo obstáculo es que la cadena del user-agent es una afirmación, no una credencial. Cualquier cosa puede llamarse Googlebot, y los scrapers lo hacen rutinariamente — así que un log sin filtrar infla cada número que te importa. Google documenta dos rutas de verificación: una búsqueda inversa de DNS en la IP solicitante, y listas JSON publicadas de los rangos de IP de sus crawlers que puedes comparar directamente. Filtra a los hits verificados primero. Es una unión contra una lista publicada, y es la diferencia entre analizar Googlebot y analizar quienquiera que sintió que podía usar su nombre esa semana.

El método: una unión de tres vías

Todo lo útil en análisis de log surge de unir tres conjuntos de URLs. Primero: todo lo que tu sitio realmente enruta — del repo o CMS, la verdad de base de lo que existe. Segundo: todo lo que tu sitemap declara — qué dices que importa. Tercero: todo lo que el Googlebot verificado obtuvo durante la ventana — 30 días mínimo, 90 si la retención lo permite. Tres conjuntos, y cada desajuste entre ellos es un hallazgo.

Obtenido pero no enrutado: desperdicio de crawl — variantes de parámetros, URLs muertas, restos de redirección, rutas de staging que se filtraron. Enrutado pero nunca obtenido: páginas que existen e invisibles — el conjunto huérfano que ningún dashboard de crawler detecta confiablemente, porque tu propio crawler del sitio sigue los mismos links que Googlebot y pierde las mismas páginas. Declarado pero rara vez obtenido: páginas que dices que importan que el comportamiento de Googlebot dice que no. Las uniones son mecánicas — un script, no un producto — y la salida es pequeña: un puñado de conjuntos de URL, cada uno ya formado como una tarea.

Qué buscar: los hallazgos que rinden

No toda anomalía en un log merece una tarea. Cinco patrones confiablemente se convierten en fixes que pueden verificarse en Search Console después — y cada uno debe dejar el análisis ya llevando la métrica que lo juzgará, elegida antes de que el fix se lance.

Desperdicio de crawl

El hallazgo clásico, y el que el log presenta con claridad brutal. La propia orientación sobre presupuesto de crawl de Google nombra los culpables — navegación facetada, ID de sesión, espacios de URL duplicados e infinitos — como patrones que drenan capacidad de crawl de las páginas que ganan. En un sitio que auditamos, la mayoría de los fetches verificados de Googlebot sobre la ventana fueron a variantes de listados parametrizados — órdenes de clasificación y combinaciones de filtros de las mismas páginas subyacentes — mientras las páginas comerciales recientemente publicadas esperaban días por una primera visita. Nada en Search Console lo encuadró de esa forma; el log lo hizo el titular.

Páginas huérfanas y nunca obtenidas

Search Console tiene un punto ciego estructural aquí: no puede reportar significativamente sobre una URL que Google apenas sabe que existe. Una página sin links internos apuntando a ella puede aparecer como «Descubierta — actualmente no indexada» si sabes mirar — pero el log declara el hecho claramente: enrutada, en vivo, cero fetches, noventa días. Ese conjunto — enrutado menos obtenido — es la salida de más alto nivel de todo el ejercicio, porque cada página en él es contenido que pagaste que ningún motor ha leído. El fix es casi siempre links y declaración; la verificación es impresiones moviéndose desde cero, que es tan limpio como la causalidad se pone.

Frecuencia de crawl como preferencia revelada

Con qué frecuencia Googlebot regresa a una URL no es un factor de ranking y no debe leerse como uno. Es algo más útil: comportamiento revelado. Google recrawl páginas a tasas formadas por con qué frecuencia cambian y cuánto el índice parece importarles — así que cuando tus páginas de template se re-obtienen diariamente mientras la página de la que tu negocio depende se deja intacta por un mes, el log te está diciendo cómo tu arquitectura de links interna y señales de frescura realmente aterrizaron, en oposición a cómo pretendías. Trata los deltas de frecuencia como evidencia diagnóstica, aliméntalos en fixes de arquitectura de links, y verifica con posición — nunca los cites como un resultado en sí mismo.

La salvedad de presupuesto de crawl que nadie encabeza

Aquí está la oración que las páginas de herramientas entierran: la mayoría de sitios no tienen un problema de presupuesto de crawl. La documentación de presupuesto de crawl de Google es explícita sobre su audiencia — sitios del orden de un millón más URLs únicas con contenido cambiando semanalmente, o decenas de miles de páginas cambiando diariamente. Si tu sitio es trescientas URLs, Googlebot puede obtenerlo todo antes de comer, y «optimización de presupuesto de crawl» es una solución buscando un problema.

Los bots que Search Console nunca te mostrará

Hay una categoría de hallazgo de log que ningún producto de Google puede superficiar ni en principio: cada crawler que no es Google. GPTBot, ClaudeBot, PerplexityBot y sus pares son user agents documentados, auto-identificadores — y aparecen en exactamente un lugar que controlas: el access log. Search Console reporta el comportamiento de Google; si tu estrategia incluye ser leído y citado por motores de respuesta AI, el log es la única verdad de tierra de si esos motores te pueden obtener en absoluto.

Esto importa más de lo que parece, porque el modo falla es silencioso. Los protecciones anti-bot predeterminados de CDN y reglas de WAF frecuentemente desafían o bloquean AI crawlers sin que nadie decida que deberían — el equipo de marketing optimiza para citas AI mientras la configuración de borde gira los crawlers alejados en la puerta. Diez minutos de filtrado de log responden qué ningún dashboard will: ¿llegan los bots AI, ¿obtienen 200s, y qué está realmente leyendo? Si esa pregunta es en vivo para ti, la guía hermana sobre ser citado por AI cubre qué hacer una vez hayas confirmado que pueden entrar.

Del hallazgo de log al fix verificado

El engagement de análisis de log estándar termina como termina la auditoría estándar: una hoja de cálculo de hallazgos, severidad-ranking, entregada. Luego los fixes se lanzan — reglas robots apretadas, huérfanos vinculados, cadenas aplanadas — y nadie jamás establece si cualquiera de eso cambió lo que Google hace. Lo cual es un lugar extraño para detenerse, porque los hallazgos de log son inusualmente verificables: cada uno de los cinco patrones anteriores empareja naturalmente con una métrica de Search Console que se moverá si el fix funcionó.

Así que ejecútalo como un bucle, no un deliverable. Cada hallazgo se convierte en una tarea llevando su contrato de prueba — impacto esperado, la métrica de verificación de la tabla, el objetivo que cuenta como éxito — comprometido antes de que el fix se lance. El fix aterriza con una marca de tiempo y un registro de exactamente qué cambió. Alrededor de tres semanas después, la métrica se re-lee y el veredicto se escribe: confirmado, regresado, o inconcluso. Hay una simetría satisfactoria en ello: el log te dijo qué hizo Googlebot antes del fix; Search Console te dice qué hizo después. Dos fuentes independientes, cerrando el bucle desde extremos opuestos — la mecánica son el sujeto de la guía de SEO de bucle cerrado, y esto es qué se ven aplicadas una capa debajo del crawl.

Un agente hace esto práctico en la cadencia que merece. Leer un log de 90 días, verificar IPs de crawler, ejecutar la unión de tres vías, presentar los hallazgos con sus métricas, y recordar — tres semanas después de cada uno de una docena de fixes — re-leer los números correctos es exactamente el tipo de trabajo que humanos hacen una vez, brillantemente, y nunca repiten. Un sistema lo hace semanalmente sin ser recordado, y acumula el registro de cuáles fixes a nivel de log realmente verifican en tu sitio.

Si quieres la mitad de descubrimiento ejecutada contra tus propios datos primero, el informe SEO gratis conecta tu Search Console y superficies donde las páginas están siendo mostradas pero nunca elegidas — los síntomas visibles que el log entonces explica. Y si preferirías que todo el bucle se ejecutara sin ti impulsándolo — logs leídos, hallazgos presentados, fixes enviados, veredictos escritos — reserva una llamada y caminaremos por qué eso se ve en tu stack.