Integrationsvejledning til Wix cookie-samtykkebanner: Indbygget CMP, Velo og tredjepartsindlejringer i 2026
Wix er standardwebplatformen for hundredvis af millioner af små virksomheder, skabere og operatører, der ikke har et ingeniørteam og ikke ønsker et. Platformens styrke er netop dette — en hostet webstedsbygger, hvor den underliggende infrastruktur, betalingsbehandling, indholdsadministration og i stigende grad markedsføringsstakken er abstraheret fra den person, der faktisk driver webstedet. Den abstraktion er også der, hvor Wix's samtykkerisici koncentrerer sig. Platformen leverer et indbygget cookie-samtykkebanner, som operatøren kan aktivere med et par klik; banneret opfylder det overfladiske spørgsmål om, hvorvidt et banner eksisterer; og operatøren går videre. De sværere spørgsmål — om banneret faktisk forhindrer tags i at affyre inden samtykke, om tredjepartsindlejringer af HTML og Velo-kode er korrekt blokeret, om samtykkeloggen er reviderbar, om oplysningerne om grænseoverskridende overførsler er præcise — stilles sjældent, og et Wix-websted, der ikke har stillet dem, er ikke et Wix-websted, der opfylder GDPR, ePrivacy eller de regionale regimer, der har tilpasset sig dem. Denne vejledning gennemgår, hvad der skal konfigureres, og hvad der skal tilføjes, så en Wix-implementering i 2026 når en forsvarlig position.
Hvad Wix's indbyggede cookie-samtykkebanner faktisk gør
Wix Cookie Consent Banner — tilgængeligt for alle Wix-websteder under Settings, Privacy & Compliance — er et af de mere kompetente native samtykkeredskaber, som nogen hostet platform leverer. Det understøtter opt-in pr. kategori på tværs af Essential-, Functional-, Analytics- og Advertising-kategorier, kan konfigureres til at kræve eksplicit bekræftende handling, understøtter flersproget indhold via webstedets oversættelseslag og integrerer native med den samtykkepoliti, som Wix's egne Marketing Apps respekterer. Når operatøren konfigurerer banneret til at kræve samtykke og aktiverer pr.-kategori-kontroller, ærer Wix's native integrationer — Wix Analytics, Facebook Pixel-integrationen, Google Ads-integrationen, Google Tag Manager-integrationen, Hotjar-integrationen — brugerens valg uden yderligere tilslutning.
Hvad banneret ikke gør, og hvor den mest almindelige overholdelsesfejl opstår, er at blokere tredjepartsscripts, som operatøren har tilføjet via Wix's Custom Code-funktion, Velo-kode eller indlejrede HTML-widgets. Banneret registrerer brugerens valg; operatørens opgave er at læse det valg fra samtykkepoliti'et og betinget udføre tredjepartslogikken, der lever uden for Wix's administrerede integrationsliste. Mønsteret fungerer, når det er på plads, men det er ikke automatisk.
Standardkonfigurationen er ikke tilstrækkelig
Standardkonfigurationen af banneret, når operatøren første gang aktiverer det, er implicit samtykke — at besøge webstedet behandles som samtykke, indtil den besøgende afviser. Denne position har været kilden til gentagne regulatoriske resultater mod Wix-hostede websteder i hele EEA, UK og de regimer, der har tilpasset sig GDPR. Operatøren skal ændre konfigurationen til at kræve eksplicit bekræftende samtykke, inden ikke-essentielle cookies sættes, skal sætte pr.-kategori-kontakterne til som standard slåede fra og skal bekræfte, at afvisningsvalget er mindst lige så fremtrædende som acceptvalget i bannerets UI. Disse tre indstillinger — eksplicit samtykke, slåede fra som standard, fremtrædende afvisning — er det minimum, et Wix-websted behøver for at overskride den tærskel, EDPB har sat i sine retningslinjer for cookie-bannere fra 2023 og bekræftet i task force-prioriteterne for 2026.
Hvordan Wix håndterer samtykke under motorhjelmen
Wix eksponerer den besøgendes samtykkestatus via et samtykkepolitiobjekt, som platformens interne integrationer læser, og som operatørens kode kan læse via Velo-udviklerplatformen. Velo API'en eksponerer samtykkepoliti'et under wixWindow.consentPolicy på frontend og det tilsvarende modul på backend. Samtykkepoliti'et returnerer et struktureret objekt med booleanske flag pr. kategori og et tidsstempel; operatørens Velo-kode eller Custom Code læser disse flag inden initialisering af nogen ikke-essentiel tredjepartslogik.
De samtykkekategorier, Wix eksponerer, kortlægger til standardtaksonomien. Essential dækker session-, kurv-, sikkerheds- og load-balancing-cookies og kræver ikke samtykke. Functional dækker præferencer, for nylig sete lister og lignende ikke-essentiel men ikke-sporende lagring. Analytics dækker Wix Analytics, Google Analytics 4, Microsoft Clarity og lignende måleværktøjer. Advertising dækker Facebook Pixel, Google Ads, TikTok Pixel, LinkedIn Insight og det bredere markedsføringspixellager. Native Wix Marketing Apps blokeres automatisk på disse kategorier; alt, der er tilføjet af operatøren, skal blokeres manuelt.
Integrationsmønsteret for tredjepartsindlejringer og Custom Code
Mønsteret, der fungerer på Wix, har fire dele. For det første, konfigurer det indbyggede Cookie Consent Banner til at kræve eksplicit samtykke, sæt pr.-kategori-kontakterne til slåede fra som standard, og sørg for, at afvisningsvalget er mindst lige så fremtrædende som accept. For det andet, identificer alle tredjepartsscripts, som webstedet tilføjer uden for Wix's native integrationsliste — typisk lever de i Settings, Custom Code, i Velo-kodemodulerne eller i indlejrede HTML-widgets — og opret inventar over, hvilken samtykkekategori der henhører under hver. For det tredje, pak hvert tredjepartsscript ind i et samtykketchek, der læser samtykkepoliti'et inden udførelse. For det fjerde, sørg for, at databeskyttelsesmeddelelsen fra banneret afspejler de faktiske tredjeparts-modtagere, ikke Wix's generiske skabelonsprog.
- Custom Code under Settings — operatører tilføjer typisk Google Tag Manager, yderligere Facebook Pixels, yderligere Google Ads-konverteringskoder, Hotjar-snippets og opkaldssporingsscripts via Custom Code. Hvert af disse skal konfigureres med den relevante Consent Mode-indstilling i Custom Code-UI — Wix eksponerer valg af samtykkekategori på snippet-niveau — så snippetten kun indlæses, når den relevante kategori er tildelt.
- Velo-kode — backend- og frontend-Velo-kode kan læse wixWindow.consentPolicy og betinget distribuere til tredjeparts-API'er. Ethvert Velo-modul, der kalder et tredjepartsslutpunkt for at logge hændelser, affyre pixels eller synkronisere data til et CRM, skal kontrollere den relevante kategori inden udførelse.
- Indlejrede HTML-widgets — indlejrede HTML-iframes fra tredjeparter (chat-widgets, kalender-widgets, sociale indlejringer) indlæser typisk deres egne scripts, der sætter deres egne cookies. Mønsteret er at rendere iframen inde i en Velo-styret indpakning, der betinget indsætter iframelementet først, efter at den relevante gate er tildelt.
- Wix Studio-websteder — Wix Studio arver den samme samtykkepolitimekanisme, men tilføjer responsivt design og udvikler-tilstandsfunktioner, der gør det lettere at vedligeholde samtykkeblokering i Velo-stil. Integrationsmønsteret er identisk; vedligeholdelses-ergonomien er bedre.
De Wix-specifikke overholdelsesmæssige faldgruber
Tre mønstre gentager sig i Wix-implementeringer og tegner sig for størstedelen af de regulatormærkede problemer. Det første er den operatørstyrede tredjepartscontainer til Google Tag Manager — operatøren installerer GTM via Custom Code og tilføjer derefter snesevis af tags via GTM-UI'en uden at konfigurere Consent Mode v2 inde i selve GTM. Wix-banneret blokerer korrekt GTM-indlæseren, men når GTM er indlæst, affyres tags inde uden yderligere samtykkekontroller, medmindre GTM er konfigureret til at respektere Consent Mode. Løsningen er at aktivere Consent Mode v2 i GTM-containeren og koble hvert tags trigger til det relevante samtykkesignal.
Det andet er den indlejrede formularudbyder — Typeform, JotForm, Calendly og lignende — der indlæser sine egne cookies til analyse og forudfyldningsformål. Wix-banneret blokerer ikke den indlejrede widget som standard; operatøren skal blokere selve widgetelementet via Velo eller bruge klik-for-at-indlæse-pladsholdermønsteret, der udsætter iframindlæsningen, indtil brugeren interagerer med det.
Det tredje er oplysningen om grænseoverskridende overførsel. Wix's hostinginfrastruktur kører på tværs af regioner, herunder USA, og mange af operatørens tredjeparts-modtagere kører andre steder; den databeskyttelsesmeddelelseskablon, Wix leverer, nævner ikke disse jurisdiktioner specifikt, og operatøren skal redigere meddelelsen for at nævne hver modtagerregion. EDPB's vejledning fra 2023 har været eksplicit om, at generisk data behandlet af tjenesteudbydere-sprog ikke er tilstrækkeligt, og den samme standard gælder for Wix-hostede websteder.
Validering og revisionsposition for 2026
En forsvarlig Wix-implementering i 2026 skal bestå fire tekniske kontroller. For det første skal en ren browsersession, der betjenes fra en EEA IP-adresse, producere nul ikke-essentielle cookies, inden der er foretaget handling på banneret — ikke bare nul Wix-administrerede cookies, men nul cookies fra hvert Custom Code-snippet, Velo-modul og indlejret widget. For det andet skal afvisningsstien bevare den tilstand. For det tredje skal acceptstien kun producere de tags, som brugeren har samtykket til, og Wix-samtykkeloggen sammen med eventuelle operatørsidelogge skal indeholde den matchende post. For det fjerde skal en tilbagetrækning omgående stoppe yderligere tag-affyringer, udløbe de cookies, der er sat under den samtykkede session, og udbrede fravalget til eventuelle downstream-tredjeparts-modtagere, der opretholder deres egen tilstand.
Revisionssti-forventningen er der, hvor Wix forbedrer sig, men stadig kræver operatørindsats. Platformen registrerer samtykkebeslutninger i sin egen log, der er tilgængelig for webstedsejeren, hvilket er tilstrækkeligt for mange regulatorforespørgsler. For implementeringer, der har brug for et mere komplet revisionssti — bannerversion, kategoristatus, sprogversion og downstream-modtagerstatus — skal operatøren tilføje Velo-kode, der skriver samtykkehændelser til et forespørgselsbart eksternt lager. Et Wix-websted, der har konfigureret det indbyggede banner korrekt, blokeret alle Custom Code- og Velo-stier, redigeret databeskyttelsesmeddelelsen til at nævne hver grænseoverskridende modtager og tilføjet revisionssti-loggen, er et Wix-websted, der har forvandlet platformens hosted-builder-enkelthed fra et overholdelses-ansvar til en forsvarlig del af en udgivers samtykkeposition.