Squarespace Cookie Consent Integratiegids: Ingebouwde Banner, Aangepaste CSS en Code Injectie voor 2026
Squarespace bevindt zich in dezelfde productcategorie als Wix en Webflow, maar onderscheidt zich op een andere as. Waar Wix is geoptimaliseerd voor de kleine ondernemer die een brochuresite wil maken met drag-and-drop en Webflow is geoptimaliseerd voor het bureau dat visueel wil ontwikkelen zonder front-end code te schrijven, is Squarespace geoptimaliseerd voor de designer-oprichter die een creatief dienstverleningsbedrijf, een redactionele site of een kleine e-commercewinkel runt. Die positionering bepaalt het toestemmingsoppervlak dat de beheerder erft. Een Squarespace-site wordt doorgaans geleverd met de native cookiebanner ingeschakeld, Squarespace Analytics gekoppeld, een ingebedde formulierprovider voor nieuwsbriefaanmeldingen, misschien een Squarespace Commerce-winkel, een YouTube- of Vimeo-achtergrond, een Instagram-blok en een handvol scripts van derden die de beheerder heeft toegevoegd via het Code Injection-paneel. Elk van die oppervlakken brengt een aparte toestemmingsverplichting met zich mee, en de native banner is ingesteld om er enkele standaard te blokkeren en volledig stil te zijn over de rest. Een verdedigbare Squarespace-implementatie in 2026 is er een waarbij de native banner correct is geconfigureerd, het Code Injection-oppervlak is geauditeerd, de ingebedde widgets zijn ingepakt en het toestemmingslogboek wordt behandeld als een documentatieartefact dat de beheerder kan produceren wanneer daarom wordt gevraagd.
Wat de native cookiebanner van Squarespace doet en waar hij stopt
De native Cookie Banner van Squarespace — toegankelijk via Settings, Cookies & Visitor Data — ondersteunt een configureerbare banner-UI, stelt de toestemmingsstijlkeuze van de beheerder bloot en integreert met de eigen analyses en marketingoppervlakken van Squarespace. Wanneer de beheerder de banner inschakelt en de instellingen voor bezoekersgegevens configureert, respecteren de interne integraties van Squarespace de keuze van de bezoeker zonder extra bedrading: Squarespace Analytics wordt gepoort op het analyticsignaal, de remarketing-pixels van Pinterest, Facebook en Google Ads respecteren het marketingsignaal, en de eigen gedragsgegevensverzameling van het platform wordt onderdrukt voor bezoekers die weigeren.
Wat de banner niet doet, en waar de meest voorkomende compliance-fout op Squarespace optreedt, is het blokkeren van scripts van derden die de beheerder toevoegt via Code Injection. Het Code Injection-paneel — onder Settings, Advanced — laat de beheerder willekeurige HTML en JavaScript in de paginaheader, -footer of per pagina plakken. Scripts die op deze manier worden geïnjecteerd, worden uitgevoerd voordat de bezoeker de banner heeft gezien, wat betekent dat elke third-party tag die in Code Injection wordt geplakt, wordt geactiveerd ongeacht de toestemming. Hotjar, aangepaste Google Tag Manager-containers, extra Facebook Pixels, chatwidgets, videoproviders — alles wat niet in de lijst met native integraties van Squarespace staat, wordt niet gepoort door de native banner tenzij de beheerder het script in een toestemmingscontrole inpakt.
Standaard toestemmingsstijl: opt-in versus impliciet
De banner van Squarespace ondersteunt zowel opt-in als impliciete toestemmingsstijlen, en de impliciete optie blijft beschikbaar, ook al is het de bron geweest van herhaalde toezichthoudersbevindingen tegen door Squarespace gehoste sites in de hele EEA. De beheerder moet de opt-in optie selecteren, verifiëren dat de verzameling van bezoekersgegevens standaard uitstaat totdat de bezoeker accepteert, en ervoor zorgen dat de weigeroptie minstens zo prominent is als de accepteeroptie in de banner-UI. Deze drie instellingen — expliciete toestemming, standaard uit, prominente weigering — zijn het minimum dat een Squarespace-site nodig heeft om de drempel te halen die de EDPB heeft vastgesteld in de cookiebannerrichtlijnen van 2023.
Het Code Injection-oppervlak en hoe het te blokkeren
Het integratiepatroon dat werkt op Squarespace heeft drie onderdelen. Ten eerste, configureer de native banner correct. Ten tweede, identificeer elk script in Code Injection en beoordeel tot welke toestemmingscategorie het behoort. Ten derde, wikkel elk Code Injection-script in een toestemmingscontrole voordat het wordt uitgevoerd — door de blootgestelde toestemmingsstatus van Squarespace tijdens runtime te lezen of door het scriptelement conditioneel alleen in te voegen nadat de banner een positief signaal heeft teruggegeven voor de relevante categorie.
Het schoonste patroon voor in de header geïnjecteerde scripts is ze omzetten naar een placeholder-vorm: verander het type-attribuut van text/javascript naar text/plain, voeg een data-category-attribuut toe dat de toestemmingspoort identificeert, en voeg een klein bootstrap-script in dat luistert naar het toestemmingswijzigingsgebeurtenis van Squarespace en het type-attribuut herschrijft wanneer de categorie wordt verleend. Het bootstrap-patroon is hetzelfde als dat Webflow, Drupal en Cloudflare Zaraz gebruiken; de bijdrage van Squarespace is het toestemmingsstatusobject dat de bootstrap leest.
Het third-party widgetoppervlak dat Squarespace-beheerders routinematig missen
Squarespace-beheerders vertrouwen sterk op ingebedde blokken voor de rijke inhoud die het grootste deel van de aantrekkingskracht van het platform aandrijft. Elk van deze blokken introduceert een apart toestemmingsoppervlak dat de native banner niet automatisch blokkeert.
- Videoblokken — YouTube- en Vimeo-achtergrondvideo's laden bij elke paginaweergave de scripts van derden van de provider. De privacyverbeterde YouTube-insluitmodus en de do-not-track Vimeo-insluitmodus zijn opties, maar het veiligere patroon is het videoblok in te pakken in een klik-om-te-laden tijdelijke aanduiding die alleen het iframe van de provider ophaalt wanneer de bezoeker het expliciet activeert.
- Sociale blokken — Instagram-, Twitter-, TikTok- en Pinterest-blokken halen elk het insluitscript van de provider op en stellen cookies aan de providerkant in. Het patroon is hetzelfde: vervang het live blok door een statisch voorbeeld dat de inbedding alleen laadt bij gebruikersinteractie, achter de marketingtoestemmingspoort.
- Nieuwsbriefaanmeldformulieren — Het ingebouwde formulier van Squarespace is toestemmingsbewust, maar insluitingen van formulieren van derden zoals Mailchimp, Klaviyo, ConvertKit en vergelijkbare zijn dat niet, en de ingebedde formulierprovider laadt doorgaans zijn eigen analyses bij het weergeven van het formulier. Elk moet worden ingepakt in een toestemmingscontrole.
- Chatwidgets — Drift-, Intercom-, Tidio- en vergelijkbare chatinsluitingen stellen hun eigen sessie- en identiteitscookies in en laden hun eigen JavaScript. Ze horen minimaal achter de functionele toestemmingspoort, en achter de marketingpoort als het chatplatform integreert met een CRM dat bezoekersgegevens verspreidt.
Squarespace Commerce en het winkelwagenoppervlak
Squarespace Commerce introduceert strikt noodzakelijke cookies voor winkelwagenstatus, sessie-identiteit en betaling die geen toestemming vereisen omdat ze essentieel zijn voor de dienst die de bezoeker heeft aangevraagd. De complicaties ontstaan rond de marketingoppervlakken die Commerce introduceert: e-mails over achtergelaten winkelwagentjes, aanbevelingsengines voor producten, integratie met Facebook Conversions API, Google Ads-remarketing en de Klaviyo- of Mailchimp-integratie die de meeste winkels inschakelen. Deze zijn niet-essentieel en moeten worden gepoort. De native banner van Squarespace verwerkt de eigen Conversions-integraties van het platform; Klaviyo en Mailchimp en elke aangepaste Conversions-setup vereisen poortbeheer aan de beheerderszijde.
Validatie en audithouding voor 2026
Een verdedigbare Squarespace-implementatie in 2026 moet vier technische controles doorstaan. Ten eerste moet een schone browsersessie die wordt bediend vanaf een EEA IP-adres nul niet-essentiële cookies produceren voordat de banner is bediend — dit omvat door Squarespace beheerde cookies, Code Injection-scripts, ingebedde video- en sociale blokken en alle nieuwsbrief- of chatwidgets op de pagina. Ten tweede moet het weigerpad die status behouden. Ten derde moet het accepteerpad alleen de tags produceren waarvoor de bezoeker toestemming heeft gegeven, en de cookies en toestemmingsstatus van Squarespace moeten de overeenkomende record bevatten. Ten vierde moet een intrekking onmiddellijk verdere tagactivaties stoppen, de cookies laten verlopen die zijn ingesteld tijdens de toestemmingssessie en de opt-out doorgeven aan downstream derde-partij-ontvangers. De audittrailkwestie is waar de native Squarespace-banner momenteel zijn grenzen toont. De banner registreert de toestemmingsstatus van de bezoeker in een first-party cookie die de eigen integraties van Squarespace lezen, maar het platform houdt geen server-side auditlogboek bij dat opvraagbaar is via bezoekersidentificator of sessie-identificator zoals een third-party CMP dat doet. Voor implementaties die voornamelijk opereren in rechtsgebieden met lichtere audittrailverwachtingen is de native banner voldoende wanneer correct geconfigureerd. Voor implementaties die een opvraagbaar toestemmingslogboek nodig hebben — multijurisdictionele rapportage, toestemmingsrecords per vendor, integratie met de verwachte documentatiestandaard van de EDPB — is een third-party CMP gelaagd over de native banner het juiste antwoord, met de native banner uitgeschakeld en Cookiebot, OneTrust, Usercentrics of Iubenda geïnstalleerd via Code Injection. Een Squarespace-site die bewust heeft gekozen tussen de twee paden, elk Code Injection-oppervlak heeft geblokkeerd, het ingebedde widgetpatroon heeft aangepakt en rekening heeft gehouden met Commerce-specifieke marketingintegraties, is een Squarespace-site die de designervriendelijke eenvoud van het platform heeft omgezet in een verdedigbaar deel van de toestemmingshouding van de beheerder in plaats van een verborgen compliance-schuld.