SEO técnico: porquê uma auditoria é diferente duma lista de erros de crawl e indexação?

Uma auditoria de SEO técnico não é um export de ferramenta com 4xx, 5xx e metas em falta. É perceber o site, priorizar por impacto no negócio e falar com quem o constrói. Em 2023, em Berlim, o Google mostrou-o num slide: as ferramentas são um passo de quatro. O resto é critério, e é o que quase ninguém entrega.
Uma auditoria de SEO técnico não é um export de ferramenta com os 4xx, os 5xx e os metas em falta despejados numa folha. É o que fazes com isso. E a maior parte do que recebi na vida não fazia nada com isso.
SEO Técnico: o que o Google mostrou num slide em Berlim
Em setembro de 2023 estive na SMX Advanced Europe, em Berlim, e fotografei este slide de Martin Splitt, do Google. Chamava-se "Your path" e resume uma auditoria técnica em quatro passos: Understand, Examine, Evaluate, Explain.
Primeiro percebe o site: stack, setup, recursos, dependências. Depois usa as ferramentas para rastrear e identificar indícios. A seguir usa o cérebro: foca no que é relevante, fala com quem decide, confirma se o problema é mensurável, prioriza. Por fim explica a quem manda, com métricas e expectativas.
Repara onde ficam as ferramentas. No passo dois. Um de quatro, entalado entre "percebe o site" e "usa o cérebro". O Google desenhou em palco o que eu via ignorado todos os dias: a ferramenta não é a auditoria, é o terço do meio de um passo só.
O que a maioria das auditorias de SEO técnico me entregava
Durante anos recebi auditorias a um ritmo mensal, e quase todas eram a mesma coisa: um export com 4xx e 5xx, metas em falta, e o grave misturado com o trivial como se pesassem o mesmo. Trabalhei diretamente com equipas de um anunciante com centenas de sites em dezenas de países, e aquilo não acrescentava nada.
Em digital desde 1998, em SEO e SEA desde 2007, e raramente vi tanto relatório inútil junto. Na casa mãe, os problemas globais já estavam identificados há muito. O relatório não trazia novidade. Trazia perda de tempo e desfoco do ciclo de deployment. As agências externas faziam o mesmo dump e, por cima, anexavam um Excel ou um PPS com a "priorização" delas. Ruído, com uma camada de verniz por cima.
O dump que devolve ao remetente os problemas que ele próprio criou
O caso mais absurdo repetia-se: emissores a mandar para a central problemas que eram deles. Links partidos que eles tinham partido. Redirecionamentos que eles tinham configurado mal. Search Console mal montada por eles. Entregavam à casa mãe o retrato dos seus próprios erros sem darem por isso.
E o remate vinha semanas depois: um pedido para a central "resolver" o que afinal pertencia a quem reportou. Comportamento acéfalo, a correr em círculo. Uma auditoria que não percebe quem é dono de quê não é uma auditoria. É uma fotocópia com ansiedade.
À escala, um problema não é de um site: é de centenas
Quando geres centenas de sites, a pergunta certa muda. Um status code errado num template não é o problema de uma página: é o problema de todas as páginas que usam esse template, em todos os mercados. Pede uma resposta global e central, não um ticket local por cada sítio onde o sintoma aparece.
É por isto que um problema bem documentado, com impacto estimado no revenue, vale mais do que mil linhas de export. Um diz-me onde perco dinheiro e porquê. O outro diz-me que há 1.400 páginas com um aviso que, na maioria, é inofensivo. Atenção: adoro o Screaming Frog e recomendo-o a toda a gente. A ferramenta não é o problema. O problema é entregar o que ela cospe como se fosse trabalho feito.
Para lá do crawl e da indexação: o stack inteiro
O passo que quase ninguém integra é o primeiro do slide: percebe o site. E um site hoje é uma pilha de tecnologia, não um FTP com HTML. Uma auditoria séria segue o caminho do pedido: do entry point da CDN, pelo routing e o load balancing, pelos serviços de cloud, pelo render de front-end, pelo CMS, pelo DOM, pelos static assets.
E pelo modo como o layout é construído, que decide o que o motor chega sequer a ver. Uma PWA com routing no cliente serve um shell quase vazio e preenche-o com JavaScript que o crawler de IA não corre. Um site montado em componentes pode renderizar no servidor ou no browser, e essa escolha muda tudo: o mesmo site, para o Googlebot, pode ser rico ou pode ser uma página em branco.
Daqui sai a regra que uso e que me responsabiliza: se o que proponho não é possível na tecnologia que o cliente tem, e não há budget para a mudar, a recomendação não vale nada. O trabalho de SEO falha. E a culpa é minha, do especialista, não do developer que me disse à partida que não dava.
O skill que as ferramentas não têm: falar com quem constrói o site
Uma auditoria que ninguém implementa não vale nada. E quem implementa não é o SEO: são os developers, os arquitetos de software, o CloudOps, o UX, o product. O skill que decide o destino de uma auditoria não está em nenhuma ferramenta. É saber falar com cada um deles na língua certa, e é metade do trabalho.
Trabalhei lado a lado com equipas de developers, arquitetos de software, CloudOps e UX para melhorar o SEO técnico de sites internacionais. Aprendi lá o que nenhum crawl me ensinou: um issue mal comunicado é um issue que não se resolve. Fica no backlog, trimestre após trimestre, a dar razão a quem diz que o SEO "não traz nada".
Falar a língua de quem escreve o código. O Martin Splitt criou a série de JavaScript SEO do Google, nas palavras dele, para dar aos SEO "the vocabulary and the backing to actually talk to developers confidently". E deixa um aviso que me poupou erros: um SEO que critica uma técnica só porque não percebe o JavaScript perde a credibilidade à frente de quem a escreveu. Começa-se pelo que é comum, e "good developers and SEOs want websites to be fast".
Transformar o issue num ticket testável. Não "melhorar a velocidade". O ficheiro, o elemento, o critério de aceitação. Descreve-se o resultado, não a implementação: dizer ao cozinheiro o que queres comer, não como o há de cozinhar. E valida-se a exequibilidade com um developer antes de submeter, não na retrospetiva.
Priorizar com o negócio, não com a ferramenta. A Aleyda Solís tem um nome para isto: SP2, de Strategic, Prioritized, Solutions-focused, Proactive. Prioriza por impacto e esforço em três fases, da ideal (só impacto) à validada, já depois de rever com o cliente o que é exequível na tecnologia que ele tem. Reportar subidas de ranking em vez de impacto no revenue é o caminho mais curto para perder a sala.
Entrar cedo, não no fim. O SEO pertence ao ciclo de produto, não ao controlo de qualidade depois de tudo decidido. Se a escolha de framework, de routing ou de estrutura de URLs já estava fechada quando o SEO a viu, chegou tarde. Splitt lembra-o: product managers, writers, UX e developers moldam o ranking muito antes de o conteúdo sair.
Pôr um nome em cada decisão transversal. Quando toda a gente é dona do site, ninguém responde por ele. Canonicals, hreflang, estrutura de URLs: cada decisão que atravessa equipas precisa de um dono com nome, não de um comité. Foi a ausência disto que me enchia a caixa de entrada de problemas que não eram de ninguém.
Uma ferramenta encontra o problema. Só uma pessoa o resolve.
A Checklist de SEO Técnico é o ponto de partida, não a estratégia
As checklists servem, e eu tenho uma. A minha checklist de SEO técnico diz o que verificar e por que ordem de impacto. Mas uma checklist é o chão, não o edifício: impede-te de falhar o óbvio, não decide a estratégia. Ajusta-se a cada site. Um site internacional precisa de auditar hreflang; um site numa língua, não.
Não sou só eu a dizê-lo. Em novembro de 2025, num Search Lightning Talk, o próprio Splitt pediu "don't follow your tools blindly" e avisou que é preciso "experience and expertise to adapt these guidelines and checklists to the site you audit". O Google diz o que eu via em Berlim no slide dele: a checklist e a ferramenta são o início da conversa, não o fim.
O que exigir de uma auditoria de SEO técnico
Da próxima vez que receberes uma auditoria de SEO técnico, mede-a por isto: cada problema vem com o contexto do teu site, com uma estimativa de impacto no negócio, com a confirmação de que é exequível na tua tecnologia, e priorizado por esforço e retorno. Se vier sem isto, recebeste um export, não uma auditoria.
E o que perdes não é o preço do relatório. É o trimestre que a tua equipa de desenvolvimento gasta a fechar avisos inofensivos enquanto o problema que te tira revenue continua lá, bem documentado em lado nenhum. Quantos dos relatórios que a tua empresa paga passariam neste teste?
Vê o método pela voz do Google
O Martin Splitt detalha a mesma lógica neste Search Lightning Talk do Google, de novembro de 2025. Pouco mais de dez minutos que confirmam o slide de Berlim.
Fontes
- Martin Splitt - How to perform a technical SEO audit (Google Search Central, 2025)
- SMX Advanced Europe
- Aleyda Solís - How to Develop Actionable and Impactful SEO Audits
- SEOs and developers: why they are better together (Search Engine Land)
- How to write engineering tickets for SEO work (The Gray Company)
Perguntas frequentes
As ferramentas de SEO deixaram de servir?
Não, e eu uso-as todos os dias. O Screaming Frog, o Search Console e um bom crawler são indispensáveis para recolher dados. O que não servem é como produto final: um export de issues não é uma auditoria. A ferramenta encontra; a priorização, o contexto e a comunicação com quem implementa é que fazem o trabalho valer alguma coisa. Auditoria de SEO técnico →
O que é um ticket de SEO testável?
É um pedido à equipa de desenvolvimento que descreve o resultado esperado, o ficheiro ou elemento a mudar, e um critério de aceitação que qualquer pessoa consegue verificar. Não é melhorar a velocidade; é o quê, onde, e como se confirma que ficou feito. Sem isto, a correção fica à interpretação de cada um e raramente sai do backlog. Ver como trabalho →
Uma checklist de SEO técnico chega?
Não. A checklist é o ponto de partida que te impede de falhar o óbvio, mas ajusta-se a cada site e não substitui o critério. O próprio Google avisa que é preciso experiência para adaptar as checklists ao site que auditas. Usa-a como base, não como estratégia. Ver a checklist →