Integratiegids voor de Wix Cookie Consent Banner: Ingebouwde CMP, Velo en Insluitingen van Derden in 2026

Wix is het standaard webplatform voor honderden miljoenen kleine bedrijven, makers en beheerders die geen technisch team hebben en dat ook niet willen. De kracht van het platform is precies dat — een gehoste sitebouwer waarbij de onderliggende infrastructuur, betalingsverwerking, contentbeheer en steeds vaker ook de marketingstack worden afgeschermd van de persoon die de site daadwerkelijk beheert. Diezelfde abstractie is ook waar de toestemmingsrisico's van Wix zich concentreren. Het platform levert een ingebouwde cookietoestemmingsbanner die de beheerder met een paar klikken kan inschakelen; de banner beantwoordt de oppervlakkige vraag of een banner bestaat; en de beheerder gaat door. De moeilijkere vragen — of de banner daadwerkelijk voorkomt dat tags worden geactiveerd vóór toestemming, of de insluitingen van HTML van derden en Velo-code correct worden geblokkeerd, of het toestemmingslogboek auditeerbaar is, of de melding van grensoverschrijdende overdracht nauwkeurig is — worden zelden gesteld, en een Wix-site die ze niet heeft gesteld, is geen Wix-site die voldoet aan de AVG, ePrivacy of de regionale regimes die daarmee zijn afgestemd. Deze gids bespreekt wat u moet configureren en wat u moet toevoegen zodat een Wix-implementatie in 2026 een verdedigbare positie bereikt.

Wat de ingebouwde cookietoestemmingsbanner van Wix feitelijk doet

De Wix Cookie Consent Banner — beschikbaar voor elke Wix-site via Settings, Privacy & Compliance — is een van de capabelste native toestemmingstools die een gehost platform levert. Het ondersteunt opt-in per categorie voor Essential, Functional, Analytics en Advertising categorieën, kan worden geconfigureerd om expliciete bevestigende actie te vereisen, ondersteunt meertalige inhoud via de vertaallaag van de site, en integreert native met het toestemmingsbeleid dat de eigen Marketing Apps van Wix respecteren. Wanneer de beheerder de banner configureert om toestemming te vereisen en besturingselementen per categorie inschakelt, respecteren de native integraties van Wix — Wix Analytics, de Facebook Pixel-integratie, de Google Ads-integratie, de Google Tag Manager-integratie, de Hotjar-integratie — de keuze van de gebruiker zonder verdere koppeling.

Wat de banner niet doet, en waar de meest voorkomende nalevingsfout optreedt, is het blokkeren van scripts van derden die de beheerder heeft toegevoegd via de Custom Code-functie van Wix, Velo-code of ingesloten HTML-widgets. De banner registreert de keuze van de gebruiker; de taak van de beheerder is die keuze te lezen uit het toestemmingsbeleid en voorwaardelijk de logica van derden uit te voeren die buiten de beheerde integratielijst van Wix valt. Het patroon werkt zodra het op zijn plaats is, maar het is niet automatisch.

De standaardconfiguratie is niet voldoende

De standaard bannerconfiguratie wanneer de beheerder deze voor het eerst inschakelt, is impliciete toestemming — het bezoeken van de site wordt beschouwd als toestemming totdat de bezoeker weigert. Die houding is de bron geweest van herhaalde bevindingen van toezichthouders tegen door Wix gehoste sites in de EEA, het VK en de regimes die zijn afgestemd op de AVG. De beheerder moet de configuratie wijzigen om expliciete bevestigende toestemming te vereisen voordat niet-essentiële cookies worden ingesteld, moet de schakelaars per categorie standaard op off zetten, en moet verifiëren dat de weigering optie ten minste even prominent is als de acceptatieoptie in de banner-UI. Deze drie instellingen — expliciete toestemming, standaard uitgeschakeld, weigering prominent — zijn het minimum dat een Wix-site nodig heeft om de drempel te halen die het EDPB heeft vastgesteld in zijn cookiebannerwrichting uit 2023 en opnieuw bevestigd in de prioriteiten van de taskforce van 2026.

Hoe Wix toestemming achter de schermen afhandelt

Wix geeft de toestemmingsstatus van de bezoeker vrij via een toestemmingsbeleids­object dat de interne integraties van het platform lezen en dat de code van de beheerder kan lezen via het Velo-ontwikkelaarsplatform. De Velo API geeft het toestemmingsbeleid vrij onder wixWindow.consentPolicy aan de voorzijde en de equivalente module aan de achterzijde. Het toestemmingsbeleid retourneert een gestructureerd object met booleaanse vlaggen per categorie en een tijdstempel; de Velo-code of Custom Code van de beheerder leest die vlaggen voordat niet-essentiële logica van derden wordt geïnitialiseerd.

De door Wix vrijgegeven toestemmingscategorieën komen overeen met de standaardtaxonomie. Essential omvat sessie-, winkelwagen-, beveiligings- en load-balancingcookies en vereist geen toestemming. Functional omvat voorkeuren, onlangs bekeken lijsten en vergelijkbare niet-essentiële maar niet-trackingtoelaatende opslag. Analytics omvat Wix Analytics, Google Analytics 4, Microsoft Clarity en vergelijkbare meettools. Advertising omvat Facebook Pixel, Google Ads, TikTok Pixel, LinkedIn Insight en de bredere marketingpixelvoorraad. Native Wix Marketing Apps blokkeren automatisch op basis van deze categorieën; alles wat de beheerder toevoegt, moet handmatig worden geblokkeerd.

Het integratiepatroon voor insluitingen van derden en Custom Code

Het patroon dat werkt op Wix bestaat uit vier onderdelen. Ten eerste, configureer de ingebouwde Cookie Consent Banner om expliciete toestemming te vereisen, stel de schakelaars per categorie standaard op uit, en zorg ervoor dat de weigering optie ten minste even prominent is als acceptatie. Ten tweede, identificeer elk script van een derde partij dat de site toevoegt buiten de native integratielijst van Wix — doorgaans bevinden deze zich in Settings, Custom Code, in Velo-codemodules of in ingesloten HTML-widgets — en inventariseer onder welke toestemmingscategorie elk script valt. Ten derde, wikkel elk script van een derde partij in een toestemmingscontrole die het toestemmingsbeleid leest vóór uitvoering. Ten vierde, zorg ervoor dat de privacyverklaring die vanuit de banner wordt weergegeven de werkelijke ontvangers van derden weerspiegelt, niet de generieke sjabloontaal van Wix.

De Wix-specifieke nalevingsvalkuilen

Drie patronen komen steeds terug in Wix-implementaties en zijn verantwoordelijk voor het grootste deel van de door toezichthouders gemarkeerde problemen. Het eerste is de door de beheerder beheerde Google Tag Manager-container van een derde partij — de beheerder installeert GTM via Custom Code en voegt vervolgens tientallen tags toe via de GTM-UI zonder Consent Mode v2 te configureren in GTM zelf. De Wix-banner blokkeert de GTM-loader correct, maar zodra GTM is geladen, worden de tags erin geactiveerd zonder verdere toestemmingscontroles tenzij GTM is geconfigureerd om Consent Mode te respecteren. De oplossing is Consent Mode v2 in de GTM-container in te schakelen en de trigger van elke tag te koppelen aan het juiste toestemmingssignaal.

Het tweede is de ingebedde formulierprovider — Typeform, JotForm, Calendly en vergelijkbare — die zijn eigen cookies laadt voor analyse en vooraf invullen. De Wix-banner blokkeert de ingesloten widget standaard niet; de beheerder moet het widget-element zelf via Velo blokkeren, of het click-to-load-plaatshouder­patroon gebruiken dat het laden van de iframe uitstelt totdat de gebruiker ermee interacteert.

Het derde is de melding van grensoverschrijdende overdracht. De hosting­infrastructuur van Wix loopt over meerdere regio's, waaronder de Verenigde Staten, en veel ontvangers van derden van de beheerder werken elders; de sjabloon voor de privacyverklaring die Wix levert, noemt die jurisdicties niet specifiek, en de beheerder moet de verklaring bewerken om elke ontvangersregio te noemen. De EDPB-richtlijn van 2023 is duidelijk geweest dat generieke door dienstverleners verwerkte gegevens-taal niet voldoende is, en dezelfde standaard geldt voor door Wix gehoste sites.

Validatie en auditpositie voor 2026

Een verdedigbare Wix-implementatie in 2026 moet vier technische controles doorstaan. Ten eerste moet een schone browsersessie die wordt bediend vanuit een EEA IP-adres nul niet-essentiële cookies produceren voordat de banner is geactiveerd — niet alleen nul door Wix beheerde cookies, maar nul cookies van elk Custom Code-fragment, Velo-module en ingesloten widget. Ten tweede moet het weigeringspad die toestand behouden. Ten derde moet het acceptatiepad alleen de tags produceren waarvoor de gebruiker toestemming heeft gegeven, en het Wix-toestemmingslogboek samen met elk operatorzijdig logboek moet de overeenkomende record bevatten. Ten vierde moet een intrekking onmiddellijk verdere tag-activering stoppen, de tijdens de toestemming sessie ingestelde cookies laten verlopen en de opt-out doorgeven aan eventuele downstream-ontvangers van derden die hun eigen toestand bijhouden.

De verwachting van het auditspoor is waar Wix zich verbetert maar nog steeds beheerdersinspanning vereist. Het platform registreert toestemmingsbeslissingen in zijn eigen logboek dat toegankelijk is voor de site-eigenaar, wat voldoende is voor veel vragen van toezichthouders. Voor implementaties die een vollediger auditspoor nodig hebben — bannerversie, categoriestatus, taalversie en downstream-ontvangerstatus — moet de beheerder Velo-code toevoegen die toestemmingsgebeurtenissen schrijft naar een opvraagbare externe opslag. Een Wix-site die de ingebouwde banner correct heeft geconfigureerd, elk Custom Code- en Velo-pad heeft geblokkeerd, de privacyverklaring heeft bewerkt om elke grensoverschrijdende ontvanger te noemen, en het auditspoorlogboek heeft toegevoegd, is een Wix-site die de eenvoud van de door het platform gehoste bouwer heeft omgezet van een nalevingsaansprakelijkheid in een verdedigbaar onderdeel van de toestemmingspositie van een uitgever.

← Blog Alles lezen →