Auditoria de site com IA: como auditar um site com agentes de IA, da evidência à correção verificada

1. O que é uma auditoria de site com IA

Uma auditoria de site verifica como ele é construído, entregue e conectado: se está protegido, se mecanismos de busca e sistemas de IA conseguem lê-lo, se as pessoas conseguem usá-lo, qual é a velocidade e quais serviços de terceiros ele carrega. Uma auditoria de site com IA acrescenta um agente de IA a esse trabalho. O agente inicia as verificações, lê os resultados, explica tudo em linguagem simples, define com você o que corrigir primeiro e escreve o pedido de mudança para a pessoa ou o agente de código que fará a correção.

Três coisas bem diferentes são descritas com as mesmas palavras:

Este guia trata da terceira abordagem, porque é onde a IA economiza tempo de verdade, com cada achado ligado a uma evidência que você pode conferir. As verificações continuam repetíveis; o agente acrescenta julgamento, contexto e a passagem de bastão para as pessoas e ferramentas que publicam as mudanças. Se o MCP é novidade para você, o guia de MCP explica hosts, clientes, servidores e ferramentas em termos simples.

2. O que um agente de IA faz e não faz sozinho

Um modelo de linguagem é ótimo para ler, resumir e escrever. Não é uma ferramenta de rede. Se a aplicação não der uma ferramenta para a tarefa, ele não vê o que um navegador ou um crawler vê por baixo da página visível. A tabela compara um agente trabalhando sozinho, no máximo com uma ferramenta de navegação, com o mesmo agente trabalhando a partir de verificações estruturadas.

Agentes de código com terminal, como Claude Code, Codex ou Cursor, também podem rodar curl, dig ou openssl por conta própria. Isso ajuda a confirmar um achado, mas o agente escolhe os comandos no caminho: a cobertura depende do que ele pensa em verificar, os resultados variam entre execuções e nada limita suas sondagens a domínios que você verificou.

O risco da coluna do meio tem nome. A lista de riscos da OWASP para aplicações com LLMs descreve a desinformação como uma saída falsa ou enganosa que parece crível, tendo a alucinação como uma das principais causas, e agravada quando as pessoas confiam nela sem verificar. Em uma auditoria, isso aparece como “sua política DMARC está em none” para um domínio cujo registro o modelo nunca leu, ou como um cabeçalho apontado como ausente que o servidor, na verdade, envia.

Um segundo risco vem das próprias páginas. Um agente que lê um site lê texto não confiável, e uma página pode conter instruções dirigidas ao modelo, às vezes ocultas para os visitantes humanos. A OWASP chama isso de injeção indireta de prompt. Uma configuração de auditoria cuidadosa trata o conteúdo das páginas como dado a ser relatado, nunca como instrução, e mantém uma pessoa aprovando qualquer ação do agente.

O que o agente faz bem é tudo em torno da evidência: explicar o que um achado significa para este site em particular, agrupar achados relacionados, perguntar sobre contexto que as verificações não conhecem (aquele subdomínio antigo de homologação ainda está em uso?) e escrever um pedido de correção preciso o bastante para um agente de código. Essa divisão de trabalho é o núcleo de uma boa auditoria de site com IA.

3. As seis áreas a cobrir, com um checklist para cada

Uma auditoria completa olha para seis camadas. Cada uma responde a uma pergunta diferente e gera um tipo diferente de evidência. O guia de auditoria de site acompanha uma jornada de cliente pelas seis; aqui está o checklist de trabalho.

Segurança

• HTTPS e TLS: cadeia de certificados confiável, sem expiração nas próximas semanas, TLS 1.2 ou 1.3 e HTTP redirecionando para HTTPS.
• Cabeçalhos de segurança: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, proteção contra framing e Referrer-Policy nas respostas HTML.
• CORS: sem Access-Control-Allow-Origin: * em respostas com dados privados e sem origens refletidas combinadas com credenciais.
• DNS e DNS de e-mail: registros SPF e DMARC válidos para todo domínio que envia e-mail e registros restritivos (v=spf1 -all, p=reject) para domínios que nunca enviam.
• Arquivos e segredos expostos: nada acessível em caminhos como /.env, /.git/ ou backups antigos e nenhuma chave de API no JavaScript do front-end.
• Subdomínios: nenhum registro DNS apontando para recursos de nuvem apagados que outra pessoa poderia reivindicar (subdomain takeover).
• Superfície de ataque: apenas as portas abertas e os métodos HTTP que você pretende, páginas de login e de administração que você conhece e CMS e plugins atualizados, se você usa WordPress.
• Cadeia de suprimentos: scripts de terceiros carregados apenas de fontes que você escolheu.

Algumas dessas verificações só leem informação pública. Outras, como requisitar caminhos sensíveis ou escanear portas, enviam requisições com as quais o dono deve concordar, e por isso uma ferramenta de auditoria só deve executá-las em alvos cuja propriedade você verificou. O guia de auditoria de segurança de site cobre o lado da aplicação: contas, permissões e login.

SEO técnico

• Rastreabilidade: o robots.txt não bloqueia páginas ou recursos que você quer indexados.
• Indexação: nenhum noindex perdido em páginas importantes e um sitemap que lista as URLs canônicas.
• Títulos e meta descriptions: presentes, únicos e descrevendo a página.
• Títulos de seção (headings): um título principal claro e uma estrutura lógica.
• Canonicals: cada página aponta para a URL preferida, nunca para um redirecionamento ou uma página de erro.
• Dados estruturados: JSON-LD válido e coerente com o conteúdo visível.
• Links internos e redirecionamentos: páginas importantes acessíveis pela navegação ou pelo conteúdo e sem cadeias de vários redirecionamentos.
• Dados do Search Console: páginas com muitas impressões, mas CTR baixo, e consultas em que você aparece logo abaixo dos primeiros resultados. Costumam ser os ganhos mais rápidos.

Um limite importa aqui. O Google renderiza JavaScript antes de indexar uma página, mas as noções básicas de SEO para JavaScript ainda recomendam renderização no servidor ou pré-renderização, em parte porque alguns bots não executam JavaScript. Uma auditoria que lê HTML estático vê a página como esses bots; em um site que monta o conteúdo no navegador, compare os achados com a página renderizada. O guia de auditoria de SEO técnico aprofunda o tema.

Prontidão de visibilidade em IA

• Política para crawlers de IA: as regras do robots.txt para cada crawler de IA refletem o que você decidiu, e não um padrão de plugin que ninguém escolheu. Vários provedores documentam tokens separados para seus crawlers de busca e de treinamento; o Google, por exemplo, descreve o Google-Extended ao lado de seus crawlers de busca.
• llms.txt: opcional. Um índice curto em Markdown das suas páginas mais úteis, que vale a pena sobretudo em sites com muita documentação; o guia do llms.txt explica o que ele faz e o que não faz.
• Clareza da entidade: o mesmo nome, descrição, localização e dados de contato da empresa em todos os lugares, com dados estruturados Organization.
• Capacidade de resposta: páginas que respondem diretamente a perguntas reais de clientes, perto do topo, em texto e não em imagens.
• Cobertura de prompts: uma lista das perguntas que compradores fazem a um assistente e, para cada uma, a página do seu site que a responde.
• Sinais de fonte: um autor ou organização identificado, datas e citações que facilitam citar e atribuir a página.

São verificações de prontidão do seu próprio conteúdo. Elas não mostram se algum assistente cita você hoje; para isso é preciso um registro separado de perguntas e respostas. O Google afirma que seus recursos de IA não têm requisitos adicionais além da elegibilidade normal na Busca, então acesso de rastreamento e conteúdo claro vêm primeiro. O guia de auditoria de visibilidade em IA mostra como montar o conjunto de perguntas.

Acessibilidade

• Alternativas em texto: toda imagem informativa tem texto alternativo significativo e as decorativas têm um vazio.
• Formulários: todo campo tem um rótulo programático, e não só texto de placeholder.
• Estrutura: títulos em ordem, landmarks como main e nav e um link para pular ao conteúdo.
• Nomes: todo botão e link tem um nome acessível e não há links vazios.
• Idioma: a página declara o idioma com o atributo lang.
• Verificações manuais: uso só com teclado, foco visível, contraste de cores, zoom e reflow, e uma passada com leitor de tela.

O W3C é explícito: as ferramentas não conseguem verificar automaticamente todos os aspectos de acessibilidade e o julgamento humano é necessário. Uma verificação automática encontra o rótulo ausente; só uma pessoa sabe se o rótulo faz sentido. O guia de auditoria de acessibilidade descreve a revisão manual com base nas WCAG 2.2.

Desempenho

• Core Web Vitals: Largest Contentful Paint em até 2,5 segundos, Interaction to Next Paint em até 200 milissegundos e Cumulative Layout Shift de 0,1 ou menos, no percentil 75 dos carregamentos de página (web.dev).
• Dados de campo primeiro: os dados do Chrome UX Report mostram o que usuários reais do Chrome vivenciaram nos 28 dias anteriores, quando a página ou o site tem tráfego suficiente para entrar; os resultados de laboratório do Lighthouse ajudam a achar a causa.
• Mobile primeiro: teste a versão mobile das páginas que importam, como a página inicial, uma página de produto ou serviço e o checkout ou formulário de contato.
• Causas habituais: imagem de destaque grande demais, scripts e fontes que bloqueiam a renderização, deslocamentos de layout por imagens sem dimensões ou banners tardios e tags de terceiros pesadas.

A documentação do PageSpeed Insights observa que dados de laboratório e de campo podem divergir, e uma boa nota de laboratório não significa que os visitantes reais tiveram uma boa experiência. O guia de auditoria de desempenho de site mostra como ligar uma métrica lenta ao elemento que a causa.

Integrações

• Inventário: toda ferramenta de análise, gerenciador de tags, pixel de publicidade, ferramenta de consentimento e tag de verificação do site presente na página, e quem é responsável por cada uma.
• Duplicadas e sobras: duas cópias da mesma tag de análise ou um pixel de uma campanha que terminou no ano passado.
• Consentimento: uma ferramenta de consentimento onde for necessária e tags que esperam por ele.
• Dados pessoais: nenhum e-mail, telefone ou nome no data layer, nas URLs ou nos títulos de página lidos pelas tags. A ajuda do Google Analytics, por exemplo, pede que os donos de sites não enviem informações de identificação pessoal em URLs, títulos e eventos.

As verificações estáticas mostram o que o markup declara. Saber se uma tag realmente espera pelo consentimento, ou quais eventos disparam depois de um clique, exige uma sessão de navegador com as ferramentas de desenvolvedor abertas. O guia de auditoria de integrações de site percorre esse rastreamento.

4. Como auditar um site com IA, passo a passo

O Model Context Protocol (MCP) é uma forma comum de uma aplicação de IA chamar ferramentas de outros serviços. Com um serviço de auditoria conectado, o agente no seu chat ou ferramenta de código pode rodar verificações e trabalhar diretamente com os resultados. O fluxo tem nove etapas; as duas primeiras acontecem uma vez por site, as demais se repetem a cada auditoria.

1. Conectar. Adicione o serviço de auditoria como uma conexão MCP no seu cliente de IA e entre pelo navegador. Servidores MCP remotos que exigem conta costumam usar OAuth, como descreve a especificação de autorização do MCP; assim, você aprova o acesso em uma janela de login e nunca cola senha ou chave de API no chat. O Sitelemetry se conecta assim no ChatGPT, no Claude, no Claude Code, no Codex e no Cursor; o guia de conexão MCP traz os passos de cada cliente.
2. Definir escopo e autorização. Decida quais sites e páginas entram e audite apenas sites que são seus ou que você tem permissão por escrito para testar. Verificações passivas leem o que qualquer visitante vê; verificações ativas de segurança enviam requisições de sondagem e, por isso, só devem rodar depois de você verificar o controle do domínio. Diga o escopo ao agente em palavras simples: só produção, estas três URLs, sem envio de formulários.
3. Executar a auditoria. Peça uma auditoria completa ou de uma área: “Execute uma auditoria completa de https://www.example.com e liste os achados por severidade.” Auditorias longas podem rodar como tarefa em segundo plano; deixe o agente esperar o resultado em vez de iniciar uma segunda varredura.
4. Ler as evidências. Cada achado deve vir com severidade, evidência observada, impacto e correção. Peça ao agente que cite a evidência de tudo o que for classificado como alto e reproduza um ou dois achados você mesmo com curl -sI ou dig. Um achado que você consegue reproduzir é um achado que você corrige com confiança.
5. Priorizar. Ordene por severidade, depois por exposição (a página é pública, trata login ou pagamento?) e depois por esforço. Agrupe achados que compartilham uma correção, como vários cabeçalhos definidos na mesma configuração do servidor, e pergunte ao agente quais achados importam para este site e quais trazem pouco risco aqui.
6. Entregar ao agente de código um prompt de correção pronto para agentes. Transforme os achados escolhidos em um único pedido de mudança preciso, com evidência, restrições, critérios de aceite e passos de reteste (exemplo a seguir). Entregue ao agente de código que trabalha no seu repositório ou deixe o mesmo cliente fazer os dois, se tiver acesso ao repositório.
7. Publicar pelo processo normal. Revise o diff, teste em homologação e faça o deploy como em qualquer mudança. A auditoria não substitui a revisão de código, e um agente de código não deve fazer deploy sem aprovação de uma pessoa.
8. Auditar de novo para verificar. Rode a mesma verificação no mesmo alvo depois do deploy. Um achado está fechado quando um novo resultado não o mostra mais, e não quando o agente diz que editou um arquivo.
9. Monitorar. Agende a auditoria para se repetir, de modo que uma atualização de plugin, uma tag nova ou um certificado prestes a expirar apareça antes de os visitantes notarem. Semanal serve à maioria dos sites pequenos; sites que fazem deploy todo dia se beneficiam de execuções diárias.

A especificação do MCP recomenda um humano no circuito que possa negar chamadas de ferramentas, e a OWASP lista a agência excessiva, o risco de ações danosas quando um agente tem mais funcionalidade, permissões ou autonomia do que a tarefa exige, como um risco à parte. Na prática: deixe as ferramentas de auditoria só lerem e mantenha uma pessoa aprovando mudanças de código e deploys.

Um prompt de correção que um agente de código consegue executar sem adivinhar tem este formato (exemplo ilustrativo):

Fix: Strict-Transport-Security header missing
Target: https://www.example.com (all HTTPS responses)
Evidence: GET / over HTTPS returned 200 without a
Strict-Transport-Security header.
Constraints:
- Change only the header configuration of the web server or CDN.
- Use max-age=300 for now (first rollout stage); no preload.
- Do not change redirects, cookies or other headers.
Acceptance criteria:
- curl -sI https://www.example.com/ shows a
  Strict-Transport-Security header with max-age=300.
- The header is present on HTML, CSS and JavaScript responses.
Retest:
- Re-run the security audit for www.example.com and confirm
  the finding no longer appears.

Cada parte tem uma função. A evidência diz ao agente de código o que foi observado, para que ele não precise redescobrir o problema. As restrições mantêm a mudança pequena; começar o HSTS com um max-age curto e aumentá-lo em etapas é o caminho cauteloso descrito no guia de HSTS. Os critérios de aceite são comandos que qualquer pessoa pode rodar, e o passo de reteste fecha o ciclo com a mesma verificação que encontrou o problema.

5. Como avaliar uma ferramenta de auditoria de site com IA

Procure a melhor ferramenta de IA para auditar um site e você encontrará listas enormes. A escolha certa depende do seu site, mas as perguntas que separam uma ferramenta útil de auditoria com IA de um chatbot com um scanner acoplado são as mesmas para qualquer produto.

Depois, teste qualquer candidata no seu próprio site antes de depender dela:

• Rode duas vezes na mesma página, sem mudanças. Achados e severidades devem coincidir.
• Confira três achados à mão, um de segurança, um de SEO e um de acessibilidade, com curl, dig ou o código-fonte da página.
• Plante um problema conhecido em homologação, como uma imagem sem texto alternativo ou um título duplicado, e veja se ele é reportado.
• Corrija um achado e audite de novo. Ele deve desaparecer, e nada não relacionado deve mudar.
• Leia os limites. Uma ferramenta que diz o que não verifica inspira mais confiança do que uma que afirma verificar tudo.

A seção 8 lista o que o Sitelemetry cobre, como ele entrega as correções e onde estão seus limites.

6. Erros comuns e como evitá-los

O fio condutor de todos esses erros é o mesmo. Trate o agente como um colega rápido e articulado que nunca viu o servidor: dê evidências, mantenha as permissões dele restritas e confira o resultado no site no ar.

7. Um exemplo prático: o site de uma pequena clínica

Uma clínica odontológica mantém um site WordPress em www.example-clinic.com com um formulário de agendamento online. A gerente do consultório conecta um serviço de auditoria ao assistente de IA, verifica o domínio e pede uma auditoria completa da página inicial e da página de agendamento. Entre os resultados (ilustrativos, não são dados reais):

O agente explica por que os dois primeiros vêm antes: o backup expõe dados a qualquer pessoa que adivinhe o caminho, e o e-mail no código de rastreamento é repassado a todas as tags de terceiros que leem o data layer. Ele pergunta se o bloqueio dos crawlers de IA foi intencional. Ninguém havia decidido, então isso vira uma decisão do dono, e não uma correção.

No caso do backup, a correção não é código: apagar o arquivo, procurar outras cópias no servidor e descobrir qual processo o criou. Depois, verificar nos logs de acesso se houve downloads anteriores, trocar as senhas ou chaves que o backup continha e, se dados de pacientes podem ter sido expostos, seguir o procedimento de incidente de dados da clínica. Para os rótulos do formulário, o agente escreve um prompt de correção que nomeia os cinco campos e a página de agendamento em que estão, com a restrição de manter o design visual e o critério de aceite de que um leitor de tela anuncie um rótulo para cada campo. O agente de código do desenvolvedor faz a mudança, o desenvolvedor revisa e publica, e uma nova auditoria mostra o achado resolvido. O registro DMARC vai para quem gerencia o DNS, começando em p=none com relatórios, como explica o guia de implantação do DMARC. Cada item termina do mesmo jeito: alterado, publicado e verificado de novo com a auditoria que o encontrou.

8. Como executar esse fluxo com o Sitelemetry

O Sitelemetry é uma ferramenta de auditoria de site com IA criada para o fluxo deste guia:

• Seis áreas. Segurança, com até 27 módulos no plano Enterprise: DNS, SPF e DMARC, TLS, postura HTTPS, cabeçalhos de segurança, CORS, arquivos expostos, exposição de APIs e segredos, subdomain takeover, cadeia de suprimentos, superfície de autenticação, portas abertas, métodos HTTP, WordPress e mais. SEO técnico, incluindo cliques, CTR, posição e quick wins do Google Search Console. Prontidão de visibilidade em IA, acessibilidade, desempenho via PageSpeed Insights, Lighthouse e dados de campo do CrUX, e integrações.
• Evidências e correções. Os achados trazem severidade, evidência, impacto e correção, e cada auditoria pode gerar um prompt de correção pronto para agentes, com restrições, critérios de aceite e passos de reteste.
• Dentro das suas ferramentas de IA. Funciona via MCP com login OAuth no ChatGPT, no Claude, no Claude Code, no Codex e no Cursor; o guia de conexão MCP mostra como conectar. O login OAuth significa que você aprova o acesso em uma janela do navegador e nunca cola senha ou chave de API no chat.
• Verificar e monitorar. Audite de novo após uma correção para confirmá-la no site no ar. Dependendo do plano, o monitoramento roda semanalmente, diariamente ou a cada hora. Os relatórios podem ser exportados em JSON ou PDF, com relatórios white-label no Enterprise.
• Planos. Starter por US$ 49, Professional por US$ 149 e Enterprise por US$ 249 por mês; a página de preços lista o que cada um inclui.

Os limites são os que este guia pede para você procurar. As auditorias hospedadas observam o alvo sem alterá-lo, e as verificações ativas de segurança só rodam em alvos verificados. As verificações de SEO, visibilidade em IA, acessibilidade e integrações leem HTML estático, sem executar JavaScript. A verificação de visibilidade em IA avalia a prontidão do conteúdo e não consulta assistentes de IA. As verificações de acessibilidade são estáticas e orientadas às WCAG 2.2, não uma avaliação manual completa, e a auditoria de segurança não é um pentest. Mantenha as verificações manuais da seção 3 para o que a análise estática não enxerga.