Auditoria técnica de SEO: 10 erros que geram recomendação furada

A cena é conhecida por qualquer um que já entregou uma auditoria técnica de SEO↳SEO4 conteúdosPor que a transição do SEO clássico para a Otimização de Motores Generativos (GEO) exige que se repense a modelagem semânticaMarketing Tech · mai 2026O impacto da pesquisa e do SEO no comércio eletrônico: insights da State of Search Brasil 5Marketing Tech · fev 2025SEO por Elas 2025: Impulsionando e promovendo mulheres no Marketing DigitalMarketing Tech · fev 2025Ver tudo em Marketing Tech →: o documento tem dezenas de "findings", cai numa pasta compartilhada e some por seis meses. Matt Hollingshead, consultor de SEO técnico, argumenta em artigo no Search Engine Land que a culpa quase nunca é do cliente. É da auditoria: achados nunca validados, priorizados pela noção de severidade de uma ferramenta, ou escritos de um jeito que nenhum desenvolvedor consegue executar.

Para quem trabalha com growth e MarTech no Brasil, decidindo verba de canal e a qual consultoria terceirizar o SEO técnico, o texto é menos uma lista de dicas e mais um critério para separar entregável bom de relatório caro que não move ponteiro. A frase que sintetiza o argumento vem logo na abertura:

Seu crawler encontra o sintoma. Sua auditoria precisa explicar a causa, por que ela importa e o que deve acontecer a seguir.

Matt Hollingshead, Search Engine Land

Os erros de coleta: o dado que você nem enxergou

Os quatro primeiros erros são de método na hora de puxar os dados, e é onde a auditoria já nasce torta.

Rodar o crawl sem executar JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) →. No Screaming Frog, com renderização de JS ligada e armazenamento do HTML original e do renderizado, dá para comparar as duas versões lado a lado na aba View Source. O ponto que Hollingshead levanta interessa direto ao debate de GEO: o Google renderiza a maioria das páginas, mas a maior parte dos crawlers de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → não executa JavaScript. Ou seja, uma página pode ranquear no Google e ser invisível para os sistemas que geram respostas de IA. Conteúdo, links internos ou tags de canonical que só existem no DOM renderizado são um risco de descoberta que o crawl padrão não mostra.

Ignorar o relatório de indexação do Search Console (Indexação > Páginas). É o único lugar onde o Google diz diretamente se a URL está indexada, rastreada mas não indexada, descoberta mas não indexada, ou soft 404. O erro comum é tratar todo "Não indexado" como problema. Páginas com canonical apontando para outra, com noindex ou com redirect são resultado normal de um site bem configurado. O que merece investigação é o inesperado: uma página que você quer ranqueando parada em "Rastreada, não indexada no momento", ou um "Descoberta, não indexada" que só cresce.

Amostrar URLs no aleatório em vez de por template. Aqui está talvez o insight mais prático para escala. A maioria dos problemas técnicos que valem reporte são problemas de template. Erre a regra de canonical no template de produto e você quebrou 40 mil páginas de uma vez. Se a amostra tiver três posts de blog e uma página de contato, o erro passa batido. Amostrar por tipo de página (produto, categoria, post, view filtrada, paginação) também barateia o orçamento do fix: um dev estima "mudar a lógica de canonical no template de PDP" em um minuto; ninguém estima uma lista de 40 mil URLs.

Auditar a partir de uma única fonte. Toda ferramenta é cega para algo. O crawler só acha o que está linkado (páginas órfãs somem). O Search Console dá o veredito do Google, mas não o motivo. O Analytics só registra visita onde o código de tracking roda, então atividade de crawler quase não aparece. Os logs de servidor são a única fonte que mostra toda requisição do Googlebot ou de crawlers de IA e o que eles receberam de volta: rate limiting, erros 5xx intermitentes e crawl concentrado em URLs que não importam só aparecem ali. Sem logs, o relatório Crawl Stats do Search Console serve de substituto amostrado. A regra de ouro: qualquer achado que vá para o time de dev deveria estar confirmado em pelo menos duas fontes, e quando duas discordam, a discordância costuma ser o achado mais interessante.

Os erros de interpretação: confundir output de ferramenta com diagnóstico

Tratar a classificação da ferramenta como fato. Crawlers reportam títulos e H1 ausentes em páginas que renderizam bem, e registram 429 e 503 que o site só devolveu porque o crawl estava rápido demais. Antes de o achado entrar no relatório, abra a página e cheque. Para confirmar um status code, um curl resolve:

curl -I -A "Googlebot" https://exemplo.com.br/produto/123

São dois minutos por achado que evitam o dev perder meia diária caçando um problema que nunca existiu. E há um custo de credibilidade: como observa o autor, dev que foi mandado atrás de um problema fantasma passa a ler o resto do documento com desconfiança.

Documentar sintoma em vez de causa. "O site tem 12 mil URLs duplicadas" é observação, não achado. O achado é o que as produz: navegação facetada sem tratamento de parâmetro, session ID grudado na URL, um CMS que gera cópia de cada página. O dev apaga as 12 mil numa tarde, e elas voltam no próximo filtro adicionado, porque o comportamento de base não mudou. Rastrear a duplicata até a origem é justamente a parte que a ferramenta não faz por você.

Priorizar por severidade da ferramenta em vez de impacto no negócio. O crawler não sabe quais templates geram receita, qual categoria a empresa vai empurrar no próximo trimestre, nem para quais páginas o time de vendas manda prospect. O resultado são auditorias com montanha de avisos de baixo valor no topo e uma falha de renderização no template de produto de maior margem na página quatro. O exemplo do artigo é ótimo: um lote de "Page Titles: Outside " marcado como alta prioridade, quando todas aquelas URLs vêm de um template que o time vai deletar no redesign. Priorizar de verdade exige perguntar ao cliente o que a ferramenta não sabe: quais produtos são prioridade, quais páginas convertem, o que lança este ano.

Os erros de recomendação: onde a auditoria vira ou não vira deploy

Os três últimos erros são de escrita, e são os que decidem se o ticket vira código.

Recomendar mudança sem entender a arquitetura. Redirect, canonical, remoção de URL e noindex têm efeitos de segunda ordem. Um noindex numa categoria filtrada acaba cortando os links internos para os produtos abaixo dela. Um lote de URLs antigas redirecionado para a home costuma virar soft 404. Antes de recomendar, vale mapear o que linka para a página e o que ela linka, e se ela é a única rota para outra coisa.

Escrever recomendação que o dev não consegue executar. "Melhorar velocidade" não é recomendação; "fortalecer linkagem interna" também não. Uma recomendação usável traz URLs ou templates afetados, causa raiz, resultado esperado e detalhe suficiente para estimar o trabalho. Se o dev precisa voltar para perguntar o que você quer, o ticket vai para o fim do backlog e fica lá.

Prescrever a implementação em vez do resultado. Escreva o resultado e as restrições ("o canonical em páginas paginadas precisa ser autorreferente", "o conteúdo principal do produto precisa estar no HTML inicial") e deixe o dev decidir o como. Você não conhece as limitações do framework, o que mais depende daquele componente, nem o que o time já planejou para aquela parte do código. Critério de aceite dá algo para construir e checar; prescrição só abre debate sobre se a sua abordagem é a certa. O autor ressalva: em sites menores, sugerir uma abordagem faz sentido e você pode estar certo.

Onde isto não se aplica (e o que fica em aberto)

O próprio método tem custo: validar em duas fontes, rastrear causa raiz e escrever critério de aceite para cada achado leva tempo. Num site pequeno, com poucos templates e um dev que conhece o código de ponta a ponta, o rigor todo pode ser overkill, e nesse cenário prescrever a solução (o erro 10) às vezes é o caminho mais rápido. O valor da auditoria escala com a complexidade do site.

O que o texto não resolve, e é onde o leitor brasileiro precisa fazer a própria lição, é a camada de GEO. Hollingshead aponta que crawlers de IA não executam JS, mas a auditoria técnica ainda mede quase tudo pelo olhar do Googlebot. Medir visibilidade em busca generativa (se a marca é citada no ChatGPT, no Gemini, no AI Overview) exige instrumentação que a auditoria clássica não cobre. Como resume o artigo: o crawler produz uma lista de problemas em dez minutos. O cliente paga por tudo o que vem depois, quando alguém checa quais são reais, decide quais importam para o negócio e coloca um custo em cada correção.

Fonte: Search Engine Land