Documentação AX Protocol — instalar e configurar um site WordPress pronto para agentesAX Protocol — Documentação

Conviver com o SEO, a cache e a CDN

Quase todos os sites que instalam o AX Protocol já usam uma extensão de SEO, uma camada de cache e muitas vezes uma CDN. Os três tocam exatamente nos ficheiros que o protocolo gera: vale a pena fixar a ordem das operações antes de começar, em vez de a depurar depois. A sua extensão de SEO continua a ser dona do sitemap.xml e das etiquetas canónicas. O AX Protocol não substitui nenhum dos dois; acrescenta uma camada de manifesto por cima. Quando dois componentes escrevem no mesmo caminho, ganha o último da cadeia: verifique sempre o ficheiro publicado em vez de confiar no ecrã de definições.

A cache é de longe a maior fonte de problemas que parecem erros do protocolo. Um manifesto colocado em cache antes de uma alteração de definições continuará a ser servido aos agentes durante horas, e o site passa a declarar uma estrutura que já não corresponde ao seu conteúdo. A regra é simples: depois de qualquer alteração, limpe a cache toda e verifique o ficheiro publicado numa janela privada. Se usa uma CDN, acrescente também uma limpeza no edge; caso contrário a origem serve a versão nova enquanto visitantes e agentes ainda recebem a antiga.

O terceiro componente é a firewall de aplicação web. Vários fornecedores bloqueiam por predefinição os pedidos sem uma impressão digital de navegador reconhecida, e os agentes de IA encaixam plenamente nessa categoria. Se as verificações locais passam mas o mesmo pedido a partir da internet aberta devolve 403, suspeite de uma regra de bloqueio antes de suspeitar da extensão. Comece por adicionar os caminhos do manifesto à lista de autorização.

Verificações manuais

O painel comunica aquilo que a extensão julga ter publicado. Não é a mesma coisa que aquilo que um agente recebe, e as duas coisas divergem mais vezes do que seria de esperar. Quatro verificações demoram cerca de cinco minutos e apanham a maioria das falhas reais.

Primeiro, peça o manifesto com um cliente HTTP simples em vez de um navegador e confirme que obtém um 200 e JSON válido, e não uma página de desafio HTML. Segundo, obtenha da mesma forma uma página de conteúdo importante e confirme que o texto substantivo está presente na resposta em bruto — se o corpo chegar vazio, o seu conteúdo está a ser injetado por JavaScript e os agentes nunca o verão. Terceiro, siga cada URL declarado no manifesto e confirme que nenhum redireciona nem devolve 404, porque um manifesto que aponta para caminhos mortos é pior do que manifesto nenhum. Quarto, repita a primeira verificação a partir de fora da sua rede, idealmente numa ligação móvel, para excluir uma lista de autorização por IP que só faz o seu escritório parecer saudável.

Registe os resultados algures. Quando alguma coisa se partir daqui a três meses, o caminho mais rápido para o diagnóstico é o registo de como era um estado que funcionava.

Atualizações, migrações e compatibilidade ao longo do tempo

Mudar de alojamento, mudar de domínio ou passar para um subdomínio são os acontecimentos com maior probabilidade de partir a configuração do protocolo, porque os URL absolutos guardados nas definições continuam a apontar para a localização antiga. Documente a sua configuração antes de uma migração e percorra depois cada caminho do manifesto para confirmar que resolve no novo endereço. Se o site também passou de HTTP para HTTPS, procure redirecionamentos duplicados pelo caminho: uma cadeia longa de redirecionamentos leva alguns agentes a abandonar o pedido a meio.

As atualizações da extensão são menos arriscadas, mas não isentas de risco. A especificação tem versões, e uma mudança de versão principal pode alterar nomes de campos no manifesto. Leia a nota de lançamento antes de uma atualização principal e, se construiu alguma coisa que consome o seu próprio manifesto, teste-a com o novo resultado antes de a pôr em produção.

Se só tiver tempo para três coisas

Se esta é uma primeira implementação e não consegue percorrer todas as secções, três itens entregam a maior parte do valor: um manifesto válido que resolve no caminho esperado, uma descrição da organização numa linha, rigorosa, que diga o que o site faz e para quem, e um catálogo de serviços com as páginas que quer efetivamente ver citadas. Todo o resto — pontos de acesso alargados, definições de permissões, descoberta avançada — pode ser acrescentado de forma incremental. Um site com estas três coisas já é razoavelmente legível para os agentes, e poderá melhorá-lo com base no que os registos do servidor mostram em vez de por adivinhação.

Onde o AX Protocol encaixa num site multilingue

Se o site funciona em mais do que uma língua, decida cedo que língua o manifesto descreve. O protocolo emite um manifesto por variante linguística, e os agentes seguem os mesmos sinais hreflang que os motores de busca: um conjunto de traduções bem ligado significa que um agente que pergunta em espanhol chega à página espanhola em vez da inglesa. Um conjunto de traduções partido faz com que todas as línguas colapsem na predefinida, o que é pior do que não ter traduções.

A verificação é rápida: obtenha a raiz de cada língua e confirme que as ligações alternate listam todas as variantes mais a x-default, e que cada variante aponta para um URL que devolve 200 nessa língua. Os sites construídos por clonagem de páginas entre línguas falham este teste com frequência, porque as cópias nunca foram ligadas num grupo de tradução e cada uma se apresenta aos agentes como um documento sem relação.