How to add a cookie banner to a Webflow site

All posts

To add a cookie banner to a Webflow site, paste your consent platform's script into Site settings, Custom code, Head code, above every other tracking script, then publish. First clear the native Google Analytics and Meta Pixel fields under Apps and Integrations: whatever sits there loads outside your tag manager, where no consent gate reaches it.

Webflow loads tracking from two places, and your banner governs one

Guides to this question nearly all stop at the same point: sign up with a consent tool, paste the snippet into the head, publish. That is correct, and it is not what decides whether the setup holds. A Webflow site has two independent places tracking enters the page, and a banner governs one.

Site settings, Custom code is the surface you control. Defaults, banner and container all sit in the Head code box in whatever order you put them, and every tag the container fires can be held behind a consent condition.

Site settings, Apps and Integrations is the surface people forget they used. Paste a GA4 measurement ID there and Webflow injects Google Analytics on every page for you; paste a Meta Pixel ID and it does the same for the pixel. Neither goes through your container, so neither is affected by anything you configure in it. Gating your GA4 tag changes nothing while a measurement ID sits in that field.

The two fields do not even behave alike. The Meta Pixel field has a Delay for cookie consent toggle that holds the pixel until consent is recorded, and Webflow's documentation is explicit that switching it on still requires a banner of your own. The Google Analytics field has no equivalent: one can be made to wait, the other cannot.

Across Amplio Data client implementations we have measured 34% of sessions hidden by consent, and 20% to 40% of lost conversions recovered once the wiring is correct. Those are measured ranges across Amplio Data client implementations, not a guarantee.

Setting it up

1. Clear the native tracking fields first

   Open Site settings, Apps and Integrations. If a GA4 measurement ID or Meta Pixel ID sits there, Webflow injects that tag on every page itself, outside your container, where no consent condition on your tags reaches it. Clear them and load both through the container. Leaving one in place while the same tag also runs in the container double counts as well as leaks.

2. Put denied defaults above everything else

   At the very top of Site settings, Custom code, Head code, set a Consent Mode default denying ad_storage, analytics_storage, ad_user_data and ad_personalization. It has to sit above the banner and the container: a default arriving after a tag has fired is a late correction, not a default. As its own stub it also survives the banner's request being slow or failing.

3. Add the banner, then the container

   Both go in the same Head code box, banner first so it registers its state before the container parses. The box holds up to 50,000 characters, comfortable for all three together, so there is no reason to move a long configuration elsewhere to save room.

4. Put the container's noscript in Footer code

   Webflow gives you a head slot and a slot before the closing body tag, but none immediately after the opening body tag, where a container's noscript fragment is normally documented to go. Footer code is the working placement here, and it matters far less than the head snippet.

5. Deal with the scripts already in the head

   Any vendor script pasted straight into Head code loads on its own and cannot be gated by a tag manager that never owned it. Inventory that box before declaring the site done. Each script either moves into the container as a gated tag, gets wrapped so the consent layer can hold it, or is argued as strictly necessary: an eligibility question worth settling per script.

6. Publish, then verify on the live domain

   Custom code appears in preview but does not go live until you publish, so a check in the Designer proves nothing. Publish, load the live domain on a clean profile, and click nothing: no analytics or advertising cookies set, no request reaching your vendors. Then accept and confirm everything appears. Test the live domain, not only the webflow.io staging subdomain, since the two can carry different published states.

The full pre launch sequence, which is worth running once properly, is in how to test a cookie banner before going live.

Four things that catch people out on Webflow

Preview is not published. Webflow's documentation puts it plainly: the effects of custom code appear in preview, but do not go live until the site is published. Every consent check has to happen on the published site.

Components duplicate whatever you put in them. A snippet inside a Component used in a global header ships on every page that uses it. Two containers on a page is its own class of problem, and it reads as a consent fault long before anyone suspects the header. Site wide snippets belong in Site settings.

Page level code runs after site wide code. Custom code on an individual page appears after site wide code in the markup. That is the right way round for defaults, and it means a defaults stub added to one page cannot rescue it: the site wide container has already parsed above it.

The documented Pixel banner is a pixel gate, not a consent layer. Webflow documents building a banner by hand for its native Meta Pixel: Interactions to show and hide it, plus a Footer code script granting pixel consent on click. It is scoped to that pixel and says so. Read as a general consent layer it falls short: it grants consent but carries no withdrawal path, the decline button only hides the banner, and it governs nothing else on the page. Withdrawal being as easy as granting is not optional under GDPR, so it is a starting point rather than a finish line.

When the banner is up and cookies still appear

Work through the sources in the order they usually prove to be the answer. First the Apps and Integrations fields, which nothing in your container reveals. Second, scripts pasted straight into Head code. Third, a snippet duplicated through a Component. Only then open the container.

A fourth source is not Webflow's doing: a correctly gated tag can still load another vendor's pixel downstream, which is covered here. The full pre launch sequence is in how to test a cookie banner before going live.

One placement question comes up on nearly every Webflow build: head or tag manager. The answer is both, split by job. Keep a denied defaults stub in Head code so the denied state exists before anything loads, and keep the tool itself where the people who manage tags can reach it. A tool living only in the head whose request fails lets the container fire with no defaults registered, which fails in the wrong direction.

Velo installs on Webflow as one snippet in that Head code box: defaults, banner and the consent state the container reads, in the right order by construction.