Conteúdo
- Por que auditoria técnica segue sendo a base do SEO
- As 400 verificações em 8 áreas
- Hospedagem nacional vs internacional: o dilema brasileiro
- Core Web Vitals medidos com 4G local
- Como o Semalt prioriza o que consertar primeiro
- Os 12 achados mais comuns em sites .com.br
- Caso prático: clínica em Botafogo
- Perguntas frequentes
Por que auditoria técnica segue sendo a base do SEO
Fala-se muito de conteúdo, backlinks e experiência do usuário, e todos são fatores reais. Mas por baixo de tudo existe uma camada técnica que decide, antes de qualquer outra coisa, se o Googlebot consegue acessar sua página, entender o conteúdo e resolver mostrá-la na SERP. Se essa camada está quebrada, não há estratégia de conteúdo que compense.
No Brasil o problema se amplifica por três fatores locais: hospedagem compartilhada com o hemisfério norte, conectividade móvel mais fraca do que na Europa ou nos EUA e orçamentos apertados que levam a stacks WordPress + plugins que acumulam camadas e camadas de código. Uma auditoria genérica feita de um servidor em Dublin te dá métricas irreais: TTFB de 200 ms quando o usuário brasileiro vê 900 ms, LCP verde no Lighthouse quando a realidade de campo (CrUX) está no vermelho.
A auditoria técnica do Semalt foi desenhada com esse problema em mente. Roda 400 verificações com crawler próprio de IPs em São Paulo, Rio, Brasília, Fortaleza e Porto Alegre, e cruza os resultados com Chrome UX Report para medir a experiência real do usuário latino-americano, não a do laboratório.
O erro mais comum de auditorias genéricas
O Screaming Frog rodando de um PC local com fibra 300 mega te mostra TTFB de 120 ms. O site rankeia mal e você não entende por quê. A verdade: de um IP móvel da Vivo Brasil o mesmo servidor demora 940 ms. O Semalt mede isso por padrão e a partir de cinco pontos do país.
As 400 verificações em 8 áreas
Cada auditoria agrupa as checagens em oito categorias. No final gera um score global (0-100) e um score por categoria, com tickets acionáveis ordenados por impacto em tráfego orgânico estimado.
| Área | Checagens | Exemplos |
|---|---|---|
| Crawlabilidade | 52 | robots.txt, sitemap, redirect chains, órfãs |
| Indexação | 48 | noindex acidental, canonical quebrado, hreflang |
| On-page técnico | 67 | title/H1 duplicado, meta longa, structured data |
| Performance | 61 | LCP, INP, CLS, TTFB, tamanho do DOM |
| Mobile | 39 | viewport, tap targets, conteúdo escondido |
| Segurança | 34 | HTTPS, HSTS, mixed content, headers |
| Estrutura e links | 58 | profundidade, anchor text, PageRank interno |
| Assets e mídia | 41 | imagens sem alt, formatos legados, lazy load |
Hospedagem nacional vs internacional: o dilema que quebra sites brasileiros
Um debate histórico entre agências brasileiras é se compensa hospedar no país (UOL Host, Hostinger BR, KingHost, Locaweb) ou fora (SiteGround, Hetzner, DigitalOcean EUA). Cada lado tem argumentos válidos. O Semalt traz dados que resolvem o debate site a site.
Hospedagem nacional
TTFB de IP brasileiro: 90-180 ms. Bom resultado para usuários locais, mas costuma ficar aquém em CDN, HTTP/3 e edge computing. Fatura em reais, suporte em horário BR, LGPD nativa.
Hospedagem internacional + CDN
Servidor de origem nos EUA ou Europa com Cloudflare/Fastly na frente. TTFB do Brasil pode cair para 60-90 ms se o edge estiver em São Paulo. Requer configuração cuidadosa de cache e purge.
A auditoria do Semalt roda testes cruzados: mede TTFB de cinco pontos (São Paulo, Rio, Brasília, Fortaleza, Porto Alegre) e compara com o que um usuário móvel real vê. Depois recomenda uma de três rotas:
- Manter a hospedagem nacional se o TTFB médio está abaixo de 250 ms e o site é estático ou pouco dinâmico.
- Adicionar CDN Cloudflare (plano grátis ou Pro) se a hospedagem internacional passa de 400 ms do BR.
- Migrar para edge computing se o site é e-commerce com mais de 1.000 SKUs e o TTFB atual passa de 600 ms.
Dado: Cloudflare em São Paulo
A Cloudflare tem POP em São Paulo desde 2014 e em 2024 somou POPs no Rio e em Fortaleza. Um site com edge cache bem configurado responde em 45-70 ms para 92 % do país. A auditoria do Semalt verifica se sua configuração aproveita esses POPs ou está passando ao largo por regras mal montadas.
Realidade brasileira: 78% dos sites de PME auditados em 2025 têm latency > 800ms para IPs em Manaus / Belém / Fortaleza (contra < 300ms em SP/RJ). Isso derruba Core Web Vitals na medição real do CrUX.
Core Web Vitals medidos com 4G local, não com fibra de laboratório
O Google considera Core Web Vitals sinal de ranqueamento desde junho de 2021, com atualização em 2024 substituindo FID por INP. O problema para o Brasil: a maioria dos checkers online (PageSpeed Insights incluído) roda teste de laboratório com Moto G4 simulado e rede 4G padrão. A realidade brasileira é pior.
O Semalt integra três camadas de medição:
- Laboratório — Lighthouse rodado com perfis ajustados a redes reais da Vivo, Claro e TIM Brasil.
- Campo (CrUX) — dados reais de usuários Chrome desagregados por origem e por dispositivo.
- Real User Monitoring próprio — script de 4 KB que captura LCP/INP/CLS de cada visita real, sem depender do CrUX (útil para sites pequenos que não têm dados de campo no Search Console).
| Métrica | Limiar bom | Limiar ruim | Método Semalt |
|---|---|---|---|
| LCP | < 2.5 s | > 4.0 s | Lab + campo + RUM |
| INP | < 200 ms | > 500 ms | RUM (obrigatório) |
| CLS | < 0.1 | > 0.25 | Lab + RUM |
| TTFB | < 800 ms | > 1.8 s | Cinco pontos BR |
| FCP | < 1.8 s | > 3.0 s | Lab + RUM |
A diferença entre laboratório e realidade fica óbvia. Muitas agências brasileiras «passam no Lighthouse» e não entendem por que o site não rankeia: o sinal que o Google usa é o de campo, não o do teste.
Como o Semalt prioriza o que consertar primeiro
O diferencial da plataforma é que ela não joga 400 tickets desordenados no seu colo. Cada achado tem um score de impacto que combina cinco variáveis:
Peso Google
Quão próxima a checagem é de fator de ranqueamento direto (score 1-10 baseado em documentação oficial e estudos recentes).
URLs afetadas
Quantidade de páginas do site que falham a checagem, ponderada pelo tráfego orgânico atual.
Facilidade de fix
Estimativa em horas de dev, de 1 (edit rápido) a 10 (refactor pesado).
Tráfego em risco
Sessões orgânicas das URLs afetadas nos últimos 90 dias.
Correlação histórica
Quanto ganharam sites parecidos que consertaram o mesmo problema, segundo base de casos do Semalt.
Custo de oportunidade
Tráfego projetado se o problema for resolvido nas próximas 4 semanas.
O output final é uma lista de 15 a 25 tickets acionáveis (não 400), ordenados por impacto/esforço. Cada ticket vem com: URLs afetadas, código de exemplo do fix, tempo estimado de dev e ganho projetado em sessões/mês.
Os 12 achados mais comuns em sites .com.br e .br
Com mais de 8.000 sites brasileiros auditados, o Semalt identificou um padrão claro de erros recorrentes. Estes são os doze que aparecem em mais de 40 % das auditorias:
Os 12 problemas técnicos mais comuns no Brasil
- Redirect chains com 3+ pulos (Nginx mal configurado com regras legadas).
- Canonical apontando para versão
http://em sites já migrados para HTTPS. - hreflang incompleto (falta a referência recíproca na versão em inglês).
- Imagens em JPG pesado (400-800 KB) sem conversão automática para WebP.
- WordPress com 15+ plugins que somam 1.4 MB de JS bloqueante.
- Sitemap.xml desatualizado, gerado por plugin que não roda há meses.
- Structured data de produto com preço em USD quando o site vende em BRL.
- TTFB > 1.5 s por PHP-FPM sem OPcache ou com OPcache mal configurado.
- LCP de imagem hero sem
fetchpriority="high"nem preload. - Meta robots
noindexesquecido da fase de staging. - Páginas de filtros de e-commerce indexadas gerando thin content em massa.
- Certificado SSL válido mas configuração TLS 1.0 ativa (falha no Observatory da Mozilla).
Dado de campo
De cada 10 sites brasileiros auditados pelo Semalt no primeiro trimestre de 2026, sete tinham redirect chains problemáticas e seis tinham imagens hero sem otimização. São fixes de menos de 4 horas de dev e costumam recuperar entre 12 e 25 % de tráfego orgânico em 60 dias.
Caso prático: clínica médica em Botafogo
Clínica multiespecialidade em Botafogo com site de 340 páginas (serviços, profissionais, blog, agendamento online). Score técnico inicial do Semalt: 42/100. Vinham perdendo tráfego orgânico desde o core update de março 2025 sem explicação aparente.
Auditoria inicial e triagem
A auditoria detectou 187 issues técnicos. O Semalt reduziu para 18 tickets acionáveis ordenados por impacto/esforço. Os 5 principais explicavam 74 % da queda de tráfego.
Fixes críticos
Resolvido: hreflang quebrado (versão em inglês para gringos), sitemap desatualizado (faltavam 90 páginas novas), redirect chain em /especialidades/ e LCP de hero em 4.8 s por imagens sem otimizar.
Fixes de estrutura
Nova paginação no blog, canonical corrigido em fichas de profissional duplicadas, structured data MedicalOrganization implementado em todas as páginas de serviço.
Re-auditoria
Score técnico subiu para 84/100. Sessões orgânicas +47 % mês contra mês. Impressões no Search Console +82 %. Agendamentos online originados de busca orgânica dobraram.
Contratamos cinco auditorias técnicas diferentes em quatro anos. Todas tinham razão em alguma coisa. Nenhuma priorizou bem. O Semalt nos deu 18 tickets com impacto projetado em reais e em agendamentos e com isso convencemos a diretoria a aprovar o sprint técnico.
Dra. Camila S. — Diretora médica, clínica em BotafogoMais nesta série: Por que o GA4 esconde seu tráfego orgânico, Mudanças SEO em 3 minutos, sem dev interno, Keywords em português: IA treinada no Brasil.
Perguntas frequentes
Roda a partir do Brasil ou de fora?
Os dois. O crawler tem POPs em São Paulo, Rio, Brasília, Miami e Irlanda. Por padrão roda de São Paulo para sites .com.br; os outros POPs servem para verificar disponibilidade global e hreflang.
Quanto pesa o crawl para o servidor?
Menos do que uma visita normal. O bot respeita robots.txt, faz throttling automático se detecta latência crescente, e por padrão não passa de 2 requests por segundo em sites pequenos. Dá para subir para 10 rps com autorização do cliente.
Serve para Vue/React/Next.js com conteúdo dinâmico?
Sim. O Semalt renderiza JavaScript com Chrome headless real (não simulação) e verifica se o conteúdo crítico está presente no DOM inicial e não só depois da hidratação. Sites Next.js com SSR ou ISR são auditados igual a um WordPress; SPAs puros recebem warnings específicos.
De quanto em quanto tempo compensa rodar uma auditoria?
A primeira é completa e leva 8-15 minutos. Depois dá para configurar diferencial mensal (só mudanças) que roda em 2 minutos. Em sites com deploy frequente dá para engatar no CI/CD e rodar em cada release para bloquear regressões técnicas.
Substitui o Screaming Frog?
Cobre o mesmo e muito mais. O Screaming Frog segue útil para explorações ad-hoc com lógica custom. O Semalt é a ferramenta de produção: fica na nuvem, roda automático, prioriza tickets e trackeia evolução histórica.
Auditoria técnica grátis
Entre com seu Search Console, valide o domínio e em 8-15 minutos você tem a primeira auditoria completa. Sem cartão de crédito.
Rodar auditoria agora →Nenhuma ferramenta genérica te dá a foto real do seu site brasileiro porque nenhuma mede do Brasil. Se o seu site tem mais de 150 URLs e perdeu tráfego depois de um core update, rode a auditoria técnica do Semalt essa semana.