Análisis de archivos de registro

TL;DR — Tu servidor web guarda un registro de cada solicitud que recibe, incluidas las visitas de bots de motores de búsqueda como Googlebot. Analizar archivos de registro significa leer ese historial para saber exactamente qué páginas obtuvieron los bots, con qué frecuencia y si encontraron errores. Es el único lugar que muestra lo que ocurrió realmente, aunque la mayoría de los sitios pequeños no lo necesitan.

Toca para ampliar

The four-week chart compares automated and human requests to HTML content. Bot share is higher in the captured worldwide Cloudflare traffic period.

Qué es un archivo de registro

Cada vez que alguien — una persona, Googlebot o algún bot aleatorio — solicita una página de tu sitio, tu servidor escribe una línea al respecto en un archivo. Ese archivo es tu registro de acceso. Cada línea registra aproximadamente lo mismo:

• quién preguntó (una dirección IP y un nombre de “agente de usuario” como Googlebot),
• qué pidió (la URL),
• cuándo (una marca de tiempo) y
• qué recibió (un código de estado HTTP — 200 para OK, 404 para no encontrado, y así sucesivamente).

Acumula semanas de esas líneas y tendrás un registro completo y honesto de cómo los motores de búsqueda rastrean tu sitio. No una estimación. Las solicitudes reales.

Por qué vale la pena leerlo

Otras herramientas de SEO o adivinan cómo te rastrean los bots (una herramienta de rastreo finge ser un motor de búsqueda y recorre tu sitio) o resumen (Google Search Console muestra una vista muestreada y redondeada). Tus registros muestran lo real, solicitud por solicitud. Eso te permite responder preguntas como:

• ¿Qué páginas visita realmente Googlebot — y cuáles ignora?
• ¿Está el bot perdiendo tiempo en URLs basura en lugar de tus páginas importantes?
• ¿Están los bots encontrando páginas rotas (404) o errores del servidor (5xx)?
• ¿Hay páginas que los bots nunca han alcanzado?

La única regla que no puedes omitir

Cualquiera puede hacerse pasar por Googlebot. El nombre de agente de usuario en una línea de registro es solo texto — un raspador puede poner Googlebot ahí para colarse más allá de tus defensas. Así que antes de confiar en una sola línea de “Googlebot”, tienes que verificar que realmente es Google (hay una verificación DNS simple para esto en las pestañas Avanzado y Scripts). Si omites la verificación, sacarás conclusiones de tráfico falso.

¿Realmente necesitas esto?

¿Honestamente? Probablemente no, si tienes un sitio pequeño. El análisis de archivos de registro da resultados para sitios grandes — decenas de miles de URLs, comercio electrónico con muchas páginas filtradas, sitios en proceso de migración o sitios donde Google dice que “descubrió” páginas pero nunca las indexó. Si tu sitio tiene unos cientos de páginas y todas se rastrean bien, tu tiempo está mejor invertido en otra parte. (La misma lógica que el presupuesto de rastreo — la mayoría de los sitios no necesitan preocuparse por ello.)

¿Quieres el flujo de trabajo real — verificar bots correctamente, encontrar desperdicio de rastreo, detectar páginas huérfanas? Cambia a la pestaña Avanzado.

TL;DR — Los registros son la verdad fundamental sin muestreo para el rastreo: cada solicitud, cada bot, cada código de estado. El primer paso innegociable es verificar Googlebot/Bingbot mediante DNS inverso + directo (o el JSON de rangos IP publicados por Google) — los agentes de usuario se suplantan constantemente, y haces todos los cálculos de rastreo solo con el conjunto verificado. Luego lee los registros para las URLs y secciones más/menos rastreadas, la frecuencia de rastreo a lo largo del tiempo, los códigos de estado priorizados por frecuencia, el desperdicio de rastreo (parámetros, facetas, búsqueda interna, paginación infinita), páginas huérfanas y no rastreadas (cruzadas con un rastreo) y la división móvil vs. escritorio de Googlebot. Bing no publica rangos IP oficiales, así que el DNS a *.search.msn.com es el método allí. Los registros complementan las Estadísticas de rastreo de GSC — no las reemplazan. Y en 2026, los bots de IA ahora son una gran parte de lo que aparece.

Por qué los registros son la verdad fundamental

Hay tres formas de “ver” cómo te rastrean los motores de búsqueda, y no son iguales:

• Una herramienta de rastreo (Screaming Frog SEO Spider, Ahrefs Site Audit) simula un rastreo. Te dice lo que un bot podría encontrar, no lo que Google realmente obtuvo.
• GSC Crawl Stats resume lo real, pero está muestreado, agregado y limitado (aproximadamente 1 000 filas, ~90 días, sin exportación por URL).
• Los registros del servidor registran lo real: cada solicitud, para cada bot, con la URL exacta, la marca de tiempo y el código de estado.

La guía de archivos de registro de Ahrefs que revisé lo dice claramente: los registros del servidor son “la fuente más confiable de información para entender las URLs que los motores de búsqueda han rastreado.” Esa es toda la razón por la que existe esta técnica. Cuando quiero saber lo que Googlebot realmente hizo — no lo que podría hacer, no un resumen redondeado — voy a los registros.

Una línea de registro típica lleva la dirección IP, el agente de usuario, la ruta de la URL, la marca de tiempo, el método de solicitud (GET/POST) y el código de estado HTTP. Todo lo que sigue es simplemente segmentar esos campos de manera inteligente.

Cuándo realmente lo necesitas (y cuándo no)

Sé honesto contigo mismo aquí. El análisis de archivos de registro es una herramienta para sitios grandes. Se justifica en sitios con decenas de miles de URLs, comercio electrónico y navegación facetada, sitios en plena migración y sitios atascados en Discovered – currently not indexed. Como escribí en mi guía de presupuesto de rastreo, “La mayoría de los sitios no necesitan preocuparse por el presupuesto de rastreo, pero hay algunos casos en los que puede que quieras echar un vistazo.” Daniel Waisberg de Google ha hecho un punto similar sobre Crawl Stats — según la cobertura de Search Engine Journal, el informe no es una gran preocupación para sitios con menos de ~1 000 páginas.

Si tu sitio de unos pocos cientos de páginas se está rastreando bien, omite esto y ve a arreglar algo con más apalancamiento.

Cómo obtener tus registros (la parte más difícil es el acceso)

Los registros viven donde la solicitud realmente terminó:

• Apache y Nginx → el formato de registro “combinado” de Apache (el más común).
• Microsoft IIS → formato W3C.
• AWS ELB/ALB → formato ELB.
• CDNs (Cloudflare, Fastly, Akamai) → sus propias exportaciones de registros. Esto importa: en un sitio con CDN, un registro solo de origen pierde los aciertos de caché en el borde, así que extrae los registros en la capa a la que el bot realmente llegó.

Apunta a 30 días como mínimo, 90 ideal, para capturar la variación de frecuencia de rastreo. Y planifica la fricción: obtener acceso a los registros del servidor a menudo es la parte realmente difícil (la barrera de DevOps). Incluso los Googlers, en un episodio de migración de Search Off the Record, señalaron lo difícil que pueden ser de obtener los archivos de registro en la práctica. Presupuesta tiempo para la solicitud.

Los registros no son solo tráfico de bots: capturan cada solicitud, incluidos los visitantes reales, y pueden llevar valores de cadena de consulta, identificadores de sesión u otros datos sensibles junto con la ruta de la URL. La guía de registro de OWASP es contundente al respecto: las credenciales de autenticación, los tokens de acceso y la información personal identificable generalmente no deberían terminar directamente en un registro; deberían eliminarse, enmascararse o cifrarse primero. Incorpóralo en tus controles de acceso y proceso de exportación antes de entregar un archivo de registro a alguien para su análisis, no después.

Paso 1 — Verifica que los bots sean reales (haz esto antes que cualquier otra cosa)

Este es el paso que la mayoría de las guías mencionan en una línea. No lo hagas. Muchos bots fingen ser Googlebot para pasar los firewalls (Ahrefs). El agente de usuario es texto no autenticado; trata cada línea de “Googlebot” como una afirmación que debe probarse.

Googlebot — dos métodos válidos:

1. DNS inverso + directo (la comprobación bidireccional). Los propios pasos de Google: ejecuta una búsqueda de DNS inverso en la IP de tus registros con el comando host; verifica que el dominio sea googlebot.com, google.com o googleusercontent.com; luego ejecuta una búsqueda de DNS directo en ese nombre de host y verifica que resuelva de vuelta a la IP original. El paso directo es lo que hace que esto sea confiable: un suplantador puede apuntar el DNS inverso a un nombre *.googlebot.com, pero solo el viaje de ida y vuelta a la misma IP lo demuestra. (Los comandos para macOS/Linux y Windows están en la pestaña Scripts.)
2. Compara con los rangos de IP publicados por Google. Google publica archivos JSON de las IP de sus rastreadores en formato CIDR: common-crawlers.json para Googlebot y similares, además de special-crawlers.json, los archivos de buscadores activados por el usuario y un goog.json de todo Google. Como señalé en mi guía de Googlebot, Google “provided a list of public IPs you can use to verify the requests are from Google… You can compare this to the data in your server logs.” (traducción) «proporcionó una lista de IP públicas que puedes usar para verificar que las solicitudes son de Google… Puedes comparar esto con los datos en tus registros de servidor».

Bingbot: solo DNS. Este es el contraste clave: Bing no publica oficialmente rangos de IP. Bing explica que, al igual que otros buscadores, no publica una lista de direcciones ni rangos desde los que rastrea Internet, porque pueden cambiar en cualquier momento. Así que para Bingbot haces DNS inverso + directo a un nombre de host que termine en *.search.msn.com (por ejemplo, msnbot-157-55-33-18.search.msn.com), o usas la herramienta Verify Bingbot. (Microsoft ha lanzado desde entonces un JSON de IP de bingbot, pero su guía oficial de verificación sigue centrándose en DNS precisamente porque las IP cambian.)

Luego descarta los falsos. Haz todos tus cálculos de rastreo solo con el conjunto verificado. El “Googlebot” no verificado casi siempre es un raspador o un bot suplantado y pertenece a una revisión de seguridad, no a tu análisis de desperdicio de rastreo.

Paso 2: qué buscar

Una vez que trabajas con visitas verificadas, esta es la lectura:

• URLs y secciones más y menos rastreadas. Clasifica las solicitudes por URL y por directorio. Aquí es donde realmente va tu presupuesto de rastreo, y suele ser sorprendente.
• Frecuencia de rastreo a lo largo del tiempo. Analiza las tendencias de rastreo por URL/sección para detectar caídas (una migración rompió algo) o picos (una nueva sección, o una trampa para arañas generando URLs infinitas).
• Códigos de estado que los bots encuentran, priorizados por frecuencia. Cuantifica 200 frente a 301/302 (y cadenas), 404 y 5xx. Un 404 visitado 5 000 veces por semana es un problema diferente a un 404 visitado una vez: corrige por frecuencia de rastreo, no solo por existencia.
• Desperdicio de rastreo. Navegación facetada, parámetros de URL, resultados de búsqueda interna y calendarios/paginación infinitos pueden consumir una gran parte del presupuesto de rastreo en los peores infractores. Los registros muestran exactamente qué patrones de basura están quemando tiempo los bots.
• Páginas huérfanas y no rastreadas. Esto necesita ambos conjuntos de datos. Cruza los registros con un rastreo del sitio: URLs en los registros pero no en el rastreo = huérfanas, redirecciones antiguas o páginas enlazadas externamente; URLs en el rastreo pero no en los registros = páginas que Google nunca ha obtenido.
• Googlebot móvil vs. de escritorio. Divide por agente de usuario. Después de la indexación móvil primero, debería ser mayoritariamente Googlebot Smartphone: una división con mucho escritorio merece un vistazo.
• Tiempo de respuesta y salud del rastreo. Un aumento en el tiempo de respuesta promedio se correlaciona con un rastreo reducido. Según el artículo de SEJ sobre la guía de Waisberg, un aumento constante del tiempo medio de respuesta quizá no altere de inmediato la frecuencia de rastreo, pero indica que el servidor podría no soportar toda la carga.

Lo que los registros NO te dicen

Mantén esto claro o leerás demasiado en los datos:

• Rastreo ≠ indexación. Una URL que Googlebot obtiene a diario puede permanecer sin indexar indefinidamente. Los registros demuestran la obtención, no el estado de indexación; combínalos con la Indexación de páginas / Inspección de URLs de GSC para conocer el lado de la indexación.
• Rastreo ≠ posicionamiento, y rastrear más no ayuda. Como he dicho repetidamente, la frecuencia de rastreo no va a afectar tu posicionamiento. No persigas el volumen de rastreo como si fuera una palanca de posicionamiento.
• noindex no reduce el rastreo. noindex controla la indexación, no el rastreo; para detener realmente el rastreo, usa robots.txt o un código de estado.
• Rastreo ≠ entrenamiento de modelos ni citación. Una visita verificada de GPTBot, ClaudeBot, o PerplexityBot demuestra que esa solicitud ocurrió — una obtención en esa capa. No demuestra que la página se usara para entrenar un modelo, se retuviera en algún lugar posterior, o se citara en una respuesta de chat. Esos son resultados separados y no observados; no estires una línea de registro verificada más allá de lo que dice.

La novedad de 2026: los bots de IA ahora están por todas partes en tus registros

El elenco de personajes en un archivo de registro moderno ha cambiado. En mi análisis de los datos de Cloudflare Radar (Conoce a los nuevos rastreadores web), los bots de motores de búsqueda aún rastrean más — pero los bots de IA están firmemente en segundo lugar y en camino de superarlos en un par de años. GPTBot, ClaudeBot, PerplexityBot y compañía ahora aparecen con frecuencia. Cuando segmentes tus visitas verificadas por agente de usuario, no te sorprendas al encontrar rastreadores de IA rivalizando con los motores de búsqueda en cuanto a la proporción de solicitudes. (El Analizador de Archivos de Registro de Screaming Frog ha añadido un tutorial dedicado a bots de IA precisamente para esto.)

Cómo encaja esto con el resto del rastreo

Los registros son la capa de diagnóstico bajo todo el grupo de rastreo. Son cómo realmente mides el gasto del presupuesto de rastreo que los motores describen de forma abstracta (Gary Illyes lo define como “the number of URLs Googlebot can and is willing or is instructed to crawl”; (traducción) «la cantidad de URL que Googlebot puede rastrear, desea rastrear o tiene instrucciones de rastrear»). También son cómo detectas trampas para arañas en plena acción — un espacio de URLs infinito de un calendario o faceta aparece como una avalancha de solicitudes casi idénticas — y cómo confirmas si tu trabajo de frecuencia de rastreo (lastmod preciso, enlaces internos a páginas importantes) realmente cambió el comportamiento de los bots. Y recuerda que complementan, no reemplazan, las Estadísticas de rastreo de GSC: las Estadísticas de rastreo son la rampa de entrada muestreada; los registros son el detalle no muestreado, multi-bot y por URL.

Resumen de IA

Una versión condensada de la versión avanzada:

• Registros = verdad fundamental. Las herramientas de rastreo simulan, GSC muestrea; los registros de acceso del servidor registran cada solicitud, cada bot, con URL, marca de tiempo y código de estado.
• Verifica antes de analizar. Los agentes de usuario se suplantan constantemente. Confirma Googlebot mediante DNS inverso + directo o el JSON de rangos de IP publicado por Google; confirma Bingbot mediante DNS inverso a *.search.msn.com (Bing no publica rangos de IP oficiales). Haz todos los cálculos de rastreo solo con el conjunto verificado.
• Qué leer: URLs y secciones más/menos rastreadas; frecuencia de rastreo a lo largo del tiempo; códigos de estado priorizados por frecuencia (un 404 visitado 5 000 veces/semana ≠ una vez); desperdicio de rastreo (parámetros, facetas, búsqueda interna, paginación infinita); páginas huérfanas y no rastreadas (cruza referencias con un rastreo); división móvil vs. escritorio de Googlebot; tiempo de respuesta creciente como advertencia de salud del rastreo.
• No lo sobreinterpretes: rastreo ≠ indexación ≠ posicionamiento, rastrear más no ayuda al posicionamiento, noindex no reduce el rastreo, y una visita verificada de un bot de IA demuestra una obtención — no que la página se usara para entrenar un modelo o se citara en una respuesta.
• Alcance: una herramienta para sitios grandes / comercio electrónico / migraciones. La mayoría de los sitios pequeños no la necesitan.
• 2026: los bots de IA (GPTBot, ClaudeBot, PerplexityBot) ahora son una parte importante y creciente del tráfico de registros.
• Complementa las Estadísticas de rastreo de GSC — usa ambas.

Documentación oficial

Documentación de fuentes primarias para verificar rastreadores y leer datos de rastreo.

Google

• Verificar solicitudes de rastreadores y buscadores de Google — los dos métodos oficiales: DNS inverso y directo manual, y la comparación con los rangos de IP publicados.
• Cómo verificar Googlebot (Blog de Search Central) — la publicación complementaria más antigua, aún citada.
• common-crawlers.json — IP de Googlebot y rastreadores comunes en formato CIDR (nota: “las direcciones IP en los archivos JSON se representan en formato CIDR”). Complementos: special-crawlers.json, user-triggered-fetchers.json y el goog.json de todo Google.
• Descripción general de los rastreadores y buscadores de Google — cada agente de usuario de Google que verás en los registros.
• Informe de estadísticas de rastreo (Ayuda) y el blog de lanzamiento — la vista oficial y muestreada que los registros complementan.

Bing / Microsoft

• Cómo verificar Bingbot (Ayuda para webmasters) — la página oficial de verificación.
• Cómo verificar que Bingbot es Bingbot (blog) — el método canónico de DNS inverso y directo, y la declaración de que Bing no publica rangos de IP.
• Herramienta Verificar Bingbot — pega una IP para comprobarla.

Citas de la fuente

Declaraciones registradas. Cuando esté disponible, cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Google — verificación de rastreadores

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command.” (traducción) «Realiza una búsqueda DNS inversa en la dirección IP de acceso de tus registros, usando el comando host». — Documentación de Google Search Central. Ir a la cita
• “Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (traducción) «Verifica que el nombre de dominio sea googlebot.com, google.com o googleusercontent.com». Ir a la cita
• “Run a forward DNS lookup on the domain name retrieved in step 1 using the host command on the retrieved domain name.” (traducción) «Realiza una búsqueda DNS directa en el nombre de dominio obtenido en el paso 1 usando el comando host en el nombre de dominio recuperado». Ir a la cita
• “Verify that it’s the same as the original accessing IP address from your logs.” (traducción) «Verifica que sea la misma dirección IP de acceso original de tus registros». Ir a la cita

Bing — verificación y rangos de IP no publicados

• “Perform a reverse DNS lookup using the IP address from the logs to verify that it resolves to a name that end with search.msn.com.” (traducción) «Realice una búsqueda DNS inversa utilizando la dirección IP de los registros para verificar que se resuelve a un nombre que termina en search.msn.com.» — Bing Webmaster Blog. Ir a la cita
• “…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet.” (traducción) «Como otros motores de búsqueda, Bing no publica una lista de direcciones IP o rangos desde los cuales rastreamos Internet.» La razón: “the IP addresses or ranges we use can change any time, so responding to requests differently based on a hardcoded list is not a recommended approach.” (traducción) «Las direcciones IP o rangos pueden cambiar en cualquier momento, por lo que no se recomienda responder de forma distinta según una lista codificada.» Ir a la cita

Patrick Stox — sobre para qué sirven los registros (de mi trabajo en Ahrefs)

• Los registros del servidor son “the most trustworthy source of information to understand the URLs that search engines have crawled.” (traducción) «la fuente de información más confiable para comprender las URLs que los motores de búsqueda han rastreado.» Ir a la cita
• “Many bots pretend to be Googlebot to get past firewalls.” (traducción) «Muchos bots fingen ser Googlebot para pasar los firewalls.» Ir a la cita
• “If you want to see hits from all bots and users, you’ll need access to your log files.” (traducción) «Si quieres ver los accesos de todos los bots y usuarios, necesitarás acceso a tus archivos de registro.» Ir a la cita
• “The rate of crawling isn’t going to impact your rankings.” (traducción) «La velocidad de rastreo no va a afectar tus clasificaciones.» Ir a la cita

Gary Illyes, Google — presupuesto de rastreo (lo que los registros te permiten medir)

• El presupuesto de rastreo es “the number of URLs Googlebot can and is willing or is instructed to crawl.” (traducción) «el número de URLs que Googlebot puede y está dispuesto o tiene instrucciones de rastrear.» Leer la cobertura

Daniel Waisberg, Google — tiempo de respuesta como señal de salud del rastreo (el marco de SEJ de su guía de Crawl Stats)

• “Watch out for a consistent increase in average response time. Google says it might not affect crawl rate immediately, but it’s a good indicator that your servers might not be handling all the load.” (traducción) «Cuidado con un aumento constante en el tiempo de respuesta promedio. Google dice que podría no afectar la tasa de rastreo de inmediato, pero es un buen indicador de que tus servidores podrían no estar manejando toda la carga.» Ir a la cita

Verifica que un bot sea realmente Googlebot (DNS inverso y directo)

El user agent en una línea de registro es solo texto — los scrapers suplantan Googlebot para pasar los firewalls. La única verificación confiable es el DNS bidireccional: haz una búsqueda inversa de la IP, confirma que el nombre de host sea un dominio de Google, luego haz una búsqueda directa de ese nombre de host y confirma que se resuelve de nuevo a la misma IP.

macOS / Linux (usa host)

# 1) Reverse DNS the IP from your logs — it must end in googlebot.com,
#    google.com, or googleusercontent.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows (usa nslookup)

:: 1) Reverse DNS the IP — confirm it ends in a Google domain
nslookup 66.249.66.1

:: 2) Forward DNS the returned hostname — confirm it matches the original IP
nslookup crawl-66-249-66-1.googlebot.com

Si la búsqueda inversa no aterriza en un dominio de Google, o la búsqueda directa no devuelve la IP original, no es Googlebot. (Para Bingbot, ejecuta los mismos dos pasos exactos pero espera un hostname que termine en search.msn.com.) También puedes omitir el DNS y comparar la IP con los rangos publicados de Google (common-crawlers.json, en formato CIDR).

Extraer y contar los hits de rastreadores de un log sin procesar

Comandos rápidos de una línea para un log de acceso Apache/Nginx en formato combinado. (Estos seleccionan según la cadena de user-agent — recuerda verificar las IPs antes de confiar en los conteos.)

# Pull only the lines claiming to be Googlebot
grep -i "googlebot" access.log > googlebot-hits.log

# Count Googlebot hits per URL, most-crawled first
# (combined format: $7 is the request path)
grep -i "googlebot" access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn | head -50

# Count Googlebot hits per status code (combined format: $9 is the status)
grep -i "googlebot" access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# List the URLs Googlebot hit that returned a 404, by frequency
grep -i "googlebot" access.log \
  | awk '$9 == 404 {print $7}' \
  | sort | uniq -c | sort -rn

# Get the unique IPs claiming Googlebot — the list you then verify by DNS
grep -i "googlebot" access.log | awk '{print $1}' | sort -u

Ajusta las posiciones de campo $7/$9 si tu formato de log difiere (IIS/W3C y ELB ordenan los campos de manera diferente).

Flujo de trabajo de análisis de archivos de log

• Obtén los registros — registros de acceso del servidor, o exportaciones de CDN/balanceador de carga. En un sitio con CDN, extrae también los registros de borde (los aciertos de caché no aparecen en el origen).
• Toma una ventana suficiente — mínimo 30 días, ideal 90.
• Verifica primero los bots — DNS inverso y directo, o los rangos de IP publicados por Google. Bingbot → DNS a *.search.msn.com.
• Descarta los falsos — haz todos los cálculos de rastreo sobre el conjunto verificado; envía los “Googlebot” suplantados a una revisión de seguridad.
• Clasifica las URLs y secciones más/menos rastreadas — mira a dónde va el presupuesto.
• Analiza la tendencia de la frecuencia de rastreo a lo largo del tiempo — detecta caídas (migraciones) y picos (secciones nuevas, trampas para arañas).
• Cuenta los códigos de estado — cadenas 200 / 301-302 / 404 / 5xx, y prioriza las correcciones por frecuencia de rastreo, no solo por su existencia.
• Busca desperdicio de rastreo — parámetros, navegación facetada, búsqueda interna, paginación/calendarios infinitos.
• Encuentra páginas huérfanas y no rastreadas — cruza los registros con un rastreo del sitio (en registros pero no en rastreo = huérfana; en rastreo pero no en registros = nunca obtenida).
• Comprueba la división entre Googlebot móvil y de escritorio — debería ser mayoritariamente Smartphone.
• Vigila el tiempo de respuesta promedio — una tendencia al alza puede limitar el rastreo.
• Segmenta los bots de IA — GPTBot, ClaudeBot, PerplexityBot, etc. ahora representan una parte real del tráfico.
• Confirma con GSC — combina los hallazgos de rastreo con Estadísticas de rastreo e Inspección de URLs (rastreo ≠ indexación).

Qué construir en tu hoja de análisis

Ya sea que uses el Analizador de Archivos de Log de Screaming Frog, BigQuery o la plantilla de archivos de log de Ahrefs, estás construyendo las mismas pocas vistas. Después de verificar los bots, analiza cada línea en columnas y haz una tabla dinámica.

Columnas para extraer de cada línea de log

Tablas dinámicas para construir

• Rastreos por URL (y por directorio), descendente — más y menos rastreados.
• Rastreos por código de estado, luego código de estado × URL (para que un 404 de alta frecuencia salte a la vista).
• Rastreos por día/semana, segmentados por sección — la tendencia de frecuencia.
• Rastreos por bot/user agent — la división móvil/escritorio, más la cuota de bots de IA.
• Una unión de logs vs. rastreo (BUSCARV/fusión contra una exportación de rastreo de Screaming Frog o Ahrefs) para sacar a la luz huérfanos y páginas nunca obtenidas.

La guía de Ahrefs incluye una plantilla descargable que configura esto; la guía de análisis de archivos de log la enlaza.

Cómo leer un archivo de registro: qué buscar

Una lente repetible para cualquier análisis de registros. Verifica primero; luego ejecuta estos pasos.

1. Verifica, luego analiza. Los datos solo son tan buenos como la identidad del bot detrás de ellos. DNS inverso + directo (o rangos de IP); analiza solo el conjunto verificado. Bots falsificados → seguridad, no SEO.

2. ¿A dónde va el presupuesto? (lo más rastreado vs. lo menos rastreado). Clasifica por URL y por sección. El objetivo es encontrar atención gastada en los lugares erroneos — y páginas importantes que reciben muy poca.

3. ¿Qué están golpeando los bots? (códigos de estado, por frecuencia). 200 es saludable; las cadenas 3xx, 404 y 5xx son fugas. Clasifica por cuántas veces el bot golpea cada uno, no por si el error simplemente existe.

4. ¿Qué se está desperdiciando? (desperdicio de rastreo). Parámetros, navegación facetada, búsqueda interna, paginación/calendarios infinitos — los sumideros clásicos de presupuesto. Los registros nombran los patrones exactos que causan el problema.

5. ¿Qué falta? (huérfanos y no rastreados). Cruza los registros con un rastreo. En registros pero no en rastreo = huérfano/redirección antigua/enlace externo. En rastreo pero no en registros = Google nunca lo obtuvo.

6. ¿Quién está rastreando? (segmentación de bots). Googlebot móvil vs. de escritorio (debería ser mayoría Smartphone), más la cuota de bots de IA que ahora rivaliza con los motores de búsqueda.

7. ¿Está saludable el servidor? (tiempo de respuesta). Un tiempo de respuesta promedio creciente es una advertencia temprana de que el rastreo puede ser limitado.

Herramientas para el análisis de archivos de registro

• Analizador de registros de Screaming Frog — la herramienta de escritorio más completa. Verifica automáticamente los bots de búsqueda y marca las IP falsificadas, y tiene filtros de User-Agent + Estado de verificación para un análisis granular de bots. Importa un rastreo de SEO Spider y usa el filtro “Not In URL Data” para encontrar huérfanos — “URLs which were discovered in your logs, but are not present in the crawl data imported.” (traducción) «URL descubiertas en los registros, pero ausentes de los datos de rastreo importados». También tiene ahora un tutorial dedicado para monitorear bots de IA. Herramienta
• BigQuery (y Splunk / ELK Stack / Logflare / logz.io) — para almacenamiento y consulta crudos a gran escala cuando el volumen de registros es demasiado grande para una herramienta de escritorio.
• Ahrefs — cruza los registros con un rastreo de Ahrefs Site Audit para encontrar huérfanos y confirmar lo que los bots alcanzaron. (Mi herramienta de casa.)
• Semrush Log File Analyzer, OnCrawl, Botify, JetOctopus — otras plataformas de rastreo+registros, las últimas tres orientadas a empresas.
• GSC Crawl Stats — la rampa de entrada oficial, gratuita y muestreada. Complementaria a los registros crudos, no un reemplazo: es agregada, limitada y no tiene exportación por URL.
• Herramienta de verificación de Bingbot — pega una IP para confirmar que realmente es Bingbot: bing.com/toolbox/verify-bingbot.

Errores a evitar

• Confiar en la cadena “Googlebot” sin verificarla. Por qué está mal: el agente de usuario es texto no autenticado: cualquiera puede poner Googlebot en un encabezado de solicitud para evadir defensas o contaminar tu análisis con tráfico falso. En su lugar: ejecuta DNS inverso + directo (o compara con los rangos de IP publicados por Google) antes de que una sola línea cuente para tu cálculo de rastreo.
• Tratar las estadísticas de rastreo de GSC como el panorama completo. Por qué está mal: están muestreadas, redondeadas, limitadas a aproximadamente 1 000 filas y ~90 días, sin exportación por URL: resumen, no registran. En su lugar: usa los registros como la fuente de verdad y las estadísticas de rastreo como una vía complementaria y más rápida.
• Extraer solo registros del origen en un sitio con CDN. Por qué está mal: un registro de origen omite cada solicitud que la CDN sirvió desde la caché perimetral, así que estás analizando una imagen incompleta de lo que los bots realmente recibieron. En su lugar: extrae registros en la capa que el bot realmente alcanzó: la exportación de CDN/perimetral, no solo el servidor de origen.
• Corregir errores 404 y 5xx por existencia, no por frecuencia. Por qué está mal: un 404 que se recibe una vez al mes y un 404 que se recibe 5 000 veces por semana no son el mismo problema, pero tratar cada línea de error como igualmente urgente desperdicia esfuerzo de corrección. En su lugar: clasifica los problemas de código de estado por la frecuencia con la que los bots realmente los encuentran.
• Perseguir el volumen de rastreo como si fuera una palanca de posicionamiento. Por qué está mal: más rastreo no mueve el posicionamiento: es una señal de diagnóstico, no una métrica de crecimiento. En su lugar: usa la frecuencia de rastreo para detectar problemas (caídas, trampas para arañas), no como un KPI que maximizar.
• Usar noindex para intentar detener el rastreo. Por qué está mal: noindex controla la indexación, no el rastreo: Google aún tiene que obtener la página para ver la etiqueta. En su lugar: bloquea el rastreo en sí con robots.txt o un código de estado si ese es el objetivo real.
• Llamar a una URL “huérfana” solo a partir de los registros. Por qué está mal: una URL que aparece en los registros pero no en un rastreo reciente podría ser una redirección antigua, un enlace externo o un huérfano genuino: los registros por sí solos no pueden decirte cuál. En su lugar: cruza los registros con un rastreo real del sitio antes de sacar conclusiones en cualquier dirección.

KPIs permanentes para el análisis de archivos de registro

Proporción de bots verificados

• Métrica: visitas verificadas de Googlebot/Bingbot ÷ todas las visitas que afirman ser Googlebot/Bingbot por agente de usuario.
• Qué te indica: cuánto de tu “tráfico de bots” son en realidad raspadores falsificados en lugar de motores de búsqueda reales.
• Cómo obtenerla: ejecuta cada IP que afirma ser bot a través de DNS inverso + directo (o el JSON de rangos de IP) y cuenta la tasa de aprobación.
• Referencia / rango realista: no hay un número universal: depende de cuán agresivamente se raspe tu sitio. Una proporción verificada baja o en descenso es la señal para actuar, no un umbral fijo.
• Cadencia: cada vez que extraigas una nueva ventana de registros.

Proporción de desperdicio de rastreo

• Métrica: % de solicitudes de bots verificados que llegan a parámetros, facetas, búsqueda interna o paginación/calendarios infinitos.
• Qué te indica: cuánto de tu presupuesto de rastreo se va a URLs basura en lugar de páginas que importan.
• Cómo obtenerla: segmenta las visitas verificadas por patrón de URL (cadenas de consulta, rutas conocidas de facetas/búsqueda).
• Referencia / rango realista: no hay una cifra universal: es genuinamente situacional, dependiendo de la estructura de URL y las facetas de tu sitio. Establece tu propia línea base en la primera extracción y luego sigue la tendencia.
• Cadencia: ventana de registros de 30 a 90 días; vuelve a verificar después de cualquier limpieza (reglas de robots.txt, manejo de parámetros, correcciones de paginación).

Mezcla de códigos de estado, ponderada por frecuencia

• Métrica: 200 / 3xx / 404 / 5xx como proporción de las solicitudes verificadas de bots.
• Qué te indica: Dónde los bots están gastando fetches en errores en lugar de contenido en vivo, y si eso está empeorando.
• Cómo obtenerla: Cuenta el campo de código de estado de las líneas de registro verificadas.
• Referencia / rango realista: No hay un objetivo universal: depende de la antigüedad del sitio y del historial de redirecciones. Observa la tendencia, no una sola instantánea; una proporción creciente de 404/5xx es la señal accionable.
• Cadencia: Cada 30–90 días, o inmediatamente después de una migración.

División de Googlebot móvil vs. escritorio

• Métrica: Proporción de visitas verificadas de Googlebot desde el agente de usuario Smartphone vs. Desktop.
• Qué te indica: Si Google realmente te está rastreando con prioridad móvil, como se espera tras la indexación mobile-first.
• Cómo obtenerla: Segmenta las visitas verificadas por la cadena de agente de usuario de Googlebot (Smartphone vs. Desktop).
• Referencia / rango realista: Debería ser mayoritariamente Smartphone para la mayoría de los sitios; una división con mucho escritorio merece investigación, no es un fallo grave por sí sola.
• Cadencia: En cada extracción de registros.

Recuento de páginas huérfanas / no rastreadas

• Métrica: URLs en los registros pero no en un rastreo reciente (huérfanas/enlaces antiguos), y URLs en un rastreo reciente pero no en los registros (nunca obtenidas).
• Qué te indica: Páginas a las que los bots no pueden llegar fácilmente, y páginas a las que enlazas y que Google nunca se ha molestado en obtener.
• Cómo obtenerla: Combina la lista de URLs con visitas verificadas con una exportación de rastreo del sitio (Screaming Frog, Ahrefs).
• Referencia / rango realista: Totalmente situacional: depende del tamaño del sitio y de cuán recientemente migraste o reestructuraste. Sigue el recuento a lo largo del tiempo en lugar de compararlo con un número externo.
• Cadencia: Trimestral para sitios grandes, o inmediatamente después de una migración.

Indicaciones listas para copiar para el análisis de registros

Estas son para interpretar datos de registros que ya has extraído y verificado, no para generar datos de registros (nunca dejes que una IA invente líneas de registro o estadísticas).

Resumir el desperdicio de rastreo a partir de una muestra de URLs

Here is a list of URL paths that verified Googlebot hits landed on, one per
line, from my server logs. Group them into patterns (query parameters,
faceted navigation, internal search, pagination/calendars, or "looks like a
real page"), and tell me which pattern has the most URLs. Don't invent URLs
that aren't in the list — only group what I've pasted.

[paste your URL list here]

Resultado esperado: unos pocos grupos identificados y contabilizados, además de una señal del patrón que parece desperdiciar más rastreo. Úsalo como punto de partida para comprobar las rutas reales, no como respuesta definitiva.

Priorizar un desglose de códigos de estado

I have this table of HTTP status codes and how many times verified Googlebot
hit each one over the last 30 days. Rank them by which I should fix first,
weighting frequency over severity — a 404 hit 5,000 times matters more than a
500 hit twice. Explain the reasoning in one line per row.

status_code, hit_count
[paste your table here]

Resultado esperado: las mismas filas ordenadas por prioridad de corrección, con una razón breve para cada una. Contrasta el razonamiento con el contexto de tu sitio antes de actuar.

Redactar una solicitud de acceso a registros para DevOps

Write a short, plain-English email to my DevOps/hosting team asking for
30-90 days of raw web server access logs (Apache/Nginx combined format, or
our CDN's edge logs if we're behind one) for [site name]. Explain in one
sentence why I need it (verifying real Googlebot/Bingbot crawl activity vs
GSC's sampled report) and ask what export format and delivery method works
for them.

Resultado esperado: un borrador breve que puedes completar con el nombre real del sitio. Revísalo antes de enviarlo; la herramienta no envía mensajes por ti.

Explicar un resultado de verificación de DNS

I ran a reverse DNS lookup on an IP from my server logs and then a forward
DNS lookup on the hostname it returned. Here's the raw output from the
`host` command. Tell me plainly whether this confirms the request came from
real Googlebot or Bingbot, and point to exactly which line proves or
disproves it.

[paste your host/nslookup output here]

Resultado esperado: un dictamen claro vinculado a la línea concreta de la salida. Tómalo como una segunda opinión, no como sustituto de conocer la regla: el nombre del host termina en un dominio de Google o Bing y la resolución directa devuelve la IP original.

Recursos que valen tu tiempo

Mi escritura relacionada

• Cómo analizar archivos de registro para SEO, con plantilla — la guía principal de Ahrefs que revisé; el marco y la plantilla en los que se apoya este artículo.
• Cuándo preocuparse por el presupuesto de rastreo — cuándo vale la pena (y cuándo no) el análisis de registros.
• Qué es Googlebot y cómo funciona — los rastreadores y los antecedentes de verificación de IP.
• Los nuevos rastreadores web: los bots de IA alcanzan a los buscadores — por qué tus registros se ven diferentes en 2026.
• Guía para principiantes de SEO técnico — dónde encajan el rastreo y los registros en el panorama general.

Mis charlas

• How Search Works (SlideShare) — mi explicación del rastreo: Googlebot como más de 1 000 sistemas con muchos rastreadores especializados (Desktop, Mobile, Image, News, Video, Ads) que comparten un único grupo de presupuesto de rastreo, y solicitudes que en su mayoría se originan en Mountain View — una comprobación práctica de registros junto con, nunca en lugar de, una verificación adecuada. (Descargo permanente: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100 % completa o precisa».)

De otros

• Screaming Frog Log File Analyser — guía de usuario y tutorial sobre bots de IA.
• Search Engine Land — Guía de análisis de archivos de registro (Kody Wirth) — recorrido práctico que cubre formatos, herramientas y qué patrones buscar.
• Search Engine Journal — Cómo usar el informe de estadísticas de rastreo de Google — orientación de Daniel Waisberg (Google) sobre cómo leer las estadísticas de rastreo, incluida la advertencia de tiempo de respuesta; el mejor complemento para el análisis de registros.
• Search Engine Journal — Indexación y presupuesto de rastreo (Illyes + Splitt) — definición oficial del presupuesto de rastreo y cómo la calidad impulsa la demanda de rastreo.
• Search Engine Roundtable — Direcciones IP de Bingbot publicadas — cubre el matiz de que Microsoft finalmente publicó un JSON de IP de bingbot aunque la orientación oficial aún se centra en DNS.
• Conductor — Análisis de archivos de registro para SEO — explicación accesible de qué revelan los registros y cómo actuar sobre ellos.
• r/TechSEO — la comunidad para depurar rastreo e indexación.

Vídeos

• Google Search Central (YouTube) — explicaciones de Martin Splitt sobre rastreo y renderizado, y la serie How Google Search Works; contexto útil sobre los bots cuyas visitas estás verificando en tus registros. Canal

Ponte a prueba

Cinco preguntas sobre cómo verificar bots y leer lo que tus registros realmente muestran.

Registro de cambios