Search Console te dice que 12.000 páginas están indexadas y 40.000 no. Screaming Frog te dice que tu web tiene 52.000 URLs y que 300 devuelven error. Las dos herramientas te cuentan cosas verdaderas y ninguna te dice lo que necesitas saber: qué pidió Googlebot ayer, cuántas veces, y qué le devolvió tu servidor.
Eso solo está en los logs. Cada petición que llega a tu servidor deja una línea con la IP, la hora, la URL, el código de estado y el user agent. Googlebot no ejecuta tu Analytics ni rellena informes, pero deja rastro ahí igual que todo el mundo. Es la única fuente que registra el comportamiento en lugar de inferirlo.
Esta guía es el proceso completo: cómo sacar los logs, cómo separar el Googlebot de verdad del que se disfraza, qué agregaciones responden a qué preguntas, con los comandos listos para copiar. Y un bloque sobre un límite de Googlebot que Google documentó en febrero de este año y que Search Console no te va a avisar nunca de que estás incumpliendo.
Está escrita para quien no se asusta con una terminal. Los comandos son de bash y funcionan sobre logs en formato combinado de Apache o Nginx, que es lo que sirve el 90 % de los hostings.
1. Qué responde un log que no responde Search Console
La diferencia se entiende con dos preguntas.
Search Console responde a “¿está indexada esta URL?”. Los logs responden a “¿pidió Googlebot esta URL, cuándo, y qué le devolví?”.
Necesitas las dos, porque cuando una página no está indexada hay dos causas posibles y se arreglan en sitios distintos: o Google no ha llegado, que es un problema de acceso, o ha llegado y ha decidido que no merece la pena, que es un problema de contenido. Los logs te dicen cuál de las dos es.
| Pregunta | Logs | Search Console | Crawler de escritorio |
|---|---|---|---|
| ¿Googlebot pidió esta URL? | Sí, con fecha y hora | Aproximado | No, simula |
| ¿Cuántas veces al mes? | Sí, exacto | No | No |
| ¿Qué código recibió? | Sí | Agregado | El que recibe el crawler, no Google |
| ¿Cuánto tardó tu servidor con él? | Sí, si lo registras | Media agregada | El tiempo del crawler |
| ¿Está indexada? | No | Sí | No |
| ¿Qué bots de IA te visitan? | Sí | No | No |
| ¿Cuánto tiempo de histórico? | El que guardes | 3 meses | El del rastreo |
Lo que hay que saber del informe de Estadísticas de rastreo
Search Console tiene un informe de Estadísticas de rastreo que se le parece, y conviene saber sus límites antes de apoyarse en él.
Desglosa por respuesta, por tipo de archivo, por finalidad (descubrimiento o actualización) y por tipo de Googlebot. Está bastante bien. Pero Google avisa de dos cosas: que está dirigido a usuarios avanzados y que si tu sitio tiene menos de mil páginas no hace falta que lo uses, y que hay un problema conocido por el que el informe puede no capturar todas las solicitudes.
O sea, que es una muestra agregada, no un registro. Para ver una URL concreta, para cruzar con tu sitemap o para separar bots, necesitas los logs.
2. Anatomía de una línea
Esto es una línea en formato combinado, que es el que vas a encontrarte:
66.249.66.1 - - [26/Aug/2026:14:23:11 +0200] "GET /zapatillas/running/ HTTP/1.1" 200 45231 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Cada campo, con el número que le toca en awk.
Los campos que vas a usar, numerados para awk:
| Campo | Contenido | Ejemplo |
|---|---|---|
$1 | IP de origen | 66.249.66.1 |
$4 | Fecha y hora | [26/Aug/2026:14:23:11 |
$6 | Método | "GET |
$7 | URL pedida | /zapatillas/running/ |
$9 | Código de estado | 200 |
$10 | Bytes servidos | 45231 |
$11 | Referrer | "-" |
$12 en adelante | User agent | "Mozilla/5.0 ... |
El campo 10, los bytes servidos, casi nadie lo mira. En el bloque 10 verás por qué merece la pena.
Sobre el tiempo de respuesta: el formato combinado no lo incluye. Hay que añadirlo al formato de log. En Nginx con $request_time, en Apache con %D. Si no lo tienes, ponlo hoy y dentro de un mes tendrás datos. Es de lo más útil que vas a sacar de aquí y no se puede recuperar hacia atrás.
3. Conseguir los logs y filtrar
Dónde están
En un hosting compartido, en /logs/ o /access-logs/ por FTP, o en la sección de estadísticas de cPanel o Plesk. En un VPS, normalmente en /var/log/nginx/access.log o /var/log/apache2/access.log.
Si estás detrás de Cloudflare u otro CDN, cuidado con dos cosas. La primera es que el log de origen solo ve lo que no sirve la caché, así que te falta parte del tráfico de bots: pide también los logs del borde. La segunda es que la IP que registres puede ser la del CDN y no la real, con lo que la verificación del bloque siguiente no funciona. Configura el registro de la cabecera correspondiente antes de empezar.
La rotación te está borrando el histórico
La mayoría de servidores rotan los logs y guardan entre 7 y 30 días. Si quieres ventanas de 90 días, tienes que ampliarlo o exportar a otro sitio, y eso hay que decidirlo antes de necesitarlo.
Trabaja con 30 días como mínimo y 90 como ideal. Menos de un mes no da patrones, solo ruido.
Filtrar
Con logs rotados y comprimidos:
zcat access.log*.gz | grep -i "googlebot" > googlebot.log
cat access.log | grep -i "googlebot" >> googlebot.log
Y ya tienes tu fichero de trabajo. Ahora, antes de sacar ni una conclusión, hay que verificarlo.
4. Verificar que Googlebot es Googlebot
El user agent es una cadena de texto que cualquiera puede escribir. Una parte de lo que dice “Googlebot” en tus logs no lo es: son scrapers que se disfrazan para saltarse bloqueos.
Si sacas conclusiones sobre crawl budget contando peticiones de scrapers, tus conclusiones no valen nada. Este paso no es opcional.
El método oficial: DNS inverso y directo
Coges la IP, haces una consulta inversa para obtener el nombre de host, y luego una consulta directa sobre ese nombre para comprobar que devuelve la misma IP.
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1
Coincide, así que es Googlebot.
Los nombres de host válidos según la documentación de Google sobre verificación de rastreadores:
| Dominio del host | A qué corresponde |
|---|---|
crawl-***.googlebot.com | Rastreadores comunes |
geo-crawl-***.geo.googlebot.com | Rastreadores geográficos |
rate-limited-proxy-***.google.com | Rastreadores de casos especiales |
***.gae.googleusercontent.com | Peticiones iniciadas por usuarios |
google-proxy-***.google.com | Peticiones iniciadas por usuarios |
Si el host no termina en googlebot.com o google.com, no es Google.
El método rápido: los rangos de IP oficiales
Google publica ficheros JSON con sus rangos, y para volumen es mucho más práctico que hacer miles de consultas DNS. Los ficheros están en developers.google.com/static/crawling/ipranges/:
| Fichero | Contenido |
|---|---|
common-crawlers.json | Googlebot y rastreadores comunes |
special-crawlers.json | AdsBot y rastreadores de casos especiales |
user-triggered-fetchers.json | Peticiones iniciadas por usuarios |
user-triggered-fetchers-google.json | Peticiones desde infraestructura de Google Cloud |
Un cruce rápido para ver cuánto de tu supuesto Googlebot es falso:
# Cuenta peticiones por IP en tu fichero filtrado
awk '{print $1}' googlebot.log | sort | uniq -c | sort -rn | head -30
Coge las IPs con más peticiones y verifícalas. Si una IP con 40.000 peticiones no resuelve a googlebot.com, acabas de encontrar un scraper que te está costando servidor.
En una auditoría normal es habitual que entre el 5 % y el 15 % de las líneas con “Googlebot” en el user agent no sean Google. En sitios con contenido apetecible para scraping, bastante más.
5. Los bots no son uno, son muchos
Segundo error clásico: meter todo en el mismo saco. Google tiene varios rastreadores con funciones distintas, y los bots de IA son otra familia entera con otro comportamiento.
Los rastreadores de Google
| Token de user agent | Qué hace |
|---|---|
Googlebot (Smartphone) | Rastrea contenido móvil para Búsqueda, Discover, Imágenes, Vídeo y Noticias. Es el que importa |
Googlebot (Desktop) | Contenido de escritorio. Mismo token en robots.txt |
Googlebot-Image | Google Imágenes |
Googlebot-Video | Producto de vídeo |
Googlebot-News | Google News |
GoogleOther | Rastreador genérico para equipos de producto, sin efecto en un producto concreto |
Google-Extended | Controla si tu contenido se usa para entrenar futuras generaciones de modelos Gemini |
Google-CloudVertexBot | Rastrea para construir agentes de Vertex AI a petición del propietario del sitio |
Google-InspectionTool | El que se usa cuando pides una inspección de URL en Search Console |
Ese último es importante y volveremos a él en el bloque 10.
Separar Smartphone de Desktop importa porque con indexación mobile-first el que manda es el primero. Si en tus logs domina el Desktop, tienes algo raro.
Los rastreadores de IA
Como estos ya se han contado en el artículo sobre renderizado y bots de IA, aquí solo lo necesario para separarlos:
| Token | Proveedor | Para qué |
|---|---|---|
GPTBot | OpenAI | Entrenamiento de modelos base |
OAI-SearchBot | OpenAI | Que aparezcas en las funciones de búsqueda de ChatGPT |
ChatGPT-User | OpenAI | Visita una página cuando un usuario lo pide |
ClaudeBot | Anthropic | Entrenamiento |
Claude-SearchBot | Anthropic | Búsqueda de Claude |
Claude-User | Anthropic | Petición de un usuario |
PerplexityBot | Perplexity | Índice de Perplexity |
Applebot | Apple | Siri y Apple Intelligence |
Por qué mezclarlos invalida el análisis
Porque tienen comportamientos radicalmente distintos y objetivos distintos.
Googlebot ejecuta JavaScript y pide tus archivos .js y .css para renderizar. GPTBot y ClaudeBot no los ejecutan. Si sumas todo, ves un pico de peticiones a recursos estáticos y no sabes si es Google renderizando (normal y deseable) o un bot de IA descargando bundles que no va a ejecutar (desperdicio puro).
Y hay una diferencia de eficiencia enorme. En el estudio de Vercel y MERJ de diciembre de 2024, ChatGPT gastaba el 34,82 % de sus peticiones en páginas 404 y Claude el 34,16 %, frente al 8,22 % de Googlebot. Si tienes un 30 % de 404 en tus logs y no has separado por bot, vas a salir a arreglar un problema de Google que no existe.
Separa siempre. Un fichero por familia:
grep -i "googlebot" access.log > bots-google.log
grep -iE "gptbot|oai-searchbot|chatgpt-user" access.log > bots-openai.log
grep -iE "claudebot|claude-searchbot|claude-user" access.log > bots-anthropic.log
grep -i "perplexitybot" access.log > bots-perplexity.log
6. Las seis agregaciones que importan
Sobre tu fichero de Googlebot ya verificado.
6.1. Qué URLs pide más
awk '{print $7}' googlebot.log | sort | uniq -c | sort -rn | head -50
Las 50 URLs que más rastreo se llevan. Mira si son las que quieres. Es habitual encontrar el buscador interno o una faceta de ordenación en el top 10.
6.2. Qué secciones se lleva el rastreo
Más útil que la anterior, porque agrupa por plantilla:
awk '{print $7}' googlebot.log | cut -d'/' -f2 | sort | uniq -c | sort -rn | head -20
Cambia el -f2 por -f2,3 para bajar un nivel más.
Aquí es donde se ve el reparto real: si el 60 % del rastreo se va a /buscar/ y el 4 % a /productos/, ya tienes el titular de tu auditoría.
6.3. Qué códigos devuelves
awk '{print $9}' googlebot.log | sort | uniq -c | sort -rn
La distribución sana en un sitio estable es más del 80 % de 200, poco 304, un porcentaje bajo de 301 y de 404, y cero 5xx. Un solo 503 recurrente es más grave que mil 404.
Para ver qué URLs concretas fallan:
awk '$9 ~ /^5/ {print $7}' googlebot.log | sort | uniq -c | sort -rn | head -20
awk '$9 == 404 {print $7}' googlebot.log | sort | uniq -c | sort -rn | head -30
Un 404 que Googlebot pide 300 veces al mes no es un 404 normal: es una URL enlazada desde algún sitio. Búscala.
6.4. Cómo evoluciona en el tiempo
awk '{print substr($4,2,11)}' googlebot.log | sort | uniq -c
Peticiones por día. Lo que buscas son escalones: una caída brusca coincidiendo con un despliegue, o una subida coincidiendo con una fuga de URLs.
6.5. Cuánto tarda tu servidor con él
Esto necesita que hayas añadido el tiempo de respuesta al formato de log. Con Nginx y $request_time como último campo:
awk '{sum+=$NF; n++} END {print "Media:", sum/n, "s"}' googlebot.log
Y las plantillas más lentas, que es lo que de verdad interesa:
awk '{split($7,p,"/"); t[p[2]]+=$NF; c[p[2]]++} END {for (s in t) printf "%.3f s %6d %s\n", t[s]/c[s], c[s], s}' googlebot.log | sort -rn | head -20
Te devuelve el tiempo medio por sección y el número de peticiones. Una plantilla con 20.000 peticiones y 1,8 segundos de media es un problema de rastreo, no solo de usuario.
6.6. Descubrimiento contra actualización
Cruza las URLs de tus logs con tu sitemap para ver cuántas peticiones van a URLs conocidas y cuántas a URLs nuevas. Si casi todo el rastreo va a repasar lo de siempre y las URLs nuevas apenas reciben visitas, tienes un problema de descubrimiento, que casi siempre es de enlazado interno.
7. Encontrar el desperdicio
Con las agregaciones anteriores, los patrones que aparecen una y otra vez.
Facetas y parámetros. Cuenta qué proporción del rastreo se va en URLs con interrogante:
awk '$7 ~ /\?/ {print}' googlebot.log | wc -l
wc -l googlebot.log
Si la primera cifra pasa del 30 % de la segunda, tienes un espacio de filtros descontrolado, y ahí el arreglo no está en los logs: está en cómo se gobiernan las facetas y los filtros.
Búsqueda interna. Las URLs de tu buscador no deberían recibir rastreo. Si lo reciben, están enlazadas desde algún sitio o alguien las metió en un sitemap.
Cadenas de redirección. Busca las 301 más frecuentes y comprueba a dónde van:
awk '$9 == 301 {print $7}' googlebot.log | sort | uniq -c | sort -rn | head -20
Una 301 que se pide 5.000 veces al mes significa que sigue enlazada en algún sitio. Actualiza el enlace de origen en lugar de dejar que Google pague el salto para siempre.
404 sistemáticos. Si un patrón de URL genera miles de 404, no es un enlace roto: es una plantilla generando URLs mal.
Recursos estáticos. Comprueba qué porcentaje del rastreo se va en .js, .css e imágenes. Que Googlebot pida recursos es normal, porque los necesita para renderizar. Que se lleven la mitad de tu rastreo no lo es, y suele apuntar a nombres de archivo que cambian en cada despliegue. Eso lo vemos en el bloque 11.
8. Páginas ignoradas y páginas huérfanas
El cruce más rentable de todo el proceso.
Saca la lista de URLs de tu sitemap y la lista de URLs que Googlebot ha pedido en 90 días, y compáralas en las dos direcciones.
# URLs que Googlebot ha pedido
awk '{print $7}' googlebot.log | sort -u > urls-rastreadas.txt
# URLs de tu sitemap (una por línea, extraídas previamente)
sort -u urls-sitemap.txt > sitemap-ordenado.txt
# En el sitemap pero SIN rastrear: problema de descubrimiento
comm -23 sitemap-ordenado.txt urls-rastreadas.txt > sin-rastrear.txt
# Rastreadas pero NO en el sitemap: posibles huérfanas o basura
comm -13 sitemap-ordenado.txt urls-rastreadas.txt > fuera-de-sitemap.txt
Las del primer fichero llevan 90 días sin recibir una sola visita del bot estando en tu sitemap. Casi siempre es enlazado interno insuficiente, que es justo lo que revisamos en una auditoría de arquitectura web e indexación: páginas a demasiados saltos de la home, o enlazadas solo desde sitios que Google apenas visita.
Las del segundo son de dos tipos. Unas son huérfanas de verdad: existen, tienen contenido, alguien las enlaza desde fuera y tu arquitectura las ignora, muchas veces porque el menú no es rastreable. Suelen ser una oportunidad barata, porque solo hay que enlazarlas. Otras son basura generada por plantillas o por parámetros de campaña, y ahí lo que toca es cortar el grifo.
9. Los logs y tu hosting
Aquí se conecta el análisis con decisiones de infraestructura, que es la parte que casi nadie cierra.
Google lo dice sin rodeos en su guía de presupuesto de rastreo: si el sitio responde de forma consistente y sus tiempos de respuesta (incluyendo latencia y tiempo hasta el primer byte) se mantienen estables o mejoran, el límite sube. Y al revés: si el sitio se ralentiza, o responde con errores de servidor 5xx o señales de limitación como el código 429, el límite baja y Google rastrea menos.
O sea, que tu tiempo de respuesta con el bot es directamente tu capacidad de rastreo.
Lo que hay que sacar de los logs para esta conversación:
El percentil 95, no la media. La media esconde los picos. Si el percentil 95 de una plantilla está en cuatro segundos, Googlebot se está encontrando con eso una de cada veinte veces.
Los 5xx concentrados en el tiempo. Agrupa los errores de servidor por hora y mira si coinciden con los picos de rastreo. Si tu servidor se cae justo cuando Googlebot aprieta, tienes un problema de capacidad que se manifiesta como problema de SEO.
awk '$9 ~ /^5/ {print substr($4,2,14)}' googlebot.log | sort | uniq -c | sort -rn | head -20
Qué plantillas son lentas solo con el bot. Pasa más de lo que parece: una página que va rápida para el usuario porque le sirve caché, y lenta para el bot porque su combinación de parámetros nunca está cacheada. Se ve comparando el tiempo medio por sección del bloque 6.5 con lo que mide tu monitorización de usuarios.
Esta es la parte que conectamos con el resto en una auditoría SEO técnica. Las decisiones que salen de aquí son de servidor, no de SEO: caché de página para las plantillas más rastreadas, revisar los límites de CPU y de trabajadores de PHP para que un pico de rastreo no encole peticiones, y servir estáticos desde CDN para que no compitan con el HTML.
10. El límite de 2 MB que Search Console no te va a contar
Este bloque merece una lectura atenta porque es reciente y casi nadie lo ha recogido todavía.
La misma página de 3 MB, vista por dos rastreadores de Google con límites distintos.
En febrero de 2026 Google reorganizó su documentación de rastreadores y aclaró una distinción que antes se contaba mal. Los números:
| Límite | A qué aplica |
|---|---|
| 2 MB | Lo que Googlebot rastrea de un archivo de tipo admitido: HTML, CSS, JavaScript |
| 64 MB | Lo que Googlebot rastrea de un PDF |
| 15 MB | El límite por defecto del resto de rastreadores y fetchers de Google |
La frase de la documentación es literal: Googlebot rastrea los primeros 2 MB de un archivo de tipo admitido, y los primeros 64 MB de un PDF. Y añade lo que pasa al llegar al corte: Googlebot detiene la descarga y solo envía a indexación la parte ya descargada.
Los límites se aplican a los datos sin comprimir, y cada recurso referenciado en el HTML (tus CSS y tus JS) se descarga por separado con su propio límite.
Qué se pierde en el corte
Todo lo que estuviera después del byte 2.000.000. Si tu HTML es de 3 MB, se corta a mitad de una palabra y desaparece lo que hubiera detrás: el JSON-LD si lo pones al final del body, los enlaces del footer, y cualquier contenido de la parte baja de la página.
La trampa: Search Console no te avisa
Esta es la parte buena. En pruebas publicadas en febrero de 2026, una página de 3 MB apareció indexada con normalidad en Search Console: sin aviso, sin error y sin ninguna indicación de que estuviera truncada.
Y hay un motivo técnico bonito. La herramienta de inspección de URL usa Google-InspectionTool, que es un rastreador distinto y funciona con el límite de 15 MB, no con el de 2 MB de Googlebot. Así que la inspección te enseña la página entera y la indexación se ha quedado con el primer tercio.
Es un caso perfecto de por qué hacen falta los logs: la herramienta oficial te enseña lo que ve una herramienta oficial, no lo que ve el rastreador que decide.
Cómo detectarlo en tus logs
Aquí es donde sirve el campo 10, los bytes servidos:
# Peticiones de Googlebot que rozan o superan los 2 MB
awk '$10 > 1900000 {print $10, $7}' googlebot.log | sort -rn | uniq | head -30
Y para ver el tamaño medio por sección:
awk '{split($7,p,"/"); b[p[2]]+=$10; c[p[2]]++} END {for (s in b) printf "%10.0f bytes %6d %s\n", b[s]/c[s], c[s], s}' googlebot.log | sort -rn | head -20
Si alguna plantilla se acerca al límite, ahí tienes trabajo.
A quién le pasa esto de verdad
Seamos honestos: al HTML medio, que ronda los 33 KB, esto no le afecta ni de lejos. Necesitas una página muy inflada para acercarte a 2 MB.
Los casos reales donde sí pasa: listados que pintan 500 productos en una sola página, páginas con JSON gigante embebido (el típico __NEXT_DATA__ de una aplicación con mucho estado), tablas de datos enormes sin paginar y plantillas que meten en el HTML el catálogo entero para un filtro en cliente.
Si tienes alguno de esos, comprueba el tamaño. Y en cualquier caso, la recomendación que sirve siempre: el contenido importante y el marcado estructurado, arriba; los recursos, en archivos externos.
11. La caché del renderizador y los nombres de archivo
Un patrón que aparece en los logs como un pico raro de peticiones a estáticos.
Google avisa de que su servicio de renderizado cachea de forma agresiva y puede ignorar las cabeceras de caché. Lo que quiere decir que tu Cache-Control no controla lo que hace el renderizador, y que puede estar trabajando con una versión antigua de tu JavaScript o de tu CSS.
La solución que recomienda Google es el content fingerprinting: meter una huella del contenido en el nombre del archivo, como main.2bb85551.js. Si el contenido cambia, el nombre cambia, y el renderizador se ve obligado a pedir el archivo nuevo.
El error contrario también se ve en los logs, y es más frecuente: un build que genera un hash nuevo en cada despliegue aunque el contenido no haya cambiado. Cada despliegue invalida todos los estáticos y Googlebot vuelve a descargarlos enteros. Si despliegas a diario, estás gastando una parte notable de tu rastreo en volver a bajar el mismo JavaScript con otro nombre.
Se detecta así:
awk '$7 ~ /\.(js|css)$/ {print $7}' googlebot.log | sort | uniq -c | sort -rn | head -30
Si ves veinte variantes del mismo main.HASH.js, ahí está.
12. Herramientas según el tamaño del sitio
| Tamaño | Enfoque | Por qué |
|---|---|---|
| Menos de 10.000 URLs | grep, awk y una hoja de cálculo | Los ficheros son manejables y los comandos de este artículo cubren todo |
| 10.000 a 500.000 URLs | Screaming Frog Log File Analyser o similar | Verifica bots, cruza con el rastreo y da los informes hechos |
| Más de 500.000 URLs | JetOctopus, Botify, Seolyzer o una pila propia | Volumen que no cabe en escritorio, y conviene monitorización continua |
Un aviso que ahorra tardes perdidas: no abras logs grandes con Excel. Un fichero de 10 GB satura la memoria y no vas a poder trabajar. Para eso están grep y awk, que procesan en flujo y no cargan el archivo entero.
El flujo práctico para la mayoría de casos es el intermedio: los comandos de este artículo para sacar CSV agregados, y esos CSV en una hoja para pivotar y montar el informe.
13. De auditoría puntual a política de rastreo
La mayoría de contenidos sobre esto tratan el análisis de logs como algo que se hace una vez. Es donde menos rendimiento se le saca.
El valor real aparece cuando lo conviertes en una serie temporal, porque entonces puedes responder a preguntas que un análisis suelto no responde: ¿cómo cambió el rastreo después de la migración? ¿Las categorías nuevas están recibiendo visitas o se quedaron fuera? ¿El bloqueo de facetas que pusimos en marzo liberó rastreo hacia los productos, o se fue a otro sitio?
Una rutina que funciona:
| Frecuencia | Qué se mira |
|---|---|
| Semanal | Códigos 5xx, caídas bruscas del volumen de rastreo, IPs falsas nuevas |
| Mensual | Reparto por sección, top 50 de URLs, tiempo de respuesta por plantilla, cruce con sitemap |
| Trimestral | Análisis completo, evolución respecto al trimestre anterior, revisión de la política |
| Tras cada despliegue grande | Comparación de la semana anterior y la posterior |
Y un cuadro de mando con cuatro cifras que cualquiera del equipo pueda leer: peticiones de Googlebot al día, porcentaje de respuestas 200, porcentaje de rastreo que va a plantillas de negocio, y tiempo de respuesta en el percentil 95.
Con esas cuatro, un cambio raro se ve la misma semana en lugar de en la auditoría de dentro de seis meses.
Un extra opcional
Si te interesa el ángulo de sostenibilidad, con los bytes servidos a bots y una librería como CO2.js, de la Green Web Foundation, puedes estimar la huella de carbono asociada a esa transferencia. Es una estimación, no una medición, y no cambia ninguna decisión técnica. Pero para una empresa con objetivos de sostenibilidad, poner una cifra al tráfico de bots que no aporta nada es un argumento adicional para limpiar el espacio de rastreo.
14. Checklist
Preparación
- Logs disponibles con al menos 30 días, idealmente 90
- Rotación configurada para no perder el histórico
- Tiempo de respuesta añadido al formato de log
- Si hay CDN, logs del borde además de los del origen
- IP real registrada, no la del proxy
Verificación
- Peticiones de Googlebot verificadas por DNS o por rangos oficiales
- Porcentaje de user agents falsos calculado
- Bots separados por familia: Google, OpenAI, Anthropic, Perplexity, resto
- Googlebot Smartphone separado de Desktop
Análisis
- Reparto de rastreo por sección
- Distribución de códigos de estado, con cero 5xx como objetivo
- Top 50 de URLs más rastreadas, revisado una a una
- Porcentaje de rastreo que se va en URLs con parámetros
- 404 recurrentes identificados y su origen localizado
- 301 más pedidas, con los enlaces de origen actualizados
- Tiempo de respuesta medio y percentil 95 por plantilla
Cruces
- URLs del sitemap sin rastreo en 90 días
- URLs rastreadas que no están en el sitemap
- Peticiones que se acercan al límite de 2 MB
- Estáticos con hash cambiando en cada despliegue
Continuidad
- Revisión semanal de 5xx y volumen
- Cuadro de mando con las cuatro cifras clave
- Comparación antes y después de cada despliegue grande
15. Preguntas frecuentes
¿Para qué sirven los logs si ya tengo Search Console?
Search Console responde a si una URL está indexada. Los logs responden a si Googlebot la pidió, cuándo y qué le devolviste. Cuando una página no se indexa, necesitas saber si el bot no llegó o si llegó y decidió que no. Además, el informe de Estadísticas de rastreo es una muestra agregada: Google avisa de que puede no capturar todas las solicitudes y de que si tu sitio tiene menos de mil páginas no hace falta usarlo.
¿Cuántos días de logs necesito?
Treinta como mínimo y noventa como ideal. Por debajo de un mes los patrones no son representativos, porque el rastreo tiene ciclos. Ojo con la rotación del servidor, que suele borrar a los siete o quince días.
¿Cómo sé si el Googlebot de mis logs es el de verdad?
Con una consulta DNS inversa sobre la IP y otra directa sobre el nombre obtenido, comprobando que coinciden y que el host termina en googlebot.com o google.com. Para volumen es más práctico cruzar con los ficheros JSON de rangos de IP que publica Google.
¿Es normal que Googlebot pida muchos 404?
Alguno sí. Más del 10 % de forma sostenida, no: significa que hay URLs rotas enlazadas desde algún sitio. Y ojo con no mezclar bots: en el estudio de Vercel, más de un tercio de las peticiones de ChatGPT y Claude terminaban en 404, frente al 8,22 % de Googlebot. Si no separas, el diagnóstico sale mal.
¿De verdad Googlebot solo lee 2 MB de mi HTML?
Sí. Google lo documentó al reorganizar su documentación en febrero de 2026: Googlebot rastrea los primeros 2 MB de un archivo de tipo admitido y los primeros 64 MB de un PDF, y al llegar al límite detiene la descarga y solo envía a indexación la parte descargada. Los 15 MB que se citaban antes son el límite por defecto del resto de rastreadores de Google.
¿Search Console me avisa si mi página supera los 2 MB?
No. En pruebas de febrero de 2026, una página de 3 MB apareció indexada con normalidad, sin aviso ninguno. La herramienta de inspección de URL usa Google-InspectionTool, que trabaja con el límite de 15 MB, así que te enseña la página entera aunque la indexación se haya quedado con la primera parte.
¿Los tiempos de respuesta afectan al rastreo?
Sí, y Google lo dice explícitamente. Si los tiempos de respuesta se mantienen o mejoran, el límite de capacidad de rastreo sube. Si el sitio se ralentiza o devuelve errores 5xx o códigos 429, el límite baja y Google rastrea menos.
¿Puedo analizar logs con Excel?
Para sitios pequeños sí, con los datos ya agregados. Para el fichero en bruto no: un log de varios gigas satura la memoria. Usa grep y awk para agregar y lleva el resultado a la hoja de cálculo.
¿Los logs sirven para algo con los buscadores de IA?
Bastante. Son la única forma de ver cuántas veces te visitan GPTBot, ClaudeBot o PerplexityBot, qué rutas recorren y qué códigos les devuelves. Y sirven para detectar si tu CDN les está devolviendo un 403 sin que tú lo sepas, que es algo que no aparece en ninguna otra herramienta.
16. Qué hacer con todo esto
Empieza pequeño. Saca treinta días de logs, filtra por Googlebot, verifica una docena de IPs y lanza las tres primeras agregaciones del bloque 6: por sección, por código y por URL. Con eso, en una hora, ya sabes dónde se está yendo el rastreo y si tienes errores de servidor.
Si no tienes el tiempo de respuesta en el formato de log, añádelo hoy. Es el dato que más rendimiento da y el único que no se puede recuperar hacia atrás.
Y si tienes plantillas que pintan cientos de elementos en una sola página, comprueba el tamaño del HTML antes que ninguna otra cosa. Ese límite de 2 MB no lo vas a ver en ningún informe.
Cuándo te compensa pedir ayuda
Puedes hacerlo tú si tienes acceso al servidor y te manejas con la terminal. Los comandos de este artículo cubren el 90 % de lo que necesita un sitio mediano.
Busca ayuda cuando el volumen no quepa en herramientas de escritorio, cuando haya CDN y varias capas de caché de por medio y no sepas qué log refleja la realidad, cuando el análisis tenga que traducirse en decisiones de infraestructura, o cuando lleves meses viendo caer la indexación sin que Search Console te dé una explicación.
El siguiente paso
En Consultoría SEO Sevilla trabajamos el análisis de logs junto con lo que hay alrededor: la arquitectura que genera las URLs, el rendimiento del servidor que condiciona el rastreo y la política que evita que el problema vuelva en seis meses.
Si quieres saber qué está haciendo Googlebot de verdad en tu servidor, mira en qué consiste la auditoría SEO técnica o escríbenos y lo comprobamos.
Y para seguir: facetas y filtros: por qué el canonical no es la solución y renderizado y SEO: por qué ChatGPT no ve tu web en React.
