GDPR e WordPress: cookie, consenso e conformità senza plugin invadenti che rallentano il sito

Il banner cookie è la parte del GDPR che tutti vedono, ed è per questo che quasi tutti lo confondono con l'intera conformità. Non lo è. Il banner è il meccanismo di raccolta del consenso; la conformità è tutto ciò che succede dopo — cosa fai con il consenso raccolto, come lo tracci, per quanto conservi i dati, e cosa dice la tua informativa. Un banner perfetto con un'informativa vuota o con script che caricano senza consenso è comunque non conforme.

Su WordPress il problema si aggrava perché la maggior parte dei plugin "GDPR" fa l'opposto di ciò che serve: aggiungono decine di KB di JavaScript, caricano script di terze parti per gestire il consenso, e spesso non bloccano davvero gli script di tracking prima del consenso. Il risultato è un sito più lento e una conformità di facciata. La conformità reale è più semplice e più leggera di quanto sembri.

I quattro requisiti reali (non solo il banner)

Primo: il consenso deve essere granulare. L'utente deve poter accettare o rifiutare categorie diverse di cookie separatamente (tecnici sempre attivi, analitici opzionali, marketing opzionali). Un banner con solo "Accetta tutto" o un pre-checked "Accetta" non è conforme. Secondo: il consenso deve essere tracciato. Devi poter dimostrare, per ogni utente, cosa ha accettato e quando. Terzo: gli script non tecnici devono essere bloccati prima del consenso, non caricati e poi disattivati. Quarto: l'informativa deve descrivere realmente quali cookie carichi, perché, e per quanto li conservi.

Il terzo punto è quello dove la maggior parte delle implementazioni fallisce tecnicamente. Caricare Google Analytics e poi nascondere il banner non blocca il tracking — lo script ha già inviato dati. Il blocco deve avvenire prima dell'esecuzione dello script, condizionato allo stato del consenso.

<!-- Blocca Google Analytics prima del consenso -->
<!-- type="text/plain" impedisce l'esecuzione automatica -->
<script
  type="text/plain"
  class="analytics-consent"
  data-category="analytics"
  async
  src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX">
</script>

<script type="text/plain" class="analytics-consent" data-category="analytics">
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');
</script>

<!-- Dopo il consenso, il JS del banner cambia type da text/plain a text/javascript -->

Tracciare il consenso (il requisito più dimenticato)

Il GDPR non chiede solo di raccogliere il consenso, ma di poterlo dimostrare. Devi sapere, per ogni visitatore, quale categoria ha accettato e quando. La soluzione standard è salvare lo stato del consenso in un cookie tecnico (che non richiede a sua volta consenso, perché è necessario al funzionamento del sistema di consenso stesso).

// Salvataggio del consenso granulare (esempio minimale)
function saveConsent(categories) {
  const consent = {
    necessary: true,           // sempre attivo
    analytics: categories.analytics || false,
    marketing: categories.marketing || false,
    timestamp: new Date().toISOString(),
    version: '2.0'              // versione della policy
  };
  // Cookie tecnico, 180 giorni, SameSite=Lax
  document.cookie =
    'cookie_consent=' + encodeURIComponent(JSON.stringify(consent)) +
    ';max-age=15552000;path=/;SameSite=Lax';

  // Attiva gli script della categoria accettata
  if (consent.analytics) enableScripts('analytics');
  if (consent.marketing) enableScripts('marketing');
}

// Lettura del consenso al caricamento della pagina
function loadConsent() {
  const match = document.cookie.match(/(?:^|; )cookie_consent=([^;]+)/);
  if (!match) return null;
  try { return JSON.parse(decodeURIComponent(match[1])); }
  catch { return null; }
}

Data retention: per quanto conservi i dati

Il quarto requisito, e forse il meno implementato, è la data retention — per quanto tempo conservi i dati personali. Il GDPR dice che i dati vanno conservati "non più a lungo del necessario". Per un sito WordPress questo significa definire: per quanto tieni i log di accesso, per quanto i dati dei form di contatto, per quanto i commenti se abilitati, per quanto i dati di analytics aggregati.

Non esiste una durata universale corretta: dipende dalla finalità. I dati di un form di preventivo vanno conservati per il tempo necessario a gestire la richiesta e gli eventuali adempimenti fiscali, poi cancellati. I log di sicurezza si tengono il tempo necessario a investigare incidenti, tipicamente 90-180 giorni. Il punto è averlo definito e documentato nell'informativa — non lasciarlo implicito.

La conformità GDPR su WordPress non è un plugin da installare e dimenticare. È un insieme di scelte — quali dati raccogli, perché, per quanto, con quale consenso — che vanno riflesse sia nel codice (blocco reale degli script, tracciamento del consenso) sia nell'informativa (descrizione veritiera di ciò che il sito fa). Fatto bene, è anche più leggero: meno script caricati senza consenso significa un sito più veloce, non più lento.