Como verificar se um site criado por IA foi indexado pelo Google

Receber uma URL pública não significa que a página já entrou no índice do Google. O deploy pode estar concluído, o site pode abrir normalmente e ainda faltar descoberta, rastreamento, processamento ou uma decisão de indexação do mecanismo de busca.

Esse intervalo costuma gerar correções no escuro: republicar o mesmo arquivo, mudar o canonical sem evidência ou solicitar indexação várias vezes. O caminho mais seguro é separar as etapas e investigar a URL exata.

Este guia mostra como verificar um site criado por IA depois de publicar, interpretar os sinais do Search Console e devolver ao agente apenas problemas que pertencem ao código ou ao pacote.

Publicado, rastreável e indexado são estados diferentes

Uma entrega pode passar por estas camadas:

arquivos corretos
→ build concluída
→ deploy ativo
→ URL pública acessível
→ URL descoberta
→ página rastreada
→ conteúdo processado
→ URL indexada ou excluída
→ possível exibição em uma busca

Cada seta precisa de evidência própria.

Não use uma camada para afirmar outra. O Site no Ar consegue publicar e devolver a URL; o mecanismo externo decide quando rastrear, indexar e apresentar a página.

Confirme a versão publicada primeiro

Antes de abrir uma ferramenta de busca, verifique a entrega:

• URL exata e domínio oficial;
• status HTTP e conteúdo esperado;
• versão ou commit publicado;
• data e resultado do deploy;
• title, H1 e canonical servidos;
• ausência de login ou bloqueio involuntário;
• links internos que levam à página;
• presença no sitemap, quando aplicável.

Abra o código-fonte retornado pela URL, não apenas o DOM depois do JavaScript. Um site pode mostrar conteúdo no navegador e ainda entregar metadata incompleta no documento inicial.

O guia de Publicação cobre Pages, assets e pacote estático. Se a URL ativa mostra uma versão antiga, resolva a publicação antes de diagnosticar indexação.

Garanta que a URL deveria ser indexada

Nem toda página pública precisa estar no índice. Confirme a intenção:

URL:
conteúdo único e útil:
deve aparecer em busca? sim / não
canonical esperado:
meta robots esperado:
links internos de descoberta:
sitemap:
responsável pela decisão:

Páginas de preview, duplicatas, resultados internos, versões com parâmetros e rotas temporárias podem ser excluídas de propósito. Buscar “100% de cobertura” sem entender essas escolhas transforma decisões corretas em falsos problemas.

Quando a URL deve ser indexável, procure bloqueios básicos:

• meta tag ou cabeçalho noindex;
• regra de robots.txt que impede rastreamento;
• canonical apontando para outra URL;
• resposta 404, soft 404, erro de servidor ou redirect inesperado;
• página sem links internos e ausente do sitemap;
• conteúdo duplicado ou muito próximo de outra rota;
• conteúdo principal dependente de uma execução que o crawler não recebeu.

O artigo de sitemap e robots.txt ajuda a revisar descoberta e rastreamento sem usar robots.txt como privacidade. Para URLs duplicadas, consulte o guia de canonical.

Use a propriedade correta no Search Console

O Search Console ajuda a monitorar e diagnosticar a presença de propriedades que você controla. A URL inspecionada precisa pertencer à propriedade aberta.

Confira com atenção:

• https versus http;
• domínio próprio versus endereço temporário;
• hostname com ou sem www;
• caminho completo;
• propriedade e permissão da conta.

Se o site passou a usar um Custom Domain, não presuma que dados do hostname anterior representam o domínio novo. A documentação de Domínios próprios cobre DNS, verificação e SSL no Site no Ar; a verificação de propriedade no Search Console continua sendo uma etapa do serviço externo.

Inspecione uma URL específica

A ferramenta de inspeção de URL mostra informações sobre a versão indexada conhecida e permite testar a URL ativa.

Use a URL completa e compare duas visões:

Versão indexada

Mostra o que o Google registrou da última versão processada, incluindo estado de indexação, rastreamento e canonical selecionado quando disponível. Ela pode estar atrás do deploy atual.

Registre a data do último rastreamento antes de concluir que uma correção publicada não funcionou.

Teste ao vivo

Testa a versão que está disponível agora e ajuda a identificar problemas imediatos de acesso ou indexabilidade. Um teste ao vivo aprovado não prova que a URL já está indexada. Ele indica que a versão atual parece elegível nos aspectos testados.

Compare:

URL inspecionada:
deploy ativo:
último rastreamento conhecido:
status da versão indexada:
resultado do teste ao vivo:
canonical declarado:
canonical selecionado:
rastreamento permitido:
indexação permitida:
próxima ação:

Interprete o motivo antes de corrigir

O relatório de indexação agrupa URLs por estados e motivos. Alguns representam defeitos; outros representam escolhas legítimas ou processamento ainda pendente.

Não altere todas as páginas de uma categoria por causa de uma única amostra. Inspecione URLs representativas e confirme se o padrão está na fonte, na build ou apenas no relatório antigo.

O Page Indexing report é útil para enxergar padrões, enquanto a inspeção de URL responde melhor sobre uma rota específica.

Solicite indexação sem transformar o botão em ritual

Depois de corrigir um problema e confirmar a versão ao vivo, você pode solicitar indexação pela inspeção de URL. A orientação oficial para novo rastreamento recomenda a ferramenta para poucas URLs e sitemap para um conjunto maior.

Considere estes limites:

• é necessário controlar a propriedade;
• há cotas para solicitações;
• repetir o pedido não acelera o rastreamento;
• processamento pode levar de dias a semanas;
• a solicitação não garante inclusão nem exibição imediata.

Para muitas páginas, envie um sitemap atualizado e mantenha links internos claros. Não solicite manualmente dezenas de URLs para compensar uma arquitetura que não permite descobri-las.

Saiba quando republicar

Republicar faz sentido quando a investigação encontrou um problema na fonte ou no pacote, como:

• noindex acidental;
• canonical incorreto;
• sitemap desatualizado;
• rota ausente da build;
• erro de status ou conteúdo;
• link interno quebrado;
• metadata herdada de preview.

Não republique apenas porque o relatório ainda mostra a versão anterior. Primeiro compare a data do crawl, o teste ao vivo e o deploy ativo.

Quando houver uma correção real, mude a fonte, gere a build, publique no mesmo Site e verifique a URL. O fluxo de republicação com agente de IA mantém a continuidade da URL e separa alteração, deploy e prova ao vivo.

Peça ao agente um diagnóstico com fronteiras

O agente pode organizar a investigação sem receber permissão para mudar política de indexação:

Diagnostique por que estas URLs podem não estar indexadas.
Não altere arquivos nem publique.

Domínio oficial: [domínio]
Versão publicada: [commit ou referência]
URLs que deveriam ser indexáveis: [lista]
Evidências do Search Console: [status, motivo e data]

Para cada URL, compare:
- status e conteúdo publicado;
- canonical, meta robots e robots.txt;
- presença no sitemap e links internos;
- divergência entre build, teste ao vivo e versão indexada;
- causa provável e evidência;
- correção mínima na fonte, se houver.

Não remova bloqueios intencionais, não troque canonical por palpite
e não prometa prazo ou posição no Google.

Depois, aprove somente as correções sustentadas pela evidência. Use a auditoria SEO do Site no Ar para localizar fundamentos técnicos na URL ativa, lembrando que a auditoria não substitui o estado externo de indexação.

Checklist final de indexação

Ao encerrar a análise, confirme:

• URL e propriedade corretas;
• deploy e versão ativa registrados;
• página deve realmente ser indexada;
• URL retorna status e conteúdo esperados;
• canonical aponta para o endereço aprovado;
• nenhum noindex ou bloqueio acidental;
• página aparece em links internos e no sitemap quando aplicável;
• versão indexada e teste ao vivo foram distinguidos;
• data do último rastreamento foi considerada;
• motivo do relatório foi interpretado antes da correção;
• republicação ocorreu apenas quando a fonte mudou;
• solicitação de indexação não foi repetida sem necessidade;
• não houve promessa de prazo, posição ou rich result.

Indexação não é o último checkbox do deploy. É um processo externo que começa com uma página pública, acessível, coerente e descobrível. Quando cada camada tem sua própria evidência, a equipe consegue corrigir o que controla e esperar o que depende do mecanismo de busca — sem pedir ao agente que adivinhe.