Webflow Consent Mode with CookieBeam: How the Bridge Signals Consent

What the Webflow Consent Bridge Does

The CookieBeam Webflow consent bridge is a vendor integration that connects your cookie banner's analytics category to Webflow's Analyze and Optimize products. It works by writing consent state to localStorage under the key Webflow's own scripts read (intellimize_user_tracking_choice_<siteId>) and, when available, calling the Webflow JavaScript API (wf.allowUserTracking or wf.denyUserTracking). The bridge self-gates on the data-wf-intellimize-customer-id DOM attribute: if the page doesn't use Analyze or Optimize, no consent code runs and no localStorage keys are written. For first-time visitors the bridge pre-seeds a deny value before Optimize's bundle boots, closing a race condition where Optimize could default to tracking before the banner loads. When the visitor accepts or rejects analytics, the bridge updates localStorage and the Webflow API in real time; on withdrawal it forces deny through a separate event path.

This article covers each stage in detail. If you're looking for how to add a cookie banner to a Webflow site in general, see the Webflow cookie consent setup guide instead.

How the Bridge Gates Itself

The bridge checks for a DOM attribute: data-wf-intellimize-customer-id on the <html> element. Webflow stamps this attribute when Analyze or Optimize is enabled for a site. If the attribute isn't there, the bridge exits immediately and adds zero overhead to the page.

This self-gating means the bridge can be on by default without affecting sites that don't use Webflow's analytics features. You don't need to configure anything in CookieBeam to activate it. The bridge is enabled by default under the vendor consent signals setting. To disable it, switch off Webflow in your banner's vendor consent signals panel.

What Happens Before Consent

At page load, the bridge runs three steps in order.

First, it reads the site ID from data-wf-intellimize-customer-id on the HTML element.

Second, it checks localStorage for the key intellimize_user_tracking_choice_<siteId>. If the key holds neither allow nor deny (a first-time visitor, or the key was deleted), the bridge writes deny. This pre-seed is critical because Webflow Optimize reads this key as its bundle boots, which can happen before CookieBeam's consent state resolves. Without the pre-seed, Optimize might read an empty key and default to tracking.

Third, for returning visitors, the bridge checks CookieBeam's stored consent record. If the visitor previously accepted analytics, the bridge writes allow to localStorage and calls the Webflow API immediately. This ensures returning visitors who already consented get Analyze and Optimize active on page load, without waiting for a banner interaction that won't happen (the banner stays hidden for returning visitors with stored consent).

After Accept, Reject, and Withdrawal

When the visitor accepts the analytics category, CookieBeam fires the cookiebeam:consentUpdate event with analytics_storage: 'granted' in its detail. The bridge reads this, writes allow to localStorage, and calls wf.allowUserTracking({ activate: true }) through Webflow's ready callback.

When the visitor rejects analytics, the same event fires with analytics_storage: 'denied'. The bridge writes deny to localStorage and calls wf.denyUserTracking().

Withdrawal has its own path. When a visitor reopens the banner and switches analytics off, CookieBeam fires a separate cookiebeam:consentWithdrawn event. The bridge catches this and forces deny, writing to localStorage and calling wf.denyUserTracking(). The withdrawal path is separate because the standard consent update event may not fire during a reset.

A deduplication guard prevents the bridge from calling the Webflow API twice with the same value. If the state hasn't changed, nothing fires.

localStorage and the Optimize Race

Webflow Optimize reads its tracking choice key early in its boot sequence. On a fast page, Optimize's bundle can load before CookieBeam finishes initializing. The pre-seed to deny closes this race: even if Optimize boots first, it finds a deny value and won't track until the bridge updates it.

There's one edge case worth knowing. If the Webflow JavaScript API (window.wf) hasn't loaded when the consent decision is made, the bridge writes to localStorage but can't call wf.allowUserTracking() or wf.denyUserTracking(). This works in practice because Optimize reads the localStorage key as it boots. But if Webflow ever requires the API call itself (not just the localStorage value) to take effect, this path would need revisiting. As of September 2026, localStorage is the primary consent channel and the API call is a secondary confirmation.

EU vs US: One Bridge, No Region Check

The bridge doesn't check the visitor's region. It gates on analytics_storage, which CookieBeam's regional engine has already resolved. EU visitors arrive under an opt-in preset where analytics_storage defaults to denied. US opt-out visitors arrive under a preset where it defaults to granted, because US opt-out laws scope sale and sharing rather than analytics. The bridge reads the resolved signal and acts on it.

If you tighten analytics to opt-in for US visitors through regional consent rules, that tightening flows through to the Webflow bridge automatically.

For the broader picture of how CookieBeam handles consent across all vendor integrations, see the consent mode integrations overview, the Google Consent Mode v2 guide, and the Advanced vs Basic consent mode comparison. Official Webflow documentation on Analyze and Optimize consent is available at Webflow Analyze and the Webflow Optimize.