Guides / Prompting and shipping

How to Add Cookie Consent to Your Website

Add a cookie banner that actually blocks scripts until people agree: what needs consent, CMP vs custom, Google consent mode and a checklist. Not legal advice.

Mythex Team · 2026-09-29 · 6 min read

To add cookie consent, first list what your site stores in visitors' browsers and sort it into strictly necessary and optional. Then add a banner — from a consent management platform or built yourself — that blocks optional scripts like analytics and ad pixels until the visitor accepts, offers "Reject" as easily as "Accept", remembers the choice and lets people change it later. A banner that shows but doesn't block anything does not do the job.

This guide is general information about how consent banners work technically, not legal advice. Privacy rules differ by country and change; check the rules that apply to your visitors, or ask an adviser.

What needs consent (in general terms)

Cookie rules usually cover cookies and similar technologies: localStorage, tracking pixels, device fingerprinting. The common split, based on EU and UK guidance:

Some specifics that are easy to get wrong:

• The EU and UK use an opt-in model: optional cookies wait until the visitor agrees. Guidance from regulators such as the UK's ICO says consent must be a clear positive action, and people must be able to enable or disable non-essential cookies easily.
• The UK changed in 2025. The Data (Use and Access) Act 2025 lets some cookies be set without consent, including analytics used only to improve your own site and producing aggregate statistics that can't identify people — with a duty to tell users clearly. Read the ICO's current guidance before relying on it.
• Several US states use an opt-out model for "selling" or "sharing" personal data for targeted advertising, and some expect you to honour the browser-level Global Privacy Control signal.
• Google ads: as of September 2026, Google requires publishers using AdSense, Ad Manager or AdMob to use a Google-certified consent management platform integrated with the IAB's Transparency and Consent Framework when serving ads in the EEA, the UK and Switzerland.

Options: CMP, library or custom

The last option is underrated. If all you want is visitor counts, a cookieless analytics tool can remove the need for a banner in many places — check its documentation and your local rules.

If you run Google ads in Europe, a certified CMP is the practical choice. For a small business site with analytics only, a well-built custom banner or a library is often enough.

How a banner works under the hood

The part people skip is blocking. A correct setup:

1. Before any choice, only necessary cookies and scripts run. Analytics, pixels and embeds are not loaded at all (or, with Google tags, are loaded with consent set to denied).
2. The banner shows clear choices at the first layer: Accept all, Reject all, and a way to choose by category.
3. On a choice, the site stores it — typically in a first-party cookie or localStorage — with a version and date, then loads only the accepted categories.
4. On later visits, the stored choice is read before anything optional loads.
5. A "Cookie settings" link, usually in the footer, reopens the choices at any time. Withdrawing should be as easy as giving consent.
6. If you change what you use, bump the version so people are asked again.

Google consent mode

For Google Analytics and Google Ads, Google's consent mode connects the tags to the banner. As of September 2026, Google's documentation describes four main consent types: ad_storage, analytics_storage, ad_user_data and ad_personalization. You set a default before the Google tag loads, then an update when the visitor chooses:

gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied'
});
// later, when the visitor accepts analytics only:
gtag('consent', 'update', { analytics_storage: 'granted' });

Google describes a basic implementation, where tags don't load until consent, and an advanced one, where tags load with consent denied and send cookieless signals. Basic is simpler to reason about. For EEA traffic, Google expects the ad_user_data and ad_personalization signals to be sent. See how to set up Google Analytics for the tag itself.

Prompts that work

Add a cookie consent banner. Categories: necessary (always on), analytics (Google Analytics 4) and marketing (Meta pixel). Nothing in analytics or marketing may load before consent. First screen: "Accept all", "Reject all" and "Customise", with equal prominence. Store the choice with a version number and date in a first-party cookie for 6 months, load only accepted categories, and add a "Cookie settings" link in the footer that reopens the banner. Use Google consent mode with all four types defaulted to denied.

List every cookie, localStorage key and third-party script this site uses, which page loads it, and whether it is strictly necessary. Output a table I can use for the cookie policy.

The YouTube embeds on /about load before consent. Replace them with a thumbnail and a play button that loads the video only after the visitor clicks, and show a note that YouTube may set cookies.

Step by step

1. Audit what your site sets: open DevTools → Application → Cookies and Local Storage on a fresh visit, and check the Network tab for third-party requests. Include embeds and chat widgets.
2. Categorise each item: necessary, preferences, analytics, marketing. Remove anything you don't use.
3. Decide the approach: CMP, library or custom, based on the table above.
4. Implement blocking so optional scripts load only after consent. For Google tags, add consent mode defaults before the tag.
5. Build the banner with equal Accept and Reject options, category choices and a settings link.
6. Write the cookie policy (often part of your privacy policy) listing what you use and why; see how to write terms of service and a privacy policy.
7. Test in a private window: before choosing, no optional cookies or requests; after rejecting, still none; after accepting, the right ones appear; after changing your mind, they stop.
8. Recheck whenever you add a new tool.

Common mistakes

• A banner that blocks nothing. Scripts fire on page load while the banner politely asks.
• Accept is a big button, Reject is hidden in a second screen or a grey link.
• Pre-ticked categories or "legitimate interest" toggles switched on by default.
• No way to change your mind after the first choice.
• Forgetting embeds: YouTube, maps, social feeds and chat widgets can set cookies too.
• Asking on every page load because the choice isn't stored properly.
• The banner covering the page on phones, or trapping keyboard focus. Make it accessible and small enough to read past.
• Copying another site's policy that describes cookies you don't use.

Consent checklist

• Every cookie, storage key and third-party script listed and categorised
• Optional scripts blocked until consent (verified in DevTools)
• Accept and Reject equally easy on the first layer
• Category choices available; nothing optional pre-selected
• Choice stored with a version and date; asked again after changes
• "Cookie settings" link on every page
• Google consent mode defaults set before Google tags, if used
• Cookie or privacy policy matches what the site actually does
• Rules for your visitors' countries checked with current guidance or an adviser

For the background, read what are cookies and what is GDPR.

Cookie consent on Mythex

Mythex doesn't add a consent banner or analytics to your app on its own — both are things you ask for, so you decide what loads. Run the audit prompt first, then the banner prompt with your real categories, and test in Preview with DevTools open before publishing. If you use a hosted CMP, it gives you a script and an ID; the ID is public and can go in the front-end code, and anything secret belongs in project settings (environment variables and secrets). Publish again after changes so the live site uses the new banner.