Guía de integración do consentimento de cookies en Squarespace: Banner integrado, CSS personalizado e inxección de código para 2026
Squarespace atópase na mesma categoría de produto que Wix e Webflow, pero diferénciase nun eixo diferente. Mentres Wix optimiza para o pequeno empresario que quere crear un sitio de folleto arrastrando e soltando, e Webflow optimiza para a axencia que quere desenvolvemento visual sen escribir código front-end, Squarespace optimiza para o deseñador-fundador que xestiona un negocio de servizos creativos, un sitio editorial ou unha pequena tenda de comercio electrónico. Ese posicionamento moldea a superficie de consentimento que herda o operador. Un sitio Squarespace normalmente vén co banner nativo de cookies habilitado, Squarespace Analytics conectado, un provedor de formularios incrustado para subscricións a boletíns, quizais unha tenda Squarespace Commerce, un fondo de YouTube ou Vimeo, un bloque de Instagram e un pequeno puñado de scripts de terceiros que o operador engadiu a través do panel Code Injection. Cada unha desas superficies xera unha obrigación de consentimento separada. Un despregamento Squarespace defendible en 2026 é aquel onde o banner nativo foi correctamente configurado, a superficie Code Injection foi auditada, os widgets incrustados foron envolvidos e o rexistro de consentimento foi tratado como un artefacto de documentación.
Que fai o banner nativo de cookies de Squarespace e onde se detén
O Cookie Banner nativo de Squarespace — accesible en Settings, Cookies & Visitor Data — admite unha interface de banner configurable e intégrase coas superficies analíticas e de mercadotecnia propias de Squarespace. Cando o operador activa o banner e configura os axustes de datos de visitantes, as integracións internas de Squarespace respectan a elección do visitante sen necesidade de máis configuración: Squarespace Analytics contrólase mediante o sinal analítico, os píxeles de remarketing de Pinterest, Facebook e Google Ads respectan o sinal de mercadotecnia.
O que o banner non fai, e onde ocorre o fallo de cumprimento máis común en Squarespace, é controlar os scripts de terceiros que o operador engade a través de Code Injection. O panel Code Injection — en Settings, Advanced — permite ao operador pegar HTML e JavaScript arbitrario na cabeceira, pé de páxina ou localizacións por páxina. Os scripts inxectados deste xeito execútanse antes de que o visitante vise o banner. Hotjar, contedores personalizados de Google Tag Manager, píxeles adicionais de Facebook, widgets de chat, provedores de vídeo — calquera cousa que non estea na lista de integración nativa de Squarespace non será controlada polo banner nativo a menos que o operador envolva o script nunha verificación de consentimento.
Estilo de consentimento predeterminado: opt-in vs implícito
O banner de Squarespace admite estilos de consentimento opt-in e implícito, e a opción implícita segue dispoñible aínda que foi fonte de repetidas constatacións regulatorias contra sitios aloxados en Squarespace no EEA. O operador debe seleccionar a opción opt-in, verificar que a recollida de datos de visitantes está desactivada de forma predeterminada e garantir que a opción de rexeitamento sexa polo menos tan prominente como a de aceptación. Estes tres axustes son o mínimo que un sitio Squarespace necesita para superar o limiar establecido polo EDPB nas súas directrices de banner de cookies de 2023.
A superficie de Code Injection e como controlala
O padrón de integración ten tres partes. Primeiro, configurar correctamente o banner nativo. Segundo, identificar cada script en Code Injection. Terceiro, envolver cada script de Code Injection nunha verificación de consentimento antes da súa execución.
O padrón máis limpo é converter os scripts a forma de marcador de posición: cambiar o atributo type de text/javascript a text/plain, engadir un atributo data-category e incluír un pequeno script bootstrap. O padrón bootstrap é o mesmo que usan Webflow, Drupal e Cloudflare Zaraz.
A superficie de widgets de terceiros que os operadores de Squarespace pasan por alto habitualmente
Os operadores de Squarespace dependen moito dos bloques incrustados. Cada bloque introduce unha superficie de consentimento separada.
- Bloques de vídeo — YouTube e Vimeo cargan scripts de terceiros en cada renderizado. Envolva o bloque de vídeo nun marcador de posición click-to-load.
- Bloques sociais — Instagram, Twitter, TikTok e Pinterest establecen cookies do provedor. Substitúa por unha vista previa estática detrás da porta de consentimento de mercadotecnia.
- Formularios de subscrición a boletíns — Mailchimp, Klaviyo, ConvertKit non son conscientes do consentimento. Cada un precisa envolvemento.
- Widgets de chat — Drift, Intercom, Tidio establecen cookies de sesión propias. Polo menos detrás da porta de consentimento funcional.
Squarespace Commerce e a superficie do carriño
Squarespace Commerce introduce cookies estritamente necesarias para o estado do carriño e o pagamento que non requiren consentimento. As complicacións xorden arredor das superficies de mercadotecnia: correos de carriños abandonados, Facebook Conversions API, Google Ads remarketing, Klaviyo ou Mailchimp. Estes son non esenciais e deben controlarse.
Validación e postura de auditoría para 2026
Un despregamento defendible debe superar catro verificacións técnicas. Primeiro, cero cookies non esenciais antes do banner desde IP EEA. Segundo, a ruta de rexeitamento mantén ese estado. Terceiro, a ruta de aceptación produce só etiquetas consentidas. Cuarto, a retirada detén inmediatamente os disparos de etiquetas. O banner nativo é suficiente para xurisdicións con requisitos máis lixeiros. Para rexistros de consentimento consultables — Cookiebot, OneTrust, Usercentrics ou Iubenda a través de Code Injection é a resposta correcta. Un sitio que abordou todas as superficies converteu a simplicidade da plataforma en postura de consentimento defendible.