El proyecto era una cadena de veinte supermercados con presencia online consolidada: catálogo de productos, páginas de tienda por localización, ofertas semanales y sección de recetas. Un sitio con volumen real. Miles de URLs activas, actualizaciones frecuentes y, según el cliente, un tráfico orgánico que llevaba meses sin crecer aunque el contenido seguía publicándose con regularidad. No había caída brusca, no había ninguna alerta en el panel. Solo estancamiento. Ese tipo de problema que, si no lo buscas, no te llama.
Lo que me llamó la atención desde el primer vistazo fue la distancia entre lo que el sitio publicaba y lo que Google parecía procesar. Había páginas de producto actualizadas desde hacía semanas que seguían mostrando datos viejos en los resultados, o directamente no aparecían. Con ese volumen de contenido y esa frecuencia de cambios, el crawl budget disponible debería ser suficiente para mantener el índice al día. Pero algo estaba consumiendo ese margen antes de que el rastreador llegara donde tenía que llegar.
Operario: Serpion
Expediente del caso: El rastro oculto del crawl budget
Empresa o negocio: Cadena de 20 supermercados
Archivado en: Indexación
Nivel: Intermedio
Lo que los logs del servidor contaban sobre el crawl budget
La cadena tenía un historial limpio: sin penalizaciones, sin cambios de dominio recientes, sin migraciones a la vista. No había nada que justificara ese desajuste de forma obvia. Y sin embargo, las páginas importantes seguían esperando. Aquí había ruido, pero no era ruido cualquiera.
El primer paso fue revisar los logs del servidor. No siempre se tienen a mano, pero en este caso el equipo técnico del cliente los facilitó sin problema. Y lo que encontré ahí fue la primera señal concreta que explicaba el malestar: el rastreador de Google visitaba el sitio con frecuencia, sí, pero se concentraba en zonas que no eran las prioritarias. Las páginas de tienda por localización, que agrupaban productos según el supermercado más cercano al usuario, recibían visitas del Googlebot de forma sistemática. Las fichas de producto individuales, en cambio, mostraban huecos de hasta dieciocho días sin ningún acceso registrado.
-- Extracto de logs del servidor (Googlebot, octubre 2024) --
2024-10-01 08:14:22 Googlebot /tiendas/madrid-norte/ 200
2024-10-01 08:14:25 Googlebot /tiendas/madrid-sur/ 200
2024-10-01 08:14:28 Googlebot /tiendas/barcelona-gracia/ 200
2024-10-01 08:14:31 Googlebot /tiendas/valencia-centro/ 200
...
[Últimas 4.200 visitas registradas: 91% en /tiendas/ — 6% en /ofertas/ — 3% resto]
Última visita a /productos/aceite-oliva-virgen-extra-5l/: 2024-09-13 11:02:44
Última visita a /productos/detergente-ropa-liquido-3l/: 2024-09-15 09:47:12
Última visita a /productos/yogur-natural-pack-8u/: 2024-09-12 14:23:05
El patrón era bastante claro: el rastreador estaba invirtiendo la mayor parte de sus visitas en el directorio de tiendas, un bloque de páginas que cambiaba poco y cuyo contenido relevante para el usuario era básicamente dirección, horario y mapa. Útil para el usuario local, pero no exactamente el núcleo del catálogo. Mientras tanto, las fichas de producto, que sí se actualizaban con precios, disponibilidad y promociones semanales, llevaban semanas sin recibir una sola visita del Googlebot.
Antes de sacar conclusiones, consideré que el problema podría estar en la estructura de enlazado interno. Si las páginas de tienda recibían muchos más enlaces internos que las fichas de producto, el rastreador seguiría esa lógica de forma natural: cuantos más caminos apuntan a una zona, más tiempo pasa en ella. Era una hipótesis razonable. Lo comprobé con Screaming Frog: lancé un rastreo completo del sitio y revisé cuántos enlaces internos apuntaban a cada directorio.
El resultado no validaba esa hipótesis. Las fichas de producto tenían más enlazado interno que las páginas de tienda: aparecían en la home, en las páginas de categoría, en los bloques de ofertas y en la sección de recetas. Si el rastreador siguiera solo la densidad de enlaces, la distribución de visitas debería ser la inversa. Ahí quedó claro que el enlazado interno no era la causa. El problema no era que Google no encontrara las páginas. Era que algo lo detenía antes de entrar en ellas.
Por qué el crawl budget se consumía antes de llegar al catálogo
Con el enlazado interno descartado, volví a los datos de Google Search Console para cruzar la información. El informe de cobertura mostraba algo que hasta ese momento no había terminado de procesar: había un volumen inusualmente alto de URLs en estado "Descubierta: actualmente sin indexar". No eran errores, no eran exclusiones declaradas. Eran páginas que Google había encontrado pero no había rastreado todavía.
-- Google Search Console · Informe de cobertura (octubre 2024) --
Indexadas: 4.820
Excluidas: 1.340
· Descubierta: actualmente sin indexar → 987
· Rastreada: actualmente sin indexar → 201
· Página con redirección → 98
· Otras exclusiones → 54
URLs afectadas por estado "Descubierta: sin indexar":
/productos/aceite-oliva-virgen-extra-5l/
/productos/detergente-ropa-liquido-3l/
/productos/yogur-natural-pack-8u/
/productos/pan-molde-integral-450g/
[...y 983 fichas de producto más]
Casi mil fichas de producto descubiertas pero sin rastrear. Google sabía que existían porque las había encontrado a través de enlaces, pero no había entrado en ellas. El crawl budget disponible se estaba agotando antes de llegar a ese directorio, y las señales de los logs confirmaban exactamente ese comportamiento: el Googlebot consumía su margen de visitas en el directorio de tiendas y salía del sitio sin haber procesado el catálogo.
Un sitemap no obliga al rastreador a priorizar páginas. Google elige dónde entrar según las señales que encuentra, y algo en este sitio le estaba diciendo que priorizara unas zonas sobre otras. La pregunta era qué señal concreta estaba generando ese efecto.
El bloqueo que nadie recordaba haber puesto
La respuesta llegó al revisar en detalle la configuración técnica del sitio. El archivo robots.txt tenía una regla Disallow activa sobre el directorio /productos/ para el agente genérico. No era una exclusión total, pero sí era suficiente para que el Googlebot interpretara esa zona como de baja prioridad o de acceso restringido. La regla llevaba ahí desde una migración anterior: alguien la había añadido para bloquear el rastreo durante el proceso de cambio de estructura, y después nadie la había eliminado.
-- robots.txt (estado antes de la corrección) --
User-agent: *
Disallow: /productos/
Disallow: /wp-admin/
Disallow: /busqueda/
Sitemap: https://www.cadena-supermercados.es/sitemap.xml
Eso explicaba el comportamiento del rastreador, pero no todo. Porque incluso con ese Disallow, algunas fichas de producto sí habían sido rastreadas e indexadas en el pasado. Al inspeccionar el HTML de varias páginas de producto manualmente, encontré la segunda capa del problema: un subconjunto de fichas tenía una metaetiqueta noindex activa en el código. No todas, pero sí suficientes para reforzar la señal de bloqueo que ya transmitía el robots.txt.
-- HTML de ficha de producto (ejemplo representativo) --
<head>
<title>Aceite de oliva virgen extra 5L | Supermercados X</title>
<meta name="robots" content="noindex, follow">
<link rel="canonical" href="https://www.cadena-supermercados.es/productos/aceite-oliva-virgen-extra-5l/">
</head>
La combinación era devastadora para el crawl budget: el archivo de configuración desaconsejaba la entrada al directorio, y las propias páginas pedían no ser indexadas. Google obedecía. No estaba fallando ni ignorando el sitio. Estaba leyendo instrucciones contradictorias y priorizando las que le resultaban más claras: mantente lejos del catálogo.
Los bloqueos heredados suelen sobrevivir más que las migraciones. Nadie los detecta porque nunca generan errores. Solo generan silencio.
El impacto era directo: casi mil páginas de producto con actualizaciones semanales de precios y disponibilidad llevaban meses sin ser procesadas. Google tenía en su índice versiones antiguas de esas fichas, o directamente no las tenía. Las búsquedas relacionadas con productos concretos no devolvían resultados frescos. Y el tráfico orgánico del catálogo, que debería crecer con cada actualización, se había quedado plano.
Liberar el rastreador sin romper la estructura
Con el diagnóstico confirmado, el siguiente paso era decidir cómo intervenir. Había urgencia real: el cliente actualizaba precios y ofertas cada semana, y Google llevaba meses sin procesar esos cambios. Pero la urgencia no podía convertirse en prisa técnica.
Qué tocar primero sin desestabilizar el índice
La tentación más inmediata era eliminar el Disallow y el noindex de golpe y esperar que Google procesara todo de una vez. Tenía cierta lógica: si el bloqueo era la causa, quitarlo debería normalizar el flujo. El problema era el volumen. Liberar de repente cerca de mil URLs sin ningún criterio de prioridad significaba entregar al rastreador un catálogo entero sin ninguna señal de qué era más importante. El crawl budget disponible podría distribuirse de forma poco eficiente igualmente, simplemente por otro motivo.
La corrección que tenía más sentido era secuencial. Primero, eliminar el Disallow sobre /productos/ en el robots.txt, dejando solo las exclusiones que sí tenían lógica: el panel de administración, el buscador interno y los parámetros de sesión. Eso abriría el paso al directorio sin generar ruido adicional. Segundo, revisar ficha a ficha —o por lotes, con ayuda de Screaming Frog— cuáles tenían el noindex activo y eliminarlo de forma controlada, empezando por las páginas con mayor volumen de búsqueda potencial. Tercero, reforzar el enlazado interno desde las páginas de categoría hacia las fichas más relevantes para acelerar la señal de prioridad.
El riesgo de hacerlo mal estaba en el orden. Si se eliminaba el noindex antes de abrir el Disallow, Google podría intentar indexar páginas que aún no podía rastrear correctamente, generando inconsistencias en el informe de cobertura. Había que abrir el camino antes de encender la señal.
Validamos cada cambio en Google Search Console usando la herramienta de inspección de URLs antes y después de cada intervención. En los primeros diez días tras la corrección del robots.txt, los logs ya mostraban visitas del Googlebot en páginas de producto que llevaban semanas sin recibir tráfico de rastreo. A las tres semanas, el número de URLs en estado "Descubierta: actualmente sin indexar" había bajado de 987 a 312. No todo de golpe, pero la dirección era clara y estable.
No estábamos ante una recuperación instantánea. Estábamos ante una normalización del flujo de rastreo que el sitio debería haber tenido desde el principio.
💡 Qué he aprendido
Este caso me confirmó algo que ya intuía pero que no había visto tan limpio hasta entonces: los problemas más difíciles de detectar no son los que gritan. Son los que funcionan en silencio durante meses porque nadie los puso ahí con mala intención. Esa regla en el archivo de configuración era correcta en su momento. El contexto cambió y la regla no. Nadie la revisó porque nunca generó ningún error visible.
Desde entonces, incluyo la revisión del presupuesto de rastreo como parte del diagnóstico inicial en cualquier sitio con un volumen de URLs relevante. No espero a que los síntomas sean obvios. Si hay huecos en los logs, quiero saberlo antes de que se conviertan en meses de estancamiento. Y si hay configuraciones heredadas de migraciones anteriores, también quiero verlas pronto.
Lo que más me quedó de este expediente fue la imagen de esas fichas de producto esperando. Contenido actualizado cada semana, sin que Google las visitara. La cadena hacía su trabajo. El sitio, técnicamente, también. Solo había una instrucción antigua que nadie había apagado.
Bitácora de Serpion
Analista Digital
🧩 Notas del caso
Cadena de veinte supermercados con catálogo online activo y actualizaciones frecuentes de precio y disponibilidad. El tráfico orgánico llevaba meses estancado sin causa aparente. El rastreador de Google consumía sus visitas en el directorio de tiendas y no llegaba a las fichas de producto, que acumulaban hasta dieciocho días sin ningún acceso registrado.
La causa era una combinación de reglas de bloqueo heredadas de una migración anterior que nadie había revisado ni eliminado. La intervención consistió en liberar el acceso al directorio de forma secuencial y eliminar las etiquetas que impedían la indexación, priorizando las páginas con mayor potencial de búsqueda.
🔎 Pistas SEO extraídas del caso
- Huecos de rastreo de hasta 18 días en fichas de producto con estado HTTP 200 y contenido actualizado semanalmente.
- El 91% de las visitas del Googlebot registradas en logs se concentraban en el directorio de tiendas, con escasa rotación de contenido.
- 987 URLs en estado "Descubierta: actualmente sin indexar" en Google Search Console, correspondientes casi todas al catálogo de productos.
- El enlazado interno apuntaba con más fuerza al catálogo que al directorio de tiendas, lo que descartaba esa vía como causa del desvío de rastreo.
- Presencia de metaetiquetas de exclusión de indexación en un subconjunto de fichas de producto sin documentación ni justificación vigente.
🚫 Errores SEO detectados en el caso
- Regla de bloqueo activa sobre el directorio principal del catálogo: heredada de una migración anterior, impedía que el rastreador priorizara las fichas de producto, desviando el presupuesto disponible hacia zonas menos relevantes.
- Metaetiquetas de exclusión de indexación sin auditoría posterior: aplicadas durante una fase de construcción del sitio y nunca revisadas, generaban una señal de bloqueo adicional sobre páginas que debían estar completamente accesibles.
- Ausencia de monitorización de logs de rastreo: el desvío llevaba meses activo sin que nadie en el equipo lo detectara, porque no había ningún sistema de alerta sobre la distribución de visitas del Googlebot.
- Sitemap declarando URLs bloqueadas como válidas: el sitemap incluía fichas de producto que el archivo de configuración restringía, generando una contradicción de señales que Google resolvía a favor de la restricción.
- Falta de documentación de cambios técnicos en migraciones: ningún registro indicaba por qué o cuándo se habían añadido las reglas de bloqueo, lo que dificultó la validación de cuáles eran seguras de eliminar.
📘 Glosario SEO del expediente
- Crawl budget: número de URLs que Google está dispuesto a rastrear en un sitio durante un período determinado, distribuido según señales de calidad y accesibilidad.
- Logs del servidor: registros generados por el servidor que documentan cada petición recibida, incluyendo las visitas del Googlebot con URL, fecha y código de respuesta.
- Descubierta: actualmente sin indexar: estado de Google Search Console que indica que Google conoce la URL pero aún no la ha rastreado ni procesado para incluirla en el índice.
- Disallow: directiva del archivo robots.txt que indica al rastreador que no debe acceder a una ruta o directorio concreto del sitio.
- Noindex: instrucción en el código HTML de una página que indica a Google que no debe incluir esa URL en su índice, aunque sí pueda rastrearla.
📏 Mini guía práctica
- Revisa los logs del servidor antes de cualquier otra herramienta cuando detectes estancamiento orgánico sin causa aparente: el patrón de visitas del Googlebot revela dónde se está consumiendo el margen de rastreo.
- Audita el archivo robots.txt después de cada migración o cambio de estructura importante, y documenta el motivo de cada regla activa con fecha de creación.
- Cruza el sitemap con las reglas de bloqueo del robots.txt: cualquier URL declarada en el sitemap que también esté restringida genera una contradicción que el rastreador resolverá en contra de la indexación.
- Antes de eliminar reglas de bloqueo en masa, ordena la intervención: abre primero el acceso al directorio y elimina después las etiquetas de exclusión, nunca al revés.
- Configura alertas sobre el estado de cobertura en Search Console para detectar acumulaciones de URLs en estado "Descubierta: sin indexar" antes de que se conviertan en semanas de retraso.
Deja una respuesta
Expedientes y Archivos