What a Cookie Banner Actually Has to Do
A cookie banner has three jobs. It blocks non-essential trackers until the visitor makes a choice, it records that choice as evidence you can produce later, and it re-applies the same choice on the next visit so nobody gets asked twice. A grey strip that says "we use cookies, OK" does none of those things, and it's exactly the kind of banner that shows up in enforcement decisions.
The good news: the steps are the same whether you run WordPress, a hand-coded HTML site, Shopify, or a React app. The platform only changes where you paste one line of code. This guide covers the whole flow, and points to the platform-specific details where they matter.
Start With What You're Consenting To
You can't gate trackers you haven't found. Before you add a banner, run an inventory so you know which cookies, pixels, and storage keys your site actually sets, who sets them, and why. A homepage that looks clean often loads analytics, a chat widget, embedded video, and two ad pixels once you scroll. Walk through how to audit your website's cookies first, then sort each item into a category using cookie categories. Everything that isn't strictly necessary needs consent before it runs.
Skip this and you'll build a banner with the right buttons that quietly leaks data anyway, because the trackers were never wired to it.
Adding the banner
Pick a consent management platform (CMP)
A CMP is the tool that shows the banner, stores the choice, and blocks scripts. You can hand-roll one, but you'd be rebuilding regional rules, translations, consent logging, and Google Consent Mode from scratch. A CMP like CookieBeam gives you those out of the box and keeps up with the law as it changes.
Install the snippet in the <head>
Every CMP gives you one script tag. It has to load in the <head>, as early as possible, and before any analytics or marketing tags. Load order is the whole game: if a tracker runs before the CMP, it has already set its cookie and the banner is decorative.
Define your categories
In the CMP dashboard, map the trackers you found in your audit to categories (necessary, functional/preferences, analytics, marketing). This is what the toggles in the banner control.
Gate your existing scripts
Tell the CMP which scripts belong to which category so it can hold them until consent. Most CMPs support both a tagging approach (you mark each script) and automatic blocking of known trackers. See the next section for the mechanics.
Test before you publish
Open the site in a private window, watch the Network tab, and confirm nothing non-essential fires before you click a button. Then confirm "reject" actually blocks and "accept" actually loads. Never trust that it works because the banner appeared.
The One Line That Matters
On most platforms, adding the banner is a single script tag placed high in the <head>:
- WordPress: a plugin, or the snippet dropped into your theme's header (or via a header-injection plugin). See the WordPress cookie consent guide.
- Hand-coded HTML: paste the tag directly into
<head>on every page (or your shared header include). - Shopify / Wix / Squarespace / Webflow: use the platform's custom-code or header-injection field. Each has a dedicated guide, for example Webflow and Squarespace.
- React / Next.js / Vue: load the script in your root layout or document head so it runs before your app hydrates. See the Next.js guide.
The requirement is identical across all of them: the CMP loads first, non-essential tags load never (until consent). Once the snippet is in, you customize the look to match your brand, see how to customize your cookie banner.
Why the Banner Alone Isn't Enough
A banner that shows toggles but lets Google Analytics load anyway is worse than no banner, because it tells regulators and visitors you understood the obligation and ignored it. The technical half of the job is holding scripts until the choice is made. CookieBeam does this by rewriting a blocked script's type to text/plain so the browser skips it, then re-running it once its category is granted, and it can auto-block known trackers you didn't tag. The full mechanics are in how to block scripts before consent.
If you use Google's advertising or analytics products, you'll also wire the banner to Google Consent Mode so the tags adjust their behaviour to the consent state, see setting up Consent Mode with a CMP.
Launch checklist
CMP snippet loads first in the <head>
Before any analytics, ad, or marketing tag on every page.
Every non-essential tracker is mapped to a category
Analytics and marketing tags are gated, not filed under necessary.
Reject-all is present and as easy as accept-all
Same layer, equal prominence. This is a hard legal requirement in the EU.
Nothing non-essential fires pre-consent
Verify in the Network tab in a fresh private window.
The choice is stored and re-applied on return visits
Nobody should see the banner again until consent expires or is withdrawn.
A cookie policy describes what actually loads
Keep it in sync with your real inventory, not a template.
Do You Even Need One?
Not every site legally needs a banner, and plenty that show one are doing it wrong. Before you build, confirm what actually triggers the requirement for your audience in do I need a cookie banner, then use the GDPR compliance checklist to make sure the finished banner holds up.