A Mentira do HTTP 200 na Google Indexing API: Testamos o Script do GitHub em 70 URLs Reais e Construímos o Auditor Verdadeiro em Python
Se você pesquisar google indexing api python no GitHub, encontrará dezenas de repositórios prometendo indexar até 200 páginas por dia em minutos. Você configura a service_account.json, roda o script, o terminal imprime HTTP 200 OK — URL_UPDATED para todas as páginas e você comemora. Só tem um problema: para artigos editoriais, esse HTTP 200 é um falso verde silencioso.
• Respostas
HTTP 200 OK recebidas na Indexing API (urlNotifications:publish): 70 de 70 (100%)• Páginas realmente indexadas (
verdict: PASS) quando auditadas via urlInspection/index:inspect: 15 na Torre 1 e 4 na Torre 2• Páginas com status
Detectada, mas não indexada no momento (NEUTRAL): 55 URLs
1. Por Que a Indexing API Devolve 200 OK e Ignora Seu Artigo?
A documentação oficial da Google Indexing API especifica que o endpoint https://indexing.googleapis.com/v3/urlNotifications:publish aceita apenas páginas com dados estruturados do tipo JobPosting (vagas de emprego) ou BroadcastEvent (transmissões ao vivo em vídeo). Porém, a armadilha técnica que engana 99% dos desenvolvedores no GitHub é o comportamento da API:
- A validação de autenticação OAuth2 e formato da requisição ocorre de forma síncrona e devolve
HTTP 200 OKcom o metadadolatestUpdate. - O descarte por ausência de schema
JobPosting/BroadcastEventocorre de forma assíncrona na fila interna do Googlebot, sem gerar nenhum erro ou webhook de rejeição!
2. A Solução Real: Reaproveitando a Mesma service_account.json na URL Inspection API v1
Aquela mesma credencial google_service_account.json que você adicionou como proprietária/usuária no Google Search Console serve para consultar a API que realmente diz a verdade: a URL Inspection API (/v1/urlInspection/index:inspect) combinada com a Search Analytics API.
3. 🛠️ Simulador Interativo: Decodificador de Vereditos da URL Inspection API
Teste abaixo os três estados reais retornados pela API oficial do Google Search Console e veja a ação técnica recomendada pela nossa fábrica para cada caso:
🔍 Analisador de Estado de Indexação (`indexStatusResult`)
4. O Que Realmente Acelera a Indexação de um Domínio Novo (Medido na Torre 2)
Na Torre 2 (realmakeia.com), conseguimos indexar 4 das 5 páginas iniciais em menos de 72 horas sem depender da Indexing API falsa, aplicando três práticas mecânicas:
- Submissão programática do
sitemap.xmlvia API oficial de Sitemaps (PUT /webmasters/v3/sites/{siteUrl}/sitemaps/{feedpath}) sempre que uma URL nova entra no ar. - Malha interna sem páginas órfãs + Cache Edge HTML (`HIT` em <50ms): Quando o Googlebot visita a Home (
/), encontra links diretos HTML (sem depender de JS client-side) e recebe a resposta direto da borda da Cloudflare sem fila de banco de dados. - Tráfego externo com sinais reais de engajamento (GitHub + Redes): Nossos repositórios no GitHub geraram 220 clones e visitas diretas para os artigos técnicos, sinalizando utilidade real ao rastreador.
4. Os 3 Estados Reais da URL Inspection API (Como Ler o Movimento do Googlebot)
Quando você substitui o disparo cego da Indexing API pela leitura diária via urlInspection.index:inspect, você passa a enxergar a verdadeira máquina de estados do Googlebot. Em nossa vigília automatizada sobre as 70 URLs monitoradas, comprovamos que toda página nova atravessa exatamente três estágios sequenciais:
- Estágio 1 — "O Google não reconhece o URL" (
URL is unknown to Google): Ocorre imediatamente após a publicação. Mesmo que o sitemap já tenha sido enviado comHTTP 204, o agendador de rastreamento ainda não alocou fila para processar os novos nós. - Estágio 2 — "Detectada, mas não indexada no momento" ou "Rastreada, mas não indexada" (
NEUTRAL): Este é o ponto de virada que a maioria dos operadores interpreta erroneamente como defeito. Na realidade, sair do Estágio 1 para o Estágio 2 significa que o Googlebot já baixou e digeriu o sitemap e o HTML da página. Em nosso experimento de campo, vimos um lote inteiro de 15 páginas saltar simultaneamente do Estágio 1 para o Estágio 2 exatamente 72 horas após a densificação da malha de links internos. - Estágio 3 — "Enviada e indexada" (
PASS / SUBMITTED_AND_INDEXED): A página superou o filtro de qualidade e similaridade semântica (Jaccard) e já está apta a gerar impressões orgânicas na SERP.
5. A Divergência Entre o Agregado do Painel e a Inspeção Individual por URL
Uma descoberta técnica fundamental para quem constrói dashboards de SEO em Python: o número total de páginas indexadas exibido no gráfico agregado do painel web do Search Console (relatório Páginas) e o somatório de URLs com verdict: PASS retornado pela API urlInspection não atualizam no mesmo segundo.
Em nossas medições de laboratório, o relatório agregado chegou a registrar 21 páginas indexadas enquanto a inspeção individual URL a URL apontava 15 páginas com status PASS no mesmo dia. Os dois números são legítimos e convivem: o relatório agregado reflete o lote de índice mais recente do datacenter, enquanto o endpoint index:inspect consulta o cache detalhado por URL para permitir diagnóstico de canônica e último rastreamento.
6. Como Limpar Sitemaps Fantasmas (Era WordPress) via API REST
Outro problema silencioso que trava a indexação de domínios recém-migrados para arquiteturas estáticas (como Cloudflare Pages) é a permanência de sitemaps antigos registrados no Search Console — como o clássico sitemap_index.xml gerado por plugins de WordPress. Quando esse arquivo deixa de existir e passa a retornar HTTP 404, o Google mantém URLs legadas (com prefixos http:// ou www.) na fila de diagnóstico, gerando falsos alertas de "Página com redirecionamento" ou "Página alternativa com tag canônica correta".
Para expurgar definitivamente um sitemap legado via Python sem depender da interface visual, basta enviar uma requisição DELETE autenticada para a API Webmasters v3:
# Remove um sitemap legado (ex: sitemap_index.xml) do Google Search Console via API
import requests
site_id = "sc-domain%3Aseudominio.com"
old_sitemap = "https%3A%2F%2Fseudominio.com%2Fsitemap_index.xml"
url_del = f"https://searchconsole.googleapis.com/webmasters/v3/sites/{site_id}/sitemaps/{old_sitemap}"
resp = requests.delete(url_del, headers={"Authorization": f"Bearer {creds.token}"}, timeout=10)
print("Status DELETE Sitemap Legado:", resp.status_code) # Esperado: HTTP 204 No Content
7. Perguntas Frequentes sobre Indexação e APIs do Google
Devo rodar o script de submissão de sitemap quantas vezes por dia?
Apenas uma vez após cada deploy real que adicione ou modifique URLs. Disparar PUT no sitemap a cada 5 minutos sem que haja alteração real no arquivo XML não acelera o Googlebot e pode fazer com que o agendador reduza a frequência de releitura do seu manifesto.
Qual o fator técnico que mais acelerou a saída de URLs do estado "Desconhecido" para "Indexado"?
Em nossos testes controlados, não foi nenhum truque de API: foi a densidade da malha de links internos contextuais combinada com um Hub temático central. Quando elevamos a malha interna de 711 para 1.199 links internos (garantindo zero páginas órfãs e links bidirecionais entre os artigos e a página inicial), o Googlebot rastreou os novos lotes em metade do tempo anterior.
⚡ Conheça Nossos Kits de Produção & Automação em Código Real
Escolha abaixo o pacote de engenharia que você quer implantar hoje na sua operação (pagamento único via Pix ou Cartão na Stripe):