Before You Start

Cookie consent is one of the most misunderstood compliance requirements in nonprofit digital. Most organisations either over-engineer it, spending time on configuration that isn’t warranted by their actual tracking setup, or under-engineer it, running a banner that looks compliant but isn’t blocking anything correctly.

This guide covers the setup I use for nonprofit clients on Webflow. It’s specific and sequential. By the end you’ll have a working implementation that correctly gates analytics and advertising tags behind user consent, passes Google Consent Mode V2 signals, and is defensible to the ICO if questioned.

What you need before starting:

  • A Webflow site on a paid hosting plan with a custom domain connected
  • A Google Tag Manager account with the GTM container code not yet added to the site (or already added, since this guide covers both)
  • A CookieYes account (the free plan covers one site at 100 pages per scan and 5,000 pageviews a month, with paid plans starting at $10 a month, checked September 2026)
  • Access to your GA4 property
  • A clear list of every third-party tool your site uses that sets cookies or collects data

Two scenarios this guide covers:

Scenario A: analytics only (GA4, Webflow Analyze). The client runs no advertising. The setup is simpler: CookieYes, GTM, GA4, Consent Mode V2 for analytics signals. No advertising consent signals required.

Scenario B: full advertising consent (GA4 plus Meta Pixel and/or LinkedIn Insight Tag). The client runs or plans to run paid advertising targeting European audiences. Full Consent Mode V2 implementation required including ad storage, ad user data, and ad personalisation signals.

If your organisation runs Google advertising to audiences in the EEA, the UK or Switzerland, Consent Mode V2 is not optional. It is not itself a law. The law is PECR regulation 6, which since 5 February 2026 bars storing anything on a visitor’s device, or reading anything from it, unless one of the Schedule A1 exceptions applies; consent is the exception that covers advertising, and Consent Mode is how you signal that consent to Google, and Google enforces it through its EU user consent policy. If you run no advertising at all, PECR applies exactly the same and the analytics layer still has to be gated correctly. Cookie consent and GDPR for nonprofit websites covers what UK law requires and what changed on 5 February 2026.

Start with Scenario A and add Scenario B elements if they apply to your organisation.

Step 1: Create Your CookieYes Account and Connect Your Domain

Go to cookieyes.com and create an account. On the free plan you get one site, 100 pages per scan and 5,000 pageviews a month. For most charity websites that is enough; above it, paid plans start at $10 a month.

Once logged in, add your website domain. CookieYes will scan your site for cookies and categorise them automatically. The scan isn’t exhaustive: it catches most common cookies but won’t find everything, particularly cookies set by third-party scripts that load conditionally. Review the results and manually add any cookies you know the site sets that the scan missed.

CookieYes organises cookies into five categories:

  • Necessary. Session cookies, security tokens. Cannot be declined.
  • Functional. Preference cookies, language settings.
  • Analytics. GA4, Webflow Analyze, Microsoft Clarity.
  • Performance. Measurement of the site's key performance indicators.
  • Advertisement. Meta Pixel, LinkedIn Insight Tag, Google Ads.

Confirm every cookie on your site is in the correct category. An analytics cookie miscategorised as Necessary will fire without consent, which is a compliance failure.

Step 2: Style the Banner to Match the Brand

CookieYes provides a default banner layout that works well without modification. I don’t adjust the layout, position, or structure: the default is designed for compliance and usability and doesn’t need changing.

The only thing I style is the buttons, so they match the client’s brand colours. In CookieYes’s banner customisation settings:

  1. Navigate to the Customise section of your CookieYes dashboard
  2. Find the button colour settings
  3. Set the Accept button background colour to the client’s primary brand colour, and give Decline the same size, weight and placement rather than a quieter treatment
  4. Set the button text colour to ensure sufficient contrast (WCAG 2.2 AA requires a contrast ratio of at least 4.5:1 for normal text)
  5. Apply the same logic to the Manage Preferences button

Equal prominence is the constraint here, not a style preference. The ICO’s finalised guidance on storage and access technologies sets out that a compliant consent mechanism "makes it as easy to refuse consent as it is to accept" (ICO, 2026). A brand-coloured Accept next to a greyed-out or text-only Decline fails that test however good it looks.

Leave everything else at the default. The banner position (bottom bar or popup), the text layout, and the preference centre design are all functional as they come. Adding custom CSS or structural changes to the banner introduces the risk of breaking consent flows, which is not worth it for aesthetic reasons.

Step 3: Install CookieYes via the Native GTM Integration

CookieYes integrates with Google Tag Manager natively, which is the recommended installation method. It means CookieYes loads through GTM rather than requiring a separate script in your Webflow custom code, and it allows GTM to receive consent signals directly from CookieYes without additional configuration.

First, if GTM isn’t already installed on the Webflow site:

In GTM, create a new container for the site (or use an existing one). GTM provides two code snippets: one for the <head> and one for the <body>. In Webflow, add these in the site’s Custom Code settings:

  • Head code snippet → Webflow Site Settings → Custom Code → Head Code
  • Body snippet → Webflow Site Settings → Custom Code → Footer Code

Publish the Webflow site after adding the GTM snippets so they go live on the domain.

Now install CookieYes via GTM:

  1. In your CookieYes dashboard, go to Advanced Settings and open Get Installation Code
  2. Select Google Tag Manager as the installation method and copy your Website Key
  3. In GTM, go to Tags → New → Tag Configuration and search the Community Template Gallery for the CookieYes CMP template
  4. Add the tag and paste your Website Key into the Website Key field
  5. Set the trigger to Consent Initialization, which fires on all pages, so CookieYes loads before any other tag attempts to fire
  6. In CookieYes’s Advanced Settings, turn Support GCM on and leave Allow Google tags to fire before consent switched off

That last toggle is the one decision in this step that matters. Off is basic consent mode, where "you prevent Google tags from loading until a user interacts with a consent banner". On is advanced consent mode, where "Google tags load when a user opens the website or app" and send cookieless measurements before the visitor has answered the banner. The verification tests in Step 8 assume basic mode. CookieYes documents the full Webflow path if you need the screenshots. Nothing you configure in GTM is live until the container is published: click Submit, give the version a name and a description, then click Publish.

Before any other tag fires, which means before GA4, before Meta Pixel, before anything, GTM needs to establish default consent states. The default for all signals must be denied. PECR regulation 6 bars storing or reading anything on the device unless an exception applies, and the statistical purposes exception added in February 2026 expressly does not cover advertising (ICO, 2026), so denied is the only defensible starting state for these four signals.

In GTM, create a new tag:

  1. Tag type: Custom HTML. The snippet below is raw gtag() code, so it cannot go into a Google Tag’s configuration fields, and a Custom HTML tag has no Tag ID of its own. Google’s stated preference for Tag Manager is a consent mode template from the Community Template Gallery; a Custom HTML tag is how you set the defaults yourself (Google, 2026)

  2. Paste the following into the tag’s HTML field:

    <script>
  window.dataLayer = window.dataLayer || [];
  function gtag() { dataLayer.push(arguments); }

  gtag('consent', 'default', {
    ad_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
    analytics_storage: 'denied',
    wait_for_update: 2000,
  });
</script>

  3. Set the trigger to Consent Initialization, firing on all pages

  4. This tag must fire before the CookieYes tag. Use tag sequencing in GTM so the consent default fires first

Those four signals are the ones Consent Mode V2 defines: ad_storage, ad_user_data, ad_personalization and analytics_storage (Google, 2026).

The wait_for_update value (2000 milliseconds) tells Google tags to pause for two seconds while waiting for the CMP to update consent. This prevents a race condition where GA4 attempts to fire before CookieYes has loaded and communicated the user’s consent choice.

When a user accepts analytics cookies, CookieYes fires a consent update event through GTM:

gtag('consent', 'update', {
  analytics_storage: 'granted',
});

For Scenario B clients who accept advertising cookies:

gtag('consent', 'update', {
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
});

CookieYes handles firing these update events automatically via the GTM integration, so you don’t need to write this code manually. It fires when a user makes their consent choice in the banner.

With consent defaults in place, install GA4 through GTM:

  1. In GTM, create a new tag → Google Tag (this replaced the old Google Analytics: GA4 Configuration tag type)
  2. Enter your GA4 Measurement ID
  3. Set the trigger to All Pages
  4. In the tag’s Advanced Settings, open Consent Settings and confirm the tag requires analytics_storage before firing

When analytics_storage is denied, GA4 will not set cookies or collect user-level data. When consent is granted, GA4 fires normally. Modelled data is not the automatic backstop it is often described as: Google requires advanced consent mode plus at least 1,000 events a day with analytics_storage denied for seven days, and at least 1,000 daily users with consent granted on 7 of the previous 28 days. A property that does not clear both thresholds gets no modelled data, and in basic consent mode nothing reaches Google when consent is denied, so there is nothing to model from.

Step 6: Install Meta Pixel and LinkedIn Insight Tag (Scenario B Only)

Skip this step if your organisation doesn’t run advertising on Meta or LinkedIn.

Meta Pixel:

  1. In GTM, create a new tag → Custom HTML (or use the Meta Pixel template if available in your GTM container)
  2. Paste the Meta Pixel base code from your Meta Events Manager
  3. Set the trigger to All Pages
  4. In Advanced Settings, require ad_storage and ad_user_data consent before the tag fires

LinkedIn Insight Tag:

  1. In GTM, create a new tag → LinkedIn Insight Tag (use the GTM template from the Community Gallery)
  2. Enter your LinkedIn Partner ID
  3. Set the trigger to All Pages
  4. Require ad_storage consent before firing

Neither tag should fire until the user has accepted advertisement cookies. Verify this in Step 8.

Step 7: Webflow Analyze Tracking Default (Analyze Clients Only)

If your client is paying for Webflow Analyze, Webflow’s built-in analytics, you need to configure one additional setting.

In Webflow, go to the Insights tab, then Settings, then Tracking. Tracking is off by default on a new site. Once it is switched on, three defaults are available: Always track visitors, Let visitors opt out, and Don’t track by default. Choose Don’t track by default, which leaves tracking off for every visitor unless they explicitly opt in.

Left on Always track visitors, Analyze collects data regardless of the visitor’s CookieYes choice, because Analyze is a platform feature rather than a GTM tag and doesn’t receive GTM consent signals.

The setting does not carry the visitor’s choice on its own. Webflow is explicit: “If you choose Let visitors opt out or Don’t track by default, you’ll need a consent management solution to allow visitors to opt in or out of tracking. Otherwise, Analyze and Optimize won’t function properly” (Webflow, 2025). The routes Webflow documents are its DataGrail and Finsweet integrations, integrating an existing platform such as TrustArc or OneTrust through its APIs, or building your own banner in custom code (Webflow, 2026). CookieYes is not one of them. So on a site running Analyze, Don’t track by default switches tracking off, but nothing turns it back on for a visitor who accepts analytics on the CookieYes banner until one of those routes is in place. That leaves two honest options, and the right one depends on how much the client values Analyze. If Analyze is what they want, they have to adopt one of the routes Webflow documents above, which in practice means running that solution instead of CookieYes rather than alongside it. If what they actually want is consent-gated analytics, the simpler route is to leave Analyze switched off and run GA4 behind the CookieYes banner already in place, which is the setup the rest of this guide describes.

If your client is not paying for Webflow Analyze, skip this step entirely. The standard Webflow site plan doesn’t include Analyze, and this setting is irrelevant without it.

Step 8: Verify the Implementation

Verification is not optional. A consent implementation that looks correct but isn’t blocking tags is worse than no banner at all: it gives the appearance of compliance without the substance.

Test 1: Open the site in an incognito window.

Open your browser’s developer tools (F12) and go to the Network tab. Filter by google-analytics.com. Load the page. Before interacting with the consent banner, confirm that no GA4 requests appear in the Network tab. If GA4 is firing before consent is given, the consent default is not configured correctly.

Test 2: Accept analytics consent and confirm GA4 fires.

Click Accept on the CookieYes banner. Confirm that GA4 requests now appear in the Network tab. This confirms the consent update event is working and GA4 is responding to it correctly.

Test 3: Use GTM Preview Mode.

In GTM, open Preview Mode and connect to your live site. You’ll see a real-time panel of every tag, trigger, and variable. Check:

  • Does the CookieYes tag fire on Consent Initialization?
  • Does the consent default tag fire before GA4?
  • Does GA4 remain blocked until consent is granted?
  • When you accept cookies, does GA4 fire immediately?

Test 4: Decline all cookies and verify nothing fires.

Open a fresh incognito window, load the site, and click Decline All in the CookieYes banner. Confirm in the Network tab that no analytics or advertising requests appear. If any do, there is a consent configuration error that must be fixed before the site goes live.

Common Problems and How to Fix Them

GA4 fires before consent is given

The consent default tag is either not configured, not set to fire on Consent Initialization, or firing after the GA4 tag. Open GTM Preview Mode and read the actual firing order; if the consent default is not first, fix it with tag sequencing.

CookieYes banner appears but consent choices aren’t respected

The CookieYes GTM integration may not be passing consent signals correctly. Confirm the CookieYes tag is using the Consent Initialization trigger and that the GTM container has been published after the CookieYes template was added.

Webflow Analyze is collecting data despite cookie decline

The tracking default in Webflow’s Insights settings is still Always track visitors. This is a separate configuration from GTM, because GTM signals don’t reach Analyze.

The banner doesn’t appear on the site

The GTM container code hasn’t been published after adding the CookieYes tag, or the GTM snippets in Webflow Custom Code weren’t saved correctly. Confirm the GTM container is published and the Webflow site has been republished after adding the custom code.

A Note on When Full CMP V2 Is Required

Not every nonprofit needs the full Consent Mode V2 advertising configuration.

If your organisation doesn’t run Google Ads, Meta advertising, or LinkedIn campaigns targeting European audiences, the advertising consent signals (ad_storage, ad_user_data, ad_personalization) are less immediately critical, because there are no advertising tags to gate. You still need analytics consent configured correctly for PECR and UK GDPR compliance, but Google only requires the advertising layer of Consent Mode V2 when you run advertising through its platforms.

If you do run advertising targeting European audiences, or plan to, implement the full configuration from the start. Retrofitting advertising consent signals after campaigns are already running is more disruptive than doing it correctly upfront.

When in doubt, implement the full configuration. The additional steps are few, and they cover every signal Consent Mode V2 defines.

A Blueprint Audit maps this across your own site, as part of a full governance diagnostic.

Further Reading