Auditoria Técnica de SEO: Rastreamento, Indexação, Arquitetura e Core Web Vitals

A maioria das "auditorias técnicas de SEO" termina como PDFs de 200 páginas arquivados em uma pasta do Google Drive que ninguém abre. A engenharia as ignora porque leem como artigos acadêmicos: inventários de problemas sem triagem, sem templates de ticket e sem estimativas de tráfego associadas às correções.

Esta é a versão para ICs. Cinco áreas focadas, diagnósticos nomeados e uma fila de tickets que seus engenheiros vão realmente incluir no próximo sprint. O valor da auditoria não está na apresentação. Está no PR mesclado.

Se você sair de uma auditoria trimestral com uma planilha de 47 abas, mas nenhum commit, você fez um projeto de pesquisa, não uma auditoria.

O Framework de Auditoria em 5 Áreas

Toda auditoria técnica que eu conduzo cobre as mesmas cinco áreas, nesta ordem, porque as dependências fluem para baixo: não faz sentido otimizar os CWV em páginas que o Google não consegue rastrear, nem corrigir schema em páginas que não estão indexadas. Trabalhe o funil.

1. Rastreabilidade
2. Cobertura de indexação
3. Arquitetura e links internos
4. Core Web Vitals
5. Dados estruturados

Você consegue concluir o primeiro ciclo em dois dias focados para um site com menos de 50 mil URLs. Para sites maiores, planeje uma semana e apoie-se mais na amostragem de logs.

1. Rastreabilidade

Ferramentas: Screaming Frog ou Sitebulb para o crawl completo, logs de servidor para o que o Googlebot realmente acessa, testador de robots.txt no GSC.

Comece com o robots.txt. Leia linha por linha. Em seguida, verifique o que está bloqueado no nível de diretório versus no nível de padrão. Os erros clássicos que encontro pelo menos uma vez por trimestre:

• Regras de staging vazando para produção. Alguém copia Disallow: / do ambiente de staging para o robots.txt de produção durante um deploy. O site inteiro some em 48 horas. A correção são dois caracteres. O dano são seis semanas.
• Rotas /api/ bloqueadas acidentalmente quando servem conteúdo hidratado. Alguns aplicativos Next.js e Nuxt buscam de /api/... para dados de ISR ou SSR. Se esses endpoints estão bloqueados, o Googlebot vê páginas parcialmente renderizadas na segunda passagem.
• CSS e JS bloqueados. Ainda acontece. O Googlebot precisa renderizar a página. Se não consegue carregar a folha de estilo, as verificações de compatibilidade mobile falham e o posicionamento cai.
• Bloqueio em navegação facetada que também concentra 60% do tráfego de cauda longa. Comum em e-commerce. Bloquear URLs de parâmetros no robots.txt também bloqueia os sinais canonical que teriam consolidado essas páginas.

Após o robots.txt, execute um crawl completo no Screaming Frog com renderização de JavaScript ativada. Compare o HTML renderizado com o HTML bruto. Se a versão renderizada tiver 3.000 palavras a mais do que a bruta, você tem um problema de renderização de JS (mais sobre isso abaixo).

Em seguida, amostre os logs do servidor. Duas semanas de logs de acesso filtrados por user agents do Googlebot. Agrupe por código de status e padrão de URL. Você está buscando:

• Erros 5xx chegando ao Googlebot (servidor não consegue acompanhar a taxa de crawl)
• Soft 404s (status 200 com conteúdo de "página não encontrada")
• Armadilhas de crawl (combinações infinitas de parâmetros em navegação facetada, widgets de calendário que chegam ao ano 3024, IDs de sessão em URLs)

O orçamento de rastreamento só importa em sites com mais de 100 mil URLs. Se você tem um site SaaS com 800 páginas, pare de se preocupar com orçamento de rastreamento e preocupe-se com o motivo de 12 dessas 800 páginas gerarem 90% do tráfego orgânico.

2. Cobertura de Indexação

Ferramentas: Relatório de Indexação do GSC (agora chamado de relatório de Páginas), Screaming Frog comparando páginas rastreadas versus indexadas.

Abra o relatório de Páginas do GSC. Filtre por "Não indexado". Leia cada motivo de status. Os dois que geram mais bugs de regressão:

• "Descoberto, ainda não indexado." O Google encontrou a URL, mas não a buscou. Geralmente significa baixa prioridade de rastreamento (conteúdo ralo, poucos links internos) ou servidor lento.
• "Rastreado, atualmente não indexado." O Google buscou e decidiu não indexar. Esse é um sinal de qualidade. Conteúdo ralo, quase-duplicatas e páginas consideradas de baixo valor acabam aqui. Resolver isso é um problema de conteúdo, não técnico. Não abra ticket para a equipe de dev por "Rastreado, não indexado."

Os clássicos:

• Noindex em páginas importantes. O erro clássico. Alguém adiciona <meta name="robots" content="noindex"> em um arquivo de layout usado pelo diretório /blog/ inteiro e o tráfego despenca em 30 dias. Já vi isso partir de um dev que estava testando um único artigo e esqueceu de reverter a mudança no layout. Sempre verifique a base de código em busca de noindex durante uma auditoria. Sempre.
• Incompatibilidades canonical. A página A tem <link rel="canonical" href="pagina-b"> e a página B tem <link rel="canonical" href="pagina-a">. O Google escolhe uma e ignora a outra, mas é uma questão de sorte saber qual. Correção: toda página aponta canonical para si mesma, a menos que haja uma razão deliberada de consolidação.
• Tratamento de parâmetros. Parâmetros UTM, IDs de sessão, ordenações, combinações de filtros. Cada variante é uma URL separada para o Google, a menos que você canonicalize. Regra padrão: toda URL com parâmetro aponta canonical para a URL base limpa. Exceção apenas para parâmetros que alteram o conteúdo de forma significativa (como variantes de produto).
• Erros de hreflang. Se você opera em múltiplos idiomas, erros na tag de retorno de hreflang se propagam em cascata. O relatório de Segmentação Internacional do GSC ainda exibe esses erros.

Verificação de sanidade: faça site:seudominio.com no Google. O número retornado deve corresponder aproximadamente ao total indexado no GSC (com margem de 20%). Se o site: mostra 12.000 e o GSC mostra 4.000, algo está errado, e a diferença geralmente são URLs com parâmetros que o Google indexou antes da canonicalização.

3. Arquitetura e Links Internos

Ferramentas: Sitebulb (melhor da categoria para visualizar profundidade do site), relatório de profundidade de crawl do Screaming Frog.

Três diagnósticos, ordenados pela frequência com que os encontro em auditorias:

Profundidade a partir da homepage. Qualquer página a mais de quatro cliques da homepage é um sinal de alerta. Execute um crawl no Screaming Frog, ordene por profundidade de crawl em ordem decrescente. Páginas com profundidade 6+ geralmente são órfãs ou estão isoladas por navegação inadequada. Se a sua página de produto de maior receita está na profundidade 5, você tem um problema de arquitetura, não de conteúdo.

Páginas órfãs. Páginas sem nenhum link interno de entrada. O Sitebulb tem um relatório dedicado. Causas comuns: landing pages antigas de uma campanha, artigos de blog que o time editorial esqueceu de linkar de algum lugar, páginas de produto lançadas sem atualização da navegação. Vincule-as a um hub relevante ou aplique noindex. Não as deixe acumulando.

Distribuição de links internos. Execute o relatório de contagem de links internos por URL do Screaming Frog. Trace a distribuição. Você está buscando a cauda longa de páginas com 0 a 2 links internos. Essas páginas vão ter dificuldade para posicionar independentemente da qualidade do conteúdo. A estrutura hub-and-spoke (página pilar para um cluster de artigos relacionados) é a correção mais limpa: cada artigo do cluster linka para o pilar, e o pilar linka de volta para todos os artigos do cluster.

Armadilhas de navegação facetada. Se você tem e-commerce ou marketplace, a navegação facetada pode gerar milhões de combinações de URL. A árvore de decisão:

• Filtros que alteram o conteúdo de forma significativa (categoria, marca): indexáveis, canonical para si mesmos
• Filtros que apenas ordenam ou paginam: noindex ou canonical para a categoria base
• Filtros combinados (categoria + marca + preço + tamanho): bloqueie no robots.txt ou use AJAX para que não gerem URLs rastreáveis

Breadcrumbs. Toda página de conteúdo deve ter um componente de breadcrumb visível, marcado com schema BreadcrumbList. Breadcrumbs ajudam os usuários a se orientar, fornecem ao Google um sinal estrutural adicional e conquistam a exibição de breadcrumb nas SERPs.

4. Core Web Vitals

Ferramentas: PageSpeed Insights para dados de laboratório e de campo, Lighthouse para testes de laboratório reproduzíveis, painel de Performance do Chrome DevTools para diagnóstico, relatório de Core Web Vitals do GSC para monitoramento.

Os limites importam. Memorize-os:

Sempre meça nos dados de campo (CrUX, os números de usuários reais no PageSpeed Insights e no GSC), não em laboratório. Os dados de laboratório contam uma história; os de campo contam a verdade. O laboratório pode estar aprovando enquanto o CrUX está reprovando, porque os usuários reais estão em redes mais lentas e dispositivos mais antigos.

Priorize as correções por camadas. Cada métrica tem uma escada clara:

Correções de LCP (em ordem de esforço vs. impacto):

Correções de INP:

Correções de CLS:

Execute o PageSpeed Insights nos seus 10 principais templates (homepage, artigo de blog, categoria, produto, preços etc.), não em URLs individuais. Os templates são onde você implementa correções uma vez e elas se propagam para todas as páginas.

5. Dados Estruturados

Ferramentas: Relatório de Resultados Avançados do GSC, validador do schema.org, extração de dados estruturados do Screaming Frog.

Verificação de cobertura. Cada tipo de conteúdo deve ter seu schema correspondente:

• Artigos: Article ou BlogPosting
• Páginas de produto: Product com Offer
• Páginas de FAQ: FAQPage
• Organização (homepage e rodapé): Organization
• Breadcrumbs (em toda página): BreadcrumbList
• Conteúdo de instruções: HowTo

Execute o Screaming Frog com extração de dados estruturados ativada. Filtre para URLs com erros ou tipos ausentes. Cruze com o relatório de Resultados Avançados do GSC. Essa é a fonte de verdade sobre o que o Google valida.

A perspectiva de AEO (otimização para motores de resposta) importa cada vez mais. Sistemas de busca com LLM se baseiam fortemente em dados estruturados para decidir qual conteúdo citar. Uma página de FAQ com schema FAQPage válido e pares de P&R limpos é citada pelo ChatGPT, Perplexity e pelo AI Overviews do Google de forma muito mais consistente do que o mesmo conteúdo sem schema. Schema não é mais apenas para snippets avançados. É o modo como as máquinas decidem do que trata a sua página.

A Realidade da Renderização de JS

Se o seu site é um SPA construído em React, Vue, Svelte ou Angular sem SSR ou SSG, você está jogando no modo difícil.

O Googlebot faz uma renderização em dois ciclos. Primeiro ciclo: ele vê a resposta HTML inicial. Para um SPA sem pré-renderização, isso é quase um <div id="root"></div> em branco com uma tag de script. Segundo ciclo: horas a semanas depois, quando a fila de renderização do Google tiver capacidade, ele busca novamente e executa o JS. O conteúdo é indexado, eventualmente.

O diagnóstico de "página em branco no Screaming Frog": execute o Screaming Frog com renderização de JS desativada. Se suas páginas retornam 200 OK com <body> vazio, é isso que o Googlebot vê no primeiro ciclo. Agora execute com renderização de JS ativada. Se o conteúdo aparecer, o Google vai chegar lá eventualmente. Se não aparecer, você tem um bug mais profundo (barreira de autenticação, hidratação quebrada, erro de JS bloqueando a renderização).

Quando isso importa:

• Notícias e conteúdo de tendências. Se você depende de indexação pelo Googlebot em 24 horas, o atraso do segundo ciclo é fatal. SSR ou SSG, sem exceção.
• Catálogos grandes. Um site de e-commerce com 50 mil produtos e renderização do lado do cliente vai ver o orçamento de rastreamento consumido pela fila de renderização. O Google decide quais páginas valem o segundo ciclo.
• Páginas com barreira de autenticação. Se a lógica de hidratação redireciona usuários não autenticados (o que o Googlebot é), o Google vê um redirecionamento, não o seu conteúdo.

A árvore de decisão:

• Site de conteúdo: SSG (Next.js, Astro, Eleventy)
• Aplicativo de produto: SSR para páginas de marketing, CSR para o próprio app
• Migração muito cara: pré-renderização (Prerender.io, Rendertron) como medida temporária

Peça à equipe de engenharia que registre o cabeçalho User-Agent nas falhas de renderização. Se você encontrar o Googlebot, tem evidência para levar a uma sessão de planejamento de sprint.

Empacotando Achados como Tickets de Dev

É aqui que a maioria das auditorias morre. Os achados são reais. Os tickets nunca são escritos. A engenharia escolhe as tarefas mais fáceis do backlog porque ninguém associou impacto de negócio à sua auditoria.

O entregável é uma fila de tickets priorizada. Minha divisão padrão para uma auditoria trimestral:

• 3 P0s (problemas que bloqueiam indexação). O site não consegue posicionar se não forem corrigidos. Exemplos: noindex em páginas importantes, robots.txt bloqueando diretórios indexáveis, tags canonical apontando para 404s.
• 8 P1s (falhas de Core Web Vitals e problemas de arquitetura). Exemplos: LCP > 4s no template principal, nenhum link interno para páginas de receita, navegação facetada gerando armadilhas de crawl.
• 20 P2s: lacunas de schema, correção de hreflang, revisão de meta descrições, texto alternativo de imagens, refinamento menor de arquitetura.

Todo ticket precisa dos mesmos campos:

Título: [SEO P0] Tag meta noindex no layout /blog/*

Padrão de URL: Todas as URLs correspondendo a /blog/*
Reprodução:
  1. Acesse https://exemplo.com.br/blog/qualquer-artigo
  2. Visualize o código-fonte
  3. Veja <meta name="robots" content="noindex"> no <head>
Esperado: A tag noindex não deve estar presente em artigos de blog indexáveis
Evidência: Print do código-fonte, relatório de Páginas do GSC mostrando 247 URLs
  com status "Excluído pela tag 'noindex'"
Impacto estimado de tráfego: 247 URLs atualmente excluídas. As 20 principais
  tinham posições 4 a 15 antes da adição do noindex (dados do Ahrefs).
  Recuperação estimada: 8 mil a 12 mil visitas orgânicas mensais em 60 dias
  após a correção + reindexação.
Critério de aceite: Arquivo de layout não renderiza mais a tag noindex para /blog/*.
  Contagem de "Excluído por noindex" no relatório de Páginas do GSC cai em 240+.

A engenharia vai executar tickets que leem assim. Não vai executar tickets que leem "Corrigir problemas de indexação no blog."

A Cadência de Auditoria

Auditorias profundas trimestrais cobrem as cinco áreas. Dois dias de trabalho focado, mais uma semana para escrever tickets e acompanhar o processo de planejamento de sprint. Todo trimestre.

Verificação mensal de cobertura de indexação. Abra o relatório de Páginas do GSC na primeira segunda-feira de cada mês. Compare com o snapshot do mês anterior. Investigue qualquer categoria de "Não indexado" que cresceu mais de 10%.

Verificação semanal de regressão de CWV. Relatório de Core Web Vitals do GSC. Qualquer template que passar de "Bom" para "Precisa Melhorar" deve ser investigado dentro da semana. Detectar uma regressão de CWV com 1 semana de atraso é uma correção de 1 hora. Detectar com 8 semanas de atraso, após um release, é uma escavação de vários sprints.

Amostragem de logs de servidor: trimestral é suficiente para a maioria dos sites, mensal para sites com mais de 500 mil URLs.

A auditoria não é um entregável único. É uma cadência operacional. A primeira é mais trabalhosa porque você está estabelecendo as linhas de base. No terceiro trimestre, a maior parte do tempo vai para as verificações de regressão e a triagem de novos problemas, não para re-auditorias completas.

Entregue correções, não achados. A auditoria só vale o quanto os PRs mesclados valem.

Saiba Mais

• Checklist de SEO On-Page para Páginas Pilar
• Estratégia de Links Internos para B2B SaaS
• Schema Markup para B2B SaaS
• Fluxo de Trabalho Semanal no GSC