O DeepSeek Harness (dsh) executa agentes que fazem trabalho real – e poucas tarefas de SEO se encaixam melhor do que o pipeline de URLs não indexadas: ler a lista, inspecionar cada URL, classificar, aguardar aprovação, enviar, verificar. Cada etapa é um comando ou um arquivo, exatamente o terreno dos agentes de harness.
Duas perguntas decidem sua configuração. Você quer um lote único scriptável e colocável em cron? Vá de headless. Quer vê-lo funcionando, responder às perguntas dele e aprovar lote a lote no chat? Use o Web UI. Este guia mostra os dois caminhos; o pipeline por baixo é o mesmo para ambos. Para a explicação profunda dos dois status (incluindo por que o Google rastreia algumas páginas e outras não), tratamos dela em detalhe na versão Hermes Agent deste fluxo. Aqui focamos na execução com o dsh.
Escolher seu caminho
Lote único headless | Web UI + programação | |
|---|---|---|
Ideal para | Lotes scriptados, cron, execução estilo CI, testes | Triagem interativa, primeiro setup, aprender os julgamentos do agente |
Início |
|
|
Aprovação | Lista pré-aprovada em um arquivo; se as regras exigirem humano, o agente pergunta com sua ferramenta de perguntas | Pergunta ao vivo no chat, você aprova lote a lote |
Programação | cron (ou a ferramenta de programação do dsh se seu perfil carregar o plugin Schedule) | Igual, mas cada execução é visível |
Saída | Arquivos de relatório na pasta do projeto | Arquivos de relatório mais a transcrição do chat |
Lotes com headless, primeiro setup com Web UI. O pipeline abaixo é o mesmo.
Os dois caminhos compartilham uma regra: o passo de escrita (o envio ao Google) fica atrás de um portão de aprovação humana. No modo headless isso significa que você revisa os arquivos gerados pelo agente antes de deixá-lo executar os comandos de envio. No modo web você aprova no chat.
O que você obtém
Uma pasta de projeto indexing/ com: inventário de URLs, listas classificadas (to-submit.txt, skip.txt, needs-fix.txt), fila de envio aprovada e registros de execução. A cada execução o dsh produz um relatório breve: quantas enviadas, quantas omitidas e por quê, o que mudou desde a última vez. Primeiro setup 60–90 minutos (sobretudo as credenciais do Google), execução semanal 15 minutos.
Antes de começar
- dsh instalado e configurado. Atualize com
npx @deepseek-ai/dsh@latest webse precisar. Sua chave de API e configurações ficam em~/.dsh/(profiles, sessions,settings.yaml);dsh webinicia ou uma tarefa headless tem sucesso = instalação confirmada. - Uma propriedade GSC da qual você é proprietário, no formato
sc-domain:example.com. - Credenciais de leitura: cliente OAuth para Search Console API (client ID + segredo).
- Credenciais de escrita: projeto Google Cloud com Indexing API ativada, chave JSON de service account, e o e-mail do service account adicionado como proprietário em GSC → Configurações → Usuários e permissões. Um 403 no envio = este passo falhou.
- Duas pastas de scripts GSC no workspace: a skill de leitura (sitemaps, Search Analytics, inspeção de URLs) e a skill de indexação (
index_submit.py). Python 3 epip install google-auth google-api-python-client. - Uma pasta de projeto, por exemplo
~/gsc-indexing-projectcomdata/,scripts/,logs/.
A parte do Google no setup é idêntica para qualquer agente; a documentação da skill gsc-indexing guia você pelo console do Cloud: ativar Indexing API, criar o service account, baixar a chave, adicioná-la como proprietário.
Caminho A: execução headless de um lote
O modo headless é dsh --profile headless "tarefa": uma tarefa, uma resposta, fim. Você coloca o pipeline inteiro em um único prompt, ou o divide em várias execuções enquanto depura.
Primeira execução (a partir da pasta do projeto):
dsh --profile headless "Execute a etapa 1 do pipeline de indexação GSC. Com o script gsc_query.py liste os sitemaps de sc-domain:example.com, extraia todas as URLs com lastmod, deduplique e escreva em data/url-inventory.csv. Informe o total."Uma boa saída: um CSV real com total coerente com o relatório de sitemaps da GSC e nenhuma coluna inventada. Controle de qualidade: abra o arquivo e confira cinco URLs aleatórias. Se o agente relatar erro de autenticação, repita o fluxo OAuth da GSC e tente de novo; o script de leitura precisa de um token fresco.
Etapa 2:
dsh --profile headless "Inspecione as URLs de data/url-inventory.csv via URL Inspection API e divida-as em data/to-submit.txt, data/skip.txt (com um motivo por linha) e data/needs-fix.txt. Inclua apenas URLs com lastmod nos últimos 90 dias."O agente executa os scripts de inspeção em lotes (a API tem limites de frequência por propriedade; cota atual no Google Cloud Console). Revise a divisão: a lista de omitidas deve ser dominada por noindex, desvios de canonical e duplicados. Se needs-fix ficar vazio em um site com milhares de URLs, amplie a janela de entrada.
A etapa 3 é o portão de aprovação – nunca em execução sem supervisão:
dsh --profile headless "Leia data/needs-fix.txt e data/skip.txt. Prepare a fila de correções e envios como tabela: URL, causa presumida (sem links internos, duplicado, canonical, noindex, fraco, soft 404), evidência, ação sugerida, nível de risco. Não envie nada."Revise a tabela no relatório, reduza data/to-submit.txt às URLs que você aprova e execute a etapa 4:
dsh --profile headless "Envie as URLs de data/approved-urls.txt com o script de indexação (index_submit.py submit --urls-file data/approved-urls.txt). Execute check-auth primeiro. Registre cada resultado em logs/submissions.log."Saída esperada: uma linha de resultado de notificação por URL, sem 403. Recuperação: 403 significa que o service account não é proprietário da propriedade; 429 significa que você atingiu a cota de 200/dia ou 600/minuto – distribua a lista por dias. Se a execução morrer no meio, retome com dsh --profile headless --resume <session>.
Caminho B: Web UI e programação semanal
dsh web abre a interface do navegador em 127.0.0.1:3080. Mesmas etapas, mas por chat e interativas: o agente pede confirmação das listas de classificação e de novo antes de cada comando de envio. Esse fluxo de aprovação ao vivo é a principal razão para escolher este caminho no primeiro setup: você vê o que o agente vai fazer com sua propriedade do Google antes de ele fazer.
Quando o pipeline estiver rodando, adicione o ritmo. O plugin Schedule do dsh registra schedule_create e repete tarefas com um temporizador dentro da sessão ao 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."
Se seu perfil não carregar o plugin Schedule, uma linha cron em volta do comando headless dá o mesmo resultado:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Execute a revisão semanal de indexação GSC e prepare a fila de envio." >> logs/weekly.log 2>&1
A programação roda as três primeiras estações; o envio fica no portão humano.
Não coloque o passo de envio na programação. A revisão semanal, a classificação e a preparação da fila podem rodar sem supervisão; o envio espera uma pessoa.
As regras de triagem que o agente aplica
A classificação e a fila dependem de uma tabela pequena. Coloque-a na pasta do projeto para que cada execução use as mesmas regras:
Causa | Correção | Enviar após corrigir? |
|---|---|---|
Nenhum link interno | Adicionar links contextuais a partir de páginas indexadas | Sim |
Página totalmente nova | Nada a corrigir; enviar uma vez e aguardar 1–2 semanas | Sim, uma vez |
Bloqueada por robots.txt | Levantar o bloqueio de caminho | Sim |
Conteúdo duplicado ou fraco | Reescrever, mesclar ou excluir | Só após uma mudança real |
canonical aponta para outro lugar | Corrigir se for erro; intencional: abandonar a URL | Só após corrigir |
noindex no momento do rastreamento | Remover o noindex | Sim, após remover |
Soft 404, arquivos, facets sem valor | Corrigir ou excluir; omissão permanente | Não |
A leitura profunda dos dois status (incluindo por que o Google rastreia algumas páginas e outras não) está no guia Hermes Agent. As causas são as mesmas, não importa qual harness execute o pipeline.
Verificar, depois aguardar
Após cada lote, confira a notificação com status: isso só prova que o Google tem metadados da URL, não que a página esteja indexada. Reinspecione as URLs enviadas 3–7 dias depois e compare os status. Um padrão saudável é discovered → crawled → indexed em 1–2 semanas. Os dados da GSC chegam com dias de atraso e o Google re-rastreia conforme seu próprio calendário – uma URL que permanece em «Crawled – currently not indexed» 10–14 dias após correções reais é um veredito de qualidade de conteúdo, não um problema de envio. O arquivo de registro torna isso visível: data, URL, tipo de notificação, status de inspeção na próxima execução. Essa é a métrica: a lista de não indexadas encolhendo com o tempo – não o número de notificações.
Limites honestos
- A Indexing API é documentada oficialmente para páginas
JobPostingeBroadcastEvent. Enviar páginas normais é prática comum, mas o Google não oferece garantias nem promessas de suporte por tipo de página. - O botão «Solicitar indexação» do Search Console não tem API pública. Indexing API é o canal scriptável mais próximo, não um clone do botão.
- A automação não cria prioridade. Se uma página continuar sem indexação após corrigir e enviar, o próximo passo é trabalho de conteúdo – não outra execução programada.
Perguntas frequentes
Posso rodar só em headless, sem o Web UI? Sim. dsh --profile headless "tarefa" executa uma tarefa e termina. As credenciais continuam em ~/.dsh/ e os scripts de leitura funcionam igual. Verifique o pipeline de ponta a ponta uma vez no Web UI antes de scriptá-lo.
Se uma execução morre, perco o trabalho? Não. Retome com dsh --profile headless --resume <session> e rode o script de envio de novo; ele deduplica URLs, então reenviar URLs já notificadas do mesmo lote é inofensivo.
Gerencio várias propriedades GSC. Preciso refazer tudo por site? Os scripts aceitam um argumento --site sc-domain:..., então um único workspace pode conter inventários e registros de várias propriedades. Mantenha um arquivo de fila aprovada e um comando de envio por propriedade; um erro de cota em um site não bloqueia os outros.
Autora: Camille Rhodes, arquiteta de mais de 300 fluxos de conteúdo de IA na Auspia. Escreve sobre automação de conteúdo, sistemas de publicação e fluxos que transformam agentes de IA em operações de crescimento confiáveis.
