DeepSeek Harness (dsh) exécute des agents qui font du vrai travail – et peu de tâches SEO conviennent mieux que le pipeline des URLs non indexées : lire la liste, inspecter chaque URL, classer, attendre l'approbation, soumettre, vérifier. Chaque étape est une commande ou un fichier, exactement le terrain des agents harness.
Deux questions décident du montage. Vous voulez un lot unique scriptable et plaçable dans cron ? Allez en headless. Vous voulez regarder tourner, répondre aux questions et approuver lot par lot dans le chat ? Utilisez le Web UI. Ce guide montre les deux chemins ; le pipeline en dessous est identique. Pour l'explication approfondie des deux statuts (y compris pourquoi Google crawle certaines pages et pas d'autres), nous l'avons traitée en détail dans la version Hermes Agent de ce workflow. Ici, nous nous concentrons sur l'exécution avec dsh.
Choisir votre chemin
Lot unique headless | Web UI + planification | |
|---|---|---|
Idéal pour | Lots scriptés, cron, exécution type CI, tests | Tri interactif, premier paramétrage, apprendre les jugements de l'agent |
Démarrage |
|
|
Approbation | Liste pré-approuvée dans un fichier ; si les règles exigent un humain, l'agent demande via son outil de question | Demande en direct dans le chat, approbation lot par lot |
Planification | cron (ou l'outil de planification de dsh si votre profil charge le plugin Schedule) | Pareil, mais chaque exécution est visible |
Sortie | Fichiers de rapport dans le dossier de projet | Fichiers de rapport plus la transcription du chat |
Les lots en headless, le premier paramétrage en Web UI. Le pipeline en dessous est le même.
Les deux chemins partagent une règle : l'étape d'écriture (la soumission à Google) reste derrière un sas d'approbation humaine. En mode headless, cela signifie que vous examinez les fichiers produits par l'agent avant de le laisser exécuter les commandes de soumission. En mode web, vous approuvez dans le chat.
Ce que vous obtenez
Un dossier de projet indexing/ avec : l'inventaire des URLs, les listes classées (to-submit.txt, skip.txt, needs-fix.txt), la file de soumission approuvée et les journaux d'exécution. À chaque exécution, dsh produit un court rapport : combien soumises, combien exclues et pourquoi, ce qui a changé depuis la dernière fois. Premier paramétrage 60–90 minutes (surtout les identifiants Google), exécution hebdomadaire 15 minutes.
Avant de commencer
- dsh installé et configuré. Mettez à jour avec
npx @deepseek-ai/dsh@latest websi besoin. Votre clé API et vos réglages sont dans~/.dsh/(profiles, sessions,settings.yaml) ;dsh webdémarre ou une tâche headless réussit = installation confirmée. - Une propriété GSC dont vous êtes propriétaire, au format
sc-domain:example.com. - Identifiants de lecture : client OAuth pour l'API Search Console (ID client + secret).
- Identifiants d'écriture : projet Google Cloud avec l'API Indexing activée, clé JSON de compte de service, et l'e-mail du compte de service ajouté comme propriétaire dans GSC → Paramètres → Utilisateurs et autorisations. Un 403 à la soumission = cette étape a échoué.
- Deux dossiers de scripts GSC dans l'espace de travail : la compétence de lecture (sitemaps, analytics de recherche, inspection d'URL) et la compétence d'indexation (
index_submit.py). Python 3 etpip install google-auth google-api-python-client. - Un dossier de projet, par exemple
~/gsc-indexing-projectavecdata/,scripts/,logs/.
La partie Google du paramétrage est identique pour n'importe quel agent ; la doc de la compétence gsc-indexing vous guide dans la console Cloud : activer l'API Indexing, créer le compte de service, télécharger la clé, l'ajouter comme propriétaire.
Chemin A : exécution headless en un lot
Le mode headless est dsh --profile headless "tâche" : une tâche, une réponse, fin. Vous mettez tout le pipeline dans un seul prompt, ou vous le découpez en plusieurs exécutions pour débugger.
Première exécution (depuis le dossier de projet) :
dsh --profile headless "Exécute l'étape 1 du pipeline d'indexation GSC. Avec le script gsc_query.py, liste les sitemaps de sc-domain:example.com, récupère toutes les URLs avec leur lastmod, déduplique et écris dans data/url-inventory.csv. Rapporte le total."Une bonne sortie : un vrai CSV avec un total cohérent avec le rapport de sitemaps de la GSC et aucune colonne inventée. Contrôle qualité : ouvrez le fichier et vérifiez cinq URLs au hasard. Si l'agent signale une erreur d'authentification, relancez le flux OAuth GSC et réessayez ; le script de lecture a besoin d'un jeton frais.
Étape 2 :
dsh --profile headless "Inspecte les URLs de data/url-inventory.csv via l'API URL Inspection et répartis-les dans data/to-submit.txt, data/skip.txt (avec une justification par ligne) et data/needs-fix.txt. Ne prends que les URLs avec lastmod dans les 90 derniers jours."L'agent exécute les scripts d'inspection par lots (l'API a des limites de débit par propriété ; quota actuel dans Google Cloud Console). Vérifiez le tri : la liste d'exclusion doit être dominée par des noindex, des déviations de canonical et des doublons. Si needs-fix reste vide pour un site de milliers d'URLs, élargissez la fenêtre d'entrée.
L'étape 3 est le sas d'approbation – jamais exécutée sans surveillance :
dsh --profile headless "Lis data/needs-fix.txt et data/skip.txt. Prépare la file de corrections et de soumissions sous forme de tableau : URL, cause présumée (pas de liens internes, doublon, canonical, noindex, pauvre, soft 404), preuve, action recommandée, niveau de risque. Ne soumets rien."Examinez le tableau dans le rapport, réduisez data/to-submit.txt aux URLs que vous approuvez, puis exécutez l'étape 4 :
dsh --profile headless "Soumets les URLs de data/approved-urls.txt via le script d'indexation (index_submit.py submit --urls-file data/approved-urls.txt). Exécute d'abord check-auth. Consigne chaque résultat dans logs/submissions.log."Sortie attendue : une ligne de résultat de notification par URL, aucun 403. Récupération : 403 signifie que le compte de service n'est pas propriétaire de la propriété ; 429 signifie que vous avez atteint le quota de 200/jour ou 600/minute – étalez la liste sur plusieurs jours. Si l'exécution meurt en route, reprenez avec dsh --profile headless --resume <session>.
Chemin B : Web UI et planification hebdomadaire
dsh web ouvre l'interface navigateur sur 127.0.0.1:3080. Mêmes étapes, mais par le chat et de façon interactive : l'agent demande confirmation des listes de classification et encore une fois avant chaque commande de soumission. Ce flux d'approbation en direct est la raison principale de choisir ce chemin au premier paramétrage : vous voyez ce que l'agent va faire avec votre propriété Google avant qu'il ne le fasse.
Une fois le pipeline rodé, ajoutez le rythme. Le plugin Schedule de dsh enregistre schedule_create et répète les tâches par minuteur dans la session en direct :
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 votre profil ne charge pas le plugin Schedule, une ligne cron autour de la commande headless donne le même résultat :
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Exécute la vérification hebdomadaire d'indexation GSC et prépare la file de soumission." >> logs/weekly.log 2>&1
La planification fait tourner les trois premières stations ; la soumission reste dans le sas humain.
Ne mettez pas l'étape de soumission dans la planification. La vérification hebdomadaire, la classification et la préparation de la file peuvent tourner sans surveillance ; la soumission attend un humain.
Les règles de tri appliquées par l'agent
La classification et la file reposent sur une petite table. Mettez-la dans le dossier de projet pour que chaque exécution utilise les mêmes règles :
Cause | Correction | Soumettre après correction ? |
|---|---|---|
Aucun lien interne | Ajouter des liens contextuels depuis des pages indexées | Oui |
Page toute neuve | Rien à corriger ; soumettre une fois, attendre 1–2 semaines | Oui, une fois |
Bloqué par robots.txt | Lever le blocage de chemin | Oui |
Contenu dupliqué ou pauvre | Réécrire, fusionner ou supprimer | Seulement après un vrai changement |
canonical pointe ailleurs | Corriger si faux ; intentionnel : abandonner l'URL | Seulement après correction |
noindex au moment du crawl | Retirer le noindex | Oui, après retrait |
Soft 404, archives, facettes sans valeur | Corriger ou supprimer ; exclure définitivement | Non |
La lecture approfondie des deux statuts (y compris pourquoi Google crawle certaines pages et pas d'autres) est dans le guide Hermes Agent. Les causes sont les mêmes, quel que soit le harness qui exécute le pipeline.
Vérifier, puis attendre
Après chaque lot, vérifiez la notification avec status : elle ne prouve que la présence de métadonnées chez Google, pas l'indexation de la page. Réinspectez les URLs soumises 3–7 jours plus tard et comparez les statuts. Un schéma sain est discovered → crawled → indexed sur 1–2 semaines. Les données GSC ont quelques jours de latence et Google recrawle selon son propre calendrier – une URL qui reste en « Crawled – currently not indexed » 10–14 jours après de vraies corrections est un verdict de qualité de contenu, pas un problème de soumission. Le fichier journal rend tout cela visible : date, URL, type de notification, statut d'inspection au prochain passage. C'est cela, la mesure : la liste des non-indexées qui rétrécit avec le temps – pas le nombre de notifications.
Limites honnêtes
- L'API Indexing est officiellement documentée pour les pages
JobPostingetBroadcastEvent. Envoyer des pages normales est une pratique courante, mais Google n'offre ni garantie ni promesse de support pour chaque type de page. - Le bouton « Demander l'indexation » de Search Console n'a pas d'API publique. L'API Indexing est le canal scriptable le plus proche, pas un clone du bouton.
- L'automatisation ne crée pas de priorité. Si une page reste non indexée après correction et soumission, la prochaine étape est le travail de contenu – pas un autre passage planifié.
FAQ
Puis-je tourner exclusivement en headless, sans le Web UI ? Oui. dsh --profile headless "tâche" exécute une tâche et se termine. Les identifiants restent dans ~/.dsh/ et les scripts de lecture fonctionnent à l'identique. Vérifiez le pipeline de bout en bout une fois dans le Web UI avant de scriptiser.
Si une exécution meurt, je perds le travail ? Non. Reprenez avec dsh --profile headless --resume <session> puis relancez le script de soumission ; il déduplique les URLs, donc renvoyer des URLs déjà notifiées du même lot est sans danger.
Je gère plusieurs propriétés GSC. Je dois tout refaire par site ? Les scripts acceptent un argument --site sc-domain:..., donc un seul espace de travail peut contenir les inventaires et journaux de plusieurs propriétés. Gardez un fichier de file approuvée et une commande de soumission par propriété ; une erreur de quota sur un site ne bloque pas les autres.
Auteure : Camille Rhodes, architecte de 300+ workflows de contenu IA chez Auspia. Écrit sur l'automatisation de contenu, les systèmes de publication et les workflows qui transforment les agents IA en opérations de croissance fiables.
