Google Fonts e GDPR: ospitare i font in locale su WordPress

Se un sito WordPress carica Google Fonts dai server di Google, il browser di ogni visitatore si collega a Google e gli rivela il proprio indirizzo IP. È questo il nocciolo della questione «Google Fonts e GDPR» (Regolamento generale sulla protezione dei dati): per trasmettere quell'indirizzo serve una base giuridica, e un tribunale tedesco ha stabilito che il sito in causa non ne aveva alcuna. La soluzione pulita è semplice: ospitare i file dei font sul proprio server.

Questa guida spiega la sentenza e che cosa è cambiato da allora, come verificare se il sito carica ancora i font da Google e tre modi per ospitarli in locale su WordPress.

Che cosa ha deciso il tribunale di Monaco su Google Fonts e GDPR

Il 20 gennaio 2022 il Tribunale regionale di Monaco di Baviera I (Landgericht München I, causa 3 O 17493/20) si è pronunciato sul caso di un sito che incorporava Google Fonts direttamente dai server di Google. Ogni visualizzazione di pagina trasmetteva a Google l'indirizzo IP del visitatore. Secondo la sentenza pubblicata (in tedesco), il tribunale ha stabilito che:

• per il gestore del sito, l'indirizzo IP dinamico del visitatore è un dato personale;
• il visitatore non aveva acconsentito alla sua trasmissione a Google;
• il gestore non aveva un legittimo interesse, perché i font si sarebbero potuti usare senza alcuna connessione ai server di Google, ospitandoli in locale;
• al visitatore è stato riconosciuto un risarcimento di 100 euro.

Si tratta della sentenza di un singolo tribunale regionale in un singolo caso, non di una pronuncia della Corte di giustizia dell'UE. Il ragionamento però è facile da seguire, e le sue conseguenze sono andate ben oltre quella causa.

L'ondata di diffide del 2022

Alla fine del 2022 la sentenza è stata seguita in Germania da un'ondata di diffide di massa, la cosiddetta «Abmahnwelle». Le lettere chiedevano pagamenti ai gestori di siti che caricavano ancora Google Fonts da remoto. Diverse di queste diffide sono state poi considerate abusive.

Chi riceve una lettera del genere non dovrebbe pagare né firmare nulla in fretta, ma farla esaminare da un avvocato. In ogni caso conviene eliminarne la causa, così che la questione non si ripresenti.

Il Data Privacy Framework non risolve il problema?

Solo in parte. L'EU-U.S. Data Privacy Framework (DPF), basato sulla decisione di adeguatezza della Commissione europea del 10 luglio 2023, offre una base di adeguatezza per i trasferimenti verso le aziende statunitensi certificate, e Google LLC è certificata. Il 3 settembre 2025 il Tribunale dell'Unione europea ha respinto un ricorso contro il DPF (causa T-553/23, Latombe/Commissione). Il 31 ottobre 2025 è stata proposta un'impugnazione dinanzi alla Corte di giustizia, tuttora pendente: il quadro potrebbe quindi cambiare.

La sentenza di Monaco è anteriore al DPF. Il DPF indebolisce l'argomento del paese terzo, cioè il timore che i dati finiscano negli Stati Uniti senza una protezione adeguata. Non tocca invece l'altro argomento: serve comunque una base giuridica per inviare a Google l'indirizzo IP, e un legittimo interesse è difficile da sostenere quando i font si potrebbero semplicemente ospitare in proprio.

L'hosting locale resta quindi la soluzione pulita. È anche un esempio da manuale di protezione dei dati fin dalla progettazione (art. 25 GDPR): i dati semplicemente non lasciano mai il server.

Come verificare se il sito carica Google Fonts

Usare gli strumenti per sviluppatori del browser

1. Aprire il sito in una finestra privata.
2. Aprire gli strumenti per sviluppatori (F12, oppure Cmd+Option+I su Mac) e passare alla scheda Rete (Network).
3. Spuntare Disattiva cache (Disable cache) e ricaricare la pagina.
4. Digitare fonts.googleapis.com nel campo del filtro, poi fonts.gstatic.com.

Qualsiasi richiesta verso questi domini significa che la pagina carica Google Fonts: fonts.googleapis.com fornisce il CSS, fonts.gstatic.com i file dei font veri e propri.

Il controllo va ripetuto su diversi tipi di pagina: home page, un articolo del blog, la pagina dei contatti, negozio e checkout, pagina di login. Slider, form builder, plugin di mappe o banner dei cookie a volte caricano font propri solo nelle pagine in cui compaiono.

Cercare nel codice sorgente e nei file del tema

Aprire il codice sorgente della pagina (Ctrl+U, oppure Cmd+Option+U su Mac) e cercare gli stessi due domini. Così si trovano i tag <link> e i suggerimenti di preconnect, ma non i font importati all'interno dei file CSS o caricati via JavaScript: il test affidabile resta la scheda Rete.

Con un accesso alla shell si possono anche elencare i file di temi e plugin che li citano:

grep -rl -e "fonts.googleapis.com" -e "fonts.gstatic.com" wp-content/themes wp-content/plugins

I page builder spesso salvano nel database le scelte relative ai font, quindi un risultato vuoto qui non dimostra che il sito sia pulito.

Come ospitare Google Fonts in locale su WordPress

Le strade sono tre, dalla meno alla più impegnativa. Dopo ciascuna conviene ripetere il controllo nella scheda Rete.

Opzione 1: tema, page builder o libreria dei font

Molti temi e page builder offrono ormai un'impostazione per caricare Google Fonts in locale. La dicitura cambia da prodotto a prodotto («load fonts locally», «self-host fonts» o simili), quindi vale la pena esplorare il Customizer del tema (Aspetto → Personalizza) e le impostazioni di performance o privacy del builder.

Con un tema a blocchi ci pensa la libreria dei font (Font Library) di WordPress 6.5 e versioni successive. Nell'Editor del sito si aprono Stili, poi Tipografia, e da lì si gestiscono i font. La prima volta che si sfoglia la raccolta Google Fonts si autorizza WordPress a collegarsi a Google; i font installati vengono poi scaricati e salvati sul sito, e i visitatori li caricano da lì (Learn WordPress).

Opzione 2: un plugin per i font locali

Diversi plugin della directory di WordPress.org rilevano le richieste a Google Fonts, scaricano i file sul server e riscrivono i riferimenti. Basta cercare «local Google Fonts» nella directory. Il plugin va scelto con la stessa cura riservata a qualsiasi altro; la nostra guida ai plugin WordPress vulnerabili spiega che cosa verificare.

Opzione 3: @font-face manuale in un tema child

Questa strada dà il pieno controllo senza un plugin aggiuntivo:

1. Scaricare la famiglia di font e conservare solo gli stili e i pesi effettivamente usati. Per il web, il formato più compatto è WOFF2.
2. Copiare i file in una cartella fonts del tema child, insieme al file di licenza del font.
3. Aggiungere le regole @font-face a un foglio di stile caricato dal tema child, di solito il suo style.css.
4. Impedire al tema di caricare la copia remota.

Un esempio minimo con due pesi del font Inter:

@font-face {
  font-family: "Inter";
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url("fonts/inter-400.woff2") format("woff2");
}
@font-face {
  font-family: "Inter";
  font-style: normal;
  font-weight: 700;
  font-display: swap;
  src: url("fonts/inter-700.woff2") format("woff2");
}
body {
  font-family: "Inter", system-ui, sans-serif;
}

Il percorso in url() è relativo al file CSS, quindi fonts/ indica la cartella accanto a style.css.

Per bloccare la copia remota, usare l'opzione del tema, se c'è. Altrimenti cercare nel codice sorgente della pagina il tag <link> di fonts.googleapis.com: il suo id ha una forma come themename-fonts-css, e l'handle del foglio di stile è quell'id senza -css. Poi aggiungere questo codice al functions.php del tema child:

add_action( 'wp_enqueue_scripts', function () {
    wp_dequeue_style( 'themename-fonts' ); // sostituire con l'handle reale
}, 20 );

Vanno rimossi anche gli eventuali suggerimenti preconnect verso fonts.gstatic.com: un preconnect apre una connessione al server di Google anche quando da lì non viene scaricato alcun font.

Sulla licenza: secondo il repository di Google Fonts, la maggior parte dei font della raccolta usa la SIL Open Font License 1.1, alcuni la licenza Apache 2 o la Ubuntu Font License. La OFL consente di usare, incorporare e ridistribuire i font, quindi ospitarli in locale non crea problemi. I font di altra provenienza possono avere condizioni diverse: la licenza va sempre letta.

Controllare anche le altre richieste a terzi

La stessa logica vale per tutto ciò che una pagina carica dal server di un'altra azienda: l'indirizzo IP del visitatore arriva lì nel momento stesso in cui la pagina si apre. Con la scheda Rete ancora aperta, cercare:

• Google Maps e altre mappe incorporate
• video incorporati da YouTube o Vimeo
• script, fogli di stile o icon font da CDN pubblici
• reCAPTCHA e controlli anti-bot simili
• immagini Gravatar nei commenti (Impostazioni → Discussione → Avatar)
• widget di chat e strumenti di analytics

Per ciascuno si decide se ospitarlo in locale (script, fogli di stile, icon font), caricarlo solo dopo un clic (mappe e video dietro un segnaposto) o chiedere il consenso dove è necessario, descrivendo nell'informativa privacy ciò che rimane.

Gli script esterni sono anche una questione di sicurezza, perché girano con pieno accesso alle pagine. La nostra checklist per la sicurezza di WordPress copre questo aspetto.

Domande frequenti

Serve il consenso per i font ospitati in locale?

I font serviti dal proprio server funzionano come le immagini e i fogli di stile: nessun dato dei visitatori arriva a Google, quindi il problema del caso di Monaco non si pone.

Il DPF basta per continuare a caricare i font da Google?

Finché resta in piedi, offre una base di adeguatezza per il trasferimento verso gli Stati Uniti. Non risponde però alla domanda se sia davvero necessario inviare l'indirizzo IP a Google. L'hosting locale evita entrambe le questioni.

L'hosting locale rallenta il sito?

Di solito no. Il browser non ha più bisogno di una connessione separata ai domini di Google, e si distribuiscono solo i pesi effettivamente usati.

Questo articolo ha carattere informativo generale e non costituisce consulenza legale.