Configure sua auditoria de SEO técnico em 9 etapas

Uma auditoria SEO técnica não começa com uma ferramenta aberta nem com um PDF de 80 páginas que ninguém lê. Começa com uma pergunta incômoda: o que está impedindo que o Google rastreie, renderize e indexe corretamente o seu site corporativo? Se você não consegue responder a isso com dados, o que você tem é uma lista de tarefas, não uma auditoria.

Este artigo descreve a sequência exata de configuração que aplico em projetos B2B com centenas ou milhares de URLs, ordenada por dependências: cada passo produz o dado que alimenta o próximo. Se você pular a ordem, acabará coletando métricas que não consegue interpretar.

Passo 0: defina o escopo antes de tocar em uma ferramenta

Em uma empresa com várias linhas de negócio, o erro mais caro é auditar «todo o domínio». Antes de configurar qualquer coisa, delimite:

• Subdomínios incluídos: blog, loja, área do cliente, help center. Decida se a área privada entra (normalmente não, mas convém documentá-lo).
• Idiomas e versões regionais: se você tem /es/, /mx/ e /ar/, cada uma precisa de revisão de hreflang própria.
• Stakeholders: quem aprova as mudanças de template costuma estar em TI, não em marketing. Identifique-o nesta fase ou o restante do processo fica bloqueado.

Um caso real: uma empresa de serviços industriais com 4 idiomas descobriu na fase de escopo que seu help center vivia em um subdomínio com CMS diferente e sem acesso a logs. Isso mudou por completo a metodologia do restante da auditoria: sem logs, a análise de rastreamento teve que se basear em amostras do Search Console e em crawls com user-agent do Googlebot.

Passo 1: configure o acesso aos dados de origem

Sem esta base, qualquer auditoria é especulativa. Você precisa, no mínimo, de:

Search Console

Verifique a propriedade por prefixo de URL sempre que puder (permite segmentar por subdiretório) e mantenha a propriedade de domínio como respaldo. Comprove que o usuário que você usará tem permissão completa, não restrita: a permissão restrita oculta dados de desempenho e de índice que você precisará depois.

Analytics

Se você usa GA4, certifique-se de que o fluxo de dados web está ativo há pelo menos 90 dias. Com menos histórico, qualquer comparação de tráfego orgânico antes/depois de uma mudança técnica é ruído. Configure um segmento de tráfego orgânico que exclua domínios de referência internos e parâmetros de campanha que sujam a atribuição.

Logs do servidor

Peça acesso aos arquivos de acesso (Apache ou Nginx) com um mínimo de 30 dias. Segundo a documentação oficial do Google sobre rastreamento, a análise de logs é a única fonte que mostra com certeza quais URLs o Googlebot visita realmente, em comparação com as que você acha que ele visita.

Acesso ao CMS e ao repositório

Você precisará poder ler os templates de cabeçalho, as regras de redirecionamento e o arquivo robots.txt. Se não tiver acesso ao repositório, peça à equipe técnica que exporte a configuração do .htaccess ou do middleware de redirecionamentos.

Passo 2: prepare o crawler com precisão

A configuração do crawler determina a qualidade de todas as descobertas posteriores. Ajustes que fazem a diferença:

• User-agent: use o do Googlebot para simular o rastreamento móvel (Googlebot Smartphone). Muitas diferenças de conteúdo só aparecem com esse agente.
• Renderização JavaScript: ative-a apenas se o seu site precisar. Em sites com muito conteúdo dinâmico, a renderização dispara o tempo de crawl e pode esgotar os créditos da ferramenta. Em um projeto com 12.000 URLs, ativar a renderização completa obrigou a dividir o crawl em segmentos por seção.
• Limite de velocidade: não ultrapasse 2-3 requisições por segundo em produção sem avisar a TI. Um crawl agressivo pode ativar o WAF e falsear os resultados com erros 403.
• Autenticação: se houver conteúdo atrás de login relevante para SEO (por exemplo, fichas de produto com preços ocultos), configure cookies ou cabeçalhos de autenticação.

Salve a configuração do crawl. Você precisará dela idêntica para comparar resultados após as mudanças.

Passo 3: valide a saúde do rastreamento com robots.txt e sitemaps

Antes de revisar qualquer outra coisa, confirme que o Google consegue chegar às suas URLs:

1. Revise o robots.txt linha a linha. Procure bloqueios de recursos CSS/JS (quebram a renderização) e de parâmetros que de fato geram conteúdo único.
2. Comprove que o sitemap XML contém apenas URLs canônicas, com status 200 e não bloqueadas. Um sitemap com redirecionamentos ou 404 é um sinal de descuido que o Google ignora progressivamente.
3. Verifique no Search Console → Sitemaps que o arquivo é processado sem erros e que as URLs descobertas coincidem com as que você espera.
4. Use a ferramenta de inspeção de URLs para as 10 páginas mais importantes por negócio e confirme «O URL está no Google» e que a versão rastreada é a canônica.

Limitação honesta: se o seu site tem mais de 50.000 URLs, a inspeção manual não escala. Nesse caso, priorize a inspeção por template (uma URL representativa por tipo) e complemente com o relatório de «Páginas» do Search Console.

Passo 4: mapeie códigos de status e redirecionamentos

Exporte do crawl todas as URLs com status diferente de 200 e classifique-as:

• 301/302: verifique que as cadeias de redirecionamento não ultrapassem um salto e identifique loops. Um padrão habitual em empresas após migrações: /produto → /produto/ → /es/produto/ → 404. Cada salto perde sinal e adiciona latência.
• 404/410: cruze a lista com o Search Console para detectar URLs que ainda recebem links externos. Essas são as que precisam de redirecionamento ou recuperação, não as que simplesmente existem.
• 5xx: se aparecerem no crawl, pare. Um servidor instável invalida qualquer outra análise.

Documente cada redirecionamento com sua origem, destino e motivo. Esse registro é o que permitirá à TI executar as mudanças sem interpretações.

Passo 5: resolva canônicas e duplicidades

Configure a revisão em três camadas:

1. Canônicas declaradas: compare a tag rel=canonical com a URL final após redirecionamentos. Uma canônica que aponta para uma URL redirecionada é um erro frequente em CMS com plugins de SEO mal configurados.
2. Parâmetros: identifique os que geram duplicados (ordenação, filtros, paginação) e decida entre canônica, noindex ou bloqueio. Atenção: bloquear no robots.txt uma URL com canônica impede que o Google leia essa canônica.
3. Variantes de URL: maiúsculas, barra final, http/https, www/não-www. Force uma única versão com redirecionamentos no nível do servidor, não do CMS.

Isso não funciona igual em todos os casos: em ecommerce com filtros facetados, a canônica por si só não resolve o problema se os filtros recebem links internos. Aí você precisa também de controle de linkagem interna e, às vezes, de renderização condicional dos links de filtro.

Passo 6: audite a renderização e o JavaScript

Compare o HTML inicial com o DOM renderizado nos templates principais. Procure:

• Conteúdo principal que só aparece após executar JavaScript (risco alto se não houver renderização do lado do servidor).
• Links internos gerados por JS que o crawler não descobre sem renderização.
• Metadados (title, canonical, hreflang) injetados por JS e que poderiam não se refletir no HTML servido.

Segundo a documentação oficial sobre renderização, o Google pode executar JavaScript, mas com orçamento de rastreamento limitado e sem garantia de que todos os scripts sejam executados. A conclusão prática: se um link ou um canonical só existe após JS, trate-o como não confiável.

Passo 7: meça Core Web Vitals com dados de campo

Não fique apenas com o Lighthouse. Configure a revisão com dados reais:

1. Exporte o relatório de Core Web Vitals do Search Console por tipo de dispositivo e agrupamento de URL.
2. Identifique quais templates reprovam em LCP, INP ou CLS, não quais páginas isoladas.
3. Priorize por impacto: um template de ficha de produto com milhares de URLs e LCP deficiente pesa mais que a home.

Nuance importante: os dados de campo têm latência (28 dias no relatório do Search Console). Se você acabou de otimizar imagens, não espere ver a mudança na mesma semana. E se o seu tráfego for baixo, pode não haver amostras suficientes para avaliar um template específico; nesse caso, combine laboratório e campo, e diga isso no relatório.

Passo 8: consolide o relatório e priorize por dependências

O entregável não é uma lista de erros. É uma sequência de execução com dependências:

• Bloqueantes: 5xx, robots.txt que bloqueia recursos, redirecionamentos quebrados. Sem isso, o resto não importa.
• Estruturais: canônicas, duplicidades, arquitetura de links internos.
• Desempenho: Core Web Vitals por template.
• Melhorias: dados estruturados, hreflang, otimização de imagens.

Cada tarefa deve indicar a URL ou template afetado, a equipe responsável e como a mudança será verificada (por exemplo, «recrawl das 200 URLs do template X e comparação de códigos de status»).

Erros de configuração que vejo se repetirem

• Auditar com o user-agent de desktop em sites onde o móvel serve conteúdo diferente. As descobertas não coincidem com o que o Google indexa.
• Confiar na cobertura do Search Console sem cruzar com logs. Há URLs rastreadas que nunca aparecem nos relatórios e outras que aparecem como «excluídas» sem motivo aparente.
• Alterar robots.txt e canônicas ao mesmo tempo. Se algo piorar, você não saberá o que causou. Uma mudança por iteração, com data registrada.
• Ignorar a área do cliente no robots.txt e descobrir meses depois que o Googlebot consome orçamento de rastreamento em URLs de sessão.

O que esta metodologia não cobre

Uma auditoria técnica não resolve um problema de intenção de busca nem de qualidade de conteúdo. Se o seu site rastreia e indexa corretamente, mas as páginas não respondem ao que o usuário busca, os dados técnicos estarão limpos e o tráfego continuará estagnado. Também não substitui uma revisão de links tóxicos nem de autoridade de domínio: são disciplinas distintas que se complementam, não se sobrepõem.

E um aviso final: nenhuma auditoria garante melhorias de posicionamento. O que ela garante é que você elimina obstáculos mensuráveis. O resto depende de fatores que você não controla a partir do servidor.