Blog · 2026-08-30

Site novo sem nenhuma página indexada? Veja se a canonical e o sitemap estão brigando

Indexação zerada não se resolve reescrevendo conteúdo: rode a API de inspeção de URL e olhe o lastCrawlTime. Tudo vazio significa sinais em conflito. Alinhe canonical, og:url, JSON-LD e sitemap, confirme que cada entrada devolve 200, reenvie o sitemap. Isso costuma resolver.

O site está no ar há semanas, o sitemap foi enviado, o conteúdo não é raso, e o Google Search Console continua mostrando 0 indexado. A reação mais comum é voltar a mexer nos artigos, trocar títulos, ou se consolar com a ideia de que domínio novo demora mesmo. Pare um pouco. Nenhuma página indexada quase nunca é problema de qualidade: é o site contando duas histórias que se contradizem. Reescrever conteúdo não conserta isso. Conserta-se olhando no lugar certo.

Comece pelo lastCrawlTime: tudo vazio significa que o Google nunca veio, não que veio e não gostou

Rode todas as URLs do site pela API de inspeção de URL do Google Search Console (urlInspection().index().inspect()) e olhe dois campos: coverageState e lastCrawlTime. Juntos eles separam o "não indexado" em duas doenças completamente diferentes:

• lastCrawlTime com valor e estado "Rastreada, mas não indexada no momento": o Google veio, olhou e decidiu deixar para depois. Só nesse caso qualidade de conteúdo e repetição de template entram na conversa.
• lastCrawlTime vazio e estado travado em "Detectada, mas não indexada no momento", ou até "URL desconhecida para o Google": o Google nunca rastreou. O texto pode estar ótimo, ele não leu. O problema está nos sinais técnicos, não nos artigos.

No caso de site novo com tudo zerado que tratamos, a varredura devolveu lastCrawlTime vazio em todas as URLs. Com esse campo vazio, dá para pular a ansiedade com conteúdo e ir direto para os sinais.

O culpado é assim: o sitemap diz A, a canonical diz B, e B volta para A com 308

Anonimizado do caso real, três linhas contam a história inteira:

sitemap <loc>           →  https://example.com/reviews/foo        (sem extensão)
canonical da página     →  https://example.com/reviews/foo.html   (com .html)
teste real em foo.html  →  devolve 308, que volta para /reviews/foo sem extensão

Percorra do ponto de vista do Google: segue o sitemap e rastreia A, a canonical em A diz que a versão oficial é B, vai buscar B, e leva um 308 de volta para A. Os dois sinais ficam empurrando a bola um para o outro, e o Google não vai adivinhar qual vale. Ele adia a página, ou desiste de indexar de vez.

Essa armadilha é fácil de pisar em plataformas de hospedagem estática. O Cloudflare Pages, por exemplo, redireciona /foo.html para /foo com 308 automaticamente. No sistema de arquivos está foo.html, mas a URL oficial pública é /foo, sem extensão. O gerador emite a canonical a partir do nome do arquivo, com .html, e o sitemap emite o loc sem extensão. Cada trecho de código parece certo isolado. O erro é a inconsistência.

Quatro lugares para alinhar, e faltar um significa que a briga continua

A URL oficial de uma página aparece em mais de um lugar no site, e estes quatro precisam bater caractere por caractere:

1. <link rel="canonical">
2. <meta property="og:url">
3. O "url" dos nós WebPage / Article no seu JSON-LD
4. <loc> no sitemap.xml

O conserto não é abrir quatro arquivos e editar cada um. É definir no gerador uma única função de URL oficial e emitir os quatro lugares a partir desse mesmo valor. Sincronizar quatro strings na mão significa que elas vão se contradizer de novo, mais cedo ou mais tarde.

Um problema vizinho que vale citar: um loc de sitemap que carregou o prefixo do diretório de build e devolve 404 em produção. Pegamos uma variante pior, em que uma linha de fallback prestativa dentro do script de verificação removia o prefixo antes de comparar, então o loc quebrado passava em toda checagem e ficou verde por rodadas e rodadas sem ninguém notar. A lição: um fallback só pode absorver diferenças de forma conhecidas e corretas, como as URLs sem extensão de uma plataforma. Ele nunca pode absorver erro. Antes de escrever cada linha de fallback, pergunte uma coisa: isso está tolerando uma variação, ou escondendo um bug?

Só existe um critério de aceite: cada loc devolve 200 direto

Depois do conserto, "a página abre" não basta. Navegadores e curl -L seguem redirecionamento sozinhos, então o 308 fica invisível. Desligue o seguimento de redirecionamento para medir:

# sem -L, para enxergar o código de status real
curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/reviews/foo"

O padrão: cada <loc> do sitemap devolve 200 quando requisitado direto. 308 é falha, porque significa que o loc não está escrito na forma oficial. 404 dispensa explicação. Depois confira algumas páginas por amostragem para validar a trindade: a URL requisitada, a canonical da página e o og:url têm que ser idênticos.

O último passo é o que mais gente pula: voltar ao Google Search Console e reenviar o sitemap. Sem isso, o Google continua com o arquivo antigo, os sinais contraditórios seguem na fila dele, e tudo o que você acabou de arrumar não vale nada.

Ainda travado em "Detectada" depois de alinhar? Vá checar os links internos

Alinhar esses quatro lugares resolve o caso "os sinais se contradizem, então ele não rastreia". Se os sinais estão limpos e a página continua parada em "Detectada, mas não indexada no momento" por muito tempo, o próximo suspeito é link interno escasso: a página existe só no sitemap, quase nada no site aponta para ela, o Google conclui que ela não é importante e nunca coloca na fila de rastreamento.

Rebalanceamos os links internos de um site de conteúdo em um setor de alta competição. Antes do rebalanceamento, 49 páginas tinham exatamente 1 link de entrada. Depois de levar todas as 116 páginas do site a pelo menos 4 links de entrada cada, o site chegou a 153 de 173 páginas indexadas (cerca de 88%). O método foi automação de novo: tratar a contagem de referências recebidas por página como métrica de gate no build, calcular antes de gerar a saída, e fazer qualquer página abaixo do mínimo puxar links de páginas relacionadas automaticamente, em vez de depender de editores lembrarem de cruzar links.

Fechamento: escreva essas checagens como script e coloque no pipeline de deploy

A ordem da investigação, resumida: API de inspeção de URL para ver o lastCrawlTime, se estiver tudo vazio alinhe canonical, og:url, url do JSON-LD e loc do sitemap nos quatro lugares, valide que cada loc devolve 200 com o seguimento de redirecionamento desligado, reenvie o sitemap, e se ainda travar vá checar os links internos. Cada passo aqui é uma checagem programável, que vale virar script rodando automaticamente em todo deploy em vez de algo que um humano lembra depois que já subiu. Se o seu site novo também está parado em zero indexado, ou se você quer automatizar essas checagens e parar de reinvestigar a mesma coisa, fale com a gente. Puxar as respostas reais da API de inspeção de URL costuma apontar em poucos minutos qual camada está brigando.

Transformamos o lançamento de sites novos em serviço

Uma canonical brigando com o sitemap é só uma das formas de morrer. Um site novo costuma falhar em ser indexado por mais de um motivo, e você elimina um de cada vez.

• Arquitetura de site e SEO técnico: canonical, sitemap, robots e dados estruturados alinhados de uma vez
• Monitoramento de indexação: checar o status de indexação página a página, achar o motivo do que não entrou e reenviar
• Produção de conteúdo: conteúdo original é a razão para te indexarem, e é a etapa mais pulada de todas

Entrega em quatro semanas, com produção toda semana. As especificações estão em Serviço de criação de site iGaming SEO.