Cookie Consent on Webflow: No-Code and Custom Code

Webflow is a fast way to ship a marketing site, but it doesn't ship a consent manager. There's no native, category-level cookie tool that blocks analytics and marketing scripts until a visitor agrees. If your Webflow site serves the EU, the UK, or a US opt-out state, that gap is yours to close with custom code.

Why it matters: in September 2025 France's CNIL fined SHEIN 150 million euros partly because trackers fired before any choice and continued after "Reject all" (CNIL). A banner that looks right but tracks on page load is precisely the failure that gets penalized.

What Webflow gives you natively (and what it doesn't)

Webflow's built-in analytics and its integrations don't gate third-party scripts behind consent. If you add Google Analytics, GTM, or a Meta Pixel through project settings or an embed, they load as soon as the page renders. To be compliant you need a consent management platform that renders the banner and actually holds those scripts until the visitor opts in.

Where consent code goes in Webflow

Custom code lives in two places, both on paid plans:

• Site-wide: Site settings › Custom code › Head code. This injects on every page.
• Per page: a page's settings › Custom code, for scripts you only need on one page.

Paste your CMP loader into the Head code field, and make it the first script there, before GA4, GTM, or any pixel. Order isn't cosmetic: the consent script must initialize before the tags it's meant to control, or it has nothing to block. Webflow documents this integration pattern in its GDPR cookie consent walkthrough.

<!-- Site settings > Custom code > Head code (FIRST, before any tag) -->
<script async src="https://cdn.cookiebeam.com/banner/YOUR_BANNER_ID/default/loader.js"></script>

The load-order trap

Two Webflow-specific gotchas break blocking even when the banner looks fine:

1. Webflow injects some scripts inline in the head before your custom code runs. If you enabled Google Analytics via Webflow's own integration field, it can fire before your CMP loads. Remove it from Webflow's integration setting and load GA only through the consent-gated path (GTM or the CMP's tag manager).
2. Embeds inside the page body still execute. An HTML embed containing a pixel will run on render regardless of your head script. Route every tag through GTM (or your CMP) so a single consent gate governs all of them.

Consent Mode v2 with GTM on Webflow

Most Webflow sites manage tags through Google Tag Manager. Put the GTM snippet after the CMP in the head, set Consent Mode defaults to denied for EEA/UK visitors, and let the CMP push a consent update when the visitor chooses. That keeps Google Ads and GA4 measurement Consent Mode v2 compliant, which has been required for EEA and UK traffic since March 2024:

<!-- After the CMP loader, still in the head -->
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  // Default: assume no consent until the banner says otherwise
  gtag('consent', 'default', {
    ad_storage: 'denied',
    analytics_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
    wait_for_update: 500,
  });
</script>
<!-- GTM container snippet goes here -->

The CMP fires gtag('consent', 'update', ...) when the visitor accepts. If tags still misfire, our Consent Mode v2 troubleshooting guide lists the common breakpoints.

Tools on Webflow that need gating

The usual sources of non-essential cookies on a Webflow site, all of which must wait for consent:

• Google Analytics 4 and GTM: route through the CMP, never the native integration field.
• Meta, LinkedIn, or TikTok pixels: conversion tracking that counts as marketing.
• Embedded YouTube or Vimeo: use the privacy-enhanced (no-cookie) embed, or gate it.
• Chat and support widgets such as Intercom or Crisp: often set functional and analytics cookies on load.
• A/B testing and heatmap tools: classified as analytics or marketing.

If any of these load through a raw HTML embed placed in the page body, the head-level banner can't stop them, the embed executes on render. Consolidate every tag behind GTM or the CMP so a single gate governs them all.

You still need a cookie policy

A banner without a linked policy is only half the job. The GDPR and ePrivacy rules expect visitors to be able to read what each cookie does, how long it lasts, and which third parties set it. On Webflow, publish a dedicated /cookie-policy page and link it from both the banner and the footer. Keep it accurate: every new tool (a chat widget, an A/B test, a video embed) can introduce cookies that belong in that list.

This is where automated scanning earns its place. Instead of hand-maintaining the table, a CMP scans your published pages, classifies the cookies it finds, and keeps the policy in sync. Manual lists go stale the moment marketing adds a tag. See automated scanning vs manual audits for why that matters.

Test before you publish

• Open the site in a fresh private window from an EU IP (or a VPN) and check the Application › Cookies panel before clicking anything, only strictly necessary cookies should exist.
• Click "Reject all" and confirm no _ga, _gid, or _fbp appears and no marketing beacons fire in the Network tab.
• Accept, then confirm the tags now load and Consent Mode shows granted.
• Re-run a full consent audit after any new embed or integration.

With CookieBeam, the loader also blocks unknown scripts by default and keeps a timestamped consent record, so a Webflow site passes the same checks a purpose-built platform would, without leaving the visual canvas. Pair this with the banner design best practices to keep the UX clean.