Gestion del presupuesto de rastreo

El presupuesto de rastreo es la combinacion de dos factores: el límite de frecuencia de rastreo (cuantas solicitudes por segundo Googlebot puede hacer sin sobrecargar tu servidor) y la demanda de rastreo (cuanto quiere Google rastrear tu sitio basado en popularidad y frescura). Juntos, determinan el número total de páginas que Googlebot rastreara en un periodo dado.

Para tiendas pequenas con menos de 5.000 páginas, el presupuesto de rastreo raramente es una preocupacion. Google rastreara tu sitio completo regularmente sin problemas. Pero una vez que tu tienda supera las 10.000 URLs (incluyendo variaciones de parametros, páginas de filtros y listados paginados), el presupuesto de rastreo se convierte en un cuello de botella real.

Una tienda de moda de tamano medio que auditamos tenia 8.000 productos reales pero más de 340.000 URLs rastreables debido a la navegación facetada, parametros de color/talla, variaciones de ordenacion y paginacion. Googlebot gastaba el 85 % de su presupuesto de rastreo en estas páginas de parametros sin valor, mientras que el 30 % de las páginas de productos reales no habian sido re-rastreadas en más de 90 dias.

El desperdicio de rastreo ocurre cuando Googlebot pasa tiempo rastreando páginas que no aportan valor SEO. En ecommerce, las mayores fuentes de desperdicio son las URLs de navegación facetada, páginas de parametros, páginas de resultados de busqueda interna y paginacion excesiva.

La navegación facetada es la peor infractora. Una página de categoría con filtros de marca, color, talla, precio y valoración puede generar miles de combinaciones de URLs. Cada combinacion (/zapatos?marca=nike&color=negro&talla=42) es una URL rastreable separada que tipicamente muestra los mismos productos en arreglos ligeramente diferentes. Google no necesita rastrear todas estas.

Los parametros de ordenacion desperdician presupuesto de rastreo silenciosamente. URLs como /categoría?orden=precio-bajo, /categoría?orden=precio-alto, /categoría?orden=mas-recientes y /categoría?orden=mas-vendidos muestran todos los mismos productos. Estas páginas no agregan contenido unico pero pueden triplicar o cuadruplicar tu conteo de URLs rastreables.

Los IDs de sesión y parametros de seguimiento agregados a las URLs (/producto?utm_source=email&session=abc123) crean versiones duplicadas rastreables de cada página. Si tu plataforma agrega estos parametros y no los maneja con etiquetas canonicas, estas multiplicando tu superficie de rastreo innecesariamente.

La herramienta principal para prevenir el desperdicio de rastreo es el robots.txt. Al no permitir patrones de URL especificos, le dices a Googlebot que no se moleste en rastrear esas páginas. Para ecommerce, esto tipicamente significa bloquear parametros de filtros facetados, ordenes de clasificacion, resultados de busqueda interna y páginas de carrito/pago.

Un robots.txt practico para una tienda ecommerce podria incluir reglas como Disallow: /*?sort=, Disallow: /*?filter=, Disallow: /search y Disallow: /cart. Estas reglas evitan que Googlebot desperdicie presupuesto de rastreo en páginas que nunca deberian aparecer en los resultados de busqueda.

Ten cuidado con el bloqueo del robots.txt. Previene el rastreo, no la indexación. Si otras páginas enlazan a una URL bloqueada, Google puede indexarla basandose en el texto ancla y el contexto del enlace, incluso sin rastrear la página misma. Para páginas que quieres completamente excluidas del indice, combina el bloqueo robots.txt con meta etiquetas noindex o etiquetas canonicas.

Otro enfoque es usar la herramienta de Parametros de URL en Google Search Console para indicar a Google como parametros especificos afectan el contenido de la página. Puedes indicar si un parametro como "sort" cambia el contenido, y si Google deberia rastrear todas, algunas o ninguna URL con ese parametro.

Google Search Console proporciona un informe de Estadisticas de rastreo bajo Configuración que muestra como Googlebot interactua con tu sitio. Este informe revela el total de solicitudes de rastreo, el tiempo de respuesta promedio, el desglose de solicitudes por tipo de respuesta y el proposito del rastreo (descubrimiento vs. actualizacion).

Presta atención al desglose de codigos de respuesta. Si un porcentaje significativo de las solicitudes de rastreo devuelven redirecciones 301/302, errores 404 o errores de servidor 5xx, estas desperdiciando presupuesto de rastreo en URLs rotas o redirigidas. Un sitio ecommerce saludable deberia ver el 90 % o más de las solicitudes de rastreo devolviendo codigos de estado 200.

El desglose por tipo de archivo muestra si Googlebot esta gastando tiempo descargando imagenes, CSS, JavaScript u otros recursos de forma desproporcionada. Si los archivos JavaScript dominan tus solicitudes de rastreo, puede indicar problemas de renderizado que fuerzan a Googlebot a hacer solicitudes adicionales.

Compara tus estadisticas de rastreo mes a mes. Una caida repentina en las solicitudes de rastreo puede indicar problemas de rendimiento del servidor o cambios en el robots.txt que bloquearon demasiado. Un pico repentino podria significar que Google descubrio un nuevo lote de URLs parametrizadas o que un cambio en el sitemap expuso páginas previamente ocultas.

Como tu tienda renderiza las páginas impacta directamente la eficiencia del rastreo. Las páginas renderizadas del lado del cliente (CSR) construidas con frameworks JavaScript como React o Vue requieren que Googlebot haga multiples solicitudes: primero para descargar el esqueleto HTML, luego para obtener y ejecutar JavaScript, y finalmente para renderizar el contenido. Este proceso es más lento y consume más presupuesto de rastreo por página.

El renderizado del lado del servidor (SSR) entrega HTML completamente renderizado en la solicitud inicial, permitiendo a Googlebot entender el contenido de la página inmediatamente. Para sitios ecommerce, SSR o generacion de sitios estaticos (SSG) tipicamente resulta en 40 % a 60 % más páginas rastreadas por sesión de rastreo comparado con equivalentes CSR.

Las tiendas Shopify se renderizan del lado del servidor por defecto, por lo que raramente es una preocupacion para los comerciantes de Shopify. Pero las tiendas construidas sobre arquitecturas headless con React/Next.js o Vue/Nuxt.js necesitan asegurar que su implementación SSR funcione correctamente. Hemos visto tiendas headless donde una configuración SSR mal configurada causaba que Googlebot viera páginas de producto vacias, llevando a una desindexacion masiva.

Prueba como Google ve tus páginas usando la herramienta de Inspeccion de URL en GSC. Haz clic en "Ver página probada" para ver tanto la respuesta HTML cruda como el HTML renderizado. Si la versión renderizada le falta información del producto, precios o resenas, tu configuración de renderizado necesita atención.

Más alla de bloquear páginas sin valor, puedes dirigir activamente a Googlebot hacia tu contenido más importante. El enlazado interno es la senal más fuerte para la prioridad de rastreo. Las páginas con más enlaces internos apuntando a ellas se rastrean con mayor frecuencia y más rápidamente despues de las actualizaciones.

Manten tu sitemap XML ajustado y preciso. Incluye solo páginas que genuinamente quieras indexar: páginas de productos, páginas de categorías, publicaciones de blog clave y páginas informativas esenciales. Elimina productos agotados (o redirigelos), páginas noindexadas y URLs de parametros de tu sitemap. Un sitemap con 5.000 URLs importantes supera a uno con 50.000 URLs donde el 90 % es basura.

Actualiza las fechas lastmod de tu sitemap con precision. Cuando actualizas el precio, la descripcion o la disponibilidad de una página de producto, la fecha lastmod debe reflejar el cambio. Googlebot usa lastmod como senal para la prioridad de re-rastreo. Hemos visto tiendas que establecen todas las fechas lastmod en el mismo valor (o usan la fecha de hoy para cada página), lo que destruye la senal y hace que Google ignore lastmod completamente.

Para cambios sensibles al tiempo como rebajas, bajadas de precio o lanzamientos de nuevos productos, puedes usar la API de Indexación (para tipos de sitio elegibles) o solicitar indexación manualmente a traves de la herramienta de Inspeccion de URL de GSC.

El leak nombro el sistema de crawl Trawler y expuso las entradas que conducen sus decisiones de scheduling. Las URLs que ganan actualizaciones frecuentes de senales "dignas de crawl" - link equity, precision lastmod, profundidad de enlaces internos, cambios de contenido recientes - son revisitadas con frecuencia. Las URLs que no lo hacen se deslizan a niveles de crawl poco frecuentes independientemente de cuan importantes sean comercialmente.

Para catálogos grandes, el comportamiento del scheduler explica por que algunas PDPs pasan semanas sin re-crawl. El fix raramente es "subir el crawl budget via robots.txt o sitemaps" - es hacer las PDPs importantes dignas de crawl. Enlaces internos de páginas frecuentemente crawleadas (homepage, hubs de categoría, posts de blog recientes) tiran las PDPs más profundas a niveles más frecuentes. Valores lastmod precisos en sitemaps XML le dicen a Trawler cuando un re-crawl esta justificado.

Lo inverso también importa. Las URLs de navegación facetada y duplicados parametrizados queman el crawl budget que Trawler asigna a tu dominio, dejando menos ciclos para las URLs que quieres indexadas. Manejo agresivo de parametros, rel=canonical y reglas disallow en URLs verdaderamente redundantes liberan ciclos Trawler para páginas de ingresos.