«Discovered – currently not indexed» e «Crawled – currently not indexed» são as duas linhas mais comuns do relatório «Páginas indexadas» do Search Console – e as piores compreendidas. Parecem uma falha técnica, mas na verdade são uma decisão de prioridade e qualidade que o Google tomou sobre suas páginas. Enviar com mais força não muda nada. Corrigir a causa, sim.
Este guia é um ciclo completo que você pode entregar inteiro ao agente Hermes: extrair a lista de URLs, inspecionar cada página, triar a causa real, aprovar a fila de correções e enviar via Google Indexing API apenas as páginas que merecem ser indexadas. No final você tem um pipeline semanal repetível – não uma sessão de cliques pontual.
O que você obtém
- Um inventário classificado: URLs travadas em «discovered», URLs rastreadas mas não indexadas e URLs que você nunca deveria ter enviado
- Uma lista aprovada para Indexing API e uma lista de omitidas com o motivo
- Uma etapa de verificação que mostra se seus envios realmente funcionaram
O que você precisa: um agente Hermes instalado e funcionando (hermes chat abre uma sessão. Passos de instalação atualizados: documentação oficial em hermes-agent.nousresearch.com/docs), uma propriedade do Search Console da qual você é proprietário e dois conjuntos de credenciais do Google (um para ler a GSC, outro para Indexing API). Primeiro setup cerca de 60–90 minutos, depois cerca de 15 minutos por semana. «Concluído» significa: suas URLs enviadas mostram uma mudança de status real na API de inspeção em até duas semanas – ou você tem provas sólidas do porquê não.
Ler bem os dois status
O Google não está travado no seu site. Ele tomou uma decisão – e o status diz qual.
Status | O que significa de verdade | Causas frequentes | Quando enviar |
|---|---|---|---|
Discovered – currently not indexed | O Google conhece a URL (via sitemap ou links) mas ainda não a rastreou | Prioridade de rastreamento baixa, links internos fracos ou ausentes, pressão no crawl budget em sites grandes, site novo, renderização JS lenta ou pesada, sitemaps que mudam com frequência | Uma vez, depois de melhorar os sinais de prioridade (sobretudo links internos) |
Crawled – currently not indexed | O Google obteve a URL mas decidiu não indexá-la | Conteúdo duplicado ou quase duplicado, conteúdo fraco, canonical para outra URL, noindex no momento do rastreamento, soft 404, julgada de baixo valor | Só se você realmente mudou algo: conteúdo, canonical ou noindex |
Indexed | Está no índice | — | Não enviar |
Excluded | Rastreada e excluída de propósito (noindex, canonical, escolha de duplicado, bloqueio) | — | Não enviar; verifique se a exclusão é intencional |
Em uma frase: envie apenas URLs que você realmente alterou ou que merecem uma segunda olhada. Indexing API é um canal de notificação, não um anulador de rankings. Enviar uma página fraca dez vezes devolve dez vezes o mesmo veredito.
Por que fazer isso com um agente
O botão «Solicitar indexação» da GSC não tem API pública – não existe forma oficial de clicá-lo por script. A automação mais próxima é a Google Indexing API, que aceita notificações de URL diretamente. Um agente agrega valor por três razões:
- O ciclo é mecânico e longo: inventário → inspeção → classificação → correção → envio → verificação. Toda semana.
- Exige trilha de auditoria: você precisa de um arquivo mostrando quais URLs foram enviadas, quando e por quê.
- Exige um portão de aprovação: a parte que escreve no Google precisa ser revisada por um humano. O Hermes é construído exatamente em torno dessa separação – com skills, pastas de projeto e regras de aprovação.
O que você precisa antes de começar
- Agente Hermes instalado. Verifique com
hermes chatantes de continuar. - Uma propriedade GSC da qual você é proprietário. No formato
sc-domain:example.com(não a URL completa). - Acesso de leitura: um cliente OAuth do Google Cloud (client ID + segredo) para Search Console API. Os scripts da skill GSC o usam para sitemaps, Search Analytics e inspeção de URLs.
- Acesso de escrita: um projeto do Google Cloud com Indexing API ativada e uma chave JSON de service account. Adicione o e-mail do service account como proprietário em GSC → Configurações → Usuários e permissões. Se o envio retornar 403, é este o passo que falta.
- Python 3 e
pip install google-auth google-api-python-client. - Uma pasta de projeto. Por exemplo
/hermes-seo-projectcomcontext/,data/,qa/e umapproval-rules.mdque exija que o passo de envio sempre requeira assinatura humana.
Passo 1: construir o inventário de URLs
Copie as duas skills GSC para o diretório de skills do Hermes (~/.hermes/skills): a skill de leitura (sitemaps, Search Analytics, inspeção de URLs) e a skill de indexação (script de envio). Se o harness cataloga skills, você também pode carregá-las com skill_view.
Depois peça ao Hermes em uma sessão de chat, a partir da pasta do projeto:
Liste todos os sitemaps de sc-domain:example.com, extraia cada URL com seu lastmod e escreva-os em data/url-inventory.csv. Marque qualquer sitemap cujo fetch falhe.
O Hermes executa os comandos de sitemap via a ferramenta de terminal e escreve o CSV. Uma boa saída: um CSV deduplicado com URL, lastmod e sitemap de origem. Controle de qualidade: confira cinco linhas aleatórias e compare o total com o relatório de sitemaps da GSC. Se a lista estiver vazia ou a autenticação falhar, repita o fluxo de autenticação GSC; o script de leitura precisa de um token OAuth fresco.
Passo 2: inspecionar e classificar
O agente inspeciona então o inventário em lotes via URL Inspection API e obtém o status de cobertura atual de cada página. Peça a próxima etapa:
Inspecione cada URL de data/url-inventory.csv. Divida-as em três arquivos: data/to-submit.txt (não indexadas e que merecem envio), data/skip.txt (com um motivo por URL) e data/needs-fix.txt (não indexadas e travadas em algo que podemos mudar).
A API de inspeção tem limites de frequência por propriedade (veja a cota atual no Google Cloud Console; vários milhares por dia, mas não infinitos). Em sites grandes, limite esta rodada às URLs com lastmod mais recente – as que você realmente alterou neste trimestre. Controle de qualidade: amostre a lista de omitidas. Ela deve ser dominada por noindex, canonicals que apontam para outra URL e duplicados – não por páginas que importam para você. Se um site com milhares de URLs der um needs-fix vazio, a etapa de inventário provavelmente perdeu páginas. Amplie o escopo de entrada.
Passo 3: triar antes de enviar
O passo que todo mundo pula. Mapeie as URLs travadas para uma causa e uma correção, nesta ordem:
Causa | Correção | Enviar após corrigir? |
|---|---|---|
A página não tem nenhum link interno | Adicionar links contextuais a partir de páginas indexadas | Sim |
Site ou página totalmente novo | Nada a corrigir; enviar uma vez e aguardar 1–2 semanas | Sim, uma única vez |
Bloqueada por robots.txt | Levantar o bloqueio daquele caminho | Sim |
Rastreada mas duplicada ou fraca | Reescrever, mesclar ou excluir | Só após uma mudança real de conteúdo |
canonical aponta para outra URL | Corrigir o canonical se errado; se intencional, parar de enviar esta URL | Só após corrigir |
noindex no momento do rastreamento | Remover o noindex e deixar o Google re-rastrear | Sim, após remover |
Soft 404, paginação/arquivos sem valor | Corrigir a página ou excluí-la | Não — omissão permanente |
Peça ao Hermes para preparar a fila de correções como tabela: URL, causa presumida, evidência (resultado da inspeção ou revisão de conteúdo), ação sugerida, nível de risco. Aprove cada linha no chat. Seu approval-rules.md deve exigir isso: o agente prepara, você aprova, e nada acima de risco baixo é enviado sem assinatura.

O portão de aprovação separa a preparação do agente do passo de escrita.
As correções em si são trabalho SEO normal: reescrever conteúdo, limpar canonicals, links internos. Este pipeline cobre a metade do envio. A metade da correção é coberta pelos artigos de auditoria e atualização da série Hermes.

A lista de envio é a interseção de «corrigível» e «digna de indexação».
Passo 4: enviar via Indexing API
Quando a fila estiver aprovada, coloque as URLs em data/approved-urls.txt e deixe o Hermes executar a skill de indexação:
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.txtO tipo de notificação padrão é URL_UPDATED, feito para páginas novas ou modificadas. Três números para lembrar: a cota padrão é 200 URLs por dia, 600 solicitações por minuto – e 403 significa que o service account não é proprietário da propriedade. Se a lista aprovada passar de 200, distribua em vários dias; o Hermes pode planejar os lotes restantes.
Nunca envie páginas já indexadas nem a lista de omitidas. Notificações desperdiçadas só queimam cota e criam ruído.
Passo 5: verificar e aguardar
O status logo após o envio só diz se o Google tem metadados da notificação – não se a página está indexada. A confirmação real chega dias depois.
3–7 dias após o lote, peça ao Hermes:
Reinspecione as URLs de data/approved-urls.txt e relate as mudanças de status em relação à última execução.
Uma progressão saudável é discovered → crawled → indexed. É assim que parece ao longo das semanas: a lista de não indexadas encolhe e suas correções reais (novos links internos, textos reescritos) aparecem no índice. Lembre-se: os dados da GSC chegam com dias de atraso e o Google re-rastreia de acordo com seu próprio calendário. Uma URL que permanece em «Crawled – currently not indexed» 10–14 dias após correções reais é um sinal de qualidade, não um problema de envio – escale-a para o trabalho de conteúdo.
Manter o ciclo funcionando
Transforme o pipeline em uma rotina semanal: URLs novas ou atualizadas desde a última execução → inspeção → classificação → triagem → aprovação → envio → registro. O Hermes pode executar a parte somente leitura (inventário, inspeção, classificação) sem supervisão, em um calendário, e apresentar a fila a você toda segunda-feira. O passo de envio fica atrás do portão de aprovação, com um registro contínuo em qa/indexing-log.md: data de envio, URL, tipo de notificação, resultado. Seis meses de registro são a única medida honesta de se o pipeline funciona.
Limites honestos
- O Google documenta a Indexing API para páginas com dados estruturados
JobPostingouBroadcastEvent. Usá-la em páginas normais é prática SEO difundida, mas o Google não garante indexação nem suporte para nenhum tipo de página. - O botão «Solicitar indexação» não tem API pública. Indexing API é a automação mais próxima, não o mesmo botão.
- Enviar não cria prioridade. Se uma página continuar sem ser indexada após corrigir, enviar e aguardar, a próxima resposta é a qualidade do conteúdo – não outra notificação.
Perguntas frequentes
A Indexing API funciona com páginas normais? Aceita qualquer URL que você enviar. A documentação oficial do Google mira páginas JobPosting e BroadcastEvent, então trate envios de páginas normais como best-effort: útil, comum, mas nunca garantido.
Por que continua em «Discovered – currently not indexed» depois do envio? Esse status normalmente significa prioridade de rastreamento, não fracasso. Verifique os links internos para a página, se o robots.txt bloqueia o caminho e se a página depende muito de JavaScript. Depois espere: em sites novos, do descobrimento ao rastreamento podem passar 1–2 semanas.
200 URLs por dia bastam? Para a maioria dos sites, sim – de qualquer forma você só deve enviar URLs realmente modificadas. Se tiver mais regularmente, priorize por valor de negócio e solicite aumento de cota no Google Cloud Console.
A Indexing API acelera o ranking? Não. Ela apenas notifica o Google de que uma URL mudou. O ranking é um julgamento separado dos sistemas do Google, independente de quantas notificações você enviar.
Em que difere do clique em «Solicitar indexação» no Search Console? Mesma intenção, mecanismo diferente. O botão é pura UI sem API pública; Indexing API é o canal scriptável. Nenhum dos dois anula o julgamento do Google sobre se uma página deve estar no índice.
Autor: Julian Mercer, praticante de SEO técnico na Auspia com 14 anos de experiência. Escreve sobre rastreabilidade, indexação, schema e as bases técnicas que tornam um site legível tanto para o Google quanto para os sistemas de IA.












