La guía de rastreo e indexación menciona el análisis de logs de servidor como la única fuente que muestra el rastreo real, sin muestreo ni agregación previa. Esta guía se queda exactamente ahí: en cómo se hace ese análisis en la práctica, con qué formato de datos se trabaja, cómo se verifica que una petición viene realmente de Googlebot y no de alguien que falsifica su user-agent, y qué patrones concretos merece la pena buscar en un archivo que puede tener millones de líneas.
Formato de los logs: qué campos trae cada línea
El formato más habitual es el combined log format de Apache, que añade a los campos básicos el referer y el user-agent de cada petición:
# Formato combined de Apache (LogFormat "combined")
66.249.66.1 - - [15/Jan/2032:10:23:41 +0100] "GET /productos/silla-nordica HTTP/1.1" 200 15234 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"Cada campo tiene un significado fijo: la IP de origen, la identidad remota y el usuario autenticado (casi siempre vacíos, representados con un guion), la marca de tiempo, la línea de petición completa (método, ruta y versión de protocolo), el código de estado HTTP de la respuesta, el tamaño en bytes de la respuesta, el referer, y por último el user-agent. Nginx no impone un formato fijo (se declara con la directiva log_format en la configuración) pero por defecto suele replicar una estructura muy similar a la de Apache, y es habitual añadirle un campo adicional con el tiempo de respuesta del propio servidor ($request_time), útil para cruzar directamente el análisis de logs con el diagnóstico de TTFB explicado en la guía de velocidad de servidor.
Verificar que un bot es realmente Googlebot: DNS inversa y confirmación directa
Confiar únicamente en la cadena de user-agent es un error habitual: cualquier script puede declarar "Googlebot" en su cabecera User-Agent sin ser Google en absoluto, y es una técnica común entre scrapers agresivos que quieren evitar bloqueos pensados para bots no deseados. La verificación fiable requiere dos pasos encadenados, conocidos como forward-confirmed reverse DNS.
El primer paso es una resolución inversa: a partir de la IP que hizo la petición, se obtiene el hostname que la tiene asignada. El segundo paso, imprescindible, es una resolución directa de ese mismo hostname: si el hostname resultante termina en googlebot.com o google.com, hay que resolverlo de nuevo hacia adelante y comprobar que devuelve exactamente la misma IP original. Si no coincide, la petición no viene de Googlebot por mucho que su user-agent lo diga.
# 1. Resolución inversa: qué hostname corresponde a esta IP
host 66.249.66.1
# 66.249.66.1.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
# 2. Confirmación directa: ese hostname, ¿resuelve de vuelta a la misma IP?
host crawl-66-249-66-1.googlebot.com
# crawl-66-249-66-1.googlebot.com has address 66.249.66.1Para volúmenes grandes de tráfico, hacer esta doble resolución línea por línea es poco práctico; Google publica también rangos de IP documentados y descargables en formato JSON para cada uno de sus rastreadores, que sirven como primer filtro rápido antes de reservar la verificación DNS completa para los casos dudosos o de mayor volumen.
Enfoques prácticos de parsing: de la línea de comandos a herramientas dedicadas
Para exploraciones puntuales, comandos como grep y awk son suficientes y no requieren instalar nada adicional en el propio servidor:
# Cuántas peticiones de Googlebot hay por cada código de estado
grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
# Las 20 rutas más visitadas por Googlebot
grep "Googlebot" access.log | awk -F'"' '{print $2}' | awk '{print $2}' | sort | uniq -c | sort -rn | head -20Para volúmenes que superan lo manejable por línea de comandos, con varios meses de histórico o millones de líneas diarias, existen herramientas construidas específicamente para este análisis: Screaming Frog Log File Analyser cruza automáticamente las URLs vistas en los logs con un rastreo completo del sitio, señalando de forma directa las páginas huérfanas y el desperdicio de presupuesto de rastreo; y para infraestructuras con volumen sostenido, un stack de agregación centralizada (Elasticsearch, Logstash y Kibana, o alternativas más ligeras como GoAccess para paneles en tiempo real) permite consultas y filtros que no serían viables ejecutando comandos manuales cada vez.
Qué patrones concretos buscar
La frecuencia de rastreo por patrón de URL es el primer patrón a revisar: agrupar las peticiones por tipo de plantilla (fichas de producto frente a páginas de filtro, frente a artículos de blog) revela de inmediato dónde se concentra realmente el presupuesto de rastreo, algo que ninguna estimación agregada puede mostrar con la misma precisión.
La distribución de códigos de estado del rastreo de Googlebot es el segundo: una proporción alta de 404 o 410 indica que Google sigue visitando URLs muertas, casi siempre porque hay enlaces internos rotos que siguen apuntando ahí o porque el sitemap todavía las lista; una proporción alta de errores 5xx indica problemas de servidor que Google detecta directamente y que reducen automáticamente el crawl rate limit, como se explica en la guía de rastreo e indexación.
Las páginas huérfanas que Google rastrea sin que existan enlaces internos hacia ellas son el tercer patrón, y uno de los más reveladores: cruzar la lista de URLs vistas en los logs con un rastreo completo del sitio (en modo spider, con una herramienta como Screaming Frog) muestra URLs que Google visita por señales externas (enlaces externos antiguos, sitemaps heredados de una versión anterior del sitio) pero que la arquitectura interna actual ya no enlaza desde ninguna parte, una oportunidad clara para decidir si esas páginas deben recuperarse con enlazado interno real o eliminarse de raíz.
El desperdicio de presupuesto de rastreo es el cuarto: URLs con parámetros de sesión, tracking, u orden de listado que reciben un volumen de peticiones desproporcionado respecto a su valor real. Aquí el log no es una sospecha sino la evidencia directa, con cifras reales de cuántas peticiones se están yendo a esas combinaciones frente a las páginas que sí importan.
Y el quinto es el retraso entre publicación y primera visita: comparar la fecha de publicación de una URL nueva con su primera aparición en los logs de Googlebot da una métrica directa y verificable de cuánto tarda realmente el contenido nuevo en entrar en el flujo de rastreo, sin depender de estimaciones.
Cruzar logs con Search Console y con el sitemap
El informe de estadísticas de rastreo de Search Console ofrece un resumen agregado y una muestra, útil como primera señal de alarma, pero los logs son la única fuente con el cien por cien de las peticiones reales y con las rutas exactas, no agrupadas por categoría genérica como hace Search Console. La combinación más productiva en la práctica es usar Search Console para detectar una anomalía a nivel agregado (una caída repentina en el número de páginas rastreadas, por ejemplo) y recurrir a los logs para diagnosticar con precisión qué rutas concretas la están causando.
Preguntas frecuentes
¿Cuánto tiempo hay que conservar los logs para que el análisis sea útil?
Al menos 30 días para tener una muestra representativa del rastreo habitual; idealmente varios meses, para poder detectar patrones estacionales o comparar el comportamiento antes y después de una migración o un cambio estructural del sitio.
¿Necesito acceso root al servidor para analizar logs?
No siempre. Muchos hostings y paneles de control (cPanel, Plesk) exponen los logs de acceso crudos para descarga directa sin necesitar acceso root, aunque el formato exacto y la retención disponible pueden variar según la configuración del proveedor.
¿Sirve de algo analizar logs si el sitio es pequeño?
Aporta menos porque el crawl budget rara vez es un cuello de botella real en sitios de pocas páginas, como se explica en la guía de rastreo e indexación, pero sigue siendo útil para detectar bots que falsifican el user-agent de Googlebot o fallos puntuales de servidor que otras herramientas no muestran con el mismo detalle.
¿Cómo distingo a Googlebot de otros bots de Google, como AdsBot o Google-InspectionTool?
Cada uno tiene su propio string de user-agent y sus propios rangos de IP y hostnames de verificación, documentados por separado. Conviene tratarlos como fuentes independientes en el análisis en vez de agruparlos todos bajo la etiqueta genérica "Google", porque cada uno cumple una función de rastreo distinta.
¿Los logs muestran también las visitas de usuarios reales o solo de bots?
Muestran ambas por defecto, mezcladas en el mismo archivo. Hay que filtrar explícitamente por user-agent y, de forma complementaria, por los rangos de IP de bots conocidos, para separar con fiabilidad el tráfico de rastreo del tráfico humano antes de sacar cualquier conclusión.