ClasesSEO
ES EN
Optimización de motores de búsqueda SEO

Análisis de logs del servidor para SEO: cómo ver qué rastrea Google de verdad

9 min de lectura Read in English
Análisis de logs del servidor para SEO: cómo ver qué rastrea Google de verdad
Tabla de contenidos

Search Console te dice cuántas páginas rastreó Google, pero no cada petición: agrega los datos, los muestrea y solo cubre tu dominio. Los logs del servidor guardan la hora, la URL y el código de estado exactos. El análisis de logs SEO es la diferencia entre suponer y saber.

Qué son los logs del servidor y por qué son la fuente de verdad del rastreo

Un access log es una lista de líneas: una por cada petición HTTP que recibe tu servidor. En el formato combined, cada línea guarda la IP de origen, la fecha y hora, el método, la ruta solicitada, el código de estado, el tamaño de la respuesta y el user-agent declarado. Es el registro crudo de lo que ocurrió, sin interpretación ni muestreo. De ahí su ventaja sobre cualquier panel: las herramientas agregan y estiman, el log conserva el evento individual con su hora exacta. Si necesitas saber si Google volvió a rastrear una página tras un cambio, la respuesta está en el log.

Dónde están los logs y cómo se rotan

En Apache viven en access.log; en Nginx, en el archivo del mismo nombre dentro del directorio de logs. El detalle que rompe los análisis es la rotación: los logs se parten y se comprimen en archivos .gz, así que una ventana de dos semanas puede estar repartida en varios ficheros. Únelos y ordénalos por fecha antes de concluir nada.

Logs frente a Search Console: muestra contra realidad

Las Estadísticas de rastreo tienen tres límites que conviene tener claros: solo existen para propiedades raíz, cuentan cada salto de redirección como una petición separada (301, 301 y 200 son tres filas de una sola visita lógica) y sus datos están muestreados. Google añade que un sitio con menos de mil páginas no debería necesitar ese informe. Traducido: los logs son para diagnosticar un problema concreto, no para mirar por mirar.

Cómo verificar que una petición es de Google (y no un bot impostor)

Google lo advierte en su guía de verificación de rastreadores: la cadena de user-agent se puede falsificar. Cualquiera puede escribir Googlebot en su cliente HTTP y aparecer en tus logs como si fuera el buscador. Si decides en base a esa etiqueta, trabajas con datos contaminados por scrapers y herramientas de terceros.

Método manual: reverse DNS más forward DNS

La verificación oficial tiene dos pasos. Primero se consulta el DNS inverso de la IP y se comprueba que el nombre termine en googlebot.com, google.com o googleusercontent.com. Después se consulta el DNS directo de ese nombre y se confirma que devuelve la misma IP del principio. Si los dos pasos no cierran, la petición no es de Google. Los ejemplos publicados por el buscador: la IP 66.249.66.1 resuelve a crawl-66-249-66-1.googlebot.com, la 35.247.243.240 a geo-crawl-35-247-243-240.geo.googlebot.com y la 66.249.90.77 a rate-limited-proxy-66-249-90-77.google.com.

Método automático: los JSON de rangos IP

Para volúmenes grandes, Google publica cinco archivos con los rangos en formato CIDR: rastreadores comunes, especiales, fetchers disparados por el usuario, fetchers de Google y agentes. La clave es que se actualizan casi a diario, así que una lista copiada de un blog queda obsoleta en semanas. En una revisión reciente el archivo de rastreadores comunes tenía 317 prefijos y el de agentes había pasado de 4 a 20 desde su creación en marzo de 2026. La máscara DNS de los rastreadores comunes sigue el patrón crawl-algo.googlebot.com o geo-crawl-algo.geo.googlebot.com. Si comparas miles de IPs contra el DNS, guarda en caché el resultado por IP.

Los crawlers de Google que vas a ver en tus logs (y qué significa cada uno)

No todo lo que lleva la firma de Google es rastreo de búsqueda, y confundir las categorías lleva a conclusiones equivocadas sobre tu indexación. La lista oficial agrupa a los visitantes en tres familias que conviene separar desde el primer filtro.

Rastreo de búsqueda: el que afecta a tu SEO

Googlebot, en sus versiones para smartphone y escritorio, alimenta la Búsqueda, Discover, Imágenes, Vídeo y Noticias. Sus variantes Googlebot-Image y Googlebot-Video se ocupan de esos formatos, y Storebot-Google rastrea para Shopping. Un caso que sorprende: Googlebot-News no tiene user-agent propio y rastrea con las cadenas habituales de Googlebot, así que en el log no distinguirás una visita de noticias. Estas son las peticiones que sí influyen en lo que ven tus usuarios.

Herramientas internas: no son rastreo de búsqueda

Google-InspectionTool es el agente de la Inspección de URLs y de la prueba de resultados enriquecidos. GoogleOther y sus variantes son rastreos genéricos de equipos de producto para investigación interna. Verlos en tus logs no significa que Google esté decidiendo sobre tu indexación: significa que alguien dentro de Google consulta tu página. Tratarlos como Googlebot distorsiona cualquier informe de frecuencia de rastreo.

Fetchers y agentes de IA

Aquí está la novedad del año. Google-Agent, documentado desde marzo de 2026, corresponde a agentes que navegan la web y ejecutan acciones a petición de una persona. La familia incluye además Google-GeminiNotebook (antes Google-NotebookLM), Feedfetcher, Google-CWS, GoogleMessages y Google-CloudVertexBot.

El detalle que más confunde: los fetchers disparados por el usuario ignoran robots.txt. No es un error de configuración: la petición la origina una persona, no un rastreador que decide indexarte. Bloquearlos cuando el objetivo era frenar crawlers de entrenamiento es apuntar al objetivo equivocado.

Análisis de logs SEO paso a paso: del archivo crudo a decisiones

Paso 1: preparar los datos

Une los archivos rotados del periodo y normaliza el formato a algo consultable (CSV o parquet). Y separa los bots verificados de los que solo se declaran como tales: cruza las IPs contra el JSON de rangos o contra tu caché de DNS. Ese filtro convierte una lista de líneas en una muestra fiable.

Paso 2: las métricas que importan

Con los datos limpios: peticiones por día y por crawler; distribución de códigos (200, 301, 302, 404, 5xx); tiempo de respuesta por código; URLs más rastreadas; frecuencia de rastreo de las páginas que te importan; y primera y última visita a páginas nuevas o actualizadas, que responde cuánto tarda Google en volver tras un cambio.

Paso 3: cruzar con Search Console

Los logs y Search Console responden preguntas distintas. Las Estadísticas de rastreo aportan tendencia y disponibilidad; Indexación dice qué quedó fuera y por qué; Rendimiento muestra qué páginas rastreadas reciben clics. El log explica el porqué de una variación; la herramienta pone el cuánto.

Paso 4: cinco patrones que delatan problemas

  1. Rastreo masivo de URLs con parámetros o de facetas sin contenido único: el presupuesto de rastreo se gasta en variantes que nunca van a posicionar.
  2. Picos de 5xx o tiempos de espera en horas de más tráfico: Google reduce la velocidad de rastreo y tus actualizaciones tardan más en reflejarse.
  3. Errores 404 en URLs con enlaces internos: son los que Search Console deja de reportar porque el crawler se cansa de visitarlos.
  4. Cadenas de redirección visibles como 302, 302 y 200: queman peticiones y diluyen parte de la señal.
  5. Páginas clave rastreadas muy poco o nunca mientras el crawler pasea por páginas irrelevantes: el origen suele estar en el enlazado interno o en una directiva del robots.txt.

Errores comunes al leer logs que producen conclusiones falsas

  • Dar por buena la etiqueta del user-agent sin verificar DNS ni IP.
  • Meter en la misma bolsa GoogleOther, Google-InspectionTool y Googlebot. Solo el último es rastreo de búsqueda.
  • Bloquear fetchers de IA cuando el objetivo era frenar rastreadores de entrenamiento.
  • Sacar conclusiones de un solo día: una actualización del algoritmo, un pico de tráfico o un despliegue explican variaciones puntuales.
  • Olvidar que las direcciones IP son datos personales: anonimiza, limita la retención y no publiques un log crudo.

Cuándo automatizar (y cuándo te basta Search Console)

Si tu sitio tiene menos de mil páginas, empieza por las Estadísticas de rastreo y la Inspección de URLs. Automatiza cuando haya problemas de indexación recurrentes, muchísimas URLs o necesidad de alertas, por ejemplo un aviso si cae el rastreo de una sección completa. Los enfoques van de menos a más: un script que convierta los logs en CSV o parquet, un volcado a un almacén analítico para armar paneles, y suites de análisis de logs cuando el volumen lo justifique.

Checklist para tu primer análisis

  1. Descarga la ventana de logs que quieres estudiar.
  2. Une y normaliza los archivos del periodo.
  3. Verifica las IPs contra el DNS o los JSON de rangos.
  4. Separa las peticiones por crawler.
  5. Calcula códigos de estado y URLs más rastreadas.
  6. Cruza los hallazgos con Search Console.
  7. Define una acción concreta por cada problema.

Para contexto previo, revisa qué es el SEO técnico y cómo se reparte el presupuesto de rastreo. Si el log te muestra 404 o redirecciones, tienes guías para los errores 404 y soft 404 y para la redirección 301, y conviene contrastar conclusiones con la guía de Search Console. Antes de dar por bueno un bloqueo de rastreo, revisa tu robots.txt: los logs te dirán si esa regla hace lo que creías.

Usamos cookies para mejorar tu experiencia y analizar el tráfico del sitio. Al continuar navegando aceptas su uso.

Privacidad