Auditoria de SEO técnico: um checklist priorizado para 2026

Resumindo: uma auditoria de SEO técnico responde a quatro perguntas, em ordem: o Google consegue acessar suas páginas, consegue indexar a versão certa de cada uma, consegue entender do que cada página trata, e a página funciona bem para as pessoas que ela recebe? Comece por códigos de status, robots.txt e regras de noindex; depois redirecionamentos, canonicals e sitemaps; depois títulos, dados estruturados e hreflang; por fim HTTPS, paridade mobile e Core Web Vitals. Corrija por impacto, não pelo tamanho da lista de problemas, e reverifique a cada release.

A maioria das auditorias falha do mesmo jeito. Um crawler lista 214 "problemas" ordenados por quantidade, e a equipe passa uma semana adicionando texto alternativo a imagens decorativas enquanto uma tag noindex esquecida do ambiente de staging mantém a página de preços fora do Google. Volume não é prioridade.

Este checklist segue o caminho que uma página percorre no Google: rastreada, indexada, entendida, entregue. Um problema no início da cadeia torna tudo o que vem depois irrelevante, então audite e corrija nessa ordem. Todas as regras abaixo vêm da documentação do Google.

O que uma auditoria de SEO técnico cobre

Uma auditoria técnica trata de acesso e interpretação, não de saber se o seu conteúdo merece ranquear. Os requisitos técnicos do Google são curtos: o Googlebot não está bloqueado, a página retorna HTTP 200 e a página tem conteúdo indexável. O Google acrescenta que cumpri-los "não significa que a página será indexada; a indexação não é garantida". Todo o resto de uma auditoria consiste em eliminar os motivos pelos quais o Google poderia ignorar, interpretar mal ou rebaixar uma página.

Antes de começar: quatro fontes da verdade

1. Relatório de indexação de páginas do Search Console: quais URLs o Google indexou e por que ignorou as demais.
2. Ferramenta de inspeção de URL: a visão do Google sobre uma URL, incluindo o HTML renderizado e o canonical que ele escolheu.
3. Um crawler de site: códigos de status, redirecionamentos, títulos e canonicals de todas as páginas que ele consegue alcançar.
4. Um verificador em nível de página: nosso verificador de SEO de sites gratuito executa 38 verificações na página que você informar (a home por padrão) e nos arquivos do site ao redor em cerca de 20 segundos.

Registre primeiro uma linha de base (páginas indexadas, páginas não indexadas por motivo, URLs encontradas pelo crawler); sem ela, você não saberá se as correções funcionaram.

Passo 1: o Google consegue acessar suas páginas?

Códigos de status

Toda URL que você quer na busca precisa responder com 200. O Google documenta como trata os demais códigos em How HTTP status codes affect Google Search e Redirects and Google Search:

Dois detalhes importam na prática. O Google diz que "todos os erros 4xx, exceto 429, são tratados da mesma forma", então um 404 e um 410 levam ao mesmo resultado. E o 429 é o código que firewalls e proteções contra bots enviam quando acham que um crawler está rápido demais, e por isso um produto de segurança pode reduzir silenciosamente a sua indexação.

O Google interpreta um meta refresh instantâneo como permanente e um com atraso como temporário. Redirecionamentos em JavaScript só funcionam se a renderização for bem-sucedida; a recomendação do Google é usá-los apenas quando redirecionamentos no servidor ou por meta refresh não forem possíveis.

robots.txt

O robots.txt gerencia o tráfego de crawlers. Segundo a introdução ao robots.txt do Google, ele "não é um mecanismo para manter uma página fora do Google". Uma página bloqueada "ainda pode ser indexada se for linkada por outros sites", aparecendo sem descrição.

Verifique três coisas:

• O arquivo existe na raiz e retorna 200 como texto simples, não como página HTML, ou um 404 limpo se você não precisa de regras. Nunca um 5xx: nesse caso o Google pausa o rastreamento.
• Nenhuma regra bloqueia as seções que você quer na busca. O desastre clássico é um Disallow: / copiado do staging.
• Os CSS e JavaScript necessários para renderizar a página não estão bloqueados.

O verificador de robots.txt lê o seu arquivo como o Googlebot e sinaliza regras que bloqueiam o site inteiro ou a página informada, além de um robots.txt que responde com erro de servidor.

noindex e X-Robots-Tag

Uma meta tag noindex ou um cabeçalho HTTP X-Robots-Tag: noindex mantém a página fora dos resultados. O cabeçalho também funciona para PDFs, imagens e vídeos, que não podem ter meta tag (Block Search indexing with noindex).

A armadilha: se o robots.txt bloqueia a mesma URL, "o crawler nunca verá a regra noindex, e a página ainda poderá aparecer nos resultados de busca". Para remover uma página, permita o rastreamento e sirva o noindex. Audite tanto o HTML quanto os cabeçalhos de resposta, porque CDNs e plugins podem adicionar X-Robots-Tag sem que ninguém edite a página.

Passo 2: o Google consegue indexar a versão certa?

Um site, um endereço

http://example.com, http://www.example.com, https://example.com e https://www.example.com são quatro URLs diferentes para um crawler. Escolha uma e redirecione permanentemente as outras três para ela em um único salto. Faça o mesmo com barras finais e caminhos em maiúsculas, se o seu servidor responder das duas formas. O verificador de redirecionamentos testa as quatro versões do host, mostra o código de status de cada salto e sinaliza redirecionamentos temporários, loops e cadeias longas.

Tags canonical

O guia de canonicalização do Google ordena os sinais: redirecionamentos e rel="canonical" são sinais fortes; a inclusão no sitemap é um sinal fraco. Todos são sinais, não comandos; o Google pode escolher outro canonical. Suas boas práticas:

• Use URLs absolutas nas tags canonical.
• Adicione um canonical autorreferente na própria página canônica.
• Indique o mesmo canonical em todos os métodos (tag, cabeçalho, sitemap).
• "Não use o arquivo robots.txt para fins de canonicalização."

Achados típicos: todas as páginas com canonical para a home, e canonicals apontando para URLs redirecionadas ou com 404.

Sitemaps XML

Segundo Build and submit a sitemap:

• Um único sitemap é limitado a 50.000 URLs ou 50 MB sem compactação. Sites maiores dividem em vários arquivos listados em um índice de sitemaps.
• O Google ignora <priority> e <changefreq>.
• O Google só usa <lastmod> "se for consistente e verificavelmente preciso", e ele deve refletir mudanças significativas, não um novo ano de copyright.
• Envie-o no Search Console e referencie-o no robots.txt com uma linha como Sitemap: https://example.com/sitemap.xml.

Um sitemap deve listar apenas URLs canônicas, indexáveis e que retornem 200. Redirecionamentos, 404 e páginas noindex no sitemap enviam sinais conflitantes e estão entre os achados mais comuns em um rastreamento.

Soft 404

Um soft 404 é uma página que retorna 200 mas parece um erro: uma categoria vazia, uma mensagem de "produto não encontrado", uma página de busca sem resultados. O Search Console as reporta em "Soft 404". Retorne um 404 ou 410 de verdade para conteúdo inexistente, ou coloque conteúdo útil na URL.

Renderização de JavaScript

O Google rastreia, depois renderiza com um Chromium headless e então indexa o HTML renderizado (JavaScript SEO basics). A renderização acontece "quando os recursos do Google permitirem", então o conteúdo que só existe depois da execução de scripts chega mais tarde e é mais frágil. Verifique:

• Os links são elementos <a> com href. O Google diz que "só consegue descobrir seus links" assim; manipuladores de clique em <div> ou <span> são invisíveis para ele.
• As rotas do lado do cliente usam a History API, não fragmentos #.
• Single-page apps evitam soft 404 redirecionando para uma URL que retorna 404 ou adicionando noindex às telas de erro.
• O texto importante está presente na resposta do servidor. O Google ainda recomenda renderização no servidor ou pré-renderização, e observa que "nem todos os bots executam JavaScript", o que importa ainda mais para crawlers de IA (veja o Passo 5).

Use o teste ao vivo da Inspeção de URL para comparar o HTML bruto com o HTML renderizado em um template de cada tipo.

Passo 3: o Google consegue entender cada página?

Títulos

A documentação de title link do Google pede um <title> distinto, descritivo e conciso em todas as páginas, sem keyword stuffing nem texto genérico repetido. Ela afirma que não há limite de comprimento, mas os títulos são truncados para caber no dispositivo. O Google também reescreve os title links automaticamente, usando o <title>, o título principal, og:title, o texto âncora e outras fontes, especialmente quando o título está ausente, duplicado ou pouco útil. Uma faixa prática de cerca de 30 a 60 caracteres mantém as palavras importantes visíveis; isso é uma convenção, não uma regra do Google.

Meta descriptions

O Google diz que os snippets "são criados principalmente a partir do próprio conteúdo da página" e que às vezes usa a meta description quando ela oferece um resumo mais preciso (Control your snippets). Não há limite de comprimento; o snippet é truncado conforme necessário. O que o Google alerta é contra descrições idênticas em muitas páginas e descrições feitas de listas de palavras-chave. Audite descrições ausentes e duplicadas nos seus templates importantes e escreva um resumo legível para cada um. O verificador de meta tags mostra uma prévia de como a página aparece nos resultados.

Dados estruturados

O Google recomenda JSON-LD "se a configuração do seu site permitir" e o Teste de Resultados Relevantes para validá-lo (intro to structured data). Em uma auditoria, verifique se cada template traz a marcação que deveria (Organization na home, Product nas páginas de produto, Article nos posts, BreadcrumbList onde há breadcrumbs), se ela é válida e se corresponde ao que está visível na página. Quais tipos ainda geram rich results em 2026 e como escrevê-los está no nosso guia de schema markup; o verificador de schema markup lista o que uma página declara hoje.

hreflang

Para sites com versões por idioma ou país, o guia de versões localizadas do Google define as regras:

• Use tags HTML link, cabeçalhos HTTP ou o sitemap; o Google os trata como equivalentes.
• Cada versão lista a si mesma e todas as outras versões. Anotações sem reciprocidade podem ser ignoradas.
• Use um código de idioma ISO 639-1, opcionalmente seguido de uma região ISO 3166-1 alpha-2 (en, en-GB, pt-BR). Um código de país sozinho é inválido.
• Use URLs absolutas e, opcionalmente, x-default para visitantes que não correspondem a nenhuma das suas versões.

O Google detecta o idioma da página pelo conteúdo, com seus próprios algoritmos, e não pelo hreflang nem pelo atributo lang; portanto, uma URL em alemão com texto em inglês continua sendo uma página em inglês. O verificador de hreflang valida os códigos contra essas regras, verifica a autorreferência e indica se x-default está definido; ele lê uma página, então confira também os links de retorno nas outras versões.

Passo 4: a página funciona bem para os visitantes?

HTTPS e conteúdo misto

Entregue todas as URLs via HTTPS com um certificado válido e redirecione o HTTP de forma permanente. As orientações de experiência da página do Google perguntam "Suas páginas são entregues de forma segura?". Procure também conteúdo misto (scripts ou imagens carregados via http://), que os navegadores bloqueiam parcialmente. O verificador de cabeçalhos de segurança cobre o certificado, o redirecionamento para HTTPS, o HSTS e o conteúdo misto.

Indexação mobile-first

"O Google usa a versão mobile do conteúdo de um site, rastreada com o agente de smartphone, para indexação e ranqueamento", segundo as boas práticas de indexação mobile-first. A pergunta da auditoria é a paridade: a versão mobile deve ter o mesmo conteúdo principal, os mesmos dados estruturados, as mesmas meta tags de robots e títulos e descrições equivalentes. O Google também alerta contra o lazy-loading do conteúdo principal acionado por interação do usuário, porque o Googlebot não clica, não desliza nem digita.

Observe que o Google aposentou o Teste de Compatibilidade com Dispositivos Móveis e o relatório de Usabilidade em dispositivos móveis do Search Console em 1º de dezembro de 2023, indicando o Lighthouse aos proprietários de sites (Google Search Central Blog). Nosso teste de compatibilidade com dispositivos móveis verifica o básico: a tag viewport, imagens responsivas, favicon e idioma da página.

Core Web Vitals

O Google afirma que "os Core Web Vitals são usados pelos nossos sistemas de ranqueamento", mas também diz que boas pontuações não garantem as primeiras posições e que a relevância vem primeiro. As metas no web.dev, medidas no percentil 75 das visitas reais:

O INP substituiu o First Input Delay como Core Web Vital em 2024. Em uma auditoria técnica, anote quais templates falham e siga em frente; diagnosticar e corrigir cada métrica é um projeto à parte, explicado passo a passo no nosso guia de Core Web Vitals. O verificador de Core Web Vitals lê os dados reais de usuários do Chrome do seu site.

Passo 5: preparo para a busca com IA

Para AI Overviews e AI Mode, o Google diz que a página precisa estar indexada e elegível para snippet, sem requisitos extras, e que a sua CDN ou hospedagem também deve permitir o rastreamento. Outros assistentes usam seus próprios crawlers: a OpenAI usa o OAI-SearchBot para a busca do ChatGPT e o GPTBot para treinamento, e sites que bloqueiam o OAI-SearchBot "não serão exibidos nas respostas da busca do ChatGPT". Audite três coisas: os crawlers de busca com IA são permitidos no robots.txt e pelo firewall, o conteúdo-chave está na resposta HTML e a home informa quem você é com a marcação Organization. O verificador de preparo para busca com IA testa os três; nosso guia de generative engine optimization cobre o resto.

Como ler o relatório de indexação de páginas

O relatório de indexação de páginas é onde a auditoria encontra a realidade. A própria formulação do Google: "Você não deve esperar que todas as URLs do seu site sejam indexadas, apenas as páginas canônicas." Portanto, o objetivo não é esvaziar a lista "Não indexadas". É garantir que toda página canônica importante esteja indexada e que cada exclusão seja intencional.

Depois de corrigir um problema em todos os lugares, clique em Validar correção. O Google diz que a validação é interrompida se restar uma única ocorrência e que "normalmente leva até cerca de duas semanas".

Inspeção de URL para páginas individuais

A ferramenta de inspeção de URL mostra a versão indexada (não a ao vivo) e, com Testar URL ao vivo, a página atual como o Googlebot a busca: disponibilidade, permissão de rastreamento e indexação, canonical declarado pelo usuário e selecionado pelo Google, captura de tela renderizada, HTML bruto, cabeçalhos HTTP e recursos carregados. Use-a em uma URL por template após cada correção. Solicitar indexação ajuda para algumas páginas-chave; para muitas páginas, o Google recomenda um sitemap com valores de lastmod precisos. Tanto as inspeções quanto as solicitações de indexação têm limites diários por propriedade.

Orçamento de rastreamento: só para sites muito grandes

O orçamento de rastreamento (crawl budget) é o problema mais diagnosticado em excesso no SEO. O guia de crawl budget do Google é escrito para sites com cerca de 1 milhão ou mais de páginas únicas que mudam semanalmente, sites com 10.000 ou mais páginas que mudam diariamente e sites com grande parte das URLs em "Descoberta: atualmente não indexada". O Google chama esses valores de estimativas aproximadas, não limites exatos, e diz que, se suas páginas são rastreadas no mesmo dia em que são publicadas, você não precisa do guia. Para a maioria dos sites, um sitemap atualizado e uma olhada regular na indexação de páginas bastam.

Como fazer a triagem: impacto vezes esforço

Avalie cada achado por impacto (quantas páginas importantes ele afeta e com que gravidade) e esforço (quão difícil é corrigir) e trabalhe de cima para baixo.

Corrija templates, não páginas: um título ausente em um template de produto é uma única correção.

Exemplo prático (hipotético)

O exemplo a seguir é hipotético, não são dados reais. A Northwind Outfitters, uma loja inventada de equipamentos outdoor com cerca de 1.200 páginas de produtos e categorias, faz uma auditoria após um redesign. O Search Console mostra 640 páginas indexadas, contra 1.050 antes do lançamento.

O crawler reporta 312 achados. Ordenados por quantidade, os três primeiros são texto alternativo ausente (148), títulos longos (61) e meta descriptions ausentes (40). Ordenados pela sequência deste checklist, o quadro muda:

1. Acesso: o robots.txt está correto, mas 38 URLs retornam 429 durante o rastreamento. A nova proteção contra bots limita a taxa de qualquer coisa mais rápida que uma pessoa.
2. Indexação: toda URL de categoria filtrada (?color=, ?size=) traz um canonical para si mesma, criando 400 quase duplicatas. O sitemap ainda lista 90 URLs antigas que agora redirecionam. Todas as páginas de produto em http://www. redirecionam duas vezes: para https://www. e depois para https://.
3. Compreensão: os 61 títulos "longos" passam do limite por poucos caracteres.
4. Experiência: o LCP falha no template de categoria porque a imagem hero tem lazy-loading.

A ordem de correção: liberar crawlers verificados na proteção contra bots, canonicalizar as URLs filtradas para a categoria sem filtro, regenerar o sitemap apenas com URLs canônicas, reduzir a cadeia de redirecionamento a um salto e então carregar a imagem hero da categoria de forma imediata. Texto alternativo e comprimento de títulos entram na próxima sprint de conteúdo. Seis semanas depois, a queda de indexação foi recuperada, e as URLs restantes "não indexadas" são as páginas filtradas, como pretendido.

Com que frequência auditar

Faça uma auditoria completa a cada trimestre e em torno de toda migração, redesign ou mudança de URL (rastreie o staging antes do lançamento e a produção no dia seguinte), e automatize o essencial toda semana: códigos de status, mudanças em noindex e robots.txt, erros de sitemap e a tendência da indexação de páginas. O SEO técnico raramente se degrada aos poucos; ele quebra no dia de um deploy.

Um checklist de uma hora para começar

1. Rode o verificador de SEO de sites gratuito e anote as falhas de alta prioridade.
2. Registre no Search Console as contagens de indexação de páginas por motivo.
3. Faça o teste ao vivo de uma URL por template na Inspeção de URL; compare o HTML bruto e o renderizado.
4. Verifique o robots.txt, as quatro versões do host e uma cadeia de redirecionamento.
5. Confira por amostragem dez URLs do sitemap: cada uma deve retornar 200, ser indexável e canônica.
6. Coloque os achados na tabela de impacto × esforço e corrija os três primeiros esta semana.

Como a Searvia executa uma auditoria de SEO técnico

O verificador de SEO de sites gratuito da Searvia lê a página que você informar (a home, se você informar só o domínio) e os arquivos do site ao redor (robots.txt, sitemap, llms.txt), seu certificado, seus registros DNS de e-mail e dados reais de velocidade de usuários do Chrome. Ele executa 38 verificações em seis seções: aparência na busca (9), rastreamento e indexação (6), preparo para busca com IA (7), velocidade (6), mobile (4) e segurança (6), e entrega uma nota de A+ a F com uma lista de correções priorizada e um relatório compartilhável. Versões focadas do mesmo motor estão listadas na página de ferramentas gratuitas.

Para o site inteiro, a Auditoria de site em uma conta Searvia rastreia suas páginas como um mecanismo de busca, agrupa os problemas em erros, avisos e notificações (páginas e links quebrados, redirecionamentos no sitemap, páginas noindex no sitemap, canonicals apontando para outro lugar, títulos duplicados, páginas órfãs e mais) e roda novamente toda semana, para você ver o que corrigiu e o que quebrou. O número de páginas por auditoria depende do seu plano; o plano gratuito cobre 100. Conecte o Search Console para ver a indexação e os cliques reais do Google ao lado da auditoria, e verifique seu site para enviar páginas novas e alteradas a mecanismos que suportam o IndexNow, como Bing e Yandex, após cada auditoria.