Squarespace Cookie Samtykke Integrasjonsveiledning: Innebygd Banner, Tilpasset CSS og Kodeinjeksjon for 2026
Squarespace befinner seg i samme produktkategori som Wix og Webflow, men differensierer seg på en annen akse. Der Wix er optimalisert for den lille bedriftseieren som vil lage et brosjyrenettsted med dra-og-slipp, og Webflow er optimalisert for byrået som vil ha visuell utvikling uten å skrive frontend-kode, er Squarespace optimalisert for designer-grunnleggeren som driver en kreativ tjenestebedrift, et redaksjonelt nettsted eller en liten nettbutikk. Den posisjoneringen former samtykkemoverflaten operatøren arver. Et Squarespace-nettsted leveres vanligvis med det innebygde cookie-banneret aktivert, Squarespace Analytics koblet til, en innebygd skjemaleverandør for nyhetsbrevpåmeldinger, kanskje en Squarespace Commerce-butikk, en YouTube- eller Vimeo-bakgrunn, en Instagram-blokk og en håndfull tredjepartsskript som operatøren har lagt til via Code Injection-panelet. Hver av disse overflatene medfører en separat samtykkeplikt, og det innebygde banneret er satt opp til å blokkere noen av dem som standard og er helt stille om resten. En forsvarlig Squarespace-distribusjon i 2026 er en der det innebygde banneret er riktig konfigurert, Code Injection-overflaten er revidert, de innebygde widgetene er pakket inn og samtykkeloggen er behandlet som et dokumentasjonsartefakt som operatøren kan fremlegge ved forespørsel.
Hva Squarespace' innebygde cookie-banner gjør og hvor det stopper
Squarespace' innebygde Cookie Banner — tilgjengelig under Settings, Cookies & Visitor Data — støtter en konfigurerbar banner-UI, eksponerer operatørens valg av samtykkestil og integrerer med Squarespace' egne analyser og markedsoverflater. Når operatøren aktiverer banneret og konfigurerer besøkendes datainnstillinger, respekterer Squarespace' interne integrasjoner den besøkendes valg uten ytterligere oppsett: Squarespace Analytics er sperret på analysesignalet, markedsføringspikslene fra Pinterest, Facebook og Google Ads respekterer markedsføringssignalet, og plattformens egen atferdsdatainnsamling er undertrykt for besøkende som nekter.
Det banneret ikke gjør, og der den vanligste samsvarsfeilen oppstår på Squarespace, er å sperre tredjepartsskriptene operatøren legger til via Code Injection. Code Injection-panelet — under Settings, Advanced — lar operatøren lime inn vilkårlig HTML og JavaScript i sidehodet, sidefoten eller per-side-steder. Skript injisert på denne måten kjøres før banneret er sett av den besøkende, noe som betyr at enhver tredjepartstag limt inn i Code Injection avfyres uavhengig av samtykke. Hotjar, egendefinerte Google Tag Manager-containere, ekstra Facebook Pixels, chat-widgets, videoleverandører — alt som ikke er på Squarespace' liste over innebygde integrasjoner, vil ikke bli sperret av det innebygde banneret med mindre operatøren pakker skriptet inn i en samtykkekontroll.
Standard samtykkestil: opt-in vs. implisitt
Squarespace' banner støtter både opt-in og implisitte samtykkestiler, og det implisitte alternativet er fortsatt tilgjengelig selv om det har vært kilden til gjentatte regulatorfunn mot Squarespace-hostede nettsteder over hele EEA. Operatøren må velge opt-in-alternativet, bekrefte at innsamling av besøkendes data er standard av til den besøkende aksepterer, og sørge for at avslå-muligheten er minst like fremtredende som aksepter-muligheten i banner-UI-en. Disse tre innstillingene — eksplisitt samtykke, standard av, fremtredende avslag — er minimum et Squarespace-nettsted trenger for å passere terskelen EDPB satte i retningslinjene for cookie-bannere fra 2023.
Code Injection-overflaten og hvordan den sperres
Integrasjonsmønsteret som fungerer på Squarespace har tre deler. For det første, konfigurer det innebygde banneret riktig. For det andre, identifiser hvert skript i Code Injection og vurder hvilken samtykkekategori det faller under. For det tredje, pakk hvert Code Injection-skript inn i en samtykkekontroll før det kjøres — enten ved å lese Squarespace' eksponerte samtykkestatus ved kjøring eller ved å sette inn skriptelementet betinget bare etter at banneret returnerer et positivt signal for den relevante kategorien.
Det reneste mønsteret for skript injisert i overskriften er å konvertere dem til plassholder-form: endre type-attributtet fra text/javascript til text/plain, legg til et data-category-attributt som identifiserer samtykkeporten, og inkluder et lite bootstrap-skript som lytter etter Squarespace' samtykkebyttehendelse og skriver om type-attributtet når kategorien er innvilget. Bootstrap-mønsteret er det samme som Webflow, Drupal og Cloudflare Zaraz bruker; Squarespace' bidrag er samtykkestatus-objektet som bootstrap leser.
Tredjepartswidget-overflaten Squarespace-operatorer rutinemessig går glipp av
Squarespace-operatorer er sterkt avhengige av innebygde blokker for det rike innholdet som driver det meste av plattformens appell. Hver av disse blokkene introduserer en separat samtykkemoverflate som det innebygde banneret ikke automatisk sperrer.
- Videoblokker — YouTube- og Vimeo-bakgrunnsvideoer laster leverandørens tredjepartsskript ved hver sidevisning. Den personvernforbedrede YouTube-innebyggingsmodus og do-not-track Vimeo-innebyggingsmodus er alternativer, men det sikrere mønsteret er å pakke videoblokken inn i en klikk-for-å-laste plassholder som bare henter leverandørens iframe når den besøkende eksplisitt aktiverer den.
- Sosiale blokker — Instagram-, Twitter-, TikTok- og Pinterest-blokker henter hver leverandørens innebygde skript og setter leverandørsidekookies. Mønsteret er det samme: erstatt live-blokken med en statisk forhåndsvisning som bare laster innebyggingen ved brukerinteraksjon, bak samtykkeporten for markedsføring.
- Nyhetsbrevpåmeldingsskjemaer — Squarespace' innebygde skjema er samtykkeklar, men Mailchimp, Klaviyo, ConvertKit og lignende tredjeparts skjemainnebygde er det ikke, og den innebygde skjemaleverandøren laster vanligvis sin egen analyse ved skjemavisning. Hver må pakkes inn i en samtykkekontroll.
- Chat-widgets — Drift, Intercom, Tidio og lignende chat-innebygginger setter sine egne økt- og identitetskookies og laster sin egen JavaScript. De hører hjemme bak den funksjonelle samtykkeporten som minimum, og markedsføringsporten hvis chat-plattformen integreres med en CRM som sprer besøkendes data.
Squarespace Commerce og handlekurvoverflaten
Squarespace Commerce introduserer strengt nødvendige cookies for handlekurvstatus, øktidentitet og utsjekking som ikke krever samtykke fordi de er essensielle for tjenesten den besøkende har bedt om. Komplikasjonene oppstår rundt markedsoverflater Commerce introduserer: e-poster om forlatte handlekurver, produktanbefalingsmotorer, Facebook Conversions API-integrasjon, Google Ads-remarketing og Klaviyo- eller Mailchimp-integrasjonen de fleste butikker aktiverer. Disse er ikke-essensielle og må sperres. Squarespace' innebygde banner håndterer plattformens egne Conversions-integrasjoner; Klaviyo og Mailchimp og enhver egendefinert Conversions-oppsett krever sperring på operatørsiden.
Validering og revisjonspostur for 2026
En forsvarlig Squarespace-distribusjon i 2026 må bestå fire tekniske kontroller. For det første må en ren nettlesersesjon betjent fra en EEA IP-adresse produsere null ikke-essensielle cookies før banneret er aktivert — som dekker Squarespace-administrerte cookies, Code Injection-skript, innebygde video- og sosiale blokker og eventuelle nyhetsbrev- eller chat-widgets på siden. For det andre må avslå-banen beholde den tilstanden. For det tredje må aksepter-banen bare produsere taggene den besøkende har samtykket til, og Squarespace' cookies og samtykkestatus må inneholde den samsvarende posten. For det fjerde må en tilbaketrekking umiddelbart stoppe ytterligere tagavfyring, utløpe cookies som ble satt under den samtykkebaserte sesjonen og spre opt-out til nedstrøms tredjepartsmottakere. Revisjonssporspørsmålet er der Squarespace' innebygde banner for øyeblikket viser sine grenser. Banneret registrerer besøkendes samtykkestatus i en first-party-cookie som Squarespace' egne integrasjoner leser, men plattformen opprettholder ikke en serversides revisjonslogg som kan spørres etter besøkende- eller øktidentifikator slik en tredjepartsCMP gjør. For distribusjoner som primært opererer i jurisdiksjoner med lettere revisjonssporkrav er det innebygde banneret tilstrekkelig når det er riktig konfigurert. For distribusjoner som trenger en søkbar samtykkelogg — rapportering på tvers av jurisdiksjoner, samtykkeposter per leverandør, integrasjon med EDPBs forventede dokumentasjonsstandard — er en tredjeparts-CMP lagdelt over det innebygde banneret det riktige svaret, med det innebygde banneret slått av og Cookiebot, OneTrust, Usercentrics eller Iubenda installert via Code Injection i stedet. Et Squarespace-nettsted som bevisst har valgt mellom de to veiene, sperret enhver Code Injection-overflate, adressert det innebygde widgetmønsteret og tatt hensyn til Commerce-spesifikke markedsintegrasjoner, er et Squarespace-nettsted som har gjort plattformens designervennlige enkelhet til en forsvarlig del av operatørens samtykkepostur i stedet for en skjult samsvarsgjeld.