Integrationsguide för Wix Cookie Consent Banner: Inbyggd CMP, Velo och tredjepartsembeds 2026
Wix är standardwebbplattformen för hundratals miljoner småföretag, kreatörer och operatörer som inte har ett ingenjörsteam och inte vill ha ett. Plattformens styrka är just det — ett hostat webbplatsbyggarverktyg där den underliggande infrastrukturen, betalningshanteringen, innehållshanteringen och alltmer hela marknadsföringsstacken är abstraherade från den person som faktiskt driver webbplatsen. Det abstraktionen är också där Wix samtyckesrisker koncentreras. Plattformen levererar en inbyggd banner för cookiesamtycke som operatören kan aktivera med ett par klick; bannern tillfredsställer ytnivåfrågan om en banner existerar; och operatören går vidare. De svårare frågorna — om bannern faktiskt förhindrar att taggar avfyras före samtycke, om tredjepartsembeds i HTML och Velo-kod är korrekt blockerade, om samtyckesloggen är granskningsbar, om upplysningen om gränsöverskridande dataöverföring är korrekt — ställs sällan, och en Wix-sajt som inte ställt dem är inte en Wix-sajt som uppfyller GDPR, ePrivacy eller de regionala regimer som har anpassat sig efter dem. Den här guiden går igenom vad du ska konfigurera och vad du ska lägga till för att en Wix-driftsättning 2026 ska nå en försvarbar position.
Vad Wix inbyggda banner för cookiesamtycke faktiskt gör
Wix Cookie Consent Banner — tillgänglig för varje Wix-sajt under Settings, Privacy & Compliance — är ett av de mer kapabla inbyggda samtyckesverktygen som någon hostad plattform levererar. Den stöder opt-in per kategori för Essential, Functional, Analytics och Advertising, kan konfigureras för att kräva explicit bekräftande åtgärd, stöder flerspråkigt innehåll via webbplatsens översättningslager och integreras nativt med den samtyckespolicy som Wix's own Marketing Apps respekterar. När operatören konfigurerar bannern för att kräva samtycke och aktiverar kontroller per kategori respekterar Wix inbyggda integrationer — Wix Analytics, Facebook Pixel-integrationen, Google Ads-integrationen, Google Tag Manager-integrationen, Hotjar-integrationen — användarens val utan ytterligare kopplning.
Vad bannern inte gör, och var den vanligaste efterlevnadsbrist uppstår, är att blockera tredjepartsskript som operatören har lagt till via Wix Custom Code-funktion, Velo-kod eller inbäddade HTML-widgetar. Bannern registrerar användarens val; operatörens uppgift är att läsa det valet från samtyckespolicyn och villkorligt köra den tredjepartslogik som finns utanför Wix lista över hanterade integrationer. Mönstret fungerar när det väl är på plats, men det är inte automatiskt.
Standardkonfigurationen räcker inte
Standardbannerrkonfigurationen när operatören aktiverar den första gången är implicit samtycke — att besöka sajten behandlas som samtycke tills besökaren avböjer. Den positionen har varit källan till upprepade tillsynsmyndigheters fynd mot Wix-hostade sajter i hela EEA, UK och de regimer som har anpassat sig till GDPR. Operatören måste ändra konfigurationen för att kräva explicit bekräftande samtycke innan icke-nödvändiga cookies sätts, måste som standard sätta kategoriväxlarna till off och måste verifiera att avvisningsalternativet är minst lika framträdande som godkännandealternativet i banneranvändargränssnittet. Dessa tre inställningar — explicit samtycke, standard av, avvisning framträdande — är det minimum en Wix-sajt behöver för att passera det tröskelvärde som EDPB har satt i sina riktlinjer för cookie-banner från 2023 och bekräftat i arbetsgruppens prioriteringar för 2026.
Hur Wix hanterar samtycke under huven
Wix exponerar besökarens samtyckestillstånd via ett samtyckespolicyobjekt som plattformens interna integrationer läser och som operatörens kod kan läsa via Velo-utvecklarplattformen. Velo API exponerar samtyckespolicyn under wixWindow.consentPolicy i frontend och den motsvarande modulen i backend. Samtyckespolicyn returnerar ett strukturerat objekt med booleska flaggor per kategori och en tidsstämpel; operatörens Velo-kod eller Custom Code läser dessa flaggor innan icke-nödvändig tredjepartslogik initieras.
De samtyckeskategorier som Wix exponerar mappar till standardtaxonomin. Essential täcker session-, kundvagn-, säkerhets- och lastbalanseringscookies och kräver inte samtycke. Functional täcker preferenser, nyligen visade listor och liknande icke-nödvändig men icke-spårande lagring. Analytics täcker Wix Analytics, Google Analytics 4, Microsoft Clarity och liknande mätverktyg. Advertising täcker Facebook Pixel, Google Ads, TikTok Pixel, LinkedIn Insight och det bredare marknadsföringspixellagret. Inbyggda Wix Marketing Apps blockeras automatiskt på dessa kategorier; allt som operatören har lagt till måste blockeras manuellt.
Integrationsmönstret för tredjepartsembeds och Custom Code
Mönstret som fungerar på Wix har fyra delar. Först, konfigurera den inbyggda Cookie Consent Banner för att kräva explicit samtycke, sätt kategoriväxlarna till av som standard och se till att avvisningsalternativet är minst lika framträdande som godkännande. Andra, identifiera alla tredjepartsskript som sajten lägger till utanför Wix inbyggda integrationslista — typiskt finns dessa i Settings, Custom Code, i Velo-kodmoduler eller i inbäddade HTML-widgetar — och inventera under vilken samtyckeskategori var och en faller. Tredje, omslut varje tredjepartsskript i en samtyckeskontroll som läser samtyckespolicyn innan körning. Fjärde, se till att integritetsmeddelandet som visas från bannern återspeglar de faktiska tredjepartsmottagarna, inte det generiska Wix-mallspråket.
- Custom Code under Settings — operatörer lägger ofta till Google Tag Manager, ytterligare Facebook Pixel, ytterligare Google Ads konverteringstaggar, Hotjar-snippet och samtalsspårningsskript via Custom Code. Var och en av dessa måste konfigureras med lämplig Consent Mode-inställning i Custom Code-gränssnittet — Wix exponerar val av samtyckeskategori på snippet-nivå — så att snippet bara laddas när relevant kategori har beviljats.
- Velo-kod — backend och frontend Velo-kod kan läsa wixWindow.consentPolicy och villkorligt nå ut till tredjepartsAPI:er. Alla Velo-moduler som anropar en tredjepartsendpoint för att logga händelser, avfyra pixlar eller synkronisera data till ett CRM måste kontrollera relevant kategori innan körning.
- Inbäddade HTML-widgetar — inbäddade HTML-iFrames från tredjeparter (chattwidgetar, kalenderwidgetar, sociala embeds) laddar typiskt sina egna skript som sätter sina egna cookies. Mönstret är att rendera iFrame inuti ett Velo-kontrollerat omslag som villkorligt infogar iFrame-elementet först efter att relevant gate har beviljats.
- Wix Studio-sajter — Wix Studio ärver samma samtyckespolicymekanism men lägger till responsiv design och utvecklarlägesfunktioner som gör Velo-stilig samtyckesblockering lättare att underhålla. Integrationsmönstret är identiskt; underhållsergonomin är bättre.
Wix-specifika efterlevnadsfällor
Tre mönster återkommer på Wix-driftsättningar och står för merparten av de problem tillsynsmyndigheterna har flaggat. Det första är den operatörshanterade Google Tag Manager-behållaren — operatören installerar GTM via Custom Code och lägger sedan till dussintals taggar via GTM-gränssnittet utan att konfigurera Consent Mode v2 inuti GTM. Wix-bannern blockerar korrekt GTM-laddaren, men när GTM är laddat avfyras taggarna inuti utan ytterligare samtyckeskontroller om inte GTM har konfigurerats för att respektera Consent Mode. Fixet är att aktivera Consent Mode v2 i GTM-behållaren och koppla varje taggs trigger till lämplig samtyckessignal.
Det andra är den inbäddade formulärleverantören — Typeform, JotForm, Calendly och liknande — som laddar sina egna cookies för analys- och förifyllningssyften. Wix-bannern blockerar inte den inbäddade widgeten som standard; operatören måste blockera själva widgetelementet via Velo eller använda klick-för-att-ladda-platshållarmönstret som skjuter upp iFrame-laddningen tills användaren interagerar med det.
Det tredje är upplysningen om gränsöverskridande dataöverföring. Wix hostinginfrastruktur körs över regioner inklusive USA, och många av operatörens tredjepartsmottagare körs på andra ställen; integritetsaviseringsmallen som Wix levererar namnger inte dessa jurisdiktioner specifikt, och operatören måste redigera meddelandet för att namnge varje mottagarregion. EDPB:s vägledning från 2023 har varit tydlig med att generiskt data behandlad av tjänsteleverantörer-språk inte är tillräckligt, och samma standard gäller för Wix-hostade sajter.
Validering och revisionslägning för 2026
En försvarbar Wix-driftsättning 2026 måste klara fyra tekniska kontroller. Först måste en ren webbläsarsession servad från en EEA IP-adress producera noll icke-nödvändiga cookies innan bannern har åtgärdats — inte bara noll Wix-hanterade cookies, utan noll cookies från varje Custom Code-snippet, Velo-modul och inbäddad widget. För det andra måste avvisningssökvägen behålla det tillståndet. För det tredje måste en godkännandesökväg producera enbart de taggar som användaren har samtyckt till, och Wix samtyckeslogg tillsammans med alla operatörsloggar måste innehålla matchande post. För det fjärde måste ett återkallande omedelbart stoppa ytterligare taggavfyrningar, upphäva de cookies som satts under den samtyckte sessionen och sprida opt-outen till eventuella nedströms tredjepartsmottagare som upprätthåller sitt eget tillstånd.
Revisionsloggförväntningen är där Wix förbättras men fortfarande kräver operatörsinsats. Plattformen registrerar samtycksbeslut i sin egen logg som är tillgänglig för webbplatsägaren, vilket är tillräckligt för många tillsynsmyndighetsfrågor. För driftsättningar som behöver ett mer komplett revisionslog — bannerversion, kategoritillstånd, språkversion och nedströms mottagartillstånd — måste operatören lägga till Velo-kod som skriver samtyckeshändelser till ett externt frågningsbart lager. En Wix-sajt som har konfigurerat den inbyggda bannern korrekt, blockerat varje Custom Code och Velo-sökväg, redigerat integritetsmeddelandet för att namnge varje gränsöverskridande mottagare och lagt till revisionsloggposten är en Wix-sajt som har förvandlat plattformens hostad-byggarenkelhet från en efterlevnadsskuld till en försvarbar del av en utgivares samtyckesposition.