SEOArtigo
SEO técnico: os erros que travam o crescimento de um site no Google
Em resumo
Checklist de SEO técnico para sites de empresa: indexação bloqueada, conteúdo que só existe com JavaScript, canonical errada, redirecionamento em cadeia, sitemap desatualizado e página de erro que responde como sucesso.
Antes de produzir conteúdo, garanta que o site pode ser lido
Existe uma ordem lógica em busca orgânica: o Google precisa acessar a página, entender o conteúdo e só então avaliar se vale ranquear. Quando uma empresa publica durante meses sem resultado, muitas vezes o problema está no primeiro degrau — e nenhum texto novo resolve isso. Esta é a lista dos travamentos técnicos que aparecem com mais frequência em sites de empresa no Brasil, com os limites oficiais que o Google Search Central publica.
Diagnóstico em uma tarde, sem ferramenta paga
Boa parte dos travamentos abaixo aparece numa verificação manual curta, com o navegador e o Search Console. Escolha cinco páginas que importam para o negócio — a home, duas páginas de serviço ou categoria e dois conteúdos — e passe cada uma por este roteiro:
- Código de resposta. A página responde 200 direto, sem salto de redirecionamento no caminho?
- HTML bruto. Com o código-fonte da resposta aberto (não o inspetor de elementos, que mostra a página já montada), o título, o H1 e o texto principal estão lá?
- Indexação permitida. Não há
noindexno HTML nem bloqueio norobots.txtpara aquele caminho? - Canonical. Aponta para a própria URL, absoluta, com o mesmo protocolo e domínio da barra de endereço?
- Links internos. Os links do menu e do corpo aparecem como links de verdade no HTML e levam direto ao destino final?
- Sitemap. A página está no sitemap, e o sitemap não lista endereços que falham nos itens anteriores?
- Endereço inexistente. Digite uma URL inventada no domínio e confira se a resposta é 404 de fato.
Anote o resultado numa tabela, página por coluna e item por linha. Item que falha em todas as páginas quase sempre é erro de modelo ou de configuração, resolvido num lugar só; item que falha em uma página só costuma ser exceção de conteúdo. Para conferir como o Google vê cada endereço, a ferramenta Inspeção de URL do Search Console mostra o HTML renderizado e a canonical que o buscador escolheu.
Indexação bloqueada por acidente
Dois arquivos e uma etiqueta decidem se a página entra no índice: o robots.txt, a etiqueta meta robots e o cabeçalho X-Robots-Tag. O acidente clássico é o site nascer em teste com bloqueio total e ir para produção com o bloqueio esquecido. O segundo é bloquear no robots.txt uma pasta que também guarda o CSS e o JavaScript necessários para renderizar a página — o Google acessa o HTML, não consegue montar o layout e avalia uma versão degradada.
O formato do arquivo é padronizado desde setembro de 2022 pela RFC 9309, o Robots Exclusion Protocol da IETF. Pela especificação do Google, o buscador lê no máximo 500 KiB do arquivo, ignora o que passar disso e costuma guardar a cópia em cache por até 24 horas — por isso a correção de um bloqueio não tem efeito imediato. Verificação rápida: procure linhas Disallow amplas no arquivo e noindex no HTML servido de três páginas importantes.
Há ainda uma confusão frequente entre as duas ferramentas: o robots.txt controla o rastreamento, não a indexação. A própria introdução do Google ao robots.txt diz que ele não é um mecanismo para manter uma página fora do Google: bloqueada ali, a URL pode continuar no resultado de busca, só que sem descrição, porque o conteúdo nunca foi lido — nem o noindex que estivesse nele. Para tirar uma página do índice, ela precisa estar acessível e dizer noindex; bloquear e marcar ao mesmo tempo anula a marcação.
Conteúdo que só existe depois do JavaScript
Muitos sites modernos entregam um HTML quase vazio e montam o conteúdo no navegador. O Google processa essas páginas em três fases — rastreamento, renderização e indexação —, com uma versão sempre atualizada do Chromium, e a renderização pode ficar para depois. O guia de JavaScript do Google recomenda renderizar no servidor ou pré-renderizar, porque nem todo robô executa JavaScript, e avisa que só descobre links feitos com o elemento <a> e atributo href. Em site que depende de busca orgânica, título, texto principal e links internos devem vir prontos no HTML da resposta do servidor.
| Sintoma | Como confirmar | Correção |
|---|---|---|
| Página aparece vazia para o robô | Baixar o HTML sem executar JavaScript e procurar o H1 | Renderizar no servidor ou pré-gerar a página |
| Menu e links internos invisíveis | Conferir se existem tags <a href> no HTML | Usar links reais em vez de eventos de clique |
| Título e descrição iguais em todo o site | Comparar o HTML de três páginas | Gerar metadados por página no servidor |
Um caso que escapa da tabela: abas, "ver mais" e acordeões que só buscam o texto no servidor depois do clique deixam esse texto fora do HTML inicial. Se o conteúdo importa para a busca, ele precisa estar no HTML desde o primeiro carregamento, mesmo que visualmente recolhido.
Canonical apontando para o lugar errado
A etiqueta canonical diz qual é o endereço oficial de um conteúdo. Errar é caro: canonical de todas as páginas apontando para a home some com o site do índice; canonical apontando para versão sem www enquanto o servidor redireciona para www cria conflito; canonical relativa em página com parâmetro de campanha divide sinais entre duas URLs. A regra vale para o site inteiro: uma URL absoluta, no protocolo e no domínio que o servidor realmente atende, apontando para si mesma quando a página é a versão oficial.
A canonical é uma sugestão, não uma ordem. Na documentação de URLs duplicadas, o Google classifica o redirecionamento e o rel="canonical" como sinais fortes e a inclusão no sitemap como sinal fraco — e os sinais se somam. Se links internos, sitemap e redirecionamento apontam para outra versão, o buscador escolhe sozinho a URL oficial. Os quatro precisam contar a mesma história.
Redirecionamento em cadeia e link interno para endereço morto
Depois de uma reforma de site, é comum sobrar cadeia de redirecionamento: a página antiga vai para uma intermediária, que vai para uma terceira. Os robôs do Google seguem até 10 saltos, mas cada salto já adiciona espera para o visitante. O trabalho correto é apontar cada endereço antigo diretamente para o destino final e atualizar os links internos — link interno nunca deve depender de redirecionamento. A página de códigos de status do Google define como cada resposta é tratada:
| Código HTTP | Significado | Como o Google trata |
|---|---|---|
| 301 e 308 | Mudança permanente | Sinal forte de que o destino deve ser indexado |
| 302 e 307 | Mudança temporária | Sinal fraco; a URL antiga tende a continuar valendo |
| 404 e 410 | Conteúdo inexistente ou removido | Os dois tiram a URL do índice, se ela estava indexada |
Migração e reforma de site sem perder tráfego
Boa parte destes travamentos nasce na troca de plataforma, de domínio ou de estrutura de URLs. O roteiro abaixo evita que a reforma apague o histórico conquistado.
Antes de publicar
- Exporte a lista completa de URLs atuais: sitemap, páginas com cliques no Search Console e endereços com links vindos de fora.
- Monte a tabela de correspondência, uma linha por URL antiga e seu destino final na nova estrutura. Página sem equivalente vai para o conteúdo mais próximo, não para a home.
- Anote onde está o bloqueio do ambiente de teste, para removê-lo no dia da troca.
No dia da troca
- Remova o bloqueio de teste e confira o
robots.txte o HTML de produção. - Teste uma amostra da tabela de correspondência: cada URL antiga deve chegar ao destino em um salto, com 301.
- Envie o novo sitemap no Search Console e, se o domínio mudou, registre a troca na ferramenta Mudança de endereço — ela não é necessária para passar de HTTP para HTTPS nem para alternar entre versões com e sem
www.
Nas semanas seguintes
- Acompanhe o relatório de páginas e os erros 404 de URLs antigas que ficaram fora da tabela, e inclua cada uma.
- Compare cliques das páginas principais com o período anterior à troca. Queda concentrada em poucas páginas aponta erro de redirecionamento ou de conteúdo nelas.
- Mantenha os redirecionamentos por pelo menos 1 ano, prazo que o guia de mudança de site do Google indica para transferir os sinais às URLs novas.
Sitemap e o que ele promete
Sitemap não é lista de desejos: deve conter só endereços que respondem 200, indexáveis e canônicos. Listar página com noindex, ou que redireciona, envia sinal contraditório. Cada arquivo comporta até 50.000 URLs ou 50 MB sem compressão; acima disso, divide-se em vários, reunidos num índice de sitemaps. O Google ignora os campos <priority> e <changefreq> e só usa o <lastmod> quando ele é consistentemente preciso: se todas as linhas mudam de data a cada publicação, o campo perde utilidade.
Página de erro que responde como sucesso
O problema mais silencioso da lista: o endereço não existe, o visitante vê "página não encontrada" e o servidor responde código 200. Para o Google, é uma página válida com conteúdo pobre, repetida dezenas de vezes, e o Search Console a classifica como soft 404. Endereço inexistente precisa responder 404 (ou 410, quando a remoção é definitiva) no cabeçalho, e não apenas no texto.
Perguntas para fazer a quem desenvolve o site
Muitos desses erros nascem na forma como o site foi construído. Antes de contratar uma reforma ou aprovar uma entrega, pergunte a quem desenvolve — equipe interna, agência ou plataforma:
- O conteúdo principal e os links vêm prontos no HTML do servidor, ou são montados no navegador?
- Título, descrição e canonical são gerados por página? Onde se configura cada um?
- Como o site responde a um endereço inexistente? Qual é o código de resposta?
- O sitemap é gerado automaticamente? Ele exclui páginas com
noindexe redirecionadas? - Onde ficam as regras de redirecionamento, e quem pode alterá-las sem abrir chamado?
- Como o ambiente de teste é bloqueado para busca, e o que garante que o bloqueio não vai para produção?
Resposta vaga a qualquer uma delas vira item de escopo antes de assinar, não depois da entrega. Para quem escolhe plataforma de loja, a lista também serve de critério técnico, ao lado dos pontos do hub de e-commerce.
Em que ordem corrigir, e o que medir?
Priorize pelo que bloqueia: primeiro indexação e resposta do servidor, depois renderização de conteúdo, então canonical e redirecionamentos, e por último desempenho de carregamento. Acompanhe no relatório de páginas do Search Console a razão entre indexadas e não indexadas e leia os motivos de recusa — eles nomeiam o erro.
No desempenho, a régua são as três Core Web Vitals, medidas no 75º percentil das visitas reais, separadas entre celular e computador. Os limites abaixo estão no web.dev, mantido pela equipe do Chrome; o INP substituiu o FID como métrica de resposta em 12 de março de 2024.
| Métrica | O que mede | Bom | Ruim |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Tempo até o maior elemento visível carregar | até 2,5 s | acima de 4 s |
| INP (Interaction to Next Paint) | Demora da página em reagir a clique ou toque | até 200 ms | acima de 500 ms |
| CLS (Cumulative Layout Shift) | Quanto o layout pula durante o carregamento | até 0,1 | acima de 0,25 |
Depois de destravar a base, o conteúdo passa a render; o método editorial está em marketing de conteúdo B2B, e a aplicação para catálogo em SEO para e-commerce. Outras análises ficam no hub de SEO.
Para os mesmos erros não voltarem, repita o diagnóstico de uma tarde a cada mudança de modelo de página, atualização grande da plataforma ou reforma: travamento técnico costuma voltar junto com a próxima publicação de código. Mais sobre as escolhas de sistema que sustentam o site está no hub de tecnologia.
Perguntas frequentes
Como saber se o meu site está bloqueado para o Google?
Abra o arquivo robots.txt do domínio e procure regras de bloqueio amplas, depois inspecione o HTML servido de páginas importantes em busca de noindex. O relatório de páginas do Search Console também nomeia o motivo da exclusão.
Site feito em framework moderno prejudica o SEO?
Não por si só. Prejudica quando o conteúdo só aparece depois do JavaScript. Com renderização no servidor ou pré-geração, título, texto e links chegam prontos no HTML e o problema desaparece.
Redirecionamento 301 passa autoridade?
Passa, mas cadeias com vários saltos desperdiçam sinal e tempo de carregamento. Aponte cada endereço antigo direto para o destino final e corrija os links internos.
Página sem conteúdo deve ficar no sitemap?
Não. O sitemap deve listar apenas endereços indexáveis, canônicos e que respondem com sucesso. Página noindex ou que redireciona envia sinal contraditório.
O que é soft 404?
É quando o endereço não existe, a tela mostra erro, mas o servidor responde código 200. O Google trata como página válida de baixa qualidade. O cabeçalho precisa devolver 404 ou 410.
