Auditoria de SEO técnico, o checklist que eu uso e em que ordem

Auditoria de SEO é a revisão de um site para achar o que impede o Google de rastrear, indexar e ranquear as páginas. A parte técnica segue uma ordem, porque um erro de rastreio anula qualquer ajuste de conteúdo feito depois. Eu começo pelo robots.txt, termino nos logs do servidor e entrego uma lista de correções priorizada por impacto e esforço.

SEO técnico é a parte do SEO que cuida da estrutura do site, como rastreio, indexação, velocidade, código e dados estruturados. Não é o texto, é o que deixa o texto ser encontrado. Abaixo está o checklist que eu uso, na ordem, com o que olhar e qual ferramenta abrir.

Por que a ordem importa

O Google trabalha em cadeia. Primeiro o robô precisa chegar na página. Depois ele decide se guarda a página no índice. Só então ela disputa posição. Se a cadeia quebra no primeiro elo, o resto não chega a acontecer.

Por isso eu não começo pela velocidade nem pelo schema. Um site com Core Web Vitals perfeitos e metade das páginas fora do índice continua perdendo tráfego.

O que separar antes de começar

• Acesso ao Google Search Console, de preferência como propriedade de domínio.
• Acesso ao GA4, para saber quais páginas trazem visita e conversão.
• Um crawler, programa que navega pelo site como o Googlebot e lista todas as URLs. Eu uso o Screaming Frog.
• PageSpeed Insights, para dados de velocidade de usuários reais.
• Logs do servidor dos últimos 30 dias, se o site for grande.
• A lista das 100 URLs com mais tráfego orgânico. Elas recebem atenção primeiro, porque é onde um erro custa mais.

1. Rastreio e robots.txt

Rastreio é o robô do Google visitar a página e baixar o HTML. O robots.txt é um arquivo na raiz do site que diz ao robô o que ele pode e o que não pode visitar.

O que eu olho.

• Se o robots.txt bloqueia pastas importantes, ou bloqueia CSS e JavaScript que a página precisa para ser montada.
• Se alguém usou o robots.txt para tirar páginas do Google. Isso não funciona. O próprio Google diz que o robots.txt não é um mecanismo para manter uma página fora dos resultados, e que o certo é usar noindex ou senha (guia do robots.txt).
• Páginas que respondem 404 ou 5xx e ainda recebem link interno.
• Cadeias de redirecionamento, quando uma URL leva a outra que leva a uma terceira.

Ferramenta. Crawler para status e redirecionamentos, e o relatório de robots.txt do Search Console.

2. Indexação no Search Console

Indexação é o Google guardar a página no índice. Página fora do índice não aparece em busca nenhuma, nem nos recursos de IA.

O relatório de indexação de páginas do Search Console mostra o motivo de cada página ficar de fora (ajuda do Search Console). Três status pedem atenção quase sempre.

• "Rastreada, mas ainda não indexada". O Google leu a página e escolheu não guardar. Costuma ser sinal de página fraca, parecida demais com outra, ou com poucos links internos apontando para ela.
• "Detectada, mas não indexada no momento". O Google sabe que a URL existe e ainda não visitou. Em site grande, é um sinal de que o rastreio está curto para a quantidade de URLs.
• "Cópia, o Google e o usuário não escolheram a mesma página canônica". Você disse que a página é a principal, e o Google discordou e indexou outra.

O que eu olho. A proporção entre páginas indexadas e páginas que deveriam estar indexadas. E se alguma das 100 URLs principais aparece em algum desses status.

Ferramenta. Relatório de indexação de páginas e a ferramenta de inspeção de URL, que mostra como o Google vê uma página específica.

3. Sitemap

O sitemap é um arquivo XML com a lista das URLs que você quer no índice. Ele ajuda o Google a descobrir páginas novas.

O que eu olho.

• Se cada arquivo respeita o limite de 50.000 URLs ou 50 MB sem compressão.
• Se as URLs são absolutas e só as canônicas. Página com noindex, redirecionada ou com erro não deveria estar lá.
• Se o lastmod mostra a data real da última mudança importante. O Google só usa esse campo quando ele é correto de forma consistente, e ignora priority e changefreq (guia de sitemaps do Google).

Ferramenta. Relatório de sitemaps do Search Console e o crawler em modo de lista, rodando só as URLs do sitemap. Para site com milhares de URLs, o guia de sitemap dinâmico em escala mostra como gerar sem estourar memória.

4. Canonical e duplicação

Canonical é a URL principal de um conteúdo que existe em mais de um endereço. Isso acontece muito. Versão com e sem barra no fim, com e sem www, com parâmetro de filtro, com parâmetro de campanha.

A tag rel="canonical" e o redirecionamento são indicadores fortes para o Google escolher a canônica, e o sitemap é um indicador fraco (guia de URLs canônicos). São indicadores, não ordens. Quando eles se contradizem, o Google escolhe sozinho.

O que eu olho.

• Se toda página indexável tem canonical apontando para ela mesma, ou para a versão principal.
• Se o canonical, o sitemap e os links internos apontam para a mesma URL.
• Se HTTP, não-www e barra no fim redirecionam com um único 301 para a versão certa.
• Se parâmetros de filtro e de busca interna geram milhares de URLs rastreáveis.

Ferramenta. Crawler, com o relatório de canonicals, e a inspeção de URL do Search Console, que mostra a canônica declarada e a canônica escolhida pelo Google lado a lado.

5. Arquitetura e link interno

Arquitetura é como as páginas se ligam umas às outras. O Google usa links para encontrar páginas novas e para entender a relevância de cada uma. E ele, em geral, só consegue seguir um link se for um elemento HTML <a> com atributo href (guia de links do Google).

O que eu olho.

• Páginas órfãs, que estão no sitemap mas não recebem nenhum link interno.
• Profundidade de clique, quantos cliques a partir da home até chegar numa página importante.
• Links feitos em JavaScript, como botão com onclick no lugar de <a href>.
• Texto âncora, se o texto do link diz do que trata a página de destino.

Ferramenta. Crawler, cruzado com a lista do sitemap para achar órfãs. Em site com muito conteúdo, o post sobre link interno semântico sem plugin mostra como automatizar.

6. Renderização de JavaScript

O Google processa páginas com JavaScript em três fases, rastreamento, renderização e indexação (noções básicas de SEO com JavaScript). Renderizar é executar o JavaScript para montar a página final. Se o conteúdo só aparece depois dessa etapa, ele depende de uma fase a mais para ser visto.

O mesmo guia diz que renderizar no servidor ou antes ainda é uma ótima ideia, porque deixa o site mais rápido e porque nem todo robô executa JavaScript. Isso pesa ainda mais hoje, com robôs de IA lendo o site.

O que eu olho. Comparo o HTML que o servidor entrega com o HTML renderizado. Título, H1, texto principal, links e schema precisam estar nos dois.

Ferramenta. Inspeção de URL do Search Console, na opção de testar a URL publicada e ver a página rastreada. E o crawler com renderização ligada e desligada, para comparar.

7. Core Web Vitals

Core Web Vitals são três métricas de experiência. LCP mede o carregamento do maior elemento visível. INP mede a resposta a cliques e toques. CLS mede o quanto o layout pula. O bom é LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1, medidos no 75º percentil das visitas, separado por celular e computador (web.dev).

O que eu olho.

• O relatório de Core Web Vitals do Search Console, que agrupa páginas parecidas. Um problema num modelo de página costuma afetar centenas de URLs de uma vez.
• Dado de campo (usuários reais) antes de dado de laboratório.
• Imagem principal pesada, CSS bloqueando a renderização, JavaScript de terceiros no <head> e redirecionamentos na home.

Ferramenta. Search Console, PageSpeed Insights e o painel de performance do Chrome. Para WordPress, o passo a passo está em Core Web Vitals no WordPress sem plugin de cache.

8. Dados estruturados

Dados estruturados (ou schema) são um código que descreve a página para o Google em formato de dados, como "isto é um artigo, de tal autor, publicado em tal data". O Google recomenda o formato JSON-LD quando o site permite (introdução aos dados estruturados). Schema bem feito pode ativar resultados enriquecidos, mas não garante que eles apareçam.

O que eu olho.

• Se o tipo de schema bate com o tipo de página. Article em post, Product em produto, Organization e Person na página sobre.
• Se os campos obrigatórios estão preenchidos e sem erro.
• Se o schema está no HTML do servidor, e não injetado por JavaScript depois.
• Se as datas do schema batem com as datas visíveis na página.

Ferramenta. Teste de pesquisa aprimorada do Google, inspeção de URL e os relatórios de aprimoramentos do Search Console.

9. Conteúdo e canibalização

Só aqui eu entro no conteúdo, pelo lado técnico. Canibalização é quando duas ou mais páginas do mesmo site disputam a mesma busca. O Google alterna entre elas, e nenhuma se firma.

O que eu olho.

• Títulos e H1 duplicados ou vazios.
• Meta description ausente nas páginas com mais impressão.
• Páginas finas, com pouco texto próprio, geradas por tag, filtro ou modelo.
• Buscas em que duas URLs do site trocam de posição no Search Console.
• Se o primeiro parágrafo das páginas principais responde a busca de forma direta.

Ferramenta. Search Console, no relatório de desempenho filtrado por consulta, e o crawler para títulos e H1. O método completo de achar e corrigir está no guia de canibalização de palavras-chave.

10. Logs do servidor

O log do servidor registra cada visita, inclusive as do Googlebot. É o único lugar que mostra o que o robô fez de verdade.

O que eu olho.

• Onde o Googlebot gasta as visitas. Se ele passa a maior parte do tempo em URLs de filtro e paginação, sobra pouco para as páginas que importam.
• Páginas importantes que o robô não visita há semanas.
• Se a visita é mesmo do Google. Muita ferramenta finge ser Googlebot. O Google ensina a confirmar com uma busca de DNS reversa no IP ou comparando com a lista de IPs que ele publica (como verificar o Googlebot).

Essa etapa vale mais em site grande. O guia do Google sobre orçamento de rastreio é voltado para sites com mais de 1 milhão de páginas que mudam toda semana, ou mais de 10 mil páginas que mudam todo dia, ou com muitas URLs em "Detectada, mas não indexada no momento" (gerenciamento do orçamento de rastreio). Em site pequeno, eu pulo os logs e confio no Search Console.

Ferramenta. Screaming Frog Log File Analyser, ou uma consulta direta nos logs com grep e uma planilha.

Como priorizar por impacto e esforço

Uma auditoria acha dezenas de problemas. Lista sem ordem é o jeito mais rápido de nada ser corrigido. Eu dou duas notas para cada item.

• Impacto. Quantas URLs o problema afeta, multiplicado pelo tráfego ou pela receita dessas URLs. Problema que bloqueia rastreio ou indexação ganha nota máxima.
• Esforço. Quantas horas de desenvolvimento leva e quantas pessoas precisam aprovar.

Com as duas notas, cada item cai num destes quatro grupos.

	Esforço baixo	Esforço alto
Impacto alto	Fazer já. Ex. robots.txt bloqueando pasta, canonical errado num modelo de página.	Planejar no próximo ciclo. Ex. trocar renderização no cliente por renderização no servidor.
Impacto baixo	Juntar num lote de manutenção. Ex. meta descriptions ausentes em páginas com pouca impressão.	Deixar para depois, ou não fazer. Ex. refazer o tema inteiro por ganho pequeno de velocidade.

Problema em modelo de página vem antes de problema em página solta. Corrigir o modelo de post corrige mil posts de uma vez.

Se o site vai passar por mudança de domínio, de plataforma ou de estrutura de URL, a auditoria precisa ser feita antes e repetida depois. O guia de migração de SEO sem perder tráfego mostra o que comparar.

Exemplo real, o checklist no SanarMed

No blog do Sanar Medicina, a maior plataforma de educação médica do Brasil, eu estruturei o sistema editorial entre 2024 e 2026. Em dois anos, o sistema publicou 1.113 artigos. Quando entrei, 88 das 100 URLs mais acessadas estavam sem nenhum checklist de SEO técnico aplicado.

Comecei pelas 100 URLs com mais tráfego, porque era onde cada ajuste rendia mais. Cada URL passava por um checklist curto, com title, H1, schema, canonical, Core Web Vitals e link interno, e recebia um status de ajuste. No fechamento do ciclo 2024 e 2025, as 88 estavam com pelo menos um ajuste aplicado.

Em paralelo, 113 palavras-chave paradas na quarta página do Google entraram num plano de empurrada, com reescrita de introdução, ajuste de schema e link interno para a URL alvo. Em 2024 o time fez 332 otimizações de posts existentes contra 228 posts novos. Auditoria virou rotina do sistema, não um projeto que acaba.

O case completo está em sistema editorial em escala no SanarMed, 1.113 posts.

Perguntas frequentes

Auditoria de SEO e auditoria de SEO técnico são a mesma coisa?

Não exatamente. A auditoria de SEO completa olha técnica, conteúdo e links de outros sites. A de SEO técnico olha a estrutura, que é o que vem primeiro. Neste checklist, as etapas 1 a 8 e a 10 são técnicas, e a 9 faz a ponte com o conteúdo.

Com que frequência devo auditar o site?

Eu faço uma auditoria completa uma vez e depois transformo as etapas em rotina. Search Console toda semana, as 100 URLs principais todo mês e o resto a cada trimestre ou depois de uma mudança grande.

Ferramenta gratuita resolve?

Para começar, sim. Search Console, PageSpeed Insights e o Teste de pesquisa aprimorada são gratuitos e cobrem boa parte das etapas. A versão gratuita do Screaming Frog rastreia até 500 URLs por vez (site do Screaming Frog), então em site grande a licença paga se paga rápido.

A auditoria já entrega as correções?

Em geral, ela entrega um relatório. No meu caso, eu também escrevo o código quando o cliente quer, do robots.txt ao schema.

Se você quer essa auditoria no seu site, com a lista priorizada e as correções implementadas, veja como funciona o serviço de SEO técnico. Se a necessidade é um acompanhamento mensal, com estratégia além da parte técnica, o caminho é a consultoria de SEO.