Sitemaps para GEO: os sinais que a IA segue

Sitemaps para GEO são a declaração formal de quais URLs do seu site devem ser tratadas como canônicas, atuais e dignas de recuperação pelos crawlers que alimentam assistentes de IA.

Não é um dump do banco. É contrato.

Abre o sitemap do seu site agora, em outra aba. Não o painel do plugin: o XML servido.

Olha o número total de URLs. Agora responde a segunda pergunta: quantas dessas páginas você colocaria, uma por uma, dentro da resposta de um assistente de IA sobre a sua empresa?

A distância entre esses dois números é o tamanho do ruído que o seu site emite hoje. Sem ninguém ter autorizado.

Quem foi a última pessoa a revisar o seu sitemap?

Na maioria das operações que a gente abre, a resposta é: ninguém.

O arquivo foi gerado por um plugin, com os defaults de uma instalação antiga, e desde então ele só cresce. Ninguém aprova, ninguém audita, ninguém é dono.

O resultado é previsível. Entra página de tag criada para uma campanha que acabou em 2021. Entra página de anexo de mídia. Entram listagens paginadas, resultado de busca interna, URL com parâmetro de filtro.

Tudo isso é declarado ao crawler com exatamente o mesmo peso das suas páginas de negócio.

E tem o lado inverso, que dói mais: o post type customizado que carrega o conteúdo mais valioso da operação (curso, unidade, protocolo, documentação técnica) nunca foi registrado no gerador. Ele existe, tem tráfego, e não está declarado em lugar nenhum.

Aí começa o atrito de sempre. Marketing publica a página, espera aparecer, não aparece, abre chamado e entra na fila de desenvolvimento.

Quem cuida das operações recebe esse chamado sem saber se aquilo é bug, cache, plugin ou uma regra de robots escrita três anos atrás por um fornecedor que já saiu.

Sitemap é declaração editorial de prioridade

Quando você lista tudo, você não declara nada. Você só transfere para a máquina o trabalho de adivinhar o que importa na sua operação.

E adivinhação, aqui, é sempre contra você.

O protocolo de sitemaps sempre foi explícito nisso: o arquivo é uma sugestão de quais URLs merecem atenção, não um espelho do banco de dados. A prática corporativa é que virou espelho.

Pensar sitemaps para GEO começa por essa inversão: a pergunta não é “o que o WordPress consegue listar?”, é “o que eu assino embaixo?”.

As três famílias de sinal de navegação

Vale separar, porque times diferentes mexem em cada uma e isso evita reunião improdutiva.

• Descoberta: o sitemap index e seus sub-sitemaps, a linha Sitemap: no robots.txt, os links internos contextuais e a profundidade de clique. É o que faz a URL ser encontrada.

• Elegibilidade: status HTTP, meta robots, X-Robots-Tag no cabeçalho, canonical e a cadeia de redirects. É o que diz se aquela URL pode ser usada numa resposta.

• Recência: o lastmod do sitemap, o feed e a data de modificação exposta no HTML. É o que diz se vale a pena voltar lá.

Sobre priority e changefreq: trate como campo morto. O próprio Google já declarou publicamente que ignora esses dois valores e usa apenas o lastmod, quando ele é consistente.

Discutir número de priority em reunião é queimar tempo que deveria ir para a família dois.

Agora a regra que sustenta tudo. Uma URL precisa dizer a mesma coisa em todos os lugares onde ela é declarada: sitemap, status, meta robots, header, canonical e link interno.

Coerência é o sinal. O resto é ruído.

Por que a contradição pesa mais em GEO do que no SEO clássico

Frequência.

Um buscador tradicional volta muitas vezes e vai corrigindo a leitura ao longo do tempo. Ele tem orçamento para errar e refazer.

Boa parte dos crawlers de IA passa menos vezes, renderiza menos JavaScript e reprocessa menos. A chance de correção é menor.

Contradição, nesse contexto, não atrasa. Elimina.

E não aparece erro nenhum no painel. O custo é silencioso: some menção, some citação, e ninguém consegue apontar a linha que quebrou.

Tem ainda o lastmod, que na minha visão é o sinal mais desperdiçado do WordPress. Ele só vale se for diferenciado e verdadeiro.

Se o seu sitemap diz que quinze mil páginas mudaram na mesma madrugada, você não está informando recência. Está ensinando o crawler que o seu carimbo de data não significa nada.

É como a chave reserva que todo mundo da casa tem cópia: a partir de certo ponto, ela deixa de ser controle de acesso e vira enfeite no chaveiro.

Cinco verificações no sitemap, feitas no que o servidor entrega

Terminal aberto. Tudo em cima do que o servidor responde, não do que o painel do plugin promete.

1. Composição do índice

Roda curl -s https://seudominio.com/wp-sitemap.xml e olha os sub-sitemaps listados. Depois conta cada um com curl -s …/post-sitemap.xml | grep -c “<loc>”.

O que você procura: sitemap de tag, de autor, de anexo, de taxonomia interna.

Pergunta de negócio para cada linha: essa página é destino de alguém? Se ela existe só porque o gerador nativo do WordPress ou o plugin a criou por padrão, ela sai do índice.

2. Elegibilidade da amostra

Pega vinte URLs aleatórias do sitemap e roda curl -sIL em cada uma. Você quer duas coisas: o status final e o X-Robots-Tag.

Qualquer 3xx ou 4xx dentro do sitemap é contradição pura. Você declarou como canônica uma URL que o seu próprio servidor recusa.

3. Canonical cruzado

Roda curl -s URL | grep canonical e compara o valor com a URL que está no sitemap. Tem que ser idêntico: protocolo, www e barra final inclusos.

E faz com curl, não com o inspetor do navegador. Você quer o HTML que sai atrás da sua camada de cache, não o que o browser montou depois.

4. Distribuição do lastmod

Roda grep -o “<lastmod>.*</lastmod>” sitemap.xml | sort | uniq -c | sort -rn.

Se uma data única concentra a maior parte das URLs, o seu lastmod está preso ao deploy, não ao conteúdo.

Sinal de recência queimado é pior que sinal ausente.

5. O que ficou de fora

Essa é a inversa, e quase ninguém faz.

Monta a lista das URLs que sustentam o negócio: páginas de oferta, hubs de conteúdo, documentação, material de referência. Confere duas coisas para cada uma.

Está no sitemap? E tem link interno contextual apontando para ela?

URL no sitemap sem link interno continua órfã. O sitemap declara existência, o link interno declara importância. São sinais diferentes e você precisa dos dois.

Bônus: o robots.txt

Confere a linha Sitemap: apontando para o index certo. Confere Disallow herdado bloqueando diretório de assets.

E confere se existe regra para user-agents de IA que entrou por copy-paste, sem decisão. Bloquear crawler de IA é escolha legítima de negócio, e vale separar bot de treino de bot de citação antes de decidir.

O problema é descobrir que a escolha foi tomada por acidente, em 2022, por um fornecedor que já não atende você.

Governança é o que segura o ganho

Limpar sitemap uma vez é projeto. Manter limpo é processo.

Três coisas seguram o resultado depois da faxina.

• Dono declarado: alguém aprova o que entra e o que sai do sitemap, com o mesmo rigor de quem aprova uma publicação no site.

• Regra versionada em código: a exclusão de tipos e taxonomias registrada no tema ou em plugin próprio, em vez de ficar numa caixinha de configuração que a próxima atualização pode reverter.

• Diff no pipeline: cada deploy compara a contagem de URLs do sitemap antes e depois. Variação sem ticket associado vira alerta, não rotina.

Esse trio transforma sitemaps para GEO em algo auditável, e tira a discussão do campo da opinião.

Perguntas frequentes sobre sitemaps para GEO

O sitemap nativo do WordPress é suficiente?

Para sites pequenos, geralmente sim. Em operações com múltiplos post types, taxonomias internas e áreas transacionais, o gerador nativo lista por padrão coisas que você não quer declarar e ignora estruturas customizadas. O ponto não é nativo contra plugin: é quem definiu a regra de inclusão e se essa regra está escrita em algum lugar.

Quantas URLs um sitemap para GEO deve ter?

Não existe número certo. Existe proporção: a quantidade de URLs declaradas deve se aproximar da quantidade de páginas que você defenderia numa resposta sobre a sua empresa. Se o sitemap tem dez vezes mais linhas do que isso, o problema não é volume, é ausência de critério editorial.

Preciso de um sitemap separado só para crawlers de IA?

Não. Os crawlers de IA consomem o mesmo XML, as mesmas respostas de header e o mesmo HTML servido. O que muda é a tolerância: eles voltam menos e corrigem menos. Investir num sitemap paralelo rende menos do que investir em coerência entre sitemap, status, canonical e link interno.

Vale ajustar priority e changefreq?

Não vale o tempo da reunião. Os mecanismos relevantes ignoram esses campos há anos. Coloque a energia no lastmod real por conteúdo e na elegibilidade de cada URL declarada.

Conclusão

Resumo para levar à próxima conversa com a TI.

Sitemap é declaração de prioridade, não inventário. Três famílias de sinal: descoberta, elegibilidade e recência. A regra é coerência entre as três.

Cinco verificações, todas sobre o que o servidor entrega: composição do índice, status e X-Robots-Tag da amostra, canonical cruzado, distribuição de lastmod, e o inverso, o que ficou de fora sem link interno.

Se o seu site declara páginas que ele mesmo recusa, o problema não é falta de conteúdo. É contradição, e ela custa mais caro que ausência.

Aqui na Apiki, a gente trata navegação como a camada 3 do framework de GEO Técnico, e roda essas correções dentro do WP Care, junto com a operação de publicação do dia a dia. Se quiser olhar a sua operação com a gente, é só chamar.

Roda as cinco checagens hoje: leva menos tempo que a reunião que você marcaria para discutir o assunto.

E me conta: quando foi a última vez que alguém no seu time abriu o XML servido, e não o painel do plugin?