Se un widget chatbot WordPress copre un pulsante su mobile, sceglietene la posizione considerando l’attività principale della pagina e chi controlla il template pubblicato. Un pulsante di apertura flottante adatto a un articolo può ostacolare un modulo di contatto. Un riquadro incorporato può funzionare in una pagina di assistenza senza comparire altrove. Registrate queste differenze prima di modificare il widget su tutto il sito.
Questa guida offre un registro delle responsabilità delle pagine, una tabella per decidere il posizionamento e una scheda di accettazione. Aiutano il proprietario del sito o l’agenzia a scegliere dove inserire la chat senza considerare l’anteprima dell’editor una prova. Gli esempi sono scenari proposti, non test con clienti o risultati misurati.
Autore: Achla AI, organizzazione. Revisione: 14 ottobre 2026. Preparato con l’assistenza dell’IA a partire dalla documentazione ufficiale e dalle fonti di prodotto esaminate. Questa data di revisione non è una data di pubblicazione.
Partire dall’attività su mobile, non dall’angolo della chat
Scrivete una frase per ogni famiglia di pagine: «Il visitatore deve leggere questa politica», «inviare questa richiesta» oppure «trovare il prossimo articolo pertinente». Identificate poi i controlli necessari per completare quell’attività. Un chatbot dovrebbe aiutare a trovare informazioni senza rendere più difficile l’azione già prevista dalla pagina.
Evitate di scegliere prima un angolo universale e negoziare in seguito ogni sovrapposizione. La posizione di un pulsante telefonico, di un controllo del consenso o della navigazione fissa fa parte della decisione. Il posizionamento della chat è una scelta condivisa di layout: coinvolgete quindi chi è responsabile di questi elementi.
L’esigenza è concreta: una domanda nel supporto WordPress descrive un’icona di chat che si sovrappone a un pulsante di pubblicazione su mobile. Questa segnalazione storica riguarda un altro plugin; non dimostra un difetto di Achla o del vostro sito.
Chi controlla il markup di ogni pagina WordPress?
Distinguete tre aspetti: dove si modifica il contenuto, quale template produce la pagina pubblica e quale integrazione carica il widget. Possono avere responsabili diversi. Un redattore può spostare un blocco, mentre un’agenzia controlla il footer e un plugin fornisce il pulsante della chat.
Per i contenuti Gutenberg, WordPress mette a disposizione un blocco Shortcode che inserisce l’output di uno shortcode. La sua presenza identifica un punto di modifica, non il comportamento finale di ogni integrazione. Annotate quale pagina lo contiene e verificate il markup pubblico risultante.
Per le pagine Elementor, il widget HTML documentato accetta HTML, script e shortcode. Questa possibilità non certifica uno specifico chatbot in tutti i template, popup o temi Elementor. Considerate il page builder una parte della configurazione effettiva da esaminare.
La documentazione WordPress su HTML personalizzato spiega anche il filtraggio del markup non consentito in base ai permessi. Se il codice compare nell’editor ma manca dopo il salvataggio, esaminate il flusso di modifica autorizzato. Non assegnate permessi più ampi soltanto per forzare l’inserimento di un widget.
Usate questo registro delle responsabilità prima di decidere il posizionamento:
| Famiglia di pagine | Attività principale del visitatore | Template o layout pubblico | Responsabile dei contenuti | Responsabile dell’output del widget | Responsabile del controllo condiviso |
|---|---|---|---|---|---|
| Pagine dei servizi | Comprendere il servizio | Registrare il template effettivo | Indicare il redattore | Indicare il manutentore | Indicare il responsabile della CTA |
| Articoli | Leggere e trovare informazioni correlate | Registrare il template degli articoli | Indicare il redattore | Indicare il manutentore | Indicare il responsabile della navigazione |
| Pagina di contatto | Completare la richiesta esistente | Registrare il layout del modulo | Indicare il redattore | Indicare il manutentore | Indicare il responsabile del modulo |
Lasciate visibili le responsabilità sconosciute. «Qualcuno gestisce Elementor» non basta per assegnare una correzione che interessa il footer condiviso del sito.
Scegliere la posizione in base all’attività e alla famiglia di pagine
La tabella seguente propone punti di partenza, non impostazioni predefinite già collaudate. Scegliete una posizione che possiate effettivamente mantenere secondo le regole documentate dell’integrazione.
| Famiglia di pagine | Posizione candidata | Domanda per decidere | Prova necessaria |
|---|---|---|---|
| Pagina di presentazione o servizio | Pulsante di apertura flottante | I visitatori riescono ancora a raggiungere la CTA della pagina? | Pagina pubblica con i controlli fissi visibili |
| Articolo lungo | Pulsante flottante o una sezione incorporata scelta consapevolmente | L’aiuto è individuabile senza coprire i controlli di lettura? | Template effettivo dell’articolo e stati di scorrimento |
| Pagina di politica o assistenza | Riquadro incorporato in una sezione con responsabilità chiara | Il riquadro interrompe condizioni essenziali? | Ordine dei contenuti pubblicati e collegamenti alle fonti |
| Pagina di contatto o modulo | Percorso di contatto esistente; valutare la chat separatamente | Si può completare l’attività del modulo con la chat aperta e chiusa? | Controlli del modulo, validazione e stati della tastiera virtuale |
Il connettore WordPress ufficiale di Achla prevede una sola modalità di posizionamento per tutto il sito. In modalità Inline si carica sulle pagine che contengono il relativo shortcode o blocco; le altre pagine non mostrano alcun widget. In modalità Bubble o Attach, shortcode e blocco non aggiungono un ulteriore riquadro incorporato. Un pulsante flottante ovunque e un riquadro incorporato in una pagina richiedono l’approccio manuale documentato separatamente. Consultate il contratto di installazione attuale.
Questo vincolo conta più del layout visivo preferito. Una tabella che propone posizioni diverse non può far cambiare modalità al connettore in base alla pagina. Se i requisiti sono incompatibili, rivedete la copertura proposta o chiedete al manutentore responsabile di valutare un’integrazione appropriata. La guida plugin o script incorporato tratta questa decisione di installazione più generale.
Creare il registro di posizionamento e ostruzione
Create una riga per ogni famiglia di pagine significativa, aggiungendo poi le singole eccezioni. Riutilizzate la tabella delle responsabilità anziché mantenere un secondo elenco di nomi. Il registro deve collegare un problema visibile a una pagina, a uno stato preciso e a una persona responsabile.
| Campo | Cosa registrare |
|---|---|
| Pagina e attività | URL pubblico esatto e azione che il visitatore deve completare |
| Ambito di modifica e output | Editor, template pubblico effettivo, modalità del widget e responsabile |
| Controlli vicini | Navigazione fissa, CTA locale, controllo del consenso e azioni del modulo |
| Stato del visitatore | Nuovo visitatore o visitatore di ritorno; stato pertinente del consenso; chat aperta o chiusa |
| Stato di inserimento | Tastiera virtuale visibile o nascosta, se pertinente |
| Prova | Screenshot o breve procedura di riproduzione; browser e dispositivo; data di revisione |
| Riscontro | Controllo specificamente coperto o output atteso mancante; «non verificato» se sconosciuto |
| Correzione proposta | Minima modifica circoscritta, responsabile e famiglia di pagine interessata |
| Nuova verifica e decisione | Stessa attività e stesso stato dopo la modifica; accettare, rivedere o sospendere |
Usate il registro in questo ordine:
- Scegliete una pagina pubblica rappresentativa e identificate il responsabile effettivo del template.
- Registrate la posizione prevista e i controlli concorrenti della pagina.
- Documentate lo stato specifico del visitatore e ogni ostruzione osservata.
- Assegnate la correzione minima e ripetete la stessa attività prima di decidere.
Scegliete nomi delle prove riconoscibili da un altro manutentore. «Pagina di contatto, chat aperta, tastiera visibile, invio irraggiungibile» è più utile di «su mobile si vede male». Uno screenshot può mostrare il conflitto senza la sequenza che lo produce: conservate entrambi.
Registrate le assenze con la stessa cura delle ostruzioni. In modalità Inline di Achla, una pagina senza shortcode o blocco incorporato non ha un widget per scelta progettuale. È una decisione di copertura da esaminare, non la prova che un popup debba apparire ovunque. Indicate se l’assenza è intenzionale prima di aprire una richiesta di supporto.
Esaminare la pagina pubblicata con i suoi veri controlli concorrenti
Usate il frontend pubblico ricevuto dai visitatori. Verificate quale contenitore o loader atteso è effettivamente presente, quindi confermate dove viene visualizzato il widget. Confrontate il risultato con il registro delle responsabilità: l’area di lavoro dell’editor non stabilisce quale template condiviso o integrazione abbia prodotto la pagina finale.
Esaminate la pagina con i suoi controlli presenti. La documentazione Elementor sui pulsanti flottanti descrive le impostazioni di posizione dei suoi elementi flottanti. Se il sito ne utilizza già uno, annotatene responsabile e posizione accanto al requisito della chat. Non presumete che due componenti flottanti posizionati indipendentemente si coordinino automaticamente.
Prestate attenzione ai cambiamenti di stato della pagina: un controllo del consenso può restare visibile, una CTA fissa comparire dopo lo scorrimento o la tastiera virtuale ridurre lo spazio utilizzabile durante la compilazione. Verificate l’azione della pagina in ogni stato pertinente. L’obiettivo è un’osservazione riproducibile, non una promessa generica che un’interfaccia «responsive» risolva i conflitti tra controlli.
Le indicazioni W3C sul focus non oscurato spiegano il requisito secondo cui i componenti con il focus non devono essere completamente nascosti da contenuti creati dall’autore della pagina. Consideratelo un aspetto distinto dell’accessibilità. Questo registro di posizionamento non dimostra la piena conformità alle WCAG.
Verificate anche chi fornisce il loader. Achla documenta l’uso del connettore ufficiale oppure di un tag manuale, mai di entrambi. Il connettore usa un proprio loader invece di un tag manuale letterale /w.js. Cercare soltanto quel nome di file non può quindi dimostrare un malfunzionamento del plugin. Seguite le verifiche di risoluzione dei problemi documentate prima di aggiungere un’altra installazione.
Esempi guidati: stesso widget, responsabili delle pagine diversi
Questi esempi ipotetici illustrano decisioni da esaminare; nessuno documenta un test di browser completato.
Un template di articolo e una pagina di contatto condividono il footer. Il responsabile degli articoli propone un pulsante flottante. Quello della pagina di contatto individua un’azione fissa di richiesta informazioni nella stessa zona. Registrate entrambe le famiglie di pagine prima di modificare il posizionamento globale. Il passo successivo proposto è verificare che la posizione condivisa preservi entrambe le attività, non accettare l’anteprima dell’articolo come risultato valido per tutto il sito.
Una pagina di assistenza Gutenberg contiene uno shortcode incorporato. Il responsabile del contenuto colloca il riquadro sotto l’introduzione. Il manutentore propone la modalità Inline di Achla e rileva che le normali pagine dei servizi non hanno shortcode. Il registro specifica che quelle pagine non avranno widget con questa modalità del connettore. Il proprietario può accettare tale copertura o rivederla prima della configurazione.
Una pagina Elementor appare corretta nell’editor. La pagina pubblica potrebbe usare un template condiviso controllato da un’altra persona. Identificate prima il template pubblicato e l’output effettivo. Se il contenitore necessario non è presente al montaggio del widget, cambiare colori o spostare il segnaposto nell’editor non dimostra che il requisito sia soddisfatto. Assegnate la questione dell’output pubblico al responsabile del template.
Questi esempi separano tre decisioni: dove si modifica l’interfaccia, dove appare e se i visitatori possono completare l’attività della pagina.
Accettare, rivedere o sospendere con un responsabile identificato
Accettate una posizione soltanto per le pagine e gli stati supportati da prove registrate. Una riga valida per un articolo non chiude una riga di contatto non verificata. Mantenete aperto un requisito globale finché non sono state esaminate le famiglie di pagine pertinenti.
Rivedete la soluzione quando un controllo identificato è coperto, una posizione incorporata compare nel contesto sbagliato o la copertura prevista differisce dall’output del connettore. Assegnate la correzione a chi controlla quell’ambito. Modificare un template condiviso richiede di ricontrollare le righe interessate, non soltanto la pagina usata per dimostrare la correzione.
Sospendete quando non è possibile completare l’azione principale del visitatore o le responsabilità non sono chiare. Mantenete disponibile il normale percorso di contatto o navigazione finché la decisione resta aperta. Per le procedure operative con tastiera, screen reader e viewport, consultate la guida all’accessibilità della barra di ricerca. La decisione trattata qui resta la responsabilità del posizionamento e l’ostruzione della pagina.
Valutare il connettore WordPress documentato rispetto al registro
Confrontate il connettore WordPress con i requisiti effettivi di copertura e posizionamento delle pagine. Il ruolo documentato di Achla è fornire risposte dai contenuti pubblici del sito con fonti a supporto. Non consideratelo un servizio verificato di live chat con personale, prenotazioni o automazione dei moduli.
Confrontate le modalità documentate con il registro, consultate i piani attuali e usate l’onboarding se questo compito circoscritto è adatto. Se state ancora scegliendo il tipo di esperienza di ricerca, la panoramica della ricerca IA sul sito offre un contesto più ampio. Tenete a disposizione le condizioni di posizionamento registrate per il responsabile che approverà un eventuale lancio effettivo.