Uma URL acessível é apenas parte da análise de SEO técnico. Uma página de preços ou de produto pode responder com HTTP 200 e permitir indexação enquanto um robô não consegue obter os dados necessários ao conteúdo principal. No navegador habitual, esse problema pode passar despercebido.
O caso abaixo descreve uma correção observada na Sitelemetry em 12 de setembro de 2026. Foi comprovado que um teste ao vivo do Google passou a exibir os cartões de preços. Isso não comprova indexação efetiva nem melhora de posições, tráfego ou vendas.
Escopo desta auditoria
O que pode ser medido
- Respostas e sinais de indexação da URL pública exata, juntamente com as regras robots.txt correspondentes.
- Recursos públicos necessários ao conteúdo essencial da página.
- Evidências anteriores e posteriores do teste ao vivo do Google, com registro separado das etapas seguintes.
O que ela não comprova
- Uma requisição estática não substitui os sistemas de renderização e indexação do Google.
- Um teste ao vivo bem-sucedido não garante indexação nem prazo.
- Esta correção não demonstra aumento de posições, tráfego ou receita.
As etapas manuais podem ser executadas sem assinatura. A Sitelemetry oferece auditorias de SEO nos planos pagos; a inspeção de URL no Search Console exige acesso adequado à propriedade.
O caso concreto da página de preços
Na Sitelemetry, /pricing respondia com HTTP 200 e podia ser indexada. Entretanto, o catálogo de preços não aparecia no teste ao vivo do Google. A página dependia do recurso público /api/plans, bloqueado pela regra geral Disallow: /api/. Portanto, carregar o documento HTML com sucesso não bastava para mostrar todo o conteúdo.
Em 12 de setembro de 2026, foi adicionada a exceção específica Allow: /api/plans$. O teste seguinte exibiu os cartões de preços e indicou que a página podia ser indexada; depois, foi enviada uma solicitação de indexação. Isso comprova a correção da renderização, não uma indexação já concluída ou visitas adicionais. A liberação não envolveu recursos privados das contas.
Separe três perguntas diferentes
O robô pode buscar a URL? Consegue carregar os recursos necessários e exibir o conteúdo importante? O mecanismo de busca decide então indexar a página? Essas perguntas estão relacionadas, mas exigem respostas e evidências diferentes.
O Google explica as limitações do robots.txt: bloquear o rastreamento não é uma forma confiável de remover uma URL conhecida dos resultados. O robô precisa ler uma instrução noindex; um bloqueio simultâneo pode impedi-lo. Consulte a documentação sobre bloquear a indexação. Dados confidenciais exigem, separadamente, controles reais de acesso. Nem robots.txt nem noindex protege informações contra acesso não autorizado.
Examine a página e suas dependências
- Verifique a URL exata: redirecionamentos, status, tipo de conteúdo e indicações de indexação tanto no HTML quanto nos cabeçalhos HTTP.
- Leia o robots.txt da origem correta e as regras para o robô em questão. Um simples
Allow: /não resolve todas as regras mais específicas de caminhos. - Compare o HTML inicial com o navegador normal. Identifique JavaScript, folhas de estilo e dados públicos necessários aos conteúdos decisivos.
- No teste ao vivo do Google, examine HTML renderizado, imagem da página e recursos com falha. Confira o conteúdo real, não apenas um status geral favorável.
Uma auditoria estática não é o renderizador do Google. Os fundamentos de SEO JavaScript do Google descrevem essas etapas de processamento. Quando faltar evidência, mantenha o item como verificação pendente.
Faça a menor alteração adequada
Primeiro, confirme que o recurso deve ser público e é necessário ao conteúdo. Neste caso, era o catálogo público dos planos, não dados de clientes. O trecho relevante era:
User-agent: *
Disallow: /api/
Allow: /api/plans$Esse trecho não é um robots.txt completo para copiar sem adaptação. O Google usa a regra correspondente mais específica; $ marca o fim da URL. Portanto, variantes com parâmetros e caminhos filhos não ficam automaticamente cobertos. Confira esse comportamento na especificação oficial das regras. Não libere toda a API indiscriminadamente. Conforme a arquitetura, pode ser melhor incluir o conteúdo essencial diretamente no HTML. Autenticação e permissões continuam necessárias.
Teste novamente com o Google e descreva o resultado com precisão
Confirme primeiro que robots.txt está acessível e que o recurso exato entrega os dados públicos esperados. Depois, repita o teste ao vivo e verifique se aparecem cartões de preços reais, não apenas um espaço reservado ou indicador de carregamento. Registre a data, o conteúdo visível e as falhas de recursos que ainda existirem.
Uma solicitação de indexação pode vir em seguida se for adequada ao estado da página. Mesmo assim, mantenha o status de indexação separado do teste ao vivo. Busca bem-sucedida e renderização correta não significam que a URL já foi indexada. Repetir solicitações não garante data ou posicionamento. A afirmação sustentada aqui é que o teste conseguiu mostrar o catálogo anteriormente ausente.
Priorize a próxima ação pelo impacto
Priorize páginas em que a falta de conteúdo impede uma decisão importante, como comparar planos ou entender um produto. Uma apresentação de preços quebrada merece correção sem precisar alegar grandes volumes de busca. Examine os modelos relacionados para encontrar a mesma dependência, em vez de adicionar permissões aleatórias.
Providencie também links internos acessíveis e um sitemap adequado. Segundo a documentação do Google sobre sitemaps, ele ajuda a descobrir URLs, mas não garante rastreamento ou indexação. Separe, portanto, presença no sitemap, resposta HTTP, renderização e prova de indexação. Nenhuma etapa isolada garante impressões, cliques ou compras. Assim o relatório permanece verificável e a próxima ação fica clara.
| Observação | Prioridade no contexto | Evidência a confirmar | Próxima ação |
|---|---|---|---|
| Preços essenciais ausentes na renderização | Alta na página de decisão afetada | Conteúdo do teste ao vivo e dependência pública bloqueada | Aplicar a correção específica justificada e testar novamente |
| Caminho privado da API bloqueado | Não é por si só um defeito de SEO | Determinar se o conteúdo público precisa desse recurso | Manter controles de acesso; não abrir dados privados |
| HTTP 200 sem evidência de indexação | Estado a investigar separadamente | Conteúdo renderizado e status real de indexação | Verificar o índice à parte; não relatar ganhos presumidos |
Perguntas frequentes
HTTP 200 significa que o Google vê todo o conteúdo?
Não. O HTML pode estar acessível enquanto scripts, estilos ou dados públicos estão bloqueados. Examine também o conteúdo renderizado e seus recursos.
Todos os caminhos da API devem ser liberados aos robôs?
Não. Identifique o recurso público necessário e libere apenas o escopo adequado. Dados privados continuam exigindo controles de acesso eficazes.
A correção da Sitelemetry já aumentou o tráfego orgânico?
Este caso não comprova isso. Ele documenta a renderização corrigida no teste ao vivo do Google e uma solicitação posterior de indexação, sem aumento comprovado de posições ou tráfego.
Fontes e leituras
- Google: introdução ao robots.txtdevelopers.google.com
- Google: especificação das regras robots.txtdevelopers.google.com
- Google: fundamentos de SEO JavaScriptdevelopers.google.com
- Google: impedir indexação com noindexdevelopers.google.com
- Google: visão geral dos sitemapsdevelopers.google.com
Preparado pela equipe Sitelemetry e conferido com o escopo do produto e as fontes primárias citadas. Os exemplos são ilustrativos, salvo quando um caso observado é identificado.
