Guida all'integrazione del consenso ai cookie di Squarespace: banner integrato, CSS personalizzato e iniezione di codice per il 2026

Squarespace si trova nella stessa categoria di prodotti di Wix e Webflow, ma si differenzia su un asse diverso. Mentre Wix ottimizza per il piccolo imprenditore che vuole creare un sito brochure con il drag-and-drop, e Webflow ottimizza per l'agenzia che vuole sviluppo visuale senza scrivere codice front-end, Squarespace ottimizza per il designer-fondatore che gestisce un'attività di servizi creativi, un sito editoriale o un piccolo negozio e-commerce. Quel posizionamento plasma la superficie di consenso che l'operatore eredita. Un sito Squarespace viene tipicamente fornito con il banner nativo per i cookie abilitato, Squarespace Analytics connesso, un fornitore di moduli incorporato per le iscrizioni alla newsletter, forse un negozio Squarespace Commerce, uno sfondo YouTube o Vimeo, un blocco Instagram e una manciata di script di terze parti aggiunti dall'operatore tramite il pannello Code Injection. Ognuna di queste superfici crea un obbligo di consenso separato. Un'implementazione Squarespace difendibile nel 2026 è quella in cui il banner nativo è stato configurato correttamente, la superficie Code Injection è stata verificata, i widget incorporati sono stati wrappati e il registro del consenso è stato trattato come un artefatto documentale.

Cosa fa il banner nativo dei cookie di Squarespace e dove si ferma

Il Cookie Banner nativo di Squarespace — accessibile sotto Settings, Cookies & Visitor Data — supporta un'interfaccia banner configurabile e si integra con le superfici analitiche e di marketing proprie di Squarespace. Quando l'operatore abilita il banner e configura le impostazioni dei dati dei visitatori, le integrazioni interne di Squarespace rispettano la scelta del visitatore senza ulteriore configurazione: Squarespace Analytics è condizionato al segnale analitico, i pixel di remarketing di Pinterest, Facebook e Google Ads rispettano il segnale di marketing.

Ciò che il banner non fa, e dove si verifica il fallimento di conformità più comune su Squarespace, è controllare gli script di terze parti che l'operatore aggiunge tramite Code Injection. Il pannello Code Injection — sotto Settings, Advanced — consente all'operatore di incollare HTML e JavaScript arbitrari nell'intestazione, nel piè di pagina o in posizioni per pagina. Gli script iniettati in questo modo vengono eseguiti prima che il visitatore abbia visto il banner. Hotjar, contenitori personalizzati di Google Tag Manager, pixel Facebook aggiuntivi, widget di chat, fornitori di video — tutto ciò che non è nell'elenco di integrazione nativa di Squarespace non sarà controllato dal banner nativo a meno che l'operatore non avvolga lo script in un controllo di consenso.

Stile di consenso predefinito: opt-in vs implicito

Il banner di Squarespace supporta entrambi gli stili di consenso opt-in e implicito, e l'opzione implicita rimane disponibile nonostante sia stata fonte di ripetute constatazioni dei regolatori contro i siti ospitati su Squarespace in tutto l'EEA. L'operatore deve selezionare l'opzione opt-in, verificare che la raccolta dei dati dei visitatori sia disattivata per impostazione predefinita e garantire che l'opzione di rifiuto sia almeno altrettanto prominente di quella di accettazione. Queste tre impostazioni sono il minimo di cui un sito Squarespace ha bisogno per superare la soglia fissata dall'EDPB nelle sue linee guida sui banner cookie del 2023.

La superficie di Code Injection e come controllarla

Il modello di integrazione che funziona su Squarespace ha tre parti. Primo, configurare correttamente il banner nativo. Secondo, identificare ogni script in Code Injection. Terzo, avvolgere ogni script di Code Injection in un controllo di consenso prima dell'esecuzione.

Il modello più pulito per gli script iniettati nell'intestazione è convertirli in forma segnaposto: modificare l'attributo type da text/javascript a text/plain, aggiungere un attributo data-category che identifichi il gate del consenso e includere un piccolo script bootstrap. Il modello bootstrap è lo stesso usato da Webflow, Drupal e Cloudflare Zaraz.

La superficie dei widget di terze parti che gli operatori Squarespace trascurano abitualmente

Gli operatori Squarespace si affidano molto ai blocchi incorporati per i contenuti ricchi. Ogni blocco introduce una superficie di consenso separata.

Squarespace Commerce e la superficie del carrello

Squarespace Commerce introduce cookie strettamente necessari per lo stato del carrello, l'identità della sessione e il pagamento che non richiedono consenso. Le complicazioni sorgono intorno alle superfici di marketing introdotte da Commerce: email di carrelli abbandonati, integrazione con Facebook Conversions API, remarketing Google Ads, Klaviyo o Mailchimp. Questi non sono essenziali e devono essere controllati.

Validazione e posizione di audit per il 2026

Un'implementazione Squarespace difendibile nel 2026 deve superare quattro verifiche tecniche. Primo, una sessione browser pulita servita da un indirizzo IP EEA deve produrre zero cookie non essenziali prima che il banner venga azionato. Secondo, il percorso di rifiuto deve mantenere quello stato. Terzo, il percorso di accettazione deve produrre solo i tag a cui il visitatore ha acconsentito. Quarto, un ritiro deve immediatamente interrompere ulteriori attivazioni di tag e propagare la revoca ai destinatari di terze parti a valle. Il banner nativo è sufficiente per le giurisdizioni con requisiti di audit più leggeri. Per un registro di consenso interrogabile — Cookiebot, OneTrust, Usercentrics o Iubenda installati tramite Code Injection è la risposta giusta. Un sito che ha affrontato tutte le superfici ha trasformato la semplicità amichevole per i designer della piattaforma in una parte difendibile della posizione di consenso dell'operatore anziché in un debito di conformità nascosto.

← Blog Leggi tutto →