«Discovered – currently not indexed» y «Crawled – currently not indexed» son las dos filas más comunes del informe «Páginas indexadas» de Search Console – y las peor entendidas. Parecen un fallo técnico, pero en realidad son una decisión de prioridad y calidad que Google tomó sobre tus páginas. Enviar con más fuerza no cambia nada. Corregir la causa, sí.
Esta guía es un bucle completo que puedes entregar entero al agente Hermes: extraer la lista de URLs, inspeccionar cada página, triar la causa real, aprobar la cola de correcciones y enviar por Google Indexing API solo las páginas que merecen ser indexadas. Al terminar tienes un pipeline semanal repetible – no una sesión de clics de una sola vez.
Lo que obtienes al terminar
- Un inventario clasificado: URLs atascadas en «discovered», URLs rastreadas pero no indexadas y URLs que nunca debiste enviar
- Una lista aprobada para Indexing API y una lista de omitidas con su razón
- Un paso de verificación que muestra si tus envíos realmente funcionaron
Lo que necesitas: un agente Hermes instalado y funcionando (hermes chat abre una sesión. Pasos de instalación actualizados: documentación oficial en hermes-agent.nousresearch.com/docs), una propiedad de Search Console de la que seas propietario y dos juegos de credenciales de Google (uno para leer la GSC, otro para Indexing API). Primer setup unos 60–90 minutos, luego unos 15 minutos por semana. «Terminado» significa: tus URLs enviadas muestran un cambio de estado real en la API de inspección dentro de dos semanas – o tienes pruebas sólidas de por qué no.
Leer bien los dos estados
Google no está atascado en tu sitio. Tomó una decisión – y el estado te dice cuál.
Estado | Qué significa realmente | Causas frecuentes | Cuándo enviar |
|---|---|---|---|
Discovered – currently not indexed | Google conoce la URL (por sitemap o enlaces) pero aún no la rastreó | Baja prioridad de rastreo, enlaces internos débiles o ausentes, presión de presupuesto de rastreo en sitios grandes, sitio nuevo, renderizado JS lento o pesado, sitemaps que cambian seguido | Una vez, después de mejorar las señales de prioridad (sobre todo enlaces internos) |
Crawled – currently not indexed | Google obtuvo la URL pero decidió no indexarla | Contenido duplicado o casi duplicado, contenido pobre, canonical hacia otra URL, noindex al momento del rastreo, soft 404, juzgada de bajo valor | Solo si realmente cambiaste algo: contenido, canonical o noindex |
Indexed | Está en el índice | — | No enviar |
Excluded | Rastreada y excluida a propósito (noindex, canonical, elección de duplicado, bloqueo) | — | No enviar; verifica si la exclusión es intencional |
En una frase: envía solo URLs que realmente cambiaste o que merecen una segunda mirada. Indexing API es un canal de notificación, no un anulador de rankings. Enviar una página pobre diez veces devuelve diez veces el mismo veredicto.
Por qué que lo haga un agente
El botón «Solicitar indexación» de la GSC no tiene API pública – no hay forma oficial de pulsarlo con un script. La automatización más cercana es Google Indexing API, que acepta notificaciones de URL directamente. Un agente aporta valor por tres razones:
- El bucle es mecánico y largo: inventario → inspección → clasificación → corrección → envío → verificación. Cada semana.
- Requiere un rastro de auditoría: necesitas un archivo que muestre qué URLs se enviaron, cuándo y por qué.
- Requiere una compuerta de aprobación: la parte que escribe en Google debe ser revisada por un humano. Hermes está construido exactamente alrededor de esta separación – con skills, carpetas de proyecto y reglas de aprobación.
Qué necesitas antes de empezar
- Agente Hermes instalado. Verifica con
hermes chatantes de continuar. - Una propiedad GSC de la que seas propietario. En formato
sc-domain:example.com(no la URL completa). - Acceso de lectura: un cliente OAuth de Google Cloud (ID de cliente + secreto) para Search Console API. Los scripts del skill GSC lo usan para sitemaps, Search Analytics e inspección de URLs.
- Acceso de escritura: un proyecto de Google Cloud con Indexing API activada y una clave JSON de cuenta de servicio. Añade el email de la cuenta de servicio como propietario en GSC → Configuración → Usuarios y permisos. Si el envío devuelve 403, este es el paso que falta.
- Python 3 y
pip install google-auth google-api-python-client. - Una carpeta de proyecto. Por ejemplo
/hermes-seo-projectconcontext/,data/,qa/y unapproval-rules.mdque exija que el paso de envío siempre requiera firma humana.
Paso 1: construir el inventario de URLs
Copia los dos skills de GSC al directorio de skills de Hermes (~/.hermes/skills): el skill de lectura (sitemaps, Search Analytics, inspección de URLs) y el skill de indexación (script de envío). Si el harness cataloga skills, también puedes cargarlos con skill_view.
Luego pide a Hermes en una sesión de chat, desde la carpeta del proyecto:
Lista todos los sitemaps de sc-domain:example.com, extrae cada URL con su lastmod y escríbelos en data/url-inventory.csv. Marca cualquier sitemap cuyo fetch falle.
Hermes ejecuta los comandos de sitemap vía la herramienta de terminal y escribe el CSV. Una buena salida: un CSV deduplicado con URL, lastmod y sitemap de origen. Control de calidad: revisa cinco filas al azar y contrasta el total con el informe de sitemaps de la GSC. Si la lista está vacía o falla la autenticación, repite el flujo de autenticación de la GSC; el script de lectura necesita un token OAuth fresco.
Paso 2: inspeccionar y clasificar
El agente inspecciona entonces el inventario en lotes vía URL Inspection API y obtiene el estado de cobertura actual de cada página. Pídele la siguiente etapa:
Inspecciona cada URL de data/url-inventory.csv. Divídelas en tres archivos: data/to-submit.txt (no indexadas y que merecen envío), data/skip.txt (con una razón por URL) y data/needs-fix.txt (no indexadas y atascadas en algo que podemos cambiar).
La API de inspección tiene límites de tasa por propiedad (mira la cuota actual en Google Cloud Console; varios miles al día, pero no infinito). En sitios grandes, limita esta ronda a las URLs con lastmod más reciente – las que realmente cambiaste este trimestre. Control de calidad: muestrea la lista de omitidas. Debería estar dominada por noindex, canonicals que apuntan a otra URL y duplicados – no por páginas que te importan. Si un sitio con miles de URLs da un needs-fix vacío, la etapa de inventario probablemente se perdió páginas. Amplía el rango de entrada.
Paso 3: triar antes de enviar
El paso que todos se saltan. Mapea las URLs atascadas a una causa y una corrección, en este orden:
Causa | Corrección | ¿Enviar tras corregir? |
|---|---|---|
La página no tiene ningún enlace interno | Añadir enlaces contextuales desde páginas indexadas | Sí |
Sitio o página totalmente nuevo | Nada que corregir; enviar una vez y esperar 1–2 semanas | Sí, una sola vez |
Bloqueada por robots.txt | Levantar el bloqueo de esa ruta | Sí |
Rastreada pero duplicada o pobre | Reescribir, fusionar o eliminar | Solo tras un cambio real de contenido |
canonical apunta a otra URL | Corregir el canonical si es incorrecto; si es intencional, dejar de enviar esta URL | Solo tras corregirlo |
noindex al momento del rastreo | Quitar el noindex y dejar que Google re-rastree | Sí, tras quitarlo |
Soft 404, paginación/archivos sin valor | Corregir la página o eliminarla | No — omitir permanentemente |
Pide a Hermes que prepare la cola de correcciones como tabla: URL, causa presunta, evidencia (resultado de inspección o revisión de contenido), acción sugerida, nivel de riesgo. Aprueba cada fila en el chat. Tu approval-rules.md debería exigirlo: el agente prepara, tú apruebas, y nada por encima de riesgo bajo se envía sin firma.
La compuerta de aprobación separa la preparación del agente del paso de escritura.
Las correcciones en sí son trabajo SEO normal: reescribir contenido, limpiar canonicals, enlaces internos. Este pipeline cubre la mitad de envío. La mitad de corrección la cubren los artículos de auditoría y actualización de la serie Hermes.
La lista de envío es la intersección de «corregible» y «digna de indexación».
Paso 4: enviar vía Indexing API
Cuando la cola esté aprobada, coloca las URLs en data/approved-urls.txt y deja que Hermes ejecute el skill de indexación:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txtEl tipo de notificación por defecto es URL_UPDATED, pensado para páginas nuevas o modificadas. Tres números para recordar: la cuota por defecto es 200 URLs al día, 600 peticiones por minuto – y 403 significa que la cuenta de servicio no es propietaria de la propiedad. Si la lista aprobada supera las 200, repártelas en varios días; Hermes puede planificar los lotes restantes.
Nunca envíes páginas ya indexadas ni la lista de omitidas. Las notificaciones desperdiciadas solo queman cuota y crean ruido.
Paso 5: verificar y esperar
El status justo después del envío solo te dice si Google tiene metadatos de la notificación – no si la página está indexada. La confirmación real llega días después.
3–7 días después del lote, pide a Hermes:
Vuelve a inspeccionar las URLs de data/approved-urls.txt e informa de los cambios de estado frente a la última ejecución.
Una progresión sana es discovered → crawled → indexed. Así se ve a lo largo de semanas: la lista de no indexadas se encoge y tus correcciones reales (nuevos enlaces internos, textos reescritos) aparecen en el índice. Recuerda: los datos de la GSC van con días de retraso y Google re-rastrea según su propio calendario. Una URL que sigue en «Crawled – currently not indexed» 10–14 días después de correcciones reales es una señal de calidad, no un problema de envío – escálala al trabajo de contenido.
Mantener el bucle en marcha
Convierte el pipeline en una rutina semanal: URLs nuevas o actualizadas desde la última ejecución → inspección → clasificación → triaje → aprobación → envío → registro. Hermes puede ejecutar la parte de solo lectura (inventario, inspección, clasificación) sin supervisión, con un calendario, y presentarte la cola cada lunes. El paso de envío queda tras la compuerta de aprobación, con un registro continuo en qa/indexing-log.md: fecha de envío, URL, tipo de notificación, resultado. Seis meses de registro son la única medida honesta de si el pipeline funciona.
Límites honestos
- Google documenta Indexing API para páginas con datos estructurados
JobPostingoBroadcastEvent. Usarla en páginas normales es práctica SEO extendida, pero Google no garantiza indexación ni soporte para ningún tipo de página. - El botón «Solicitar indexación» no tiene API pública. Indexing API es la automatización más cercana, no el mismo botón.
- Enviar no crea prioridad. Si una página sigue sin indexarse tras corregir, enviar y esperar, la siguiente respuesta es la calidad del contenido – no otra notificación.
Preguntas frecuentes
¿Indexing API funciona con páginas normales? Acepta cualquier URL que le envíes. La documentación oficial de Google apunta a páginas JobPosting y BroadcastEvent, así que trata los envíos de páginas normales como best-effort: útil, común, pero nunca garantizado.
¿Por qué sigue en «Discovered – currently not indexed» después de enviar? Ese estado suele significar prioridad de rastreo, no fracaso. Revisa los enlaces internos hacia la página, si robots.txt bloquea la ruta y si la página depende mucho de JavaScript. Luego espera: en sitios nuevos, del descubrimiento al rastreo pueden pasar 1–2 semanas.
¿Bastan 200 URLs al día? Para la mayoría de sitios sí – de todos modos solo deberías enviar URLs realmente modificadas. Si son más con regularidad, prioriza por valor de negocio y solicita un aumento de cuota en Google Cloud Console.
¿Indexing API acelera el ranking? No. Solo notifica a Google que una URL cambió. El ranking es un juicio separado de los sistemas de Google, independiente de cuántas notificaciones envíes.
¿En qué se diferencia del clic de «Solicitar indexación» en Search Console? Misma intención, mecanismo distinto. El botón es pura UI sin API pública; Indexing API es el canal scriptable. Ninguno anula el juicio de Google sobre si una página debe estar en el índice.
Autor: Julian Mercer, practicante de SEO técnico en Auspia con 14 años de experiencia. Escribe sobre rastreabilidad, indexación, schema y la base técnica que hace un sitio legible tanto para Google como para los sistemas de IA.
