Hvad Squarespaces native cookie-banner gør, og hvor det stopper

Squarespaces native Cookie Banner — tilgængeligt under Settings, Cookies & Visitor Data — understøtter en konfigurerbar banner-UI, eksponerer operatørens valg af samtykkestil og integrerer med Squarespaces egne analyse- og marketingflader. Når operatøren aktiverer banneret og konfigurerer besøgendes-data-indstillingerne, respekterer Squarespaces interne integrationer den besøgendes valg uden yderligere forbindelser: Squarespace Analytics gater på analytik-signalet, remarketingpixlerne fra Pinterest, Facebook og Google Ads respekterer marketingsignalet, og platformens egne adfærdsmæssige dataindsamling undertrykkes for besøgende, der afviser.

Det, banneret ikke gør, og hvor den mest almindelige overholdelsesfejl opstår på Squarespace, er at gate de tredjeparts-scripts, som operatøren tilføjer via Code Injection. Code Injection-panelet — under Settings, Advanced — lader operatøren indsætte vilkårlig HTML og JavaScript i sidehovederne, sidefoden eller per-side-placeringer. Scripts injiceret på denne måde kører, før banneret er set af den besøgende, hvilket betyder, at ethvert tredjeparts-tag, der er indsat i Code Injection, affyres uanset samtykke. Hotjar, brugerdefinerede Google Tag Manager-containere, yderligere Facebook Pixels, chat-widgets, videoudbydere — alt, der ikke er på Squarespaces native integrationsliste, vil ikke blive gated af det native banner, medmindre operatøren pakker scriptet ind i en samtykkekontrol.

Standard samtykkestil: opt-in vs implicit

Squarespaces banner understøtter både opt-in og implicit-samtykke-stile, og den implicitte mulighed er stadig tilgængelig, selvom den har været kilden til gentagne tilsynsmyndighedsfund mod Squarespace-hostede sites i hele EEA. Operatøren skal vælge opt-in-muligheden, verificere at dataindsamling om besøgende er slået fra som standard, indtil den besøgende accepterer, og sikre, at afvisningsvalget er mindst lige så fremtrædende som accept-valget i banner-UI. Disse tre indstillinger — eksplicit samtykke, standard fra, afvisning fremtrædende — er det minimum, et Squarespace-site skal bruge for at rydde den tærskel, EDPB satte i sine cookie-banner-retningslinjer fra 2023 og bekræftede i 2026 task force-prioriteterne.

Code Injection-fladen og hvordan man gater den

Integrationsmønsteret, der fungerer på Squarespace, har tre dele. Først konfigurer det native banner korrekt. For det andet identificer hvert script i Code Injection og vurder, hvilken samtykkekategori det falder under. For det tredje pak hvert Code Injection-script ind i en samtykkekontrol, før det udføres — enten ved at læse Squarespaces eksponerede samtykkestatus på køretid eller ved betinget at indsætte script-elementet kun efter at banneret returnerer et positivt signal for den relevante kategori.

Det reneste mønster for header-injicerede scripts er at konvertere dem til pladsholdere: ændr type-attributten fra text/javascript til text/plain, tilføj en data-category-attribut, der identificerer samtykkeporten, og inkluder et lille bootstrap-script, der lytter til Squarespaces samtykkeskift-hændelse og omskriver type-attributten, når kategorien er bevilget. Bootstrap-mønsteret er det samme, som Webflow, Drupal og Cloudflare Zaraz bruger; Squarespaces bidrag er samtykkestatus-objektet, som bootstrap'en læser.

Tredjeparts widget-fladen, som Squarespace-operatører rutinemæssigt overser

Squarespace-operatører er stærkt afhængige af indlejrede blokke til det rige indhold, der driver det meste af platformens appel. Hver af disse blokke introducerer en separat samtykkeflade, som det native banner ikke automatisk gater.

• Videoblokke — YouTube- og Vimeo-baggrundsvideo indlæser udbyderens tredjeparts-scripts ved hvert sidevisning. Det sikrere mønster er at pakke videoblokken ind i en klik-for-at-indlæse-pladsholder, der kun henter udbyderens iframe, når den besøgende eksplicit aktiverer den.
• Sociale blokke — Instagram-, Twitter-, TikTok- og Pinterest-blokke henter udbyderens indlejringsscript og sætter cookies på udbyderside. Erstat den direkte blok med en statisk forhåndsvisning, der kun indlæser indlejringen ved brugerinteraktion bag marketingsamtykkeporten.
• Nyhedsbrevstilmeldingsformularer — Squarespaces indbyggede formular er samtykkebevidst, men tredjepartsformular-indlejringer fra Mailchimp, Klaviyo, ConvertKit og lignende er det ikke, og den indlejrede formularudbyder indlæser typisk sin egen analysesoftware ved formularvisning. Hver skal pakkes ind i en samtykkekontrol.
• Chat-widgets — Drift, Intercom, Tidio og lignende chat-indlejringer sætter deres egne sessions- og identitetscookies og indlæser deres eget JavaScript. De hører til bag den funktionelle samtykkeport som minimum, og marketingporten hvis chatplatformen integrerer med et CRM, der propagerer besøgendes data.

Squarespace Commerce og kurv-fladen

Squarespace Commerce introducerer strengt nødvendige cookies til kurvstatus, sessionsidentitet og betaling, der ikke kræver samtykke, fordi de er essentielle for den service, den besøgende har anmodet om. Komplikationerne opstår omkring de marketingflader, Commerce introducerer: e-mails om forladte kurve, produktanbefalingsmotorer, Facebook Conversions API-integration, Google Ads-remarketing og Klaviyo- eller Mailchimp-integration, som de fleste butikker aktiverer. Disse er ikke-essentielle og skal gates. Det native Squarespace-banner håndterer platformens egne Conversions-integrationer; Klaviyo og Mailchimp og enhver brugerdefineret Conversions-opsætning kræver gating på operatørsiden.

Validering og revisionsposition for 2026

Et forsvarligt Squarespace-deployment i 2026 skal bestå fire tekniske kontroller. Først skal en ren browsersession serveret fra en EEA IP-adresse producere nul ikke-essentielle cookies, før banneret er aktiveret. For det andet skal afvisningsstien bevare denne tilstand. For det tredje skal accept-stien kun producere de tags, den besøgende har samtykket til, og Squarespace-cookies og samtykkestatus skal indeholde den matchende post. For det fjerde skal en tilbagetrækning straks stoppe yderligere tag-fyringer, udløbe cookies sat under den samtykkede session og propagere framelding til eventuelle downstream tredjeparts-modtagere.

Revisionssporsspørgsmålet er, hvor det native Squarespace-banner i øjeblikket viser sine begrænsninger. Banneret registrerer den besøgendes samtykkestatus i en førstepartscookie, som Squarespaces egne integrationer læser, men platformen vedligeholder ikke en serversiderevionslog, der kan forespørges efter besøgendeidentifikator eller sessionsidentifikator, på den måde en tredjeparts-CMP gør. For deployments, der primært opererer i jurisdiktioner med lettere revisionssporstforventninger, er det native banner tilstrækkeligt, når det er korrekt konfigureret. For deployments, der har brug for en forespørgselbar samtykkelogg — multi-jurisdiktionsrapportering, per-leverandør samtykkeregistre, integration med EDPBs forventede dokumentationsstandard — er en tredjeparts-CMP lagret over det native banner det rigtige svar, med det native banner slukket og Cookiebot, OneTrust, Usercentrics eller Iubenda installeret via Code Injection i stedet. Et Squarespace-site, der bevidst har valgt mellem de to veje, gated hver Code Injection-flade, adresseret det indlejrede widget-mønster og taget højde for Commerce-specifikke marketingintegrationer, er et Squarespace-site, der har forvandlet platformens designer-venlige enkelhed til en forsvarlig del af operatørens samtykkeprofil snarere end en skjult overholdelsesforpligtelse.