DeepSeek Harness (dsh) ejecuta agentes que hacen trabajo real – y pocas tareas SEO encajan mejor que el pipeline de URLs no indexadas: leer la lista, inspeccionar cada URL, clasificar, esperar aprobación, enviar, verificar. Cada etapa es un comando o un archivo, exactamente el terreno de los agentes de harness.
Dos preguntas deciden tu configuración. ¿Quieres un lote único scriptable y metible en cron? Ve con headless. ¿Quieres verlo funcionar, responder sus preguntas y aprobar lote por lote en el chat? Usa el Web UI. Esta guía muestra ambos caminos; el pipeline subyacente es el mismo para los dos. Para la explicación profunda de los dos estados (incluido por qué Google rastrea algunas páginas y otras no), la tratamos en detalle en la versión Hermes Agent de este flujo. Aquí nos centramos en la ejecución con dsh.
Elegir tu camino
Lote único headless | Web UI + programación | |
|---|---|---|
Ideal para | Lotes scriptados, cron, ejecución estilo CI, pruebas | Triaje interactivo, primer setup, aprender los juicios del agente |
Inicio |
|
|
Aprobación | Lista preaprobada en un archivo; si las reglas requieren humano, el agente pregunta con su herramienta de preguntas | Pregunta en el chat en línea, aprueba lote por lote |
Programación | cron (o la herramienta de programación de dsh si tu perfil carga el plugin Schedule) | Igual, pero cada ejecución es visible |
Salida | Archivos de informe en la carpeta del proyecto | Archivos de informe más la transcripción del chat |
Lotes con headless, primer setup con Web UI. El pipeline de abajo es el mismo.
Ambos caminos comparten una regla: el paso de escritura (el envío a Google) queda detrás de una compuerta de aprobación humana. En modo headless eso significa que revisas los archivos generados por el agente antes de dejarle ejecutar los comandos de envío. En modo web apruebas en el chat.
Lo que obtienes
Una carpeta de proyecto indexing/ con: inventario de URLs, listas clasificadas (to-submit.txt, skip.txt, needs-fix.txt), cola de envío aprobada y registros de ejecución. En cada ejecución dsh produce un informe breve: cuántas enviadas, cuántas omitidas y por qué, qué cambió desde la última vez. Primer setup 60–90 minutos (sobre todo credenciales de Google), ejecución semanal 15 minutos.
Antes de empezar
- dsh instalado y configurado. Actualiza con
npx @deepseek-ai/dsh@latest websi hace falta. Tu clave API y ajustes están en~/.dsh/(profiles, sessions,settings.yaml);dsh webarranca o una tarea headless tiene éxito = instalación confirmada. - Una propiedad GSC de la que seas propietario, en formato
sc-domain:example.com. - Credenciales de lectura: cliente OAuth para Search Console API (ID de cliente + secreto).
- Credenciales de escritura: proyecto de Google Cloud con Indexing API activada, clave JSON de cuenta de servicio, y el email de la cuenta de servicio añadido como propietario en GSC → Configuración → Usuarios y permisos. Un 403 al enviar = este paso falló.
- Dos carpetas de scripts GSC en el workspace: el skill de lectura (sitemaps, Search Analytics, inspección de URLs) y el skill de indexación (
index_submit.py). Python 3 ypip install google-auth google-api-python-client. - Una carpeta de proyecto, por ejemplo
~/gsc-indexing-projectcondata/,scripts/,logs/.
La parte de Google del setup es idéntica para cualquier agente; la documentación del skill gsc-indexing te guía por la consola de Cloud: activar Indexing API, crear la cuenta de servicio, descargar la clave, añadirla como propietario.
Camino A: ejecución headless de un lote
El modo headless es dsh --profile headless "tarea": una tarea, una respuesta, fin. Metes todo el pipeline en un solo prompt, o lo divides en varias ejecuciones mientras depuras.
Primera ejecución (desde la carpeta del proyecto):
dsh --profile headless "Ejecuta la etapa 1 del pipeline de indexación GSC. Con el script gsc_query.py lista los sitemaps de sc-domain:example.com, extrae todas las URLs con lastmod, deduplica y escribe en data/url-inventory.csv. Informa del total."Una buena salida: un CSV real con un total coherente con el informe de sitemaps de la GSC y sin columnas inventadas. Control de calidad: abre el archivo y revisa cinco URLs al azar. Si el agente informa de un error de autenticación, repite el flujo OAuth de la GSC e intenta de nuevo; el script de lectura necesita un token fresco.
Etapa 2:
dsh --profile headless "Inspecciona las URLs de data/url-inventory.csv vía URL Inspection API y divídelas en data/to-submit.txt, data/skip.txt (con una razón por línea) y data/needs-fix.txt. Incluye solo URLs con lastmod en los últimos 90 días."El agente ejecuta los scripts de inspección por lotes (la API tiene límites de tasa por propiedad; cuota actual en Google Cloud Console). Revisa la división: la lista de omitidas debe estar dominada por noindex, desviaciones de canonical y duplicados. Si needs-fix queda vacío en un sitio con miles de URLs, amplía la ventana de entrada.
La etapa 3 es la compuerta de aprobación – nunca en ejecución sin supervisión:
dsh --profile headless "Lee data/needs-fix.txt y data/skip.txt. Prepara la cola de correcciones y envíos como tabla: URL, causa presunta (sin enlaces internos, duplicado, canonical, noindex, pobre, soft 404), evidencia, acción sugerida, nivel de riesgo. No envíes nada."Revisa la tabla en el informe, recorta data/to-submit.txt a las URLs que apruebas y ejecuta la etapa 4:
dsh --profile headless "Envía las URLs de data/approved-urls.txt con el script de indexación (index_submit.py submit --urls-file data/approved-urls.txt). Ejecuta primero check-auth. Registra cada resultado en logs/submissions.log."Salida esperada: una línea de resultado de notificación por URL, sin 403. Recuperación: 403 significa que la cuenta de servicio no es propietaria de la propiedad; 429 significa que alcanzaste la cuota de 200/día o 600/minuto – reparte la lista por días. Si la ejecución muere en medio, retoma con dsh --profile headless --resume <session>.
Camino B: Web UI y programación semanal
dsh web abre la interfaz de navegador en 127.0.0.1:3080. Mismas etapas, pero por chat e interactivas: el agente pide confirmación de las listas de clasificación y otra vez antes de cada comando de envío. Este flujo de aprobación en vivo es la razón principal para elegir este camino en el primer setup: ves lo que el agente va a hacer con tu propiedad de Google antes de que lo haga.
Cuando el pipeline ruede, añade el ritmo. El plugin Schedule de dsh registra schedule_create y repite tareas con un temporizador dentro de la sesión en vivo:
schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."
Si tu perfil no carga el plugin Schedule, una línea cron alrededor del comando headless da el mismo resultado:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Ejecuta la revisión semanal de indexación GSC y prepara la cola de envío." >> logs/weekly.log 2>&1
La programación corre las tres primeras estaciones; el envío queda en la compuerta humana.
No metas el paso de envío en la programación. La revisión semanal, la clasificación y la preparación de la cola pueden correr sin supervisión; el envío espera a una persona.
Las reglas de triaje que aplica el agente
La clasificación y la cola dependen de una tabla pequeña. Ponla en la carpeta del proyecto para que cada ejecución use las mismas reglas:
Causa | Corrección | ¿Enviar tras corregir? |
|---|---|---|
Ningún enlace interno | Añadir enlaces contextuales desde páginas indexadas | Sí |
Página totalmente nueva | Nada que corregir; enviar una vez y esperar 1–2 semanas | Sí, una vez |
Bloqueada por robots.txt | Levantar el bloqueo de ruta | Sí |
Contenido duplicado o pobre | Reescribir, fusionar o eliminar | Solo tras un cambio real |
canonical apunta a otro lado | Corregir si es error; intencional: abandonar la URL | Solo tras corregir |
noindex al momento del rastreo | Quitar el noindex | Sí, tras quitarlo |
Soft 404, archivos, facetas sin valor | Corregir o eliminar; omitir permanentemente | No |
La lectura profunda de los dos estados (incluido por qué Google rastrea algunas páginas y otras no) está en la guía Hermes Agent. Las causas son las mismas, dé quien dé el pipeline.
Verificar y esperar
Tras cada lote, comprueba la notificación con status: solo prueba que Google tiene metadatos de la URL, no que la página esté indexada. Reinspecciona las URLs enviadas 3–7 días después y compara los estados. Un patrón sano es discovered → crawled → indexed en 1–2 semanas. Los datos de la GSC van con días de retraso y Google re-rastrea según su calendario – una URL que sigue en «Crawled – currently not indexed» 10–14 días después de correcciones reales es un veredicto de calidad de contenido, no un problema de envío. El archivo de registro lo hace visible: fecha, URL, tipo de notificación, estado de inspección en la siguiente ejecución. Esa es la métrica: la lista de no indexadas encogiéndose con el tiempo – no el número de notificaciones.
Límites honestos
- Indexing API está oficialmente documentada para páginas
JobPostingyBroadcastEvent. Enviar páginas normales es práctica común, pero Google no da garantías ni promesas de soporte por tipo de página. - El botón «Solicitar indexación» de Search Console no tiene API pública. Indexing API es el canal scriptable más cercano, no un clon del botón.
- La automatización no crea prioridad. Si una página sigue sin indexarse tras corregir y enviar, el siguiente paso es trabajo de contenido – no otra ejecución programada.
Preguntas frecuentes
¿Puedo correr solo en headless, sin el Web UI? Sí. dsh --profile headless "tarea" ejecuta una tarea y termina. Las credenciales siguen en ~/.dsh/ y los scripts de lectura funcionan igual. Verifica el pipeline de punta a punta una vez en el Web UI antes de scriptarlo.
Si una ejecución muere, ¿pierdo el trabajo? No. Retoma con dsh --profile headless --resume <session> y vuelve a ejecutar el script de envío; deduplica URLs, así que reenviar URLs ya notificadas del mismo lote es inofensivo.
Gestiono varias propiedades GSC. ¿Tengo que rehacerlo por sitio? Los scripts aceptan un argumento --site sc-domain:..., así que un workspace puede contener inventarios y registros de varias propiedades. Mantén un archivo de cola aprobada y un comando de envío por propiedad; un error de cuota en un sitio no bloquea a los demás.
Autora: Camille Rhodes, arquitecta de más de 300 flujos de contenido IA en Auspia. Escribe sobre automatización de contenido, sistemas de publicación y flujos que convierten agentes IA en operaciones de crecimiento fiables.
