Descubierta: actualmente sin indexar en Search Console

Cuando Search Console marca una URL como «descubierta: actualmente sin indexar», Google no está diciendo que tu contenido sea malo. Te está diciendo algo más simple y, en un sitio pequeño o mediano, casi siempre más fácil de arreglar: sabe que esa URL existe, pero todavía no ha decidido rastrearla. No hay fecha de último rastreo en el informe porque, literalmente, no se ha producido ningún rastreo.

Este estado suele confundirse con otros dos, y la confusión importa porque cada uno pide una solución distinta. «Rastreada: actualmente no indexada» es un veredicto sobre la calidad de una página que Google sí llegó a descargar. Los problemas de presupuesto de rastreo (crawl budget) solo son relevantes en sitios con cientos de miles o millones de URLs. Si tu sitio tiene unos pocos cientos o unos pocos miles de páginas y ves URLs acumulándose en «descubierta: actualmente sin indexar», el motivo casi nunca es que Google se haya quedado sin capacidad de rastreo. Es que algo en tu propio sitio le está diciendo a Google que esas URLs no merecen prioridad todavía: enlaces internos débiles, ruido en el sitemap, un servidor que responde despacio o demasiadas variantes de URL compitiendo por el mismo hueco en la cola.

Qué significa exactamente este estado en Search Console

El informe de páginas de Search Console agrupa cada URL en un estado según en qué punto se encuentra dentro del proceso de indexación. «Descubierta: actualmente sin indexar» es el escalón más temprano de esa cadena: Google conoce la URL —normalmente porque apareció en tu sitemap, porque otra página enlaza a ella o porque la encontró por otra vía— pero todavía no ha llegado a descargarla. No hay contenido evaluado, no hay veredicto de calidad, no hay nada que corregir en la página en sí, porque Google ni siquiera la ha abierto.

La propia documentación de Google es explícita sobre uno de los motivos más comunes de este estado: el rastreo se pospuso porque Google esperaba que descargar esa URL sobrecargara el servidor, así que decidió reprogramarlo. Por eso la columna de última fecha de rastreo aparece vacía: no es que el dato se haya perdido, es que el evento nunca ocurrió.

La cadena completa tiene tres eslabones, cada uno con su propia causa:

• Descubierta, sin rastrear todavía: este artículo. El problema es de prioridad y acceso, no de contenido.
• Rastreada, sin indexar: Google ya la descargó y decidió no indexarla; el problema suele ser de calidad o duplicidad.
• Indexada: la URL entró en el índice y es candidata a aparecer en resultados.

Por qué no es un problema de calidad ni de presupuesto de rastreo

Es fácil mezclar este estado con «rastreada: actualmente no indexada», y la confusión lleva a soluciones opuestas. En ese otro estado, Google sí descargó la página, la analizó y decidió, de momento, no meterla en el índice. Ahí el problema casi siempre es de contenido: duplicidad con otra URL del propio sitio, contenido demasiado fino, señales de calidad débiles o una versión mejor de la misma información ya indexada en otro lugar. La solución pasa por mejorar o consolidar esa página. En «descubierta: actualmente sin indexar» ese análisis todavía no ha empezado. No tiene sentido reescribir el contenido de una URL que Google ni siquiera ha abierto: el problema no está en lo que dice la página, está en si Google decide ir a buscarla.

Tampoco es, casi nunca, un problema de presupuesto de rastreo en el sentido técnico del término. El crawl budget —el número de URLs que Googlebot está dispuesto a rastrear en un sitio durante un periodo dado— solo se convierte en un factor limitante real en sitios con un volumen de URLs muy superior a lo que cualquier rastreador puede cubrir con margen: tiendas con cientos de miles de referencias, portales de anuncios clasificados, foros con años de hilos acumulados. Si tu catálogo tiene unos pocos cientos o unos pocos miles de páginas, la capacidad de rastreo de Google no es, en la práctica, el cuello de botella. El cuello de botella es la prioridad: con qué fuerza el resto del sitio le dice a Google que esa URL merece un hueco en la cola.

Enlaces internos débiles: la señal de prioridad más habitual

De las cuatro causas, esta es la que más veces explica el patrón en sitios pequeños y medianos. Google se apoya, entre otras señales, en cuántos enlaces internos recibe una URL y desde qué tipo de páginas para decidir con qué prioridad la rastrea. Una URL enlazada solo desde el sitemap XML —sin ningún enlace de navegación, ninguna mención en otro artículo, ningún enlace desde una página de categoría— le llega a Google como una URL que el propio sitio no considera importante. El sitemap dice «esto existe»; el enlazado interno dice «esto importa». Cuando solo tienes lo primero, es razonable que Google la deje esperando.

Esto aparece con mucha frecuencia en productos de catálogo dados de alta por importación masiva sin enlazarlos desde ninguna categoría, en publicaciones de blog que dejaron de aparecer en el bloque de artículos relacionados en cuanto se publicó contenido más reciente, o en páginas de aterrizaje creadas para una campaña puntual y nunca enlazadas desde el menú ni desde ninguna otra página del sitio. También influye la profundidad de clics: una URL a la que solo se llega tras cuatro o cinco clics desde la portada compite en clara desventaja frente a otra accesible en dos.

• ¿Cuántos enlaces internos recibe la URL, aparte del que aporta el propio sitemap?
• ¿Desde qué páginas la enlazas: portada, categoría, artículos relacionados, o solo desde una lista paginada que casi nadie visita?
• ¿A cuántos clics de la portada está esa URL en la práctica, no en el mapa del sitio ideal que tienes en la cabeza?

Ruido en el sitemap: cuando el mapa deja de ser útil

El sitemap XML es una de las vías por las que Google descubre URLs, pero un sitemap ruidoso puede jugar en tu contra en lugar de ayudar. Si incluye URLs que devuelven 404, que redirigen a otra dirección, que llevan una etiqueta noindex o que son casi duplicados exactos entre sí, Google aprende con el tiempo que ese sitemap es poco fiable. No dejará de leerlo, pero sí reduce la confianza que deposita en él como señal de qué rastrear primero.

El campo lastmod es otro punto donde se pierde valor sin darse cuenta. Si todas las URLs del sitemap muestran la misma fecha —porque el generador la escribe al vuelo cada vez que se regenera el archivo, en lugar de reflejar cuándo cambió realmente cada página— Google no puede usarlo para distinguir contenido recién actualizado de contenido que lleva años igual. Un lastmod que no aporta información no ayuda a priorizar nada.

Otro patrón habitual: sitemaps generados automáticamente que crecen sin control y terminan incluyendo miles de URLs de baja utilidad —resultados de búsqueda interna, páginas de archivo por fecha con contenido mínimo, borradores que deberían llevar noindex— mezcladas con las páginas que sí importan. Cuanto más diluido está el sitemap, menos peso relativo tiene cada URL individual como señal de descubrimiento.

Estrangulamiento del servidor y la cola de rastreo

Ya se mencionó que la documentación de Google señala la posible sobrecarga del servidor como un motivo explícito para posponer un rastreo. No es una suposición: el propio rastreador ajusta de forma dinámica cuánto y con qué frecuencia visita un sitio en función de cómo responde ese servidor. Si los tiempos de respuesta suben, si aparecen errores 5xx con cierta frecuencia, o si el hosting empieza a devolver respuestas lentas o incompletas bajo carga, Googlebot reduce la velocidad de rastreo para no empeorar la situación. Menos rastreo significa, casi por definición, que hay URLs descubiertas que se quedan esperando su turno más tiempo del habitual.

Esto es especialmente común en hosting compartido con recursos limitados, en sitios detrás de un WAF o un sistema antibots demasiado agresivo que limita peticiones por IP o por user-agent sin distinguir bien a Googlebot del tráfico malicioso, y en picos de carga puntuales —una migración, una campaña que dispara el tráfico de golpe— que coinciden justo con el momento en que Google intentaba rastrear URLs nuevas.

• Revisa el informe de estadísticas de rastreo en Search Console: tiempo de respuesta medio y desglose de códigos de respuesta por día.
• Cruza esos datos con los logs del servidor filtrando por el user-agent de Googlebot para ver tasas de error y tiempos reales, no solo los que reporta la muestra de Search Console.

Explosión de URLs: más páginas de las que puedes rastrear con prioridad

Un catálogo con filtros combinables, un calendario de eventos que genera una URL por cada día del año, parámetros de sesión o de seguimiento que crean una URL nueva por cada combinación, o una paginación que sigue generando páginas mucho más allá del contenido real: todo esto multiplica el número de URLs que Google descubre sin multiplicar el número de páginas que de verdad quieres indexar. Cuando la proporción entre URLs de valor real y URLs generadas automáticamente se dispara, las de valor real compiten por atención dentro de un conjunto mucho más grande, y es más probable que se queden en la cola más tiempo del que deberían.

Esto no es lo mismo que la duplicidad por navegación por facetas o por parámetros de URL —eso ya es materia de contenido, no de descubrimiento—; aquí el efecto que interesa es de volumen: cuantas más variantes de baja prioridad compiten por el mismo rastreo, más tarda en llegarle el turno a la variante canónica que sí quieres posicionar. Reducir el número de combinaciones descubribles suele ser el primer paso que de verdad mueve la aguja.

Cómo diagnosticarlo y qué corregir primero

El punto de partida es el propio informe de páginas de Search Console, filtrado por el estado «descubierta: actualmente sin indexar». Exporta la lista completa en lugar de mirar solo la muestra que se ve en pantalla, y busca patrones: ¿se concentran en un directorio concreto, en un tipo de plantilla, en URLs con ciertos parámetros? Un patrón claro apunta casi siempre a una causa estructural —una plantilla que genera enlazado débil, un tramo del sitemap con errores— en lugar de a casos aislados que no comparten origen.

Toma después una muestra representativa y pásala, una a una, por la herramienta de inspección de URLs. El informe indica si apareció en el sitemap, si Google la conoce por otra vía, y a veces ofrece pistas adicionales. No tiene sentido pedir indexación manual de mil URLs de la lista: ese botón está pensado para casos puntuales, no como solución a un patrón estructural.

Antes de fijar el orden de trabajo, conviene descartar dos atajos.

Lo que no ayuda: pedir indexación manual de forma repetida sin tocar la causa de fondo, o dar por hecho que el problema es de contenido y reescribir páginas que Google todavía no ha abierto. Ninguna de esas acciones cambia la señal de prioridad que hizo que Google pospusiera el rastreo; solo corregir la causa raíz lo hace, y suele tardar varias semanas en reflejarse en el informe. El orden de prioridad, en la práctica, suele ser este:

• Enlaza la URL desde al menos una página con enlazado interno real —una categoría, un artículo relacionado, un elemento de navegación— no solo desde el sitemap.
• Limpia el sitemap: retira las URLs con 404, redirects o noindex, y comprueba que lastmod refleja cambios reales y no una fecha genérica.
• Revisa el informe de estadísticas de rastreo y los logs del servidor para descartar tiempos de respuesta altos o errores 5xx en las horas de mayor actividad de Googlebot.
• Si el patrón viene de parámetros o de navegación por facetas, reduce primero el número de variantes descubribles antes de pedir que se rastree ninguna de ellas por separado.