Squarespace Cookie-beleegyezés Integrációs Útmutató: Beépített Banner, Egyéni CSS és Kódinjekció 2026-ra
A Squarespace ugyanabba a termékkategóriába tartozik, mint a Wix és a Webflow, de más tengelyen különbözik. Míg a Wix a kisüzleti tulajdonosra optimalizál, aki húzással-ejtéssel szeretne prospektusoldalt létrehozni, a Webflow az ügynökségre, amely front-end kód írása nélkül szeretne vizuális fejlesztést, addig a Squarespace a tervező-alapítóra optimalizál, aki kreatív szolgáltatási vállalkozást, szerkesztőségi oldalt vagy kis e-kereskedelmi boltot vezet. Ez a pozicionálás alakítja a beleegyezési felületet, amelyet az operátor örököl. Egy Squarespace-webhely jellemzően aktivált natív cookie-bannerrel, csatlakoztatott Squarespace Analytics-szal, hírlevél-feliratkozáshoz beágyazott űrlapszolgáltatóval, esetleg Squarespace Commerce-üzlettel, YouTube- vagy Vimeo-háttérrel, Instagram-blokkal és néhány harmadik féltől származó scripttel érkezik, amelyeket az operátor a kódinjekciós panelen keresztül adott hozzá. Ezek mindegyike külön beleegyezési kötelezettséget teremt. A 2026-ban védhető Squarespace-telepítés az, ahol a natív banner megfelelően van konfigurálva, a kódinjekciós felület auditálva van, a beágyazott widgetek be vannak csomagolva, és a beleegyezési napló dokumentációs műtárgyként van kezelve.
Mit csinál a Squarespace natív cookie-bannere és hol áll meg
A Squarespace natív Cookie Banner — Settings, Cookies & Visitor Data alatt érhető el — konfigurálható banner-felhasználói felületet támogat és integrálódik a Squarespace saját analitikai és marketing felületeivel. Amikor az operátor aktiválja a bannert és konfigurálja a látogatói adatok beállításait, a Squarespace belső integrációi tiszteletben tartják a látogató választását: a Squarespace Analytics az analitikai jelre kapuzik, a Pinterest, a Facebook és a Google Ads újracélzási pixelei tiszteletben tartják a marketing jelet.
Amit a banner nem tesz meg, az a kódinjekción keresztül hozzáadott harmadik féltől származó scriptek kapuzása. A kódinjekciós panel — Settings, Advanced alatt — lehetővé teszi az operátor számára, hogy tetszőleges HTML-t és JavaScript-et illesszen be az oldalfejlécbe, az oldalláblécbe vagy oldalankénti helyszínekre. Az ily módon injektált scriptek azelőtt futnak le, mielőtt a látogató látta volna a bannert. Hotjar, egyéni Google Tag Manager-konténerek, további Facebook-pixelek, csevegő widgetek, videószolgáltatók — minden, ami nincs a Squarespace natív integrációs listáján, nem lesz kapuzva a natív banner által, hacsak az operátor nem csomagolja a scriptet beleegyezés-ellenőrzésbe.
Alapértelmezett beleegyezési stílus: opt-in vs. implicit
A Squarespace-banner mindkét beleegyezési stílust támogatja, és az implicit beállítás az EEA-ban Squarespace-en hosztolt oldalak ellen hozott szabályozói megállapítások forrása volt. Az operátornak az opt-in beállítást kell választania, ellenőriznie kell, hogy a látogatói adatgyűjtés alapértelmezetten ki van-e kapcsolva, és biztosítania kell, hogy az elutasítási lehetőség legalább olyan hangsúlyos legyen, mint az elfogadásé. Ez a három beállítás az a minimum, amelyre egy Squarespace-webhelynek szüksége van az EDPB 2023-as cookie-banner irányelveiben meghatározott küszöb átlépéséhez.
A kódinjekciós felület és kapuzása
A Squarespace-en működő integrációs minta három részből áll. Először a natív bannert kell megfelelően konfigurálni. Másodszor azonosítani kell minden scriptet a kódinjekciós területen. Harmadszor minden kódinjekciós scriptet bele kell csomagolni egy beleegyezés-ellenőrzésbe végrehajtás előtt.
A legtisztább minta a fejlécbe injektált scriptek számára az, hogy helyőrző formába alakítják őket: a type attribútumot text/javascript-ről text/plain-re változtatják, hozzáadnak egy data-category attribútumot és egy kis bootstrap scriptet. A Webflow, a Drupal és a Cloudflare Zaraz is ugyanezt a bootstrap mintát használja.
A harmadik féltől származó widget felület, amelyet a Squarespace-operátorok rendszeresen kihagynak
A Squarespace-operátorok erősen támaszkodnak a beágyazott blokkokra a gazdag tartalomhoz. Mindegyik blokk külön beleegyezési felületet vezet be.
- Videóblokkok — A YouTube- és Vimeo-háttérvideók minden oldalrendereléskor betöltik a szolgáltató harmadik féltől származó scriptjeit. Csomagolja a videóblokkot click-to-load helyőrzőbe.
- Közösségimédia-blokkok — Az Instagram-, Twitter-, TikTok- és Pinterest-blokkok szolgáltatói oldalon sütiket állítanak be. Cserélje ki statikus előnézetre, amely csak felhasználói interakcióra tölt a marketing beleegyezési kapu mögött.
- Hírlevél-feliratkozási űrlapok — A Mailchimp, Klaviyo, ConvertKit beágyazások nem beleegyezés-tudatosak. Mindegyiket be kell csomagolni.
- Csevegő widgetek — A Drift, az Intercom, a Tidio saját munkamenet-sütiket állít be és JavaScript-et tölt be. Legalább a funkcionális beleegyezési kapu mögé kell helyezni.
Squarespace Commerce és a kosárfelület
A Squarespace Commerce bevezeti a szükségszerűen szükséges sütiket a kosár állapotához, a munkamenet-azonosítóhoz és a fizetéshez, amelyek nem igényelnek beleegyezést. A bonyodalmak a Commerce által bevezetett marketing felületek körül merülnek fel: elhagyott kosár e-mailek, Facebook Conversions API, Google Ads remarketing, Klaviyo vagy Mailchimp. Ezek nem elengedhetetlenek és kapuzni kell őket.
Érvényesítés és auditpozíció 2026-ra
A védhető telepítésnek négy technikai ellenőrzést kell meghaladnia. Először EEA IP-ről kiszolgált tiszta böngészőmunkamenetnek nulla nem nélkülözhetetlen sütit kell termelnie a banner előtt. Másodszor az elutasítási útvonalnak meg kell tartania ezt az állapotot. Harmadszor az elfogadási útvonalnak csak a beleegyezett tageket kell termelnie. Negyedszer a visszavonásnak azonnal le kell állítania a további tagfelvételeket. A natív banner elegendő a könnyebb követelményű joghatóságok számára. Lekérdezhető beleegyezési naplóhoz — a Cookiebot, az OneTrust, a Usercentrics vagy az Iubenda a kódinjekción keresztül telepítve a helyes válasz. Egy webhely, amely az összes felületet kezelte, a platform egyszerűségét védhető beleegyezési pozícióvá alakította.