Auditoria de SEO com IA: por que uma sessão não cobre um site inteiro

Um assistente de IA consegue revisar bem uma página: ele lê o title, os títulos e o texto que recebe e explica o que mudar. Uma única sessão de IA não consegue auditar um site inteiro, por dois motivos. A maior parte das evidências de que uma auditoria de SEO precisa não está no texto da página que o assistente lê: ela fica em cabeçalhos de resposta, no robots.txt, no sitemap XML, nos redirecionamentos e nas relações entre páginas. E, acima de um tamanho modesto, um site tem mais URLs do que uma sessão consegue ler e comparar de uma vez. O primeiro motivo é o maior, e um modelo maior não o diminui.

Em 45 sites externos auditados pelo SEOReport entre maio e outubro de 2026, 94% dos 506 problemas apontados estavam em algum lugar que quem lê a página nunca vê. Esta página percorre a conta da cobertura, mostra onde ficam essas evidências e explica como auditar um site com IA entregando ao assistente um diagnóstico do site inteiro antes que ele comece a corrigir. Ela parte de por que verificações pontuais com IA não substituem uma auditoria de SEO sistemática, que comparou os dois métodos; o assunto aqui são os números.

O que uma sessão de chat alcança e o que uma auditoria do site registra

Uma auditoria de site com IA feita no chat normalmente começa por um URL. A ferramenta de busca do assistente solicita aquela página e devolve o que recebeu, muitas vezes convertido em texto legível, e a conversa raciocina sobre esse texto. Uma auditoria sistemática começa um nível acima, no site. Ela lê os arquivos que governam o host inteiro, registra a resposta HTTP de cada URL que solicita, compara o HTML bruto com a página renderizada e depois compara as páginas entre si e com o sitemap.

O caminho de um único URL é um trabalho útil. Mas é só um caminho por um site que tem muitos, e cada etapa pode perder alguma coisa. Uma conversão para texto preserva as palavras que o visitante lê e pode descartar as tags do head e os cabeçalhos de resposta. E a próxima sessão começa sem as páginas que esta leu.

Qual é o tamanho do site que você está pedindo para um assistente auditar?

Dos 45 sites externos auditados pelo SEOReport entre maio e outubro de 2026, 15 (33%) não tinham sitemap XML no endereço indicado no robots.txt nem em /sitemap.xml. Entre os 29 desses sites cujo sitemap listava pelo menos um URL, o sitemap mediano listava cerca de 90 URLs; um quarto listava 20 ou menos, um quarto listava mais de 440, e o décimo maior listava mais de 3.000.

São sites enviados para uma auditoria do SEOReport, não uma amostra aleatória da web, e eles tendem a ser pequenos. Ainda assim, a dispersão é grande: os sites do décimo maior listam mais de 150 vezes mais URLs do que os do quarto menor. O terço de sites sem sitemap no endereço esperado também importa. Para eles, não existe uma lista de páginas onde um assistente ou um rastreador procuraria, então as páginas precisam ser encontradas seguindo links, uma busca de cada vez.

Quantas sessões leva uma auditoria de SEO com IA do site inteiro?

A tabela abaixo é um modelo, não uma medição. Ela divide os tamanhos de sitemap acima por um número suposto de páginas que uma sessão consegue ler por completo e ainda comparar lado a lado. As premissas:

• Uma sessão lê cada URL do sitemap uma vez, por completo, e o mantém disponível para comparação com os outros.
• São mostradas duas capacidades: 25 páginas e 100 páginas por sessão. As duas são ilustrativas. A capacidade real depende do assistente, da ferramenta de busca dele e do peso de cada página, e não a medimos.
• Só os URLs do sitemap são contados. robots.txt, cabeçalhos de resposta, saltos de redirecionamento e páginas renderizadas somam trabalho, então todos os números são um limite inferior.

Para cerca de metade dos 29 sites com sitemap, com a premissa generosa, o sitemap inteiro cabe numa sessão. É aí que uma revisão por chat se defende melhor. Acima da mediana, o número de sessões cresce com o site, e as sessões não somam uma auditoria.

A menos que o assistente tenha um recurso de memória ou que você cole anotações adiante, cada nova sessão começa sem as páginas que a anterior leu. Anotações carregam conclusões. Uma comparação posterior precisa da própria evidência: o URL canônico exato da página 12, o código de status por trás do redirecionamento da página 340. E uma sessão que escolhe a própria abordagem a cada vez pode verificar coisas diferentes em lotes diferentes, então o lote 7 e o lote 8 não são medidos da mesma forma.

A maior parte das evidências de SEO não está na página que você cola

O número de sessões é o problema menor. O gráfico abaixo pega os 506 problemas apontados em 45 sites externos auditados pelo SEOReport entre maio e outubro de 2026 e coloca cada um no lugar onde uma pessoa teria de olhar para ver a evidência. 94% estavam em algum lugar que quem lê a página nunca vê: cabeçalhos de resposta, tags do head, dados estruturados, sitemap XML, robots.txt, redirecionamentos ou relações entre páginas.

Nos mesmos 45 sites (maio a outubro de 2026), todos tinham pelo menos um problema apontado fora do texto visível da página, e em 24 deles (53%) todos os problemas apontados estavam fora dele. O site mediano tinha problemas apontados em 5 locais de evidência diferentes, e um quarto tinha 6 ou mais. Mesmo deixando de fora todos os cabeçalhos de segurança, 91% dos problemas restantes ainda estavam fora do texto visível da página.

Cada local exige uma forma própria de olhar:

• A resposta HTTP. A documentação do Google sobre como bloquear a indexação (consultada em outubro de 2026) diz que o noindex pode ser enviado como cabeçalho de resposta X-Robots-Tag, e a documentação sobre como especificar uma canônica diz que rel="canonical" pode ser enviado como cabeçalho HTTP Link. Nenhum dos dois aparece em lugar nenhum do texto da página.
• robots.txt. A documentação do Google sobre robots.txt (consultada em outubro de 2026) diz que o arquivo precisa ficar no diretório raiz e que as regras dele só valem para o host, o protocolo e a porta que o servem. www.example.com e shop.example.com respondem cada um ao próprio arquivo, como explica o nosso guia de robots.txt e acesso de rastreamento.
• HTML bruto versus página renderizada. A documentação do Google sobre SEO para JavaScript (consultada em outubro de 2026) diz que o Google usa o HTML renderizado para indexar uma página, que o melhor lugar para a canonical é o HTML, que o JavaScript não deve trocá-la por outro URL e que, quando encontra um noindex, o Google pode pular a renderização. Em 34 sites externos nos quais o SEOReport comparou o HTML bruto do servidor com a página renderizada (maio a outubro de 2026), 7 (21%) dependiam de JavaScript para algo que um buscador lê primeiro: o title, a meta description, a canonical ou o H1 só apareciam depois da execução do JavaScript, ou o HTML bruto quase não trazia o texto da página. Um assistente que lê texto convertido vê uma dessas duas versões, e a conversa raramente diz qual.

Alguns problemas só existem entre páginas

Dos mesmos 45 sites externos (maio a outubro de 2026), 32 (71%) tinham pelo menos um problema que não se vê em nenhum URL isolado: ele só aparece quando o sitemap é comparado com as páginas que lista, quando as páginas são comparadas entre si ou quando a biblioteca de artigos é lida como um todo. Sem a biblioteca de artigos, o número é 28 de 45 (62%).

Veja a forma dessa evidência num site ilustrativo:

# https://www.example.com/robots.txt
User-agent: *
Disallow: /checkout/

# https://www.example.com/sitemap.xml lists
https://www.example.com/checkout/
https://www.example.com/old-services/      (answers 301)

# https://www.example.com/en/services/ declares
hreflang="es" -> https://www.example.com/es/servicios/

# https://www.example.com/es/servicios/ declares
no hreflang link back to /en/services/

Cada arquivo parece correto sozinho. Os problemas só aparecem quando eles são lidos juntos:

• O sitemap contradiz as páginas. A documentação do Google sobre sitemaps (consultada em outubro de 2026) diz que um sitemap não garante que os URLs dele sejam rastreados e indexados, e a documentação sobre canônicas chama a inclusão no sitemap de sinal fraco de canonicalização. Listar um URL que redireciona, está bloqueado ou tem noindex manda um sinal contraditório. Em 29 sites externos cujos sitemaps o SEOReport buscou (maio a outubro de 2026), 8 (28%) tinham pelo menos um URL no sitemap que redireciona, está marcado com noindex ou é bloqueado pelo robots.txt.
• O robots.txt esconde um noindex. A documentação do Google diz que um rastreador bloqueado pelo robots.txt nunca vê o noindex da página, e o URL ainda pode ser indexado se outras páginas linkarem para ele. Ver isso exige o robots.txt e a página juntos, como mostra a nossa análise de conflitos de indexabilidade.
• Hreflang sem link de volta. O guia do Google sobre versões localizadas (consultado em outubro de 2026) afirma que, se duas páginas não apontarem uma para a outra, as tags serão ignoradas. Confirmar isso exige as duas páginas, como mostra o guia de implementação de hreflang.
• Uma canonical que aponta para um destino ruim. Uma canonical que indica uma página que redireciona ou tem noindex só fica visível quando o destino também é buscado.

Uma sessão de chat consegue pegar qualquer um desses casos se por acaso tiver as duas metades. Em muitas sessões, as metades podem facilmente cair em conversas diferentes, e nenhuma das conversas vê problema algum.

Como verificar o que uma auditoria de site com IA realmente cobriu

Antes de agir com base na auditoria de um assistente, peça quatro coisas: a lista de URLs que ele buscou, as linhas do robots.txt que leu, o código de status e os cabeçalhos da sua página inicial, e se ele comparou o HTML bruto com a página renderizada. Se ele não conseguir mostrar, considere que a auditoria não cobriu esses pontos. Depois, compare a lista de URLs dele com o seu sitemap.

Reunir essas mesmas evidências você mesmo leva três comandos:

curl -s https://www.example.com/robots.txt
curl -s -D - -o /dev/null https://www.example.com/ | grep -iE '^(HTTP/|location|x-robots-tag|link)'
curl -s https://www.example.com/sitemap.xml | grep -o '<loc>' | wc -l

O segundo comando faz uma solicitação GET normal e imprime só os cabeçalhos de resposta. Use o endereço de sitemap indicado no seu robots.txt, se for diferente de /sitemap.xml. Se o sitemap for um índice, a última contagem é o número de sitemaps filhos, não de páginas. Confira também se o assistente chegou a receber a sua página. Dos 377 sites externos enviados ao SEOReport entre maio e outubro de 2026, pelo menos 51 (13,5%) não deixaram um rastreador automatizado avaliar a página inicial, e pelo menos 34 (9%) responderam com um desafio contra bots ou CAPTCHA. A ferramenta de busca de um assistente também é um cliente automatizado; se ela deu de cara com uma página de desafio, foi o desafio que ela revisou. Nosso artigo sobre proteção contra bots que bloqueia rastreadores trata desse caso.

Dê ao assistente uma auditoria do site inteiro e depois deixe que ele corrija

Os assistentes são fortes no trabalho que vem depois de um diagnóstico: explicar um achado, escrever a mudança no template, rascunhar um mapa de redirecionamentos, reescrever um title. O que falta a uma sessão é uma entrada repetível e no nível do site. Um diagnóstico completo do SEOReport fornece isso. Ele lê o robots.txt e o sitemap, examina a sua página inicial e uma amostra das páginas que o sitemap lista e para as quais os seus links internos apontam, registra o status HTTP de cada página que solicita e compara o HTML bruto da sua página inicial com a página renderizada. Ele relata os achados que só existem entre páginas, como entradas de sitemap que contradizem as páginas que listam, links internos para páginas inexistentes e artigos quase duplicados. Cada achado traz a evidência e indica os URLs afetados, e cada achado tirado de uma amostra informa quantas páginas foram examinadas. Todo diagnóstico roda as mesmas verificações definidas, do mesmo jeito, então dois relatórios do mesmo site podem ser comparados achado por achado.

Um agente pode criar o relatório, acompanhar o andamento e ler cada achado pelo servidor MCP e pela API REST. As sessões dele passam então a começar pelo diagnóstico e a gastar a capacidade nas correções, um achado por vez. A página de agentes descreve essa configuração.

Perguntas frequentes

O ChatGPT consegue fazer uma auditoria de SEO?

Qualquer assistente capaz consegue revisar as páginas que recebe ou consegue buscar, e explica os problemas com clareza. Uma auditoria de SEO do site inteiro também precisa do robots.txt, do sitemap, dos cabeçalhos de resposta, do HTML bruto e renderizado e de comparações entre páginas. Trate uma auditoria por chat como uma revisão das páginas que ele leu e peça essa lista.

Modelos de IA maiores vão fechar essa lacuna?

Mais capacidade aumenta o número de páginas por sessão no modelo acima. Não leva as evidências para o texto da página: cabeçalhos, robots.txt e conflitos entre páginas ainda precisam ser buscados e comparados de forma deliberada. Um método fixo importa tanto quanto a capacidade, porque é ele que faz duas execuções concordarem.

Uma única sessão de IA basta para um site pequeno?

Para um site com uns 20 URLs, uma sessão consegue ler todas as páginas. Ela ainda precisa ter diante de si o robots.txt, o sitemap, os cabeçalhos de resposta e o HTML bruto, então peça esses itens explicitamente. O tamanho é a metade mais fácil do problema.

Devo colar o meu sitemap inteiro no chat?

Um sitemap colado dá à sessão uma lista de URLs. Não dá as páginas, os cabeçalhos nem os códigos de status delas. O assistente ainda precisa solicitar cada URL, o que traz de volta a conta de sessões descrita acima.