DeepSeek Harness (dsh) esegue agenti che fanno lavoro reale – e poche attività SEO si adattano meglio del pipeline delle URLs non indicizzate: leggere l'elenco, ispezionare ogni URL, classificare, attendere l'approvazione, inviare, verificare. Ogni fase è un comando o un file, esattamente il terreno degli agenti harness.
Due domande decidono la tua configurazione. Vuoi un lotto unico scriptabile e mettibile in cron? Vai con headless. Vuoi vederlo girare, rispondere alle sue domande e approvare lotto per lotto nella chat? Usa il Web UI. Questa guida mostra entrambi i percorsi; il pipeline sottostante è lo stesso per entrambi. Per l'analisi approfondita dei due stati (incluso perché Google crawla alcune pagine e altre no), la trattiamo in dettaglio nella versione Hermes Agent di questo flusso. Qui ci concentriamo sull'esecuzione con dsh.
Scegliere il tuo percorso
Lotto unico headless | Web UI + pianificazione | |
|---|---|---|
Ideale per | Lotti scriptati, cron, esecuzioni stile CI, test | Triage interattivo, primo setup, imparare i giudizi dell'agente |
Avvio |
|
|
Approvazione | Elenco pre-approvato in un file; se le regole richiedono un umano, l'agente chiede con il suo strumento di domande | Chiede in diretta nella chat, approvi lotto per lotto |
Pianificazione | cron (o lo strumento di pianificazione di dsh se il tuo profilo carica il plugin Schedule) | Uguale, ma ogni esecuzione è visibile |
Output | File di report nella cartella di progetto | File di report più la trascrizione della chat |
Lotti con headless, primo setup con Web UI. Il pipeline sotto è lo stesso.
Entrambi i percorsi condividono una regola: il passo di scrittura (l'invio a Google) resta dietro un cancello di approvazione umana. In modo headless significa che esamini i file prodotti dall'agente prima di lasciargli eseguire i comandi di invio. In modo web approvi nella chat.
Cosa ottieni
Una cartella di progetto indexing/ con: inventario delle URLs, elenchi classificati (to-submit.txt, skip.txt, needs-fix.txt), coda di invio approvata e registri di esecuzione. A ogni esecuzione dsh produce un breve report: quante inviate, quante escluse e perché, cosa è cambiato dall'ultima volta. Primo setup 60–90 minuti (soprattutto le credenziali Google), esecuzione settimanale 15 minuti.
Prima di iniziare
- dsh installato e configurato. Aggiorna con
npx @deepseek-ai/dsh@latest webse serve. La tua chiave API e le impostazioni sono in~/.dsh/(profiles, sessions,settings.yaml);dsh websi avvia o un'attività headless riesce = installazione confermata. - Una proprietà GSC di cui sei proprietario, nel formato
sc-domain:example.com. - Credenziali di lettura: client OAuth per Search Console API (client ID + segreto).
- Credenziali di scrittura: progetto Google Cloud con Indexing API attivata, chiave JSON di service account, e l'email del service account aggiunta come proprietario in GSC → Impostazioni → Utenti e autorizzazioni. Un 403 all'invio = questo passo è fallito.
- Due cartelle di script GSC nel workspace: la skill di lettura (sitemap, Search Analytics, ispezione URLs) e la skill di indicizzazione (
index_submit.py). Python 3 epip install google-auth google-api-python-client. - Una cartella di progetto, ad esempio
~/gsc-indexing-projectcondata/,scripts/,logs/.
La parte Google del setup è identica per qualsiasi agente; la documentazione della skill gsc-indexing ti guida nella console Cloud: attivare Indexing API, creare il service account, scaricare la chiave, aggiungerla come proprietario.
Percorso A: esecuzione headless di un lotto
Il modo headless è dsh --profile headless "attività": un'attività, una risposta, fine. Mettici l'intero pipeline in un solo prompt, o dividilo in più esecuzioni mentre fai debug.
Prima esecuzione (dalla cartella di progetto):
dsh --profile headless "Esegui la fase 1 del pipeline di indicizzazione GSC. Con lo script gsc_query.py elenca le sitemap di sc-domain:example.com, estrai tutte le URLs con lastmod, deduplica e scrivi in data/url-inventory.csv. Riporta il totale."Un buon output: un CSV reale con un totale coerente con il report sitemap della GSC e nessuna colonna inventata. Controllo qualità: apri il file e verifica cinque URLs a caso. Se l'agente segnala un errore di autenticazione, ripeti il flusso OAuth GSC e riprova; lo script di lettura ha bisogno di un token fresco.
Fase 2:
dsh --profile headless "Ispeziona le URLs di data/url-inventory.csv via URL Inspection API e dividile in data/to-submit.txt, data/skip.txt (con un motivo per riga) e data/needs-fix.txt. Includi solo URLs con lastmod negli ultimi 90 giorni."L'agente esegue gli script di ispezione a lotti (l'API ha limiti di frequenza per proprietà; quota attuale in Google Cloud Console). Controlla la divisione: l'elenco delle escluse deve essere dominato da noindex, deviazioni di canonical e duplicati. Se needs-fix resta vuoto su un sito con migliaia di URLs, allarga la finestra di ingresso.
La fase 3 è il cancello di approvazione – mai eseguita senza supervisione:
dsh --profile headless "Leggi data/needs-fix.txt e data/skip.txt. Prepara la coda di correzioni e invii come tabella: URL, causa presunta (nessun link interno, duplicato, canonical, noindex, scarso, soft 404), evidenza, azione suggerita, livello di rischio. Non inviare nulla."Esamina la tabella nel report, riduci data/to-submit.txt alle URLs che approvi ed esegui la fase 4:
dsh --profile headless "Invia le URLs di data/approved-urls.txt con lo script di indicizzazione (index_submit.py submit --urls-file data/approved-urls.txt). Esegui prima check-auth. Registra ogni risultato in logs/submissions.log."Output atteso: una riga di risultato della notifica per URL, nessun 403. Recupero: 403 significa che il service account non è proprietario della proprietà; 429 significa che hai raggiunto la quota di 200/giorno o 600/minuto – distribuisci l'elenco su più giorni. Se l'esecuzione muore a metà, riprendi con dsh --profile headless --resume <session>.
Percorso B: Web UI e pianificazione settimanale
dsh web apre l'interfaccia browser su 127.0.0.1:3080. Stesse fasi, ma via chat e interattive: l'agente chiede conferma degli elenchi di classificazione e di nuovo prima di ogni comando di invio. Questo flusso di approvazione in diretta è la ragione principale per scegliere questo percorso nel primo setup: vedi cosa l'agente farà con la tua proprietà Google prima che lo faccia.
Quando il pipeline gira, aggiungi il ritmo. Il plugin Schedule di dsh registra schedule_create e ripete le attività con un timer dentro la sessione in diretta:
schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."
Se il tuo profilo non carica il plugin Schedule, una riga cron attorno al comando headless dà lo stesso risultato:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Esegui la revisione settimanale di indicizzazione GSC e prepara la coda di invio." >> logs/weekly.log 2>&1
La pianificazione fa girare le prime tre stazioni; l'invio resta nel cancello umano.
Non mettere il passo di invio nella pianificazione. La revisione settimanale, la classificazione e la preparazione della coda possono girare senza supervisione; l'invio aspetta una persona.
Le regole di triage che applica l'agente
La classificazione e la coda dipendono da una piccola tabella. Mettila nella cartella di progetto così ogni esecuzione usa le stesse regole:
Causa | Correzione | Inviare dopo la correzione? |
|---|---|---|
Nessun link interno | Aggiungere link contestuali da pagine indicizzate | Sì |
Pagina completamente nuova | Niente da correggere; inviare una volta e aspettare 1–2 settimane | Sì, una volta |
Bloccata da robots.txt | Rimuovere il blocco di percorso | Sì |
Contenuto duplicato o scarso | Riscrivere, unire o eliminare | Solo dopo un vero cambiamento |
canonical punta altrove | Correggere se sbagliato; intenzionale: abbandonare l'URL | Solo dopo la correzione |
noindex al momento del crawl | Rimuovere il noindex | Sì, dopo la rimozione |
Soft 404, archivi, facet senza valore | Correggere o eliminare; esclusione permanente | No |
L'analisi approfondita dei due stati (incluso perché Google crawla alcune pagine e altre no) è nella guida Hermes Agent. Le cause sono le stesse, a prescindere da quale harness esegue il pipeline.
Verificare, poi aspettare
Dopo ogni lotto, controlla la notifica con status: prova solo che Google ha metadati dell'URL, non che la pagina sia indicizzata. Re-ispeziona le URLs inviate 3–7 giorni dopo e confronta gli stati. Un modello sano è discovered → crawled → indexed in 1–2 settimane. I dati GSC hanno giorni di ritardo e Google ricrawla secondo il proprio calendario – un'URL che resta in «Crawled – currently not indexed» 10–14 giorni dopo correzioni reali è un verdetto di qualità del contenuto, non un problema di invio. Il file di registro lo rende visibile: data, URL, tipo di notifica, stato di ispezione alla prossima esecuzione. Questa è la metrica: l'elenco delle non indicizzate che si riduce nel tempo – non il numero di notifiche.
Limiti onesti
- Indexing API è documentata ufficialmente per pagine
JobPostingeBroadcastEvent. Inviare pagine normali è pratica comune, ma Google non offre garanzie né promesse di supporto per tipo di pagina. - Il pulsante «Richiedi indicizzazione» di Search Console non ha un'API pubblica. Indexing API è il canale scriptabile più vicino, non un clone del pulsante.
- L'automazione non crea priorità. Se una pagina resta non indicizzata dopo correzione e invio, il passo successivo è il lavoro di contenuto – non un'altra esecuzione pianificata.
Domande frequenti
Posso girare solo in headless, senza il Web UI? Sì. dsh --profile headless "attività" esegue un'attività e termina. Le credenziali restano in ~/.dsh/ e gli script di lettura funzionano uguale. Verifica il pipeline end-to-end una volta nel Web UI prima di scriptarlo.
Se un'esecuzione muore, perdo il lavoro? No. Riprendi con dsh --profile headless --resume <session> e rilancia lo script di invio; deduplica le URLs, quindi re-inviare URLs già notificate dello stesso lotto è innocuo.
Gestisco più proprietà GSC. Devo rifare tutto per sito? Gli script accettano un argomento --site sc-domain:..., quindi un solo workspace può contenere inventari e registri di più proprietà. Tieni un file di coda approvata e un comando di invio per proprietà; un errore di quota su un sito non blocca gli altri.
Autrice: Camille Rhodes, architetta di oltre 300 flussi di contenuto IA in Auspia. Scrive di automazione dei contenuti, sistemi di pubblicazione e flussi che trasformano gli agenti IA in operazioni di crescita affidabili.
