Auditoria grátis
Search Console

Relatório de indexação de páginas: o que cada status significa e o que fazer

O guia central do Search Console: como ler o relatório, todos os motivos de não indexação, como validar a correção e por onde começar.

Equipe VarridaAtualizado em 16 min de leitura

Peça pra sua IA ler este artigo por você.

Duas lupas cruzadas, uma azul-noite e uma âmbar, cada uma mostrando uma versão da página
Neste artigo
  1. Onde fica o relatório
  2. Como ler o relatório
  3. Tabela-resumo de todos os status
  4. Status de erro: o Google tentou e não conseguiu
  5. Status que quase sempre são normais
  6. Os dois avisos: indexada, mas com problema
  7. Como conferir o status de fora do Search Console
  8. Validar a correção
  9. Relatório x Inspeção de URL
  10. O que atacar primeiro
  11. Perguntas frequentes

Resposta curta

O relatório Indexação de páginas fica em Indexação › Páginas no Search Console. Ele divide as URLs que o Google conhece em indexadas e não indexadas e, na tabela "Por que as páginas não foram indexadas", dá o motivo de cada grupo. Não indexada não é sinônimo de erro: redirecionamentos, cópias com canônica certa, noindex de propósito e 404 de páginas removidas são normais. Problema de verdade é quando uma página importante cai em Erro no servidor (5xx), noindex, robots.txt, soft 404 ou em uma canônica que você não escolheu. Corrija, clique em Validar a correção e espere: o Google diz que a validação leva, em geral, até duas semanas.

Onde fica o relatório

  1. Entre no Google Search Console e escolha a propriedade do site.
  2. No menu da esquerda, abra Indexação › Páginas.
  3. Logo acima do gráfico tem um filtro de sitemap. O padrão é Todas as páginas conhecidas. Troque pra Todas as páginas enviadas quando quiser ver só o que está nos seus sitemaps, que costuma ser a lista que importa.

Se o site é novo e ainda não aparece nada, o Google avisa que leva cerca de uma semana pra começar a rastrear e indexar um site ou página nova. O passo a passo do começo está em como colocar o site no Google.

Em site com menos de 500 páginas, a própria central diz que talvez você nem precise do relatório: buscar site:seudominio.com.br e inspecionar as páginas principais já resolve.

Como ler o relatório

Indexadas x não indexadas

No alto da página de resumo, o gráfico mostra duas contagens: páginas indexadas (verde) e não indexadas (cinza). Não espere 100%: só a versão canônica de cada página entra no índice. Cópias, variações com filtro e URLs que redirecionam ficam de fora, e isso é o comportamento esperado.

Abaixo do gráfico, o link Ver dados sobre as páginas indexadas mostra o histórico das indexadas e até mil URLs de exemplo.

As duas tabelas

  • Por que as páginas não foram indexadas: cada linha é um motivo, com a quantidade de URLs, a Origem (Site ou Google) e o estado da Validação. O Google ordena pelos problemas que considera mais importantes. Em geral, só dá pra corrigir o que tem origem "Site".
  • Melhorar a experiência na página: avisos que não impedem a indexação, mas atrapalham o Google de entender a página. É aqui que aparecem os dois status de "indexada, mas".

Cada linha abre uma página de detalhes com o gráfico do problema e até mil URLs de exemplo, cada uma com atalho pra Inspeção de URL.

O atraso dos dados

O relatório mostra o que o Google viu no último rastreamento de cada URL, não o estado ao vivo. Se você corrigiu algo ontem e a página continua com o problema, confira a data do último rastreamento dela: a correção pode ter vindo depois. Dois detalhes que confundem:

  • A lista de Não encontrado (404) mostra só URLs com 404 no último mês.
  • Um problema some da tabela 90 dias depois da última instância corrigida. Se voltar antes disso, a linha reabre com a data de primeira detecção antiga.

Se as indexadas caíram e nenhum erro subiu junto, o Google aponta como suspeitos robots.txt, noindex ou login obrigatório. O roteiro de queda está em site sumiu do Google.

Tabela-resumo de todos os status

Os nomes abaixo são os da central de ajuda em português. A tela do Search Console às vezes usa um texto um pouco diferente, mas o motivo é o mesmo.

StatusÉ problema?O que fazer
Erro no servidor (5xx)SimAchar a causa do 5xx (servidor, firewall, timeout) e validar
Erro de redirecionamentoSimDesfazer loop ou cadeia; um salto direto pro destino final
URL bloqueado pelo arquivo robots.txtDependeSe a página importa, liberar no robots.txt
URL marcado como "noindex"DependeSe a página importa, tirar a meta tag ou o cabeçalho
Erro soft 404Sim404 de verdade se não existe; conteúdo se existe
Bloqueada devido a solicitação não autorizada (401)DependePágina pública atrás de senha: tirar a senha
Não encontrado (404)Normal, na maioria301 se a página mudou de lugar; corrigir links internos
Bloqueada devido a acesso proibido (403)Sim, se a página é públicaLiberar o Googlebot no servidor, CDN ou firewall
O URL foi bloqueado devido a outro problema 4xxDependeInspecionar e ver qual 4xx o servidor devolveu
Rastreada, mas ainda não indexadaSó se forem páginas importantesMelhorar conteúdo e links internos
Detectada, mas não indexada no momentoSó se forem páginas importantesServidor mais rápido, menos URLs inúteis
Página alternativa com tag canônica adequadaNãoNada
Cópia sem página canônica selecionada pelo usuárioNormalmente nãoDeclarar a canônica se o Google escolheu a errada
Cópia, o Google e o usuário não escolheram a mesma página canônicaDependeAlinhar canonical, redirects, sitemap e links
Página com redirecionamentoNãoTirar do sitemap e atualizar links internos
Página indexada, mas bloqueada pelo robots.txtAvisoEscolher: liberar no robots.txt ou trocar por noindex
Página indexada, mas sem conteúdoAvisoVer na Inspeção de URL por que o conteúdo não aparece

Status de erro: o Google tentou e não conseguiu

Erro no servidor (5xx)

O servidor respondeu com um erro da faixa 500, ou o pedido expirou, quando o Googlebot pediu a página. É problema. Além de a página não entrar, o Google diz que 5xx e 429 fazem ele desacelerar o rastreamento do site, e que URLs que dão erro de servidor de forma consistente acabam saindo do índice. Causas comuns: servidor sobrecarregado, timeout em página dinâmica pesada ou proteção contra DoS bloqueando o Googlebot. O que fazer: abra Configurações › Estatísticas de rastreamento e veja o status do host; rode o teste ao vivo na Inspeção de URL pra ver se o erro se repete (pode ter sido passageiro); se for bloqueio de firewall, libere o Googlebot com o provedor de hospedagem.

Erro de redirecionamento

O Google encontrou uma cadeia de redirecionamento longa demais, um loop, um URL de redirecionamento acima do tamanho máximo ou um URL inválido ou vazio no caminho. É problema. A causa clássica é regra de HTTPS brigando com regra de www. Por padrão os rastreadores do Google seguem até 10 saltos, mas o certo é um salto só, direto pro endereço final. Confira com o curl mais abaixo e veja o guia de redirect 301 ou 302.

URL bloqueado pelo arquivo robots.txt

O robots.txt proíbe o Googlebot de baixar a página. Pode ser normal: áreas de admin, carrinho e busca interna costumam ser bloqueadas de propósito, e o Google lembra que não faz sentido validar o que está bloqueado por escolha. Vira problema quando a regra pega páginas que deveriam estar no Google, quase sempre um Disallow: / que veio do ambiente de teste. Se a ideia é tirar a página do Google, robots.txt não é o jeito certo: a central de ajuda manda liberar o rastreamento e usar noindex. O passo a passo está em robots.txt bloqueando o Google.

URL marcado como "noindex"

O Google achou uma diretiva noindex na página, na meta tag robots ou no cabeçalho HTTP X-Robots-Tag, e respeitou. Se a página não deveria estar no Google, é o resultado esperado. Se deveria, é um dos problemas mais caros, porque o site sai do Google em silêncio. A causa mais comum é o "não indexar" da homologação que foi pra produção. Remova a diretiva, confirme com Testar o URL publicado e clique em Solicitar indexação. Mais em noindex sem querer.

Erro soft 404

A página parece uma página de "não encontrado", ou está praticamente vazia, mas responde com código de sucesso (200). Uma causa comum é site de página única (SPA) que devolve 200 pra qualquer endereço. O Google recomenda responder 404 quando a página realmente não existe e adicionar conteúdo quando ela existe. Pra ver o que o Google viu, rode o teste ao vivo e clique em Ver a página testada. Detalhes por plataforma em soft 404.

Bloqueada devido a solicitação não autorizada (401)

O servidor pediu autenticação e o Googlebot não tem senha. Normal em área de membros; problema quando a página deveria ser pública, como um site inteiro atrás da senha da hospedagem. Abra a página numa janela anônima: se pedir login, o Google também está barrado. Remova a exigência de autorização ou permita o acesso do Googlebot verificando a identidade dele.

Não encontrado (404)

A página respondeu 404. Na maioria das vezes, é normal: o Google descobriu o endereço por um link antigo ou a página foi excluída. A central de ajuda diz que 404 não é problema se a página foi removida sem substituta, e recomenda corrigir só os 404 que você mesmo linka ou lista no sitemap. Se a página mudou de lugar, use 301 pro endereço novo. Pra achar quem aponta pra URL quebrada, a verificação de links quebrados ajuda.

Bloqueada devido a acesso proibido (403)

O servidor respondeu 403. O Google explica que o Googlebot nunca envia credenciais, então um 403 pra ele é o servidor errando. Se a página é pública, é problema. A causa típica é firewall, CDN ou plugin de segurança que bloqueando bots. Libere o Googlebot nessa camada. E não use 401 nem 403 pra frear o rastreamento: o Google diz que eles não afetam a taxa de rastreamento.

O URL foi bloqueado devido a outro problema 4xx

O servidor devolveu um 4xx que não é 401, 403 nem 404. O Google não indexa URLs com 4xx. Se a página deveria existir, inspecione o URL e veja o código exato que o servidor mandou.

Status que quase sempre são normais

Página com redirecionamento

Um URL não canônico que redireciona pra outro. Não é problema: quem entra no índice é o destino, se o Google achar que ele merece. Cresce muito depois de migração ou troca pra HTTPS. O que fazer: confirmar que o redirect é 301 e leva pra página equivalente (não pra home), tirar os endereços antigos do sitemap e atualizar os links internos pra apontarem direto pro destino. Guia completo em redirect 301 ou 302.

Página alternativa com tag canônica adequada

A página é uma versão alternativa (AMP, mobile ou desktop) que aponta corretamente pra canônica, que está indexada. Nenhuma ação é necessária. Páginas de idioma alternativo não são detectadas aqui, segundo o Google.

Cópia sem página canônica selecionada pelo usuário

A página é cópia de outra e não declara canônica, então o Google escolheu a outra e não vai mostrar esta. O Google diz que isso não é erro, é o comportamento padrão. Vira problema quando a escolhida é a errada, por exemplo a versão com parâmetro no lugar da limpa. Nesse caso, declare o rel="canonical" absoluto na página certa e nas cópias. Se a página não é cópia de verdade, deixe o conteúdo dela claramente diferente.

Cópia, o Google e o usuário não escolheram a mesma página canônica

Você declarou esta página como canônica, mas o Google achou outra mais adequada e indexou a outra. É problema quando a página do Google é a que você não queria na busca. A causa mais comum são sinais contraditórios: canonical diz uma coisa, sitemap e links internos dizem outra, ou um domínio de preview (como .vercel.app) com o mesmo conteúdo. Na Inspeção de URL, compare URL canônico declarado pelo usuário e URL canônico selecionado pelo Google. Lembre que canonical é sinal, não ordem: alinhe canonical, redirects 301, sitemap e links pro mesmo endereço. Os dois guias que aprofundam: duplicada, Google escolheu canônica diferente e canonical errado no vercel.app.

Rastreada, mas ainda não indexada

O Google baixou a página e decidiu não indexar, por enquanto. A central diz que ela pode ou não entrar no futuro e que não é preciso reenviar o URL. Em filtro, tag e página fina, é normal. Nas páginas que importam, a causa costuma ser conteúdo raso ou parecido demais com outras páginas, e a saída é melhorar o conteúdo e dar links internos pra ela.

Detectada, mas não indexada no momento

O Google conhece o endereço, mas ainda não rastreou, e por isso a data do último rastreamento fica em branco. Segundo o Google, normalmente ele quis rastrear e adiou pra não sobrecarregar o site. Em site grande, costuma ser servidor lento ou URLs demais. Os dois status são explicados lado a lado em rastreada, mas não indexada.

Os dois avisos: indexada, mas com problema

Página indexada, mas bloqueada pelo robots.txt

A página está no índice mesmo bloqueada no robots.txt, porque o Google achou links pra ela em outros lugares. Ele não lê o conteúdo, então o snippet na busca fica pobre. Quase sempre é alguém que tentou tirar a página do Google pelo robots.txt. Decida: se quer a página fora da busca, remova o bloqueio e use noindex (com o bloqueio, o Google nunca vê o noindex); se quer a página na busca, libere no robots.txt.

Página indexada, mas sem conteúdo

A página está no índice, mas o Google não conseguiu ler o conteúdo, porque ele está oculto pro Google ou num formato que ele não indexa. Não é bloqueio de robots.txt. Inspecione o URL, rode o teste ao vivo e veja a Captura de tela e o HTML renderizado em Ver a página testada.

Como conferir o status de fora do Search Console

Antes de clicar em validar, confirme a correção com o mesmo tipo de pedido que o Google faz. O código de status e a cadeia de redirecionamento:

Terminal
# código final e quantos redirecionamentos até lá
curl -sIL -A "Googlebot" https://seusite.com.br/pagina | grep -iE "^HTTP|^location"

# só o código, sem seguir redirect
curl -s -o /dev/null -w "%{http_code}\n" https://seusite.com.br/pagina

Noindex no cabeçalho ou no HTML:

Terminal
curl -sI https://seusite.com.br/pagina | grep -i x-robots-tag
curl -s https://seusite.com.br/pagina | grep -io '<meta[^>]*robots[^>]*>'

Canonical declarado e soft 404 num endereço que não existe:

Terminal
curl -s https://seusite.com.br/pagina | grep -io '<link[^>]*canonical[^>]*>'
curl -s -o /dev/null -w "%{http_code}\n" https://seusite.com.br/nao-existe-123

Se o último comando devolver 200, o site tem soft 404 em qualquer endereço errado. Pra checar uma URL de cada vez sem terminal, use verificador de redirect, verificar noindex, verificar canonical, verificar robots.txt e verificar soft 404. A varredura grátis da Varrida confere tudo isso de uma vez na home e numa amostra de páginas do site. Mudar o user agent no curl não reproduz tudo: o pedido não sai dos servidores do Google, então o teste ao vivo da Inspeção de URL continua sendo a prova final.

Validar a correção

Depois de corrigir todas as URLs de um motivo, abra a página de detalhes dele e clique em Validar a correção. O Search Console verifica algumas páginas na hora e depois põe na fila só as URLs conhecidas com aquele problema, não o site inteiro. Você recebe e-mail no fim. Validar não é obrigatório: o Google atualiza a contagem sozinho ao rastrear de novo.

Os estados da validação do problema:

  • Não foi iniciado: alguma instância nunca entrou numa validação.
  • Iniciado: validação em andamento, sem instância remanescente encontrada até agora.
  • Tudo certo até agora: todas as instâncias verificadas até aqui estão corrigidas.
  • Aprovado: todas as instâncias conhecidas foram eliminadas ou não estão mais disponíveis.
  • N/D: o Google viu que estava tudo corrigido sem você pedir validação.
  • Falha: um certo número de páginas ainda tem o problema. Corrija e reinicie.

Cada URL também ganha um estado: Pendente (na fila), Aprovado, Falha ou Outro (o Google não conseguiu acessar a URL, o que conta como aprovado).

Quanto demora: em geral, até duas semanas, mas pode demorar muito mais em alguns casos. Não dá pra pedir outra validação antes do ciclo atual acabar. Se falhar, clique em Ver detalhes, corrija as URLs e use Iniciar nova validação; ela reverifica só as que estavam Pendente ou Falha e as instâncias novas. Uma dica do próprio Google pra acelerar: envie um sitemap só com as páginas mais importantes, filtre o relatório por ele e valide esse subconjunto. Como montar o arquivo está em sitemap XML.

Relatório x Inspeção de URL

Relatório Indexação de páginasInspeção de URL
EscopoO site inteiro, agrupado por motivoUma URL por vez
DadosÚltimo rastreamento de cada URLVersão indexada e, com "Testar o URL publicado", teste ao vivo
Busca por URLNão dá pra pesquisar nem filtrar por URLÉ pra isso que serve
AçãoValidar a correção de um motivo inteiroSolicitar indexação de uma página
LimiteExemplos limitados a mil URLs por motivoLimite diário de testes e de pedidos de indexação

Use o relatório pra achar padrões e a Inspeção pra confirmar uma página. Se a Inspeção não mostra problema e o relatório mostra, você provavelmente corrigiu depois do último rastreamento. E o teste ao vivo não confere tudo: duplicatas e canônicas não são testadas em tempo real. Solicitar indexação também não garante que a página entre.

O que atacar primeiro

A tabela já vem ordenada pelo que o Google acha mais importante, mas o que vale é o impacto no seu site. A ordem que a gente recomenda:

  1. A home e as páginas que vendem. Inspecione uma por uma. Se alguma não estiver indexada, ela passa na frente de tudo.
  2. noindex e robots.txt em páginas importantes. Tiram seções inteiras do Google de uma vez e costumam ser uma linha de configuração.
  3. Erro no servidor (5xx), 403 e 401 em páginas públicas. Além de bloquear, 5xx faz o Google rastrear menos o site todo.
  4. Erro de redirecionamento e soft 404. Loops e páginas vazias com 200 desperdiçam rastreamento.
  5. Canônica diferente da declarada. Quando a URL escolhida pelo Google é a errada.
  6. Rastreada ou Detectada, mas não indexada. Só nas páginas que importam; aqui o trabalho é conteúdo, links internos e velocidade.
  7. 404, Página com redirecionamento, cópias e alternativas. Na maioria, normais. Só limpe o sitemap e os links internos.

O Google sugere priorizar motivos com origem "Site" e validação em "Falha" ou "Não foi iniciado".

Perguntas frequentes

É normal ter mais páginas não indexadas do que indexadas?

Pode ser. O Google cita como causas comuns regras de robots.txt que bloqueiam seções grandes e muitas páginas duplicadas por parâmetros de filtro ou ordenação. Abra cada motivo e veja se as páginas importantes estão na lista.

Quanto tempo leva a validação da correção?

Segundo o Google, em geral até duas semanas, mas pode demorar muito mais em alguns casos. Não dá pra pedir uma nova validação antes de o ciclo atual terminar.

Corrigi o problema e o relatório ainda mostra o erro. Por quê?

O relatório reflete o último rastreamento de cada URL. Confira a data do rastreamento: se a correção veio depois, rode o teste ao vivo na Inspeção de URL e solicite a indexação.

Dá pra procurar uma URL específica no relatório?

Não. O relatório não permite pesquisar nem filtrar por URL. Pra saber o status de uma página, use a Inspeção de URL.

Página com redirecionamento é erro?

Não. URLs que redirecionam não são indexadas, só o destino. Basta garantir que o redirect é 301 pra página equivalente e tirar os endereços antigos do sitemap.

Fontes

Publicado em 16 de outubro de 2026. Viu algo desatualizado? Escreve pra contato@varrida.com.

Varredura grátis

Veja o que o Google enxerga no seu site.

Cole o endereço e, em menos de 1 minuto, veja a nota e os problemas mais graves, cada um com a correção. Sem cadastro.

  • Grátis
  • Sem cadastro
  • Menos de 1 minuto
Continue lendo

Outros guias do blog