Um site pode ter um design bonito, um círculo verde no plugin de SEO e ainda assim perder pessoas antes mesmo de o conteúdo principal carregar. Ou o Google pode indexar uma URL diferente da que você espera. Ou um pedido pode funcionar, mas a mensuração pode enviá-lo duas vezes.
É por isso que não começo uma auditoria técnica perseguindo a pontuação cem em um único teste. Primeiro procuro erros que impeçam o negócio, a indexação ou o uso do site. Só depois aprimoro os pequenos detalhes.
1. Verifique se as URLs importantes retornam o status correto
Revise as principais páginas de serviços, os artigos que recebem tráfego, a página de contato e o caminho de conversão. Uma página importante deve retornar 200. Conteúdo movido permanentemente deve ter um único redirecionamento direto 301. Uma página removida não deve acabar silenciosamente na página inicial.
Também verifico as variantes HTTP e HTTPS, www e não-www, barras finais e parâmetros. O resultado deve ser uma única URL canônica. O Google descreve um redirecionamento como um forte sinal de canonização e recomenda combiná-lo com uma URL canônica e um sitemap consistentes em sua documentação sobre URLs canônicas.
2. Verifique a indexação pela perspectiva da página real
Robots.txt, meta robots, canonical e sitemap precisam funcionar em conjunto. Um erro comum é indexar uma página que não tem lugar na pesquisa enquanto se bloqueia conteúdo importante. Use a Inspeção de URL no Search Console em várias URLs representativas. Ela mostra o que o Google sabe sobre a página e permite testar a versão publicada.
- A URL canônica é a que você deseja?
- A página está disponível sem login ou bloqueios?
- O sitemap contém apenas URLs 200 indexáveis?
- Os links internos evitam redirecionamentos?
- Há páginas importantes órfãs?
O Google mantém uma visão geral dessas áreas em sua documentação sobre rastreamento e indexação.
3. Meça a velocidade nas pessoas, não apenas no laboratório
PageSpeed Insights e Lighthouse são ferramentas úteis de diagnóstico. Mas um teste de laboratório não é igual à experiência de visitantes reais. Os Core Web Vitals atuais são LCP, INP e CLS; os dados de campo trabalham com dispositivos e conexões reais. A documentação oficial do Web Vitals explica a visão geral e a diferença entre dados de campo e de laboratório.
Eu leria as prioridades assim:
- LCP: quando o conteúdo principal aparece.
- INP: quão rapidamente a página responde ao uso.
- CLS: se os elementos pulam durante o carregamento.
- TTFB e rede: se alguma coisa começa a acontecer rapidamente.
O Google também afirma explicitamente que uma boa pontuação não garante posições de destaque. A usabilidade geral é mais importante do que perseguir um único número. Consulte a documentação sobre experiência na página.
4. Encontre o verdadeiro culpado pelo carregamento
No waterfall e no DevTools, procure tempo longo de servidor, CSS e JavaScript bloqueadores, imagens grandes demais, fontes, solicitações repetidas e terceiros. A antiga regra de "combinar todos os arquivos" não é mais universal. Com protocolos modernos, a quantidade de código não utilizado e o bloqueio da thread principal podem importar mais.
- Carregue a imagem principal em um tamanho adequado e em um formato moderno.
- Defina as dimensões das imagens para que elas não desloquem o conteúdo.
- O conteúdo abaixo da primeira viewport pode usar carregamento lento nativo.
- Carregue apenas os pesos e conjuntos de caracteres necessários das fontes.
- Carregue scripts de marketing de forma assíncrona e apenas onde eles tiverem uma finalidade.
- Comprima os recursos de texto e defina um cache longo para arquivos versionados.
Um terceiro custa caro não apenas em milissegundos. Cada pixel, widget de chat e mapa de calor cria mais responsabilidades operacionais e de dados. Se ninguém usa o relatório, remova o script.
5. Percorra o site como cliente, com teclado e celular
No celular, percorra a navegação, o formulário, o diálogo de cookies e o pedido. Aumente o texto, desative as imagens e use um teclado. Os títulos devem formar uma estrutura compreensível, um formulário precisa de rótulos e uma mensagem de erro deve dizer o que corrigir.
Toda página deve ter uma tarefa principal. Isso não significa um botão a qualquer custo, mas uma hierarquia clara. Encontre outros pontos práticos no checklist básico de UX.
6. Corrija erros de recursos e JavaScript
Um 404 para uma imagem, fonte ou script não é algo cosmético. Ele pode quebrar a aparência, a mensuração ou a funcionalidade. Verifique os erros no console do navegador, as solicitações de rede malsucedidas e as respostas 5xx repetidas no servidor. Teste os caminhos críticos após cada implantação.
7. Use dados estruturados apenas para conteúdo verdadeiro
Schema não é uma forma de forçar avaliações com estrelas. É uma descrição legível por máquinas do que realmente está na página. Use um tipo compatível e teste-o no Rich Results Test. O Google lista os formatos compatíveis atuais e as ferramentas de teste em sua documentação sobre dados estruturados.
8. A mensuração não deve quebrar o site que deveria medir
Carregue GA4, plataformas de publicidade e outros scripts de forma não bloqueadora. Dê nome aos eventos com base nas decisões, não em cada clique. Verifique duplicidades, consentimento e se alguém realmente usa os dados. Encontre uma base prática nos artigos sobre Google Tag Manager e Google Analytics 4.
9. Dinheiro e risco determinam a ordem das correções
- Um pedido, formulário ou login quebrado.
- Uma página importante indisponível ou não indexável.
- Um problema de segurança e componentes desatualizados.
- Grandes problemas de usabilidade móvel e Core Web Vitals.
- Erros de mensuração que levam a decisões ruins.
- Só depois, pontuações menores e problemas cosméticos.
SEO técnico é a linha de largada. Ele não vence a corrida sozinho, mas um site quebrado pode perdê-la antes do tiro de largada. Se você precisa transformar descobertas técnicas em prioridades de negócio, pode descrever o site e a decisão que está enfrentando.