What Wix's built-in cookie consent banner actually does

The Wix Cookie Consent Banner — available to every Wix site under Settings, Privacy & Compliance — is one of the more capable native consent tools any hosted platform ships. It supports per-category opt-in across Essential, Functional, Analytics, and Advertising categories, can be configured to require explicit affirmative action, supports multilingual content via the site's translation layer, and integrates natively with the consent policy that Wix's own Marketing Apps respect. When the operator configures the banner to require consent and enables per-category controls, Wix's native integrations — Wix Analytics, the Facebook Pixel integration, the Google Ads integration, the Google Tag Manager integration, the Hotjar integration — honour the user's choice without further wiring.

What the banner does not do, and where the most common compliance failure occurs, is gate third-party scripts that the operator has added through Wix's Custom Code feature, Velo code, or embedded HTML widgets. The banner records the user's choice; the operator's job is to read that choice from the consent policy and conditionally execute the third-party logic that lives outside Wix's managed integration list. The pattern works once it is in place, but it is not automatic.

The default configuration is not enough

The default banner configuration when the operator first enables it is implicit-consent — visiting the site is treated as consent until the visitor declines. That posture has been the source of repeated regulator findings against Wix-hosted sites across the EEA, the UK, and the regimes that have aligned with the GDPR. The operator must change the configuration to require explicit affirmative consent before non-essential cookies are set, must default the per-category toggles to off, and must verify that the reject option is at least as prominent as the accept option in the banner UI. These three settings — explicit consent, default off, reject prominent — are the minimum a Wix site needs to clear the threshold the EDPB has set in its 2023 cookie banner guidelines and reaffirmed in the 2026 task force priorities.

How Wix handles consent under the hood

Wix exposes the visitor's consent state through a consent policy object that the platform's internal integrations read and that the operator's code can read through the Velo developer platform. The Velo API surfaces the consent policy under wixWindow.consentPolicy on the front end and the equivalent module on the back end. The consent policy returns a structured object with boolean flags per category and a timestamp; the operator's Velo code or Custom Code reads those flags before initialising any non-essential third-party logic.

The consent categories Wix exposes map to the standard taxonomy. Essential covers session, cart, security, and load-balancing cookies and does not require consent. Functional covers preferences, recently-viewed lists, and similar non-essential but non-tracking storage. Analytics covers Wix Analytics, Google Analytics 4, Microsoft Clarity, and similar measurement tools. Advertising covers Facebook Pixel, Google Ads, TikTok Pixel, LinkedIn Insight, and the broader marketing pixel inventory. Native Wix Marketing Apps gate on these categories automatically; everything operator-added needs to be gated manually.

The integration pattern for third-party embeds and Custom Code

The pattern that works on Wix has four parts. First, configure the built-in Cookie Consent Banner to require explicit consent, default the per-category toggles to off, and ensure the reject option is at least as prominent as accept. Second, identify every third-party script the site adds outside Wix's native integration list — typically these live in Settings, Custom Code, in Velo code modules, or in embedded HTML widgets — and inventory which consent category each one falls under. Third, wrap each third-party script in a consent check that reads the consent policy before executing. Fourth, ensure the privacy notice surfaced from the banner reflects the actual third-party recipients, not the generic Wix template language.

• Custom Code under Settings — operators commonly add Google Tag Manager, additional Facebook Pixels, additional Google Ads conversion tags, Hotjar snippets, and call-tracking scripts via Custom Code. Each of these must be configured with the appropriate Consent Mode setting in the Custom Code UI — Wix exposes consent-category selection at the per-snippet level — so that the snippet only loads when the relevant category is granted.
• Velo code — back-end and front-end Velo code can read wixWindow.consentPolicy and conditionally fan out to third-party APIs. Any Velo module that calls a third-party endpoint to log events, fire pixels, or sync data to a CRM must check the relevant category before executing.
• Embedded HTML widgets — embedded HTML iframes from third parties (chat widgets, calendar widgets, social embeds) typically load their own scripts which set their own cookies. The pattern is to render the iframe inside a Velo-controlled wrapper that conditionally inserts the iframe element only after the relevant gate has been granted.
• Wix Studio sites — Wix Studio inherits the same consent policy mechanism but adds responsive design and developer-mode features that make Velo-style consent gating easier to maintain. The integration pattern is identical; the maintenance ergonomics are better.

The Wix-specific compliance pitfalls

Three patterns recur on Wix deployments and account for the bulk of regulator-flagged issues. The first is the operator-managed third-party Google Tag Manager container — the operator installs GTM via Custom Code, then adds dozens of tags through the GTM UI without configuring Consent Mode v2 inside GTM itself. The Wix banner correctly gates the GTM loader, but once GTM is loaded the tags inside fire without further consent checks unless GTM has been configured to respect Consent Mode. The fix is to enable Consent Mode v2 in the GTM container and wire each tag's trigger to the appropriate consent signal.

The second is the embedded form provider — Typeform, JotForm, Calendly, and similar — that loads its own cookies for analytics and pre-fill purposes. The Wix banner does not gate the embedded widget by default; the operator must gate the widget element itself via Velo, or use the click-to-load placeholder pattern that defers the iframe load until the user interacts with it.

The third is the cross-border-transfer disclosure. Wix's hosting infrastructure runs across regions including the United States, and many of the operator's third-party recipients run elsewhere; the privacy notice template Wix ships does not name those jurisdictions specifically, and the operator must edit the notice to name each recipient region. The EDPB's 2023 guidance has been explicit that generic data processed by service providers language is not sufficient, and the same standard applies to Wix-hosted sites.

Validation and audit posture for 2026

A defensible Wix deployment in 2026 must pass four technical checks. First, a clean browser session served from an EEA IP address must produce zero non-essential cookies before the banner has been actioned — not just zero Wix-managed cookies, but zero cookies from every Custom Code snippet, Velo module, and embedded widget. Second, the reject path must keep that state. Third, an accept path must produce only the tags the user has consented to, and the Wix consent log together with any operator-side log must contain the matching record. Fourth, a withdrawal must immediately stop further tag fires, expire the cookies set during the consented session, and propagate the opt-out to any downstream third-party recipients that maintain their own state.

The audit-trail expectation is where Wix is improving but still requires operator effort. The platform records consent decisions in its own log accessible to the site owner, which is sufficient for many regulator queries. For deployments that need a fuller audit trail — banner version, category state, language version, and downstream-recipient state — the operator must add Velo code that writes consent events to a queryable external store. A Wix site that has configured the built-in banner correctly, gated every Custom Code and Velo path, edited the privacy notice to name each cross-border recipient, and added the audit-trail log is a Wix site that has turned the platform's hosted-builder simplicity from a compliance liability into a defensible part of a publisher's consent posture.