Assistenza AX Protocol — diagnosticare e risolvere i problemi di accesso degli agentiAX Protocol — Assistenza

Autodiagnosi in tre passaggi

La maggior parte delle segnalazioni che riceviamo viene risolta da chi le ha aperte, una volta che sa dove guardare. Procedi in ordine attraverso tre livelli e nella maggior parte dei casi individuerai la causa prima di aver bisogno di noi. Parti dal livello di rete: richiedi il tuo manifest con un semplice client HTTP e leggi il codice di stato. Un 403 o una pagina di verifica significa che qualcosa davanti a WordPress sta bloccando la richiesta, e nessuna configurazione del plugin potrà rimediare.

Se lo stato è corretto, passa al livello dei contenuti. Confronta ciò che la dashboard del plugin dichiara di aver pubblicato con il file effettivamente servito. Una discrepanza a questo punto dipende quasi sempre dalla cache: a livello di WordPress, dell’hosting o della CDN. Svuotale tutte e tre e ripeti il controllo prima di trarre qualsiasi altra conclusione.

Solo se entrambi i livelli sono puliti conviene guardare alla configurazione. A quel punto la domanda non è quasi mai se il protocollo funzioni, ma se stia descrivendo correttamente il tuo sito: tipo di organizzazione errato, catalogo vuoto oppure endpoint che puntano a pagine non più esistenti.

Guasti frequenti e le loro cause

Tempi di risposta e gravità

Non tutti i problemi hanno lo stesso peso, quindi classificalo prima di scrivere. Un guasto che impedisce del tutto agli agenti di leggere il sito — per esempio un manifest che restituisce un errore del server — è urgente, perché ogni giorno in cui persiste è un giorno in cui il sito viene rappresentato in modo scorretto nelle fonti su cui gli agenti si basano. Un campo mancante nel catalogo o una descrizione di servizio poco precisa sono un miglioramento più che un guasto, e possono attendere il ciclo di aggiornamento successivo.

Quella classificazione determina anche che cosa fare nell’attesa. Con un guasto bloccante, riporta prima il sito a uno stato stabile — disattiva temporaneamente il componente responsabile — e prosegui l’indagine in un secondo momento. Con uno non bloccante, lascia tutto esattamente com’è: riprodurre un guasto corretto a metà richiede più tempo che diagnosticarne uno ancora attivo.

Che cosa includere quando ci scrivi

Quattro elementi trasformano uno scambio di due giorni in una risposta sola: l’URL esatto che hai testato, la risposta grezza che hai ricevuto compreso il codice di stato, la data e l’ora in cui il comportamento è iniziato e l’elenco di ciò che è cambiato sul sito nei giorni precedenti. L’ultimo punto conta più di quanto si creda: la grande maggioranza dei guasti improvvisi risale all’aggiornamento di un plugin, a una modifica dell’hosting o a una nuova regola di sicurezza, non al protocollo in sé.

Se gestisci più siti sullo stesso stack, tieni un registro condiviso di una riga per ogni incidente e per la sua risoluzione. Ti mostrerà in fretta che quasi tutti i problemi derivano da tre o quattro cause ricorrenti, e a quel punto potrai correggere la radice invece di riparare un sito alla volta.

Mantenere sana un’implementazione nel tempo

L’implementazione di un protocollo non è un lavoro da fare una volta sola. I siti cambiano: si aggiungono plugin, si aggiornano i temi, gli hosting introducono nuovi livelli di ottimizzazione, e ognuna di queste cose può alterare silenziosamente ciò che gli agenti ricevono. I siti che restano sani sono quelli che trattano il manifest come parte della checklist di rilascio, e non come qualcosa da configurare una volta e dimenticare.

Un’abitudine utile è una revisione mensile di cinque minuti: scarica il manifest da fuori della tua rete, verifica codice di stato e struttura, controlla a campione due pagine di contenuto per accertare la presenza del testo nella risposta grezza e dai un’occhiata al tasso di errore nel log del server. Tutto ciò che si è rotto emergerà da uno di questi quattro controlli. Tutto il resto è quasi certamente a posto.

Tieni un breve registro di ogni incidente e della sua risoluzione — che cosa è successo, quando, che cosa era cambiato, che cosa lo ha risolto. Una riga per evento è sufficiente. Se gestisci più siti sullo stesso stack, un registro condiviso rivelerà in fretta che quasi tutti i problemi derivano da tre o quattro cause ricorrenti, e a quel punto potrai intervenire sulla radice invece di riparare ogni sito singolarmente.

Che cosa l’assistenza non copre

Vale la pena essere espliciti sul confine. Noi supportiamo il protocollo: se il manifest viene generato correttamente, se il plugin si comporta come documentato e se un agente riesce a scoprire e leggere ciò che il tuo sito pubblica. Possiamo anche dirti perché un agente viene bloccato e, di norma, quale livello lo sta bloccando.

Quello che non possiamo fare è sostituirci all’assistenza WordPress generica. Se il problema di fondo è un conflitto di tema, una struttura di permalink rotta, un limite di risorse a livello di hosting o un plugin di sicurezza mal configurato sull’intero sito, lo individueremo e ti diremo che cosa cambiare, ma la modifica spetta a chi gestisce il sito. Allo stesso modo, non possiamo dare garanzie su come un determinato sistema di IA tratterà i tuoi contenuti. Il protocollo rende un sito leggibile: non obbliga nessuno a leggerlo, e nessun fornitore onesto può promettere il contrario.

Per qualsiasi questione commerciale — licenze, fatturazione, trasferimento di una licenza da un dominio a un altro — il canale è diverso da quello dell’assistenza tecnica e di solito si risolve più in fretta se lo dichiari subito.

Prima di aprire una segnalazione

La maggior parte delle segnalazioni che riceviamo si risolve da sola nel momento in cui chi le apre ripete il controllo con la cache disattivata e conferma che la richiesta ha effettivamente raggiunto il server di origine. Un nodo edge della CDN che conserva una vecchia copia del file manifest ha esattamente l’aspetto di un’installazione difettosa, e nessun intervento da parte nostra cambierà ciò che l’edge sta servendo. Svuota la cache, richiedi il file con una query string che aggiri la cache e confronta ciò che ottieni con ciò che il plugin ritiene di stare pubblicando.

Se i due risultati continuano a non coincidere dopo uno svuotamento pulito, si tratta di un difetto reale e vale la pena segnalarlo. Includi entrambe le risposte per intero, insieme all’ora esatta di ciascuna richiesta, perché il comportamento possa essere riprodotto e non solo dedotto da una descrizione.