Se gestisci un sito WordPress hai quasi certamente installato un banner cookie, magari anche uno dei plugin di consenso più conosciuti, convinto che il problema “cookie” sia così risolto. In molti casi però il banner racconta una storia: “senza il tuo consenso non carichiamo nulla”, mentre il codice del sito ne racconta un’altra, e i due non sempre coincidono. Google Fonts caricati direttamente dai server di Google, una mappa incorporata, un video di YouTube in modalità standard: sono elementi che quasi ogni sito usa, e che spesso trasferiscono dati verso server esterni prima ancora che il visitatore abbia cliccato su “accetta” o “rifiuta”. In questo articolo vediamo perché succede, come si verifica e quali sono le due strade tecniche per sistemarlo.
Indice dei Contenuti
Dove si nascondono le terze parti più comuni su un sito WordPress
Il punto di partenza tecnico è semplice: ogni volta che una pagina del tuo sito chiede al browser del visitatore di scaricare qualcosa da un dominio diverso dal tuo, quel dominio riceve almeno l’indirizzo IP del visitatore, lo user agent e altre informazioni di base della richiesta HTTP. Questo accade indipendentemente da cosa dice il banner cookie, perché è una conseguenza del modo in cui funziona il web, non una scelta del plugin di consenso. Se la risorsa esterna viene caricata prima che l’utente esprima una scelta (o anche dopo un rifiuto, se qualcosa non è configurato correttamente), quel trasferimento di dati avviene comunque.
Google Fonts caricati “al volo”
È probabilmente il caso più diffuso. Molti temi e page builder inseriscono nel codice un link diretto a fonts.googleapis.com per caricare i caratteri tipografici scelti nel personalizzatore del tema. Quel link viene eseguito dal browser del visitatore appena la pagina si apre, prima di qualsiasi interazione con il banner. Il font in sé è innocuo, ma la richiesta che lo scarica passa comunque per i server di Google.
Mappe incorporate
Un iframe di Google Maps inserito per mostrare la sede dell’attività è un altro classico. L’iframe carica risorse da Google (script, immagini della mappa, cookie tecnici e di profilazione legati all’account Google) nel momento stesso in cui la pagina viene renderizzata, prima ancora che l’utente decida di interagire con la mappa.
Video YouTube o Vimeo in modalità standard
Incorporare un video con il codice embed “normale” di YouTube (quello che punta a youtube.com invece che al dominio alternativo pensato per ridurre il tracciamento, youtube-nocookie.com) fa sì che, al caricamento della pagina, il player scarichi script e imposti cookie prima ancora che l’utente prema play. Vale un discorso simile per Vimeo e per altri servizi di hosting video.
CDN, librerie di icone, plugin che “telefonano” all’esterno
Font Awesome ospitato su un CDN esterno, slider o gallery che si appoggiano a librerie JavaScript ospitate altrove, plugin di recensioni o di chat che al primo caricamento contattano un servizio esterno per verificare licenza o aggiornamenti: sono tutti pattern che si ripetono con grande frequenza. In alcuni casi non è nemmeno il tema o un plugin visibile a farlo, ma una libreria richiamata da un altro plugin, il che rende la scoperta meno immediata di quanto sembri.
Per chiarezza: gli esempi sopra descrivono pattern tecnici generici, ricorrenti su moltissimi siti WordPress a prescindere dal settore. Non fanno riferimento a un cliente, a un sito o a un dominio specifico.
Perché succede quasi sempre in buona fede
Nella grande maggioranza dei casi non c’è nessuna intenzione di aggirare le regole sul consenso. Chi costruisce un sito WordPress (un’agenzia, un freelance, lo stesso titolare dell’attività con un page builder) sceglie un font, inserisce una mappa o incolla un codice embed di YouTube perché sono funzionalità utili e visivamente comuni, senza che l’interfaccia del tema o del builder segnali in alcun modo che quella scelta comporta una connessione verso un server esterno. Il banner cookie, dal canto suo, viene spesso installato come passaggio separato, magari mesi dopo, e per impostazione predefinita blocca solo le categorie di script che il plugin stesso riesce a riconoscere automaticamente: se una risorsa non viene rilevata o classificata, resta fuori dal blocco senza che nessuno se ne accorga.
È un problema molto comune, più di quanto si pensi, proprio perché nasce dall’incontro tra due strumenti (tema/builder e plugin di consenso) che normalmente non “si parlano” tra loro. Dietro c’è più semplicemente il fatto che nessuno abbia mai controllato, con gli strumenti giusti, cosa il browser scarica realmente prima del click sul banner.
Due strade per risolvere ogni caso (e non sono equivalenti)
Una volta identificata una risorsa di terze parti che parte troppo presto, esistono in sostanza due modi per intervenire. Non sono intercambiabili: hanno un costo diverso in termini di lavoro tecnico e di manutenzione nel tempo, ed è giusto scegliere con consapevolezza.
Prima strada: dichiarare la risorsa nello strumento di consenso
La maggior parte dei plugin di gestione cookie seri permette di bloccare uno script specifico finché l’utente non presta il consenso alla categoria corrispondente (statistiche, marketing, contenuti esterni). Per farlo bene serve però un lavoro puntuale: individuare esattamente quale script o iframe carica la risorsa, capire da quale file del tema o del plugin viene generato, e configurare una regola di blocco che intercetti proprio quel caricamento, più mirata di una regola generica che spesso non copre il caso specifico. Per una mappa o un video embed, questa strada è spesso la più pratica: si sostituisce l’iframe con un segnaposto che mostra un messaggio (“contenuto bloccato, clicca per attivare la mappa”) e carica la risorsa reale solo dopo il consenso.
Seconda strada: il self-hosting, cioè eliminare la terza parte alla radice
Per alcune risorse (Google Fonts è l’esempio migliore) esiste un’alternativa più radicale: scaricare i file dei font una volta sola e servirli direttamente dal proprio server, invece di richiamarli ogni volta da Google. In questo modo la terza parte scompare del tutto per quella risorsa: non c’è nulla da bloccare né da dichiarare nel consent tool, perché la richiesta non esce mai dal dominio del sito. È la soluzione più pulita dal punto di vista tecnico, ma va detto con onestà che comporta più lavoro: bisogna scaricare e ottimizzare i file corretti, aggiornarli se il tema cambia i font in uso, e verificare periodicamente che nessun aggiornamento del tema o del builder reintroduca il caricamento remoto. Per mappe e video il self-hosting non è quasi mai praticabile allo stesso modo (non puoi “scaricare” YouTube), ma esistono comunque alternative intermedie, come sostituire l’iframe standard con la versione a maggiore tutela della privacy offerta dal servizio stesso, per poi comunque gestire il consenso come per qualsiasi altro contenuto esterno.
In pratica, per ogni risorsa individuata la domanda giusta da porsi è: “mi conviene bloccarla finché manca il consenso, o mi conviene toglierla di mezzo alla radice?”. La risposta dipende dal tipo di risorsa, da quanto è centrale per il sito e da quanta manutenzione futura si è disposti a sostenere.
Un controllo tecnico, distinto da una consulenza legale
Vale la pena essere chiari su cosa è, e cosa non è, questo tipo di verifica. Analizzare cosa scarica il browser prima del consenso, individuare gli script di terze parti e proporre come bloccarli o eliminarli è un controllo tecnico: si basa sull’osservazione del codice e del traffico di rete, un piano diverso dall’interpretazione normativa. Le questioni giuridiche (quale sia la base giuridica corretta per ciascun trattamento, come debba essere scritta l’informativa privacy, se e come tenere un registro dei trattamenti, quali obblighi specifici valgano per il tuo settore) restano di competenza di un legale o di un DPO, e nessuna verifica tecnica sul codice del sito può sostituirsi a quel parere. Le due cose si completano: la parte tecnica dice cosa succede sul sito, la parte legale dice cosa il sito dovrebbe fare per essere in regola.
Da dove partire
Se ti riconosci in qualcuno di questi scenari (un font caricato da Google, una mappa in homepage, un video incorporato nel modo “classico”), la cosa più utile è verificare, senza lasciarsi prendere dalla preoccupazione. Mi occupo di consulenza tecnica su WordPress qui a Pescara (e da remoto per chi è altrove) proprio per questo tipo di analisi: un’ora di lavoro mirato in cui, insieme, guardiamo cosa il tuo sito carica prima del consenso, quali sono le terze parti coinvolte e quali, tra le due strade viste sopra, ha più senso percorrere caso per caso. Non è la messa a norma completa del sito in un’ora (quella, quando serve, è un lavoro successivo, spesso in collaborazione con chi segue gli aspetti legali): è un punto di partenza chiaro per capire dove sei e cosa ha priorità.
Se vuoi, scrivimi raccontandomi che tipo di sito hai (tema, page builder, plugin cookie che usi già) e vediamo insieme se ha senso partire da un controllo di questo tipo.
