Allá por 2021 heredé un cliente -- una tienda de comercio electrónico en Birmingham con alrededor de 52,000 URLs indexadas -- que no podía entender por qué aproximadamente 18,000 de sus páginas de productos no habían sido rastreadas en más de tres meses. Su equipo de desarrollo había estado adivinando. Agregando sitemaps XML. Haciendo ping a Google Search Console. Nada funcionó. Entonces extraje sus registros de servidor sin procesar y en alrededor de cuarenta minutos la respuesta era completamente obvia: Googlebot estaba quemando su asignación diaria de rastreo en URLs de filtros paginados, parámetros de sesión, y una faceta de búsqueda interna rota que generaba algo como 4,000 URLs únicas pero inútiles por semana. Total desperdicio. Completa sinrazón.
Conclusión clave: Los registros del servidor muestran exactamente qué páginas lee Googlebot en un sitio de 50.000 páginas; el análisis de registros es la única verdad absoluta para las decisiones sobre presupuesto de rastreo.Server logs show exactly which pages Googlebot actually reads on a 50,000-page site; log analysis is the only ground truth for crawl-budget decisions.
Eso es para lo que realmente sirve el análisis de archivos de registro -- no para métricas de vanidad, no para presentaciones de sala de juntas, sino para descubrir exactamente qué está haciendo un rastreador en tu sitio en cualquier martes dado y eliminar la grasa despiadadamente.
Por Qué el Presupuesto de Rastreo Realmente Importa a Escala
Aquí está lo que la mayoría de las personas entienden mal. El presupuesto de rastreo no es una preocupación para un sitio de folleto de 200 páginas. Googlebot lo barrería en minutos. Pero una vez que pasas, digamos, 20,000 URLs -- y definitivamente cuando estás en 50,000 o más -- el rastreador de Google toma decisiones explícitas sobre qué priorizar. La propia documentación de Google llama a esto "crawl budget" y lo divide en dos componentes: crawl rate limit (qué tan rápido rastreará Googlebot sin sobrecargar tu servidor) y crawl demand (cuánto realmente quiere rastrear Google según las señales de popularidad y frescura).Google's own documentation calls this "crawl budget" and breaks it down into two components: crawl rate limit (how fast Googlebot crawls without hammering your server) and crawl demand (how much Google actually wants to crawl based on popularity and freshness signals).
Ambos pueden ser manipulados. Pero no puedes manipular lo que no puedes medir. Y no puedes medirlo adecuadamente sin los registros.
Las herramientas de análisis como Google Search Console te ofrecen un informe de estadísticas de rastreo. Está bien como punto de partida. Pero está agregado, retrasado, y no te dice qué URLs específicas están consumiendo el presupuesto. Los registros del servidor sí. Muestran cada solicitud que Googlebot hizo, a qué URL, a qué hora, y qué código de estado HTTP recibió a cambio. Ese es el material bruto.which specific URLs are eating the budget. Server logs do. They show you every single request Googlebot made, to which URL, at what time, and what HTTP status code it received back. That's the raw material.
Obtener los Registros
Suena obvio pero aquí es donde la mayoría de la gente se atasca. Dependiendo de tu configuración de hosting, los registros viven en lugares diferentes.
En un host WordPress gestionado como WP Engine o Kinsta, puedes extraer registros de acceso sin procesar desde el panel o vía SFTP -- busca en el directorio /logs/. En un VPS ejecutando Nginx, tu registro de acceso típicamente está en /var/log/nginx/access.log. Apache lo coloca en /var/log/apache2/access.log. Si estás en un CDN como Cloudflare, necesitarás Cloudflare Logpush (nivel enterprise) o solo verás solicitudes en el edge del CDN, no en el origen -- distinción importante.WordPress host like WP Engine or Kinsta, you can pull raw access logs from the dashboard or via SFTP -- look in the/logs/directory. On a VPS running Nginx, your access log is typically at/var/log/nginx/access.log. Apache puts it at/var/log/apache2/access.log. If you're on a CDN like Cloudflare, you'll need Cloudflare Logpush (enterprise tier) or you'll only see CDN-edge requests, not origin -- important distinction.
Para ese cliente de Birmingham, estaban en un servidor administrado de Kinsta. Extraje 30 días de registros, que sumaban aproximadamente 4,2GB de archivos comprimidos .gz. Ese es un tamaño normal para un sitio ocupado de 50.000 páginas..gz files. That's a normal size for a busy 50K-page site.
Parsear Registros Brutos Sin Perder la Cordura
Tienes dos opciones reales aquí:
- Screaming Frog Log File Analyser -- Esto es lo que uso el 90% del tiempo. Importas los archivos de registro directamente, filtras por el user agent de Googlebot, y te da un desglose ordenable de URLs rastreadas, frecuencia de rastreo, códigos de estado y tiempos de respuesta. Honestamente, para la mayoría del trabajo de agencia es la herramienta correcta. El analizador de registros de Screaming Frog maneja archivos de hasta varios GB sin colapsar, lo que importa. -- This is what I use 90% of the time. You import the log files directly, filter by Googlebot user agent, and it gives you a sortable breakdown of crawled URLs, crawl frequency, status codes, and response times. Honestly, for most agency work it's the right tool.Screaming Frog's log analyser handles files up to several GB without falling over, which matters.
- ELK Stack (Elasticsearch, Logstash, Kibana) -- Más configuración, significativamente más poder. Si tienes necesidades de monitoreo continuo para un cliente grande o un contrato empresarial, esto vale la pena invertir. Seahawk tiene un par de clientes donde canalizamos registros directamente a un panel de Kibana. Tiempo real, hermoso, y puedes establecer alertas cuando la frecuencia de rastreo de Googlebot cae repentinamente. -- More setup, significantly more power. If you've got ongoing monitoring needs for a large client or an enterprise contract, this is worth the investment. Seahawk has a couple of clients where we pipe logs directly into a Kibana dashboard. Real-time, beautiful, and you can set alerts when Googlebot crawl frequency drops suddenly.
Para una auditoría puntual, Screaming Frog Log File Analyser está bien. Para cualquier cosa continua, construye el ELK stack o al menos considera GoAccess -- es código abierto, se ejecuta en la terminal, y procesa archivos de registro grandes más rápido que casi cualquier otra cosa que haya probado.GoAccess -- it's open source, runs in the terminal, and processes large log files faster than almost anything else I've tested.
Qué buscar realmente
Una vez que tienes los datos cargados, la mayoría de la gente se queda mirándolos sin saber qué preguntas hacer. Esto es lo que yo realmente busco en una auditoría de logs:
Distribución de frecuencia de rastreo
Ordena tus URLs por frecuencia de rastreo -- cuántas veces Googlebot golpeó cada URL en la ventana de 30 días. Casi siempre encontrarás una distribución bimodal. Un grupo de URLs importantes siendo rastreadas frecuentemente (bueno) y una cola larga de URLs basura que también están siendo rastreadas frecuentemente (muy malo). Esa cola de basura es tu problema.
En ese sitio de Birmingham, las 500 URLs más rastreadas incluían 340 combinaciones de filtros/facetas. Ninguna estaba indexada. Ninguna tenía volumen de búsqueda. Googlebot visitaba ?colour=red&size=M&sort=price_asc más a menudo que visitaba las páginas de categoría reales. Increíble.?colour=red&size=M&sort=price_asc more often than it was visiting the actual category pages. Wild.
Desglose de códigos de estado
Filtra todo lo que no sea un 200. Específicamente:
- 404s siendo rastreados repetidamente -- Estos son una hemorragia de presupuesto de rastreo. Arréglalo con redirecciones 301 o parcha los enlaces internos que apunten a ellos. -- These are a crawl budget haemorrhage. Fix them with 301 redirects or patch the internal links that point to them.
- Cadenas 301 -- Una redirección que va A → B → C son dos saltos desperdiciados. Googlebot las sigue pero cuesta presupuesto y el PageRank se filtra en cada salto. -- A redirect that goes A → B → C is two wasted hops. Googlebot follows them but it costs budget and PageRank leaks at each jump.
- Errores 500 -- Si Googlebot está golpeando páginas que devuelven 500 y luego las reintenta, estás desperdiciando presupuesto Y dañando tu puntuación de rastreabilidad con Google con el tiempo. -- If Googlebot is hitting pages that return 500s and then retrying them, you're wasting budget AND damaging your crawlability score with Google over time.
- 304 No modificado -- En realidad está bien. Significa que Google está verificando la frescura y tus encabezados de caché están funcionando correctamente. -- Actually fine. Means Google is checking freshness and your caching headers are working correctly.
Picos en el Tiempo de Respuesta
Google ha dicho públicamente que los tiempos de respuesta lenta del servidor hacen que Googlebot rastree menos agresivamente. Si tus registros muestran tiempos de respuesta promedio por encima de 500ms para URLs rastreadas -- particularmente páginas de categoría o producto -- esa es una señal para arreglar tu caché del lado del servidor antes que nada. that slow server response times cause Googlebot to crawl less aggressively. If your logs show average response times above 500ms for crawled URLs -- particularly category or product pages -- that's a signal to fix your server-side caching before anything else.
Identificando los Asesinos del Presupuesto
Te voy a dar una lista de las cosas que veo consumiendo presupuesto de rastreo en sitios grandes, en orden aproximado de qué tan frecuente las encuentro:
- Navegación facetada sin noindex o disallow -- Filtros, selectores de color, selectores de tamaño, órdenes de clasificación. Estos multiplican tu cantidad de URLs geométricamente. Una categoría de producto con 10 opciones de filtro y 5 órdenes de clasificación genera 50+ variantes de URL duplicadas. En un sitio de 50K páginas, eso son potencialmente cientos de miles de URLs. -- Filters, colour pickers, size selectors, sort orders. These multiply your URL count geometrically. A product category with 10 filter options and 5 sort orders generates 50+ duplicate URL variants. Across a 50K-page site, that's potentially hundreds of thousands of URLs.
- Archivos paginados rastreados infinitamente -- /page/2, /page/3.../page/847. Si el contenido en la página 200 de tu archivo de blog tiene cero valor de búsqueda orgánica, necesitas noindexarlo o desautorizar la ruta de paginación en robots.txt. --
/page/2,/page/3.../page/847. If the content on page 200 of your blog archive has zero organic search value, you need to either noindex it or disallow the pagination path in robots.txt. - IDs de sesión en URLs -- Plataformas CMS antiguas (y algunas configuraciones heredadas de WooCommerce) añaden tokens de sesión como ?sessionid=abc123def456 a las URLs. Cada sesión genera una URL única. Googlebot rastrea todas. Este es un filtro de presupuesto catastrófico en sitios antiguos. -- Old CMS platforms (and some legacy WooCommerce setups) append session tokens like
?sessionid=abc123def456to URLs. Every session generates a unique URL. Googlebot crawls all of them. This is a catastrophic budget leak on older sites. - Contenido duplicado a través de parámetros de URL -- ?utm_source=email en enlaces internos, parámetros de rastreo filtrándose en URLs rastreables, ?ref=homepage añadido por plugins de afiliados. Arréglalo en la herramienta de parámetros de URL de Google Search Console y canonicaliza a nivel HTML. --
?utm_source=emailin internal links, tracking parameters leaking into crawlable URLs,?ref=homepageappended by affiliate plugins. Fix in Google Search Console's URL parameter tool and canonicalise at the HTML level. - Páginas huérfanas sin enlaces internos pero aún en sitemap -- Googlebot las encuentra a través del sitemap, las rastrea, no encuentra señal interna, las deprioritiza con el tiempo. Pero aún consumen presupuesto en rastreos de descubrimiento. -- Googlebot finds them via sitemap, crawls them, finds no internal signal, deprioritises them over time. But they still eat budget on discovery crawls.
- Páginas con error suave 404 que devuelven estado 200 -- Páginas de búsqueda sin resultados, páginas de categoría vacías, páginas de perfil de usuario para cuentas eliminadas. Google pierde tiempo rastreando estas y a veces las indexa. -- Search pages with no results, empty category pages, user profile pages for deleted accounts. Google wastes time crawling these and sometimes indexes them.
Arreglando Lo Que Encuentras
Honestamente, el análisis es la parte más fácil. La implementación es donde los proyectos se vuelven políticos.
Este es mi flujo de trabajo real cuando termino una auditoría de logs y necesito presentar recomendaciones:
- Robots.txt disallow para patrones de URL que nunca deberían ser rastreados -- parámetros de sesión, combinaciones de filtros, URLs de resultados de búsqueda interna. Utilizo reglas wildcard como Disallow: /*?sessionid=style. Prueba cada regla en la herramienta de prueba robots.txt de Google Search Console antes de implementar. for URL patterns that should never be crawled -- session parameters, filter combinations, internal search result URLs. I use
Disallow: /*?sessionid=style wildcard rules. Test every rule in Google Search Console's robots.txt tester before deploying. - Noindex + nofollow en páginas paginadas más allá de la página 2 o 3, dependiendo de la frescura del contenido. No desactives la paginación por completo o romperás la capacidad de Googlebot para descubrir contenido enlazado. on paginated pages beyond page 2 or 3, depending on content freshness. Don't disallow pagination entirely or you break Googlebot's ability to discover linked content.
- Etiquetas canónicas en todas las variantes de URL parametrizadas apuntando a la URL canónica limpia. Esto es redundancia junto con robots.txt. on all parameterised URL variants pointing to the clean canonical URL. This is belt-and-braces alongside robots.txt.
- Corrige errores 404 en la fuente -- Actualiza los enlaces internos o implementa redirecciones 301. Utilizo el rastreador principal de Screaming Frog junto con los datos del log para identificar qué páginas están enlazando a URLs muertas. -- Either update the internal links or implement 301 redirects. I use Screaming Frog's main crawler alongside the log data to find which pages are linking to dead URLs.
- Higiene del sitemap XML -- Elimina cualquier URL de tu sitemap que devuelva un código que no sea 200, que esté marcada como noindex, o que sea una redirección. Tu sitemap debe ser una lista curada de páginas que deseas que se indexen, nada más. -- Remove any URL from your sitemap that returns a non-200, is noindexed, or is a redirect. Your sitemap should be a curated list of pages you want indexed, nothing else.
Seahawk tuvo un cliente de fintech el año pasado -- alrededor de 65,000 páginas, principalmente contenido dinámico -- donde simplemente corregir el robots.txt para bloquear patrones de búsqueda interna redujo el rastreo de Googlebot de URLs basura en un 61% en seis semanas. El 39% restante del presupuesto de rastreo se desplazó hacia páginas de producto y categoría. La indexación de contenido nuevo pasó de un promedio de 23 días a 6 días. Este es el impacto en el mundo real.
Configurar el Monitoreo Continuo
Un audit de logs es una instantánea. La buena gestión del presupuesto de rastreo es continua. ¿Qué aspecto tiene realmente en la práctica?
Como mínimo, te recomendaría extraer y analizar logs mensualmente para cualquier sitio con más de 30,000 páginas. Observa la tendencia de frecuencia de rastreo para tus 100 URLs que generan más ingresos. Si la frecuencia de visitas de Googlebot a esas páginas está disminuyendo, algo ha cambiado -- nuevas fugas del presupuesto de rastreo, problemas de rendimiento del servidor, o una caída en la señal de PageRank.
Si quieres ser más sofisticado, configura GoAccess como un trabajo cron para procesar snapshots de logs diarios y enviar un reporte de resumen por correo. Toma aproximadamente dos horas configurarlo y te ahorra de perderte la erosión lenta del presupuesto de rastreo entre audits trimestrales.
FAQ
¿Importa el presupuesto de rastreo si ya estoy completamente indexado?
Más o menos. La indexación completa hoy no significa que se mantenga de esa manera. Si publicas contenido nuevo regularmente -- nuevos productos, nuevas publicaciones de blog, nuevas landing pages -- el presupuesto de rastreo determina con qué rapidez ese contenido fresco se descubre. Un sitio con un presupuesto de rastreo con fugas puede tener páginas nuevas sin ser inspeccionadas durante semanas. Esa es una desventaja competitiva real si estás en un nicho de rápido movimiento.
¿Debo bloquear a Googlebot completamente de ciertas subcarpetas usando robots.txt?
Sí, en casos específicos. Áreas de administración, rutas de staging, resultados de búsqueda interna, y URLs de filtros con muchos parámetros son todos candidatos razonables para reglas Disallow. Lo único que te advertiría es que no bloquees archivos JavaScript o CSS -- Googlebot los necesita para renderizar tus páginas correctamente. Muchos consejos SEO antiguos dicen que bloquees JS; ignóralo.
¿Cuántos datos de logs debo analizar?
30 días es el punto de equilibrio para la mayoría de sitios. Menos que eso y no verás patrones de rastreo de baja frecuencia. Más que eso y los tamaños de archivo se vuelven difíciles de manejar a menos que estés ejecutando un stack ELK apropiado. Para sitios de e-commerce estacional, a veces miro 60 días abarcando un período de pico para entender el comportamiento de rastreo bajo carga de tráfico.
¿Y si mi servidor no proporciona acceso a registros sin procesar?
Presiona a tu proveedor de hosting -- la mayoría de los hosts administrados tienen esto disponible incluso si no se destaca prominentemente en el panel. Si realmente no puedes obtener logs sin procesar, el análisis de bots de Cloudflare puede darte una imagen parcial para sitios detrás del proxy de Cloudflare, aunque es un pálido sustituto de datos de log reales. Considera cambiar de host si esto es un obstáculo recurrente en una cuenta de cliente grande.Cloudflare's bot analytics can give you a partial picture for sites behind the Cloudflare proxy, though it's a pale substitute for real log data. Consider switching hosts if this is a recurring blocker on a large client account.
¿Son suficientes las estadísticas de rastreo de Google Search Console?
Para un sitio pequeño, discutiblemente sí. Para cualquier cosa superior a 20K páginas, no. Las estadísticas de rastreo de GSC se agregan por día y no exponen datos a nivel de URL. Puedes ver que Googlebot rastreó 12,000 páginas en un martes, pero no cuáles fueron esas 12,000 páginas. Los archivos de log te dan esa resolución. Ambas herramientas juntas -- esa es la imagen completa.which 12,000 pages. Log files give you that resolution. Both tools together -- that's the complete picture.
---
Mira, la mayoría de SEOs saltan el análisis de archivos de registro porque se siente como territorio de DevOps. No es glamoroso. Estás buscando en gigabytes de marcas de tiempo y cadenas de agente de usuario. Pero en sitios grandes, es la diferencia entre adivinar dónde va tu presupuesto de rastreo y saber realmente. Y saber, en mi experiencia, siempre vale las dos horas que toma extraer los datos.
