Quando il chatbot del sito non si carica, identifica la fase fallita prima di cambiare impostazioni: la pagina potrebbe non contenere il caricatore, il browser potrebbe bloccare una risorsa, una regola di consenso potrebbe ritardarla intenzionalmente, la configurazione potrebbe non essere disponibile oppure un’interfaccia già montata potrebbe essere nascosta. Un widget visibile che non trova una risposta è un problema diverso. Parti dalla pagina, dallo stato del visitatore e dalle prove del browser, poi assegna un problema circoscritto al responsabile corretto.
Questa guida offre una lista originale di risorse e stati per valutare un widget di chat. Non raccomanda di disattivare Content Security Policy, copiare la lista di autorizzazioni di un altro fornitore o dichiarare conforme una configurazione del consenso. Una diagnosi utile può concludersi con una sospensione per incompatibilità, anziché con un’indicazione a indebolire la politica del sito.
Autore: Achla AI, organizzazione. Revisione: 14 ottobre 2026. Il modello combina documentazione attuale di browser e fornitori con istruzioni di installazione Achla esaminate, ed è stato preparato con assistenza dell’IA. Gli esempi sono ipotetici; non sono stati misurati incidenti di clienti o risultati di test nel browser. Lo scopo è rendere verificabile un problema di caricamento prima che il proprietario valuti o modifichi il widget.
Cosa manca: interfaccia, richiesta o fonte della risposta?
Descrivi cosa vede realmente il visitatore. «Il chatbot è rotto» unisce osservazioni diverse che richiedono responsabili e correzioni differenti.
Se manca un pulsante o un riquadro incorporato, indaga installazione, caricamento e visibilità. Se l’interfaccia appare ma non ottiene configurazione o risposta, esamina la richiesta pertinente e lo stato documentato del server. Se l’interfaccia restituisce una risposta ma omette una pagina specifica, indaga raccolta delle fonti e recupero delle informazioni separatamente.
Non cambiare i permessi di scansione per correggere un’interfaccia mancante. Analogamente, uno script caricato correttamente non prova che la richiesta di risposta sia riuscita. La documentazione di installazione di Achla distingue posizionamento e verifica, mentre le indicazioni di risoluzione dei problemi separano widget e ricerca. Parti dal livello sostenuto dall’osservazione.
Registra la pagina pubblica esatta e lo stato in cui si verifica il problema. L’anteprima di un redattore autenticato non dimostra l’esperienza di un visitatore anonimo. Annota se la pagina è appena stata aperta, è stata rivisitata o è stata raggiunta dopo una scelta di consenso.
Segui la matrice di risorse e stati
Usa questa scheda originale per registrare prove anziché indovinare una correzione. Le righe descrivono condizioni possibili, non misure provenienti da un incidente reale.
| Fase | Prove da registrare | Domanda per il responsabile |
|---|---|---|
| Marcatura della pagina | Integrazione prevista presente o assente nella pagina pubblicata | Il modello o connettore gestisce l’ambito di pagine previsto? |
| Caricatore | URL dello script, stato della richiesta e messaggio pertinente della console | Il caricatore è stato richiesto, bloccato o impossibile da caricare? |
| Configurazione | Richiesta di configurazione e risposta osservabile | Ha raggiunto il servizio previsto e lo stato documentato è pronto? |
| Richiesta di risposta | Cosa avviene inviando una domanda pubblica di prova | La richiesta è bloccata, respinta o restituisce una risposta utilizzabile? |
| Interfaccia montata | Controlli visibili ed elementi nascosti o spostati | Il widget è montato ma non appare dove previsto? |
| Sequenza del consenso | Osservazioni di nuova visita, rifiuto, accettazione e ritorno | Il ritardo è intenzionale e la sequenza approvata funziona? |
Lascia sconosciuto ciò che non sai. «Nessuna richiesta osservata» e «richiesta respinta» sono registrazioni diverse. Acquisisci un messaggio specifico della console o un risultato della richiesta, se disponibile, invece di chiamare ogni guasto «CORS».
Aggiungi una condizione di accettazione accanto alla riga fallita. Per esempio, «dopo la scelta di consenso approvata, la richiesta documentata di configurazione raggiunge il servizio previsto» è più utile di «far comparire il bot». Per un’interfaccia nascosta la condizione può indicare la pagina pubblicata e la posizione prevista del controllo. Sono criteri proposti, non verifiche completate.
Assegna la riga al responsabile di quel livello. Un problema del modello spetta al manutentore del sito; un requisito controverso della politica al responsabile della sicurezza; un ritardo intenzionale al responsabile del consenso. Il supporto del fornitore potrebbe dover chiarire un prerequisito documentato. Evita di modificare un altro livello soltanto perché le sue impostazioni sono più accessibili.
Identifica anche il meccanismo d’integrazione. Il connettore WordPress e il modulo Drupal di Achla usano un caricatore proprio, non un tag /w.js incollato direttamente. Le istruzioni attuali di installazione descrivono questa distinzione. L’assenza di quel tag specifico, da sola, non prova che il connettore abbia fallito.
Usa una domanda pubblica controllata quando verifichi la fase della risposta. Qui occorre capire se funziona il percorso della richiesta, non creare un nuovo benchmark della qualità delle risposte. Escludi dati sensibili degli account dagli input di prova e dai registri diagnostici.
Leggi l’errore della politica del browser prima di cambiare una direttiva
Content Security Policy è una politica del browser sulle risorse. La guida CSP di MDN spiega come limita i contenuti caricabili o eseguibili da una pagina. Un widget può dipendere da più risorse del suo script iniziale: un caricatore riuscito può quindi essere seguito da una richiesta di configurazione o da stili bloccati.
La documentazione di script-src riguarda origini ed esecuzione degli script. La documentazione di connect-src riguarda connessioni effettuate da interfacce come fetch. Stili e frame hanno considerazioni proprie. Associa il messaggio reale del browser alla risorsa e alla direttiva indicate.
Crea una piccola registrazione della risorsa: URL richiesto, fornitore previsto, tipo di risorsa, direttiva nominata, risultato osservato e responsabile della politica. Controlla i requisiti documentati attuali del fornitore. Non dedurre le origini da esempi di un altro venditore e non approvare un carattere jolly troppo ampio solo per eliminare l’avviso.
La pagina Intercom di risoluzione degli errori CSP descrive risorse e diagnosi per Intercom. Le indicazioni tawk.to sulle immagini mancanti nel widget descrivono i suoi sintomi specifici. Queste pagine mostrano perché un’interfaccia parzialmente visibile può avere un problema legato a una risorsa; non sono ricette di configurazione per Achla.
Se il responsabile della sicurezza usa una politica solo di segnalazione per osservare, tienila separata da quella applicata. MDN distingue segnalazione e applicazione. Un’osservazione in modalità report-only non dimostra che la politica applicata permetta il widget, e aggiungerla non autorizza a rimuovere le protezioni esistenti.
Tratta il consenso come una sequenza di stati
Il caricamento ritardato può essere intenzionale. Prima di classificare uno script mancante come difetto, stabilisci il comportamento di caricamento approvato del sito e chi ne gestisce il consenso.
La documentazione ChatLab sul caricamento dopo il consenso descrive esplicitamente questo approccio per ChatLab. Non dimostra l’integrazione automatica con ogni gestore del consenso, né che un altro fornitore segua la stessa sequenza. Il responsabile del sito deve determinare classificazione e requisiti applicabili.
Usa una registrazione separata per ogni stato previsto:
| Stato del visitatore | Cosa osservare | Cosa non deve presumere la registrazione |
|---|---|---|
| Nuovo visitatore | Se il caricatore viene richiesto prima di una scelta | Che ogni chatbot debba caricarsi subito |
| Rifiuto | Se viene mantenuto il comportamento di rifiuto approvato | Che l’assenza del widget sia automaticamente un difetto |
| Accettazione | Se la sequenza prevista inizia e termina | Che un solo script riuscito provi l’intera interazione |
| Ritorno | Se le scelte salvate producono il comportamento previsto | Che la sessione del redattore rappresenti ogni visitatore |
Sono spunti di osservazione, non conclusioni legali o risultati dichiarati di test. Se comportamento previsto e osservato divergono, registra lo stato e fornisci al responsabile del consenso un problema riproducibile. Non aggirare il meccanismo di consenso come scorciatoia generica di risoluzione.
Uno strumento di consenso può controllare il caricamento dello script, mentre una politica del browser controlla una richiesta successiva. Registra entrambi invece di scegliere prematuramente una spiegazione. Uno stato può rivelare più problemi indipendenti.
Se una politica rigorosa sugli stili non è compatibile con il widget?
A volte la conclusione corretta è che i requisiti documentati del widget non corrispondono alla politica del sito.
La guida attuale di installazione di Achla indica che il widget inserisce il foglio di stile come elemento style e include il permesso per stili inline tra i requisiti CSP. È un fatto di compatibilità da esaminare con il responsabile della sicurezza, non una raccomandazione a concedere un’eccezione generale unsafe-inline. La documentazione esaminata non dimostra un’API Achla d’integrazione con nonce o hash.
Un altro fornitore può documentare un meccanismo diverso. Il registro delle modifiche CSP di SiteSpeakAI descrive il supporto nonce del proprio widget. Questo non dimostra un supporto equivalente in Achla e non giustifica copiare l’attributo in un altro script.
Se il sito richiede una politica rigorosa con nonce o hash, sospendi l’integrazione finché non sia verificato un comportamento compatibile. Chiedi al fornitore prove attuali oppure valuta un’alternativa i cui requisiti documentati soddisfino la politica. Coinvolgi il suo responsabile: un pulsante visivamente funzionante non equivale all’accettazione di un confine di sicurezza modificato.
Anche le indicazioni BoldDesk per la risoluzione CSP trattano i requisiti del proprio widget di chat dal vivo. Usa la documentazione specifica per formulare domande, non per unire eccezioni di più fornitori in una politica permissiva.
Prepara un pacchetto diagnostico privo di informazioni private
Una consegna utile permette al manutentore del sito, al responsabile del consenso o al fornitore di riprodurre il problema senza ricevere informazioni private.
Includi pagina pubblica, data di osservazione, meccanismo d’integrazione, posizionamento previsto, stato del consenso e fase fallita della matrice. Aggiungi origine della risorsa interessata, esito della richiesta e messaggio della console. Specifica se l’interfaccia era assente, nascosta, configurata ma incapace di rispondere oppure in attesa della scelta di consenso prevista.
Per esempio, una registrazione ipotetica potrebbe dire: «Pagina pubblicata delle condizioni; nuova sessione anonima; consenso accettato; caricatore richiesto; richiesta di configurazione bloccata dalla direttiva di connessione indicata; nessuna richiesta di risposta ancora». Restringe l’indagine senza affermare che un cliente reale abbia vissuto questa sequenza.
Rimuovi credenziali, chiavi private, identificatori di sessione, messaggi personali e dati degli account. Il pacchetto non deve contenere un’intera conversazione privata o un archivio di rete non esaminato. Registra il minimo necessario a distinguere risorsa e stato falliti, indicando il responsabile della prossima decisione.
Ripeti lo stesso stato dopo una correzione approvata
Definisci correzione e responsabile prima di applicarla. Poi ripeti la stessa pagina, lo stesso stato del visitatore e la stessa domanda pubblica. Registra cosa è cambiato e quale fase riesce o resta sconosciuta. Evita di raggruppare sostituzione dello script, modifiche al consenso e alla politica in un risultato senza spiegazione.
Se la console segnala ancora una violazione, restituisci direttiva e origine esatte al responsabile della sicurezza. Se la risposta di configurazione non è pronta, segui i prerequisiti documentati del fornitore. Se è nascosta soltanto l’interfaccia, indaga il suo posizionamento invece di modificare i permessi di rete.
Un nuovo test di caricamento riuscito dimostra solo il comportamento osservato. Non certifica accessibilità, conformità della privacy, esattezza delle risposte o compatibilità con ogni browser e pagina. I guasti ambigui devono rimanere aperti con una richiesta di prove, anziché ricevere una soluzione alternativa non verificata di un altro fornitore.
Valuta i requisiti attuali di Achla prima del collegamento
Usa la matrice compilata come lista di compatibilità: installazione documentata, politica e requisiti dei contenuti pubblici del widget si adattano a questo sito specifico? Per percorsi propri dei CMS, esamina il connettore WordPress esistente o il modulo Drupal. Un percorso generico tramite script dipende dalla capacità reale del sito di includerlo e consentirlo; non dimostra un’integrazione dedicata con un altro CMS.
Dopo aver compreso interfaccia e percorso della richiesta, usa separatamente la guida al chatbot basato sui contenuti del sito per le fonti e la scheda di valutazione delle risposte fondate sulle fonti per il loro supporto. Se l’ambito documentato è adatto, avvia il percorso di onboarding esistente. Mantieni sospesa l’incompatibilità con una politica rigorosa finché le prove non la risolvono. Il risultato utile è una decisione verificabile sul sito, con protezioni ancora integre e affidate ai rispettivi responsabili.
