Apoio AX Protocol — diagnosticar e resolver problemas de acesso dos agentesAX Protocol — Apoio

Autodiagnóstico em três passos

A maioria dos pedidos que recebemos acaba por ser resolvida por quem os abriu, assim que sabe onde procurar. Percorra três camadas por ordem e, na maior parte dos casos, encontrará a causa antes de precisar de nós. Comece pela camada de rede: peça o seu manifesto com um cliente HTTP simples e leia o código de estado. Um 403 ou uma página de verificação significa que algo à frente do WordPress está a bloquear o pedido, e nenhuma configuração da extensão resolverá isso.

Se o estado estiver correto, passe à camada de conteúdo. Compare aquilo que o painel da extensão diz ter publicado com o ficheiro que está efetivamente a ser servido. Uma discrepância aqui deve-se quase sempre à cache: na camada do WordPress, na do alojamento ou na CDN. Limpe as três e volte a verificar antes de concluir seja o que for.

Só se ambas as camadas estiverem limpas é que vale a pena olhar para a configuração. Nesse ponto a questão raramente é se o protocolo funciona, mas se está a descrever corretamente o seu site: tipo de organização errado, catálogo vazio ou endpoints a apontar para páginas que já não existem.

Falhas comuns e o que as provoca

Tempos de resposta e gravidade

Nem todos os problemas têm o mesmo peso, por isso classifique-o antes de escrever. Uma falha que impede por completo os agentes de lerem o site — um manifesto que devolve um erro de servidor, por exemplo — é urgente, porque cada dia que persiste é um dia em que o site é mal representado nas fontes de que os agentes dependem. Um campo em falta no catálogo ou uma descrição de serviço pouco precisa são uma melhoria e não uma falha, e podem esperar pelo próximo ciclo de atualização.

Essa classificação decide também o que fazer enquanto espera. Perante uma falha bloqueante, devolva primeiro o site a um estado estável — desative temporariamente o componente responsável — e prossiga a investigação depois. Perante uma não bloqueante, deixe tudo exatamente como está: reproduzir uma falha parcialmente corrigida demora mais do que diagnosticar uma que continua ativa.

O que incluir quando nos contactar

Quatro elementos transformam uma troca de dois dias numa resposta única: o URL exato que testou, a resposta em bruto que recebeu incluindo o código de estado, a data e a hora em que o comportamento começou e a lista do que mudou no site nos dias anteriores. O último ponto conta mais do que se imagina — a grande maioria das falhas súbitas tem origem na atualização de uma extensão, numa alteração do alojamento ou numa nova regra de segurança, e não no protocolo em si.

Se gere vários sites sobre a mesma stack, mantenha um registo partilhado de uma linha por cada incidente e respetiva resolução. Depressa lhe mostrará que quase todos os problemas vêm de três ou quatro causas recorrentes, e a partir daí poderá corrigir a raiz em vez de reparar site a site.

Manter uma implementação saudável ao longo do tempo

A implementação de um protocolo não é uma tarefa única. Os sites mudam: acrescentam-se extensões, atualizam-se temas, os alojamentos introduzem novas camadas de otimização, e qualquer uma destas coisas pode alterar discretamente aquilo que os agentes recebem. Os sites que se mantêm saudáveis são os que tratam o manifesto como parte da lista de verificação de cada publicação, e não como algo configurado uma vez e depois esquecido.

Um hábito útil é uma revisão mensal de cinco minutos: obtenha o manifesto a partir de fora da sua rede, confirme o código de estado e a estrutura, verifique por amostragem duas páginas de conteúdo para confirmar a presença do texto na resposta em bruto e observe a taxa de erros no registo do servidor. Tudo o que estiver avariado aparecerá numa destas quatro verificações. Tudo o resto está quase de certeza bem.

Mantenha um breve registo de cada incidente e da sua resolução — o que aconteceu, quando, o que tinha mudado, o que o resolveu. Uma linha por evento é suficiente. Se gere vários sites sobre a mesma stack, um registo partilhado revelará depressa que quase todos os problemas vêm de três ou quatro causas recorrentes, altura em que poderá atacar a raiz em vez de reparar cada site individualmente.

O que o apoio não cobre

Vale a pena ser explícito quanto à fronteira. Nós apoiamos o protocolo: se o manifesto é gerado corretamente, se a extensão se comporta conforme documentado e se um agente consegue descobrir e ler aquilo que o seu site publica. Podemos também dizer-lhe porque é que um agente está a ser bloqueado e, habitualmente, que camada o está a bloquear.

O que não podemos fazer é funcionar como apoio geral ao WordPress. Se o problema de fundo for um conflito de tema, uma estrutura de ligações permanentes danificada, um limite de recursos ao nível do alojamento ou uma extensão de segurança mal configurada em todo o site, identificá-lo-emos e diremos o que mudar, mas a mudança cabe a quem mantém o site. Do mesmo modo, não podemos dar garantias sobre a forma como um determinado sistema de IA tratará o seu conteúdo. O protocolo torna um site legível: não obriga ninguém a lê-lo, e nenhum fornecedor honesto pode prometer o contrário.

Para qualquer assunto comercial — licenciamento, faturas, migração de uma licença entre domínios — o canal é distinto do apoio técnico e costuma resolver-se mais depressa se o disser logo de início.

Antes de abrir um pedido

A maioria dos relatos que recebemos resolve-se sozinha assim que quem os abriu repete a verificação com a cache desativada e confirma que o pedido chegou de facto ao servidor de origem. Um nó de edge da CDN que guarda uma cópia antiga do ficheiro de manifesto tem exatamente o aspeto de uma instalação avariada, e nenhum trabalho do nosso lado alterará aquilo que o edge está a servir. Limpe a cache, peça o ficheiro com uma query string que contorne a cache e compare o que obtém com aquilo que a extensão julga estar a publicar.

Se os dois continuarem a divergir depois de uma limpeza completa, trata-se de um defeito real e vale a pena reportá-lo. Inclua ambas as respostas na íntegra, juntamente com a hora exata de cada pedido, para que o comportamento possa ser reproduzido em vez de deduzido a partir de uma descrição.