Guida all'integrazione del consenso cookie su Webflow: banner nativo, codice personalizzato e CMP di terze parti per il 2026
Webflow occupa una posizione peculiare nell'ecosistema dei costruttori di siti web. È più vicino a uno strumento di design che a un CMS, più vicino a un CMS che a una piattaforma di app in hosting, e sempre più la piattaforma che le agenzie scelgono quando vogliono siti di marketing completamente personalizzati senza il carico tecnico di gestire uno stack Next.js o Drupal. Webflow fornisce un banner nativo Cookie Consent con impostazioni predefinite ragionevoli, espone l'iniezione di Custom Code a livello di sito e di pagina, si integra con l'HTML incorporato e fornisce agli operatori un modello CMS Collections. Un sito Webflow che ha attivato solo il banner nativo è raramente pienamente conforme; un sito che ha collegato il banner nativo a un CMP di terze parti, bloccato il Custom Code e verificato gli script incorporati è una delle implementazioni più pulite che un'agenzia può consegnare nel 2026.
Cosa fa il Cookie Consent nativo di Webflow e dove si ferma
Webflow ha aggiunto la funzione nativa Cookie Consent nel 2022 e l'ha migliorata da allora. La funzione supporta tre categorie di cookie predefinite — Essential, Marketing e Personalization — espone un'interfaccia banner configurabile accessibile tramite le impostazioni del progetto e lega il blocco di Google Analytics alla scelta dell'utente. Il banner registra il consenso dell'utente in un cookie first-party.
Quello che il banner nativo di Webflow non fa — e dove la maggior parte delle implementazioni costruite dalle agenzie manca — è bloccare il Custom Code che gli operatori aggiungono abitualmente per analytics, pixel di marketing, widget di chat e video incorporati. I punti di iniezione del Custom Code vengono eseguiti prima che il banner sia stato renderizzato. Le agenzie aggiungono spesso Hotjar, Facebook Pixel, uno script CRM di terze parti o un embed di Calendly tramite Custom Code presumendo che il banner nativo gestisca il blocco. Non lo gestisce.
L'impostazione predefinita opt-in vs. consenso implicito
Il banner nativo espone tre stili di consenso. Lo stile di consenso implicito è stata la fonte di ripetute constatazioni dei regolatori contro siti ospitati su Webflow nel EEA. Lo stile opt-in è il valore predefinito corretto per qualsiasi implementazione rivolta all'EEA, UK, Brasile, Svizzera o qualsiasi giurisdizione che abbia adottato lo standard GDPR. L'operatore deve selezionare opt-in, configurare le categorie come disattivate per impostazione predefinita e verificare nell'anteprima che il pulsante di rifiuto sia visivamente almeno altrettanto prominente quanto il pulsante di accettazione.
Blocco del Custom Code: il lavoro che il banner nativo non esegue
Il modello di integrazione che funziona su Webflow ha tre parti. Primo, configurare correttamente il banner nativo. Secondo, avvolgere ogni script Custom Code in un controllo del consenso prima dell'esecuzione. Terzo, decidere se il banner nativo è sufficiente o se un CMP di terze parti deve sostituirlo per la traccia di audit e la configurabilità per fornitore.
Il modello di blocco più semplice consiste nel leggere il cookie di consenso di Webflow o lo stato del consenso dall'hook JavaScript esposto dalla piattaforma ed eseguire condizionalmente la logica di terze parti. Per gli script aggiunti nella sezione Footer Code, il modello consiste nell'avvolgere lo snippet in un listener di eventi che si attiva all'evento di modifica del consenso di Webflow. Per gli script nella sezione Head Code — dove vivono la maggior parte degli snippet di analytics e pixel — il modello consiste nel caricare lo snippet come segnaposto, con la richiesta effettiva di terze parti differita finché il controllo del consenso non viene superato.
Il modello di segnaposto per gli script di terze parti
Il modello che funziona nelle integrazioni Webflow più comuni è il segnaposto <script type="text/plain">. Lo script di terze parti è incluso nel markup della pagina ma con l'attributo type impostato su un valore che il browser non eseguirà. Un piccolo script bootstrap — aggiunto una volta nella sezione Footer Code — ascolta l'evento di modifica del consenso di Webflow, identifica gli script segnaposto corrispondenti alla categoria concessa e riscrive il loro attributo type in text/javascript per eseguirli. Il modello è lo stesso utilizzato dal modulo EU Cookie Compliance di Drupal e che Cloudflare Zaraz applica all'edge.
L'opzione CMP di terze parti: quando il banner nativo non è sufficiente
Per i siti che necessitano di una traccia di audit più completa, configurazione per fornitore, logica multi-giurisdizione o integrazione con IAB TCF, il banner nativo non è sufficiente e un CMP di terze parti — Cookiebot, OneTrust, Usercentrics, Iubenda — dovrebbe sostituirlo. Richiede di disattivare prima il banner nativo.
- Integrazione Cookiebot — installare lo snippet Cookiebot tramite Custom Code nella sezione Head, contrassegnare gli script gestiti da Cookiebot con attributi data-cookieconsent e disattivare il banner nativo di Webflow nelle impostazioni del progetto.
- Integrazione OneTrust — installare lo snippet CDN di OneTrust, configurare la dashboard OneTrust per leggere la struttura delle categorie di Webflow e disattivare il banner nativo.
- Integrazione Usercentrics — installare lo snippet Usercentrics, configurare le definizioni di servizio nella dashboard Usercentrics che riflettono l'inventario reale dei tag dell'operatore e disattivare il banner nativo.
- Integrazione Iubenda — installare lo snippet Iubenda Consent Solution, configurare la politica e il mapping delle categorie e disattivare il banner nativo.
CMS Collections di Webflow e contenuto renderizzato dinamicamente
Le CMS Collections di Webflow meritano attenzione specifica perché introducono una superficie di consenso che le pagine statiche non hanno. Una pagina di Collection che incorpora un widget di terze parti — un embed YouTube in un post del blog, un feed TikTok in una pagina portfolio — eredita le decisioni di consenso prese nella pagina che la ospita, ma il contenuto incorporato non rispetta automaticamente tali decisioni a meno che l'operatore non abbia configurato la Collection per renderizzare l'embed tramite un segnaposto click-to-load.
Validazione e postura di audit per il 2026
Un deployment Webflow difendibile nel 2026 deve superare quattro controlli tecnici. Primo, una sessione del browser pulita servita da un indirizzo IP dell'EEA deve produrre zero cookie non essenziali prima che il banner sia stato azionato. Secondo, il percorso di rifiuto deve mantenere quello stato. Terzo, il percorso di accettazione deve produrre solo i tag per cui l'utente ha dato consenso e il log del consenso deve contenere il record corrispondente. Quarto, una revoca deve immediatamente interrompere ulteriori attivazioni di tag e propagare il rifiuto ai destinatari di terze parti downstream.
Il banner nativo registra lo stato del consenso dell'utente in un cookie first-party ma non mantiene un log di audit lato server interrogabile per identificatore di utente o sessione. Per i deployment che necessitano di una traccia di audit più completa — reporting multi-giurisdizione, record di consenso per fornitore, integrazione con lo standard di documentazione atteso dall'EDPB — un CMP di terze parti è la risposta corretta. Un sito Webflow che ha scelto deliberatamente tra i due percorsi, bloccato ogni superficie Custom Code e affrontato il modello di embed delle Collection ha trasformato la semplicità del costruttore visuale della piattaforma in una parte difendibile della postura di consenso di un'agenzia invece che un debito di conformità nascosto.