Cookie consent banner: correct, user-friendly and GDPR-proof

Introduction

Cookie banners: we see them everywhere, and they are becoming a growing source of frustration for internet users. Visitors often click them away thoughtlessly — either because they don’t understand what it says, or because the banner is too intrusive. Many site owners think that “just adding a banner” is enough, but it’s not that simple. A bad or misleading cookie consent banner does not comply with the law and drives visitors away. The Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) warns that consent for cookies may never be forced under pressure — banners must be clear and honest. In this article you’ll learn why cookie banners are needed, which cookies require consent, and how to create a user-friendly and GDPR-proof cookie consent banner. After reading, you’ll be able to set up a banner that is both legally correct and wins your visitors’ trust.

What are cookies, really?

Cookies are small text files that a website places on a visitor’s device. On a later visit the site can read that cookie again. Cookies serve many purposes: from remembering your login status to tracking your click behavior. Besides cookies there are similar techniques such as LocalStorage, tracking pixels, or scripts that store or read information on the user’s computer. In practice, all these techniques fall under the “cookie law” (Article 11.7a of the Dutch Telecommunications Act), which follows the same principle: if you store or read information on someone’s device, you need consent in many cases.

Why are browsers becoming stricter?

Simply put: cookies and tracking have been widely abused. For years, many third parties tracked users across the web with so-called third-party cookies. This has led to growing privacy concerns. Browsers respond to this: Safari and Firefox now block many tracking cookies by default, and Google’s Chrome (the most popular browser) is phasing out third-party cookies. At the same time, browsers add features like Intelligent Tracking Prevention (Safari) and Enhanced Tracking Protection (Firefox) to limit unwanted tracking techniques. These technical limitations push marketers to work in a more privacy-friendly way. In short: the era of freely dropping pixels and cookies is over; both lawmakers and browser vendors are moving toward stricter privacy.

The different types of cookies

Not every cookie is the same. Broadly, we distinguish a few categories, each with its own function and legal framework:

• Functional cookies: These are cookies that are needed for a website to function properly. Think of remembering products in a shopping cart or your language preference. Without these cookies, certain basic site functions would not work. Because functional cookies are only intended to provide the service you requested, the law considers them “necessary”. For placing purely functional cookies, a site does not need to ask for consent. As a visitor you mainly notice that the site works smoothly — you’re not constantly logged out and your settings are preserved. Functional cookies legally fall under the exception in the cookie law for strictly necessary cookies.
• Analytics (statistics) cookies: These cookies collect data about website usage, such as visitor counts and popular pages. Technically, they may track which pages you visit and for how long, often using a unique (anonymous) ID to recognize returning visitors. For visitors, analytics cookies are usually unobtrusive; you hardly notice them, except that the site owner may improve the website based on usage statistics. The legal side is often confusing: strictly speaking, not all analytics cookies require consent. If the privacy impact is very small — for example with purely internal statistics that do not, or barely, infringe on privacy — such a cookie may be placed without consent. In practice, this can mean that first-party analytics cookies with fully anonymized data sometimes can be used without a banner. But note: as soon as an analytics cookie can track a unique user over a longer period or across multiple sites, the privacy impact is no longer small. The AP clearly states that analytics cookies with unique identification or broad data visibility effectively become tracking cookies and then do require consent. Google Analytics is a well-known example: by default, GA sets cookies with a unique ID to distinguish visitors and track them across visits. Such cookies impact privacy and therefore do not fall under the exception — consent is needed (more on this later). In short: analytics cookies sit on the boundary. Limited and fully anonymized use may be possible without consent, but broader tracking for statistics legally falls under the same rules as tracking cookies.
• Marketing and tracking cookies: This is the category where most discussion happens. Tracking cookies follow individual browsing behavior and build profiles, often to offer targeted ads or personalized content. Think of cookies from advertising networks (such as Facebook Pixel, Google Ads) that register which sites or products you view, so you see targeted advertising elsewhere. What does a visitor notice? You visit a webshop, and later you see an ad for exactly that product on another site — that’s a tracking cookie at work. These cookies have a high privacy impact because they collect person-specific information about interests and behavior. Legally it’s clear: tracking cookies always require prior consent. There is no exception; they’re not strictly necessary to provide the service, so the user must explicitly say yes before they are set. The data also typically falls under the GDPR because it can often be linked back to individual users (via profile IDs, advertising IDs, etc.). And besides classic “cookies”, techniques like fingerprinting or tracking pixels also fall into this category — regardless of the technique, the effect is comparable and consent is required.
• Other tracking scripts and pixels: This category includes all kinds of other techniques for tracking users or collecting data, such as scripts that build a digital fingerprint of your device (fingerprinting), or pixels (invisible 1×1 images) that transmit information when they load. While technically different, they fall under the same legal rules as cookies: they are ways to read or store information on a device. In banners these are often grouped together with cookies as “tracking technologies”. The same rule applies: if it is strictly necessary for functional use or security, it may be used without a banner; in all other cases (analytics, marketing) consent is required. Browsers also increasingly restrict such techniques (for example by countering fingerprinting), precisely because they often track privacy-sensitive information without the user knowing.

What does the law say (in plain language)?

We keep talking about “the law”, but what do the cookie rules actually say? In the Netherlands, cookies fall under two overlapping legal frameworks:

1. The Dutch Telecommunications Act (ePrivacy): This is the implementation of the ePrivacy directive, also known as the “cookie law”. It essentially says: you may not store or read cookies or similar data on someone’s device unless the user has given prior, clearly informed consent. Exception: cookies that are strictly necessary for the service requested by the user (think functional cookies, as discussed above). That exception is interpreted narrowly — for example, login and shopping cart cookies are necessary, but a cookie that analyzes behavior for marketing is not. In the Netherlands it has additionally been indicated that some analytics cookies with minimal privacy impact may fall under the necessity exception. This is why some sites (with only basic analytics) choose not to show a banner. But anything that even slightly resembles tracking falls under the main rule: consent required.
2. The GDPR (General Data Protection Regulation): This is the privacy law that applies as soon as personal data is processed. Many cookies process personal data (think IP addresses, unique IDs linked to individuals, etc.). The GDPR states that every processing of personal data needs a legal basis (such as consent, contract performance, legitimate interest, etc.) and that transparency and security are required. With cookies, the GDPR effectively adds a second layer: first, setting the cookie must be legal under the Telecommunications Act, and then processing the collected data must be legal under the GDPR. Consent you obtain via the cookie banner in principle applies to both: you ask permission to place the cookie and to process the resulting data for a specific purpose. If a user refuses cookies (so gives no consent under the Telecommunications Act), you may not collect that data — which also removes the ability to claim you process that data under a different legal basis. It’s also important to realize that the GDPR’s one-stop-shop principle does not apply to ePrivacy matters. This means that if your website is accessible in multiple EU countries and your cookie setup is investigated, you may have to deal with each national regulator separately instead of one lead authority handling it.

Consent or another legal basis?

A common mistake is trying to rely on legitimate interest (a GDPR legal basis) instead of consent to set cookies without asking. This is misleading and usually unlawful. The Telecommunications Act requires consent for all cookies that are not strictly necessary — regardless of what the GDPR says about legal bases. So you can’t say: “We set a tracking cookie based on our legitimate interest, so we don’t need a banner.” That reasoning does not hold. The AP has explicitly indicated that for more invasive cookies such as tracking cookies, legitimate interest is not enough; the user must genuinely give consent (loosely translated from the AP’s guidance). Only if a cookie falls under the exception (so it has no or minimal privacy impact, such as certain functional cookies or strictly anonymous analytics), and personal data is still processed, can you potentially use legitimate interest as a legal basis for that data processing. Arnoud Engelfriet put it well: with cookies, “legitimate interest almost never works”, because the Telecommunications Act requires consent regardless of the GDPR legal basis. Only in the case of the Dutch exception for low-impact cookies can you place them without consent and then process the limited data under legitimate interest — but this nuance is often applied incorrectly in practice.

What do regulators explicitly reject?

Both national authorities and the EDPB (European Data Protection Board, where all EU privacy regulators cooperate) have made it clear which practices are absolutely unacceptable:

• Cookie walls (refuse = no access): Completely blocking a website for users who refuse cookies is not allowed. Consent must be freely given, which is not the case if refusing means you can’t use the site. The AP already stated in 2019 that websites must remain accessible even after refusing tracking cookies. A “take all cookies or you don’t get in” wall is therefore not acceptable — it is not a valid free choice.
• Pre-ticked choices: Consent requires a clear, active action by the user. A pre-ticked checkbox (where the user has to untick it to refuse) is not valid consent. This was confirmed by the European Court of Justice in the well-known Planet49 ruling in 2019. Yet we still see cookie settings where categories are “on” by default. That is not allowed: all non-essential cookies must be off by default until the visitor actively enables them.
• “Imbalanced” or misleading design: Often you see a big, prominent “Accept all cookies” button and somewhere hidden as a small text link an option like “Reject” or “Customize”. These design tricks — also called dark patterns — are not allowed. The user must not be subtly pushed toward accepting. If the first layer offers an option to accept all cookies, that same layer must also clearly offer an option to reject all non-essential cookies. That means an equivalent “Reject all” button next to or as prominent as “Accept all”. Also in terms of design (color, contrast, size), buttons/links may not be designed so that rejecting is unattractive or unclear. Regulators mention examples like a bright “Accept” button versus a gray, barely visible “Reject” link outside the banner frame — that undermines free choice.
• Incorrect labels (essential vs non-essential): Some banners shove almost all cookies under “functional” or “necessary”, giving the impression that everything is needed. Regulators scrutinize this. Only cookies that are truly indispensable for functionality requested by the user are strictly necessary. You can’t label a tracking cookie or marketing cookie as “functional” just because it improves rendering or generates revenue — those are not valid reasons. Make sure your cookie categories are correct, and that analytics or advertising cookies are not quietly labeled as “necessary”.
• Tracking before consent: A very practical pitfall: placing cookies or activating trackers before the user has made a choice. This happens, for example, when Google Analytics code or Facebook Pixel loads immediately on page load, without the banner being accepted. This is simply against the law. The AP has observed that many sites get this wrong: cookies are set on the first screen before any click has taken place. Consent must be obtained before placement, not after. Not “temporarily, we’ll delete it later if the user refuses” — no placement means no data collection before there is consent.
• Misleading texts or unclear information: Under the GDPR, consent must be informed. Vague or reassuring language that doesn’t match reality — such as “We use cookies for a better experience” without mentioning advertising tracking — is not enough. Visitors must understand in plain language what they agree to: which cookies, which data, for which purposes, and (at a high level) with whom it is shared. Many banners fail here by being too generic or by only showing key information after multiple clicks. So provide a clear explanation per category or cookie, preferably at a glance or via a “more info” toggle inside the banner.
• Misusing legitimate interest: As discussed above, we see banners that, next to “consent”, also show checkboxes for “legitimate interest” for certain cookies — often even pre-checked. This confuses users (“I see both consent and a legitimate interest toggle — what does this mean?”) and is legally shaky. You can’t mix two legal bases for the same processing, and for cookies that require consent, legitimate interest is not an alternative. The EDPB has indicated that relying on legitimate interest to, for example, create personalized ads or profiles is not acceptable in the context of cookies. In short: avoid offering a “legitimate interest” option in your banner unless you know exactly what you’re doing and it is legally correct. In most cases it’s a bad excuse to place cookies without a real opt-in, and regulators won’t accept it.

Why many cookie banners are not legally correct

We’ve outlined the rules — now the practice. Unfortunately, a large share of cookie banners on websites does not meet these requirements. Some common mistakes:

• Pre-filled consent: This remains a classic. Banners where certain cookie categories are already checked when the banner opens, or where a default “Accept all” implicitly applies unless you take action. As explained, this is not valid consent under both the GDPR and Court of Justice rulings. Yet pre-checked boxes still appear, often in lesser-known CMPs or custom implementations. This is easy to fix: make sure everything is off by default, except necessary cookies that you set anyway (and those shouldn’t be presented as an optional choice).
• “Accept” shouts, “Reject” whispers: A very common design choice is a bright or large “Accept all cookies” button while the option to reject is hidden as a small link or behind a “Cookie settings” button. This visually nudges users to click accept without thinking. This deliberate friction for rejecting is seen by the AP and other regulators as misleading. Such a banner is not aligned with the requirement of free choice. In France, for example, it has been explicitly stated that “Refuse” must be just as easy as “Accept”, otherwise fines follow — and this position is shared across the EU. If your banner only shows a prominent accept button, that’s a red flag.
• Unclear categories or language: Jargon or euphemisms can undermine a banner. Terms like “experience cookies” or “performance cookies” mean nothing to most users. Or banners that simply say “We use cookies. Do you accept? Yes/no” without further information — that’s too thin to count as “informed”. Also legally relevant: the purpose descriptions must be correct. Don’t incorrectly label a tracking cookie as “functional” to avoid consent. This kind of mislabeling is a known culprit. In 2019 the AP found that misleading cookie banners — such as incorrect categorization and lack of real choice — were widespread and started an enforcement campaign.
• Placing cookies despite refusal: A very problematic practice is when a user clicks “Reject” or “Only necessary cookies”, but the site still places analytics or marketing cookies. Sometimes this happens due to technical errors (the banner is there, but scripts load regardless of the choice), sometimes intentionally (“the user won’t notice”). We see this, for example, with some embedded external content: a YouTube video that places cookies as soon as it loads, even if the user hasn’t chosen anything yet. This not only undermines trust, it is also unlawful. If you promise that no tracking happens without consent, you must enforce that technically. That means testing. Verify that after refusing there are truly no Google Analytics hits, no marketing tags active, and so on. There are tools to scan your site for unwanted cookies. Many companies underestimate this — and get caught during inspections because cookies were still set before consent.
• Assuming “analytics” is always allowed without consent: As explained earlier, this is only half true. Yes, some analytics cookies can be set without consent, but only if they have virtually no privacy impact (e.g. anonymous first-party statistics). In practice, many websites use Google Analytics or similar tools that do track users across sessions via unique IDs. That does not fall under the exception, even if someone calls it “just analytics”. In 2022 the AP indicated that standard Google Analytics (Universal or even GA4) often cannot simply be used legally, partly due to data transfers to the US and user identification. In short: unless you have explicitly set up a cookieless, fully anonymized analytics solution, it is safer to ask consent for analytics. Many banners get this wrong by categorizing analytics as “necessary” or “no consent needed”, which does not match the regulator’s position.

In summary: legal mistakes with cookie banners come down to not taking the spirit of the law seriously: free, informed choice. Whether it’s design tricks or incomplete information, users (and the AP) are increasingly seeing through it.

What does a good cookie banner look like?

After all these pitfalls, the logical question is: what does a good cookie consent banner look like in 2024–2026? What complies with the rules and is still visitor-friendly? Here are the key characteristics:

• Honest and transparent: A good banner clearly communicates what you do and why. No misleading language, but terms an average SME owner or consumer understands. For example: “We use cookies for web statistics (to improve our site) and marketing (to show personalized ads). Please indicate what you give consent for.” Clear, to the point, no fine print. The AP emphasizes that cookie banners must be clear and honest. You don’t need a scare story, but you do need to be upfront.
• Fully opt-in, no sneaky opt-out: Anything that isn’t necessary is off until the user chooses. So by default, no tracking or analytics takes place unless and until consent is given. Technically this means: block all non-essential scripts and cookies until there is a “yes”. In the banner itself this means: no pre-checked boxes. The user actively turns any toggles on.
• Usability and equivalence: The banner must offer real choice in the simplest possible way. Concretely: on the first layer, show both an “Accept all” and a “Reject all” button, clearly and with equivalent styling. Also show an option to make more granular choices (e.g. “Settings” or “Choose per type”). Crucially, rejecting must not be hidden — visitors should be able to refuse all non-essential cookies in one click. This is not only a legal requirement by now, it’s also something users appreciate: a sense of control without pushy nudges.
• Only apply technology after consent: This is perhaps the most important practical property. A good cookie banner is connected to your technical implementation. That means: you don’t load tracking pixels, ad scripts, or an analytics library unless the user agrees (or only the categories that were enabled). There are different ways to achieve this. You can use a tag management solution (like Google Tag Manager) that “listens” for consent. Or you can use Google Consent Mode if you use Google Analytics/Ads: a special mode Google developed to make its tags behave appropriately based on consent. In basic blocking, Consent Mode ensures Google tags do nothing until consent is given. In an advanced mode, tags may load with consent state = denied, meaning they store no personal data and only send limited anonymized data to Google. In all cases: the banner and the underlying technology must go hand in hand. A banner that records “no” but still sets cookies is obviously worthless. Conversely, consent can mean those cookies are set from that moment on — but not earlier. This sometimes requires development work, but there are many ready-made Consent Management Platforms (CMPs) and open-source scripts that handle this. In any case, make sure your developer tests the mechanism with all cookies that appear on the site.
• Clarity about choices: Besides the extreme buttons (“all yes” or “all no”), it helps if users can indicate their preferences. For example, a screen where they can choose per category (Functional, Statistics, Marketing). But keep it clear: use understandable category names and give a short explanation per item. Avoid a maze of 12 separate categories with obscure names — that overwhelms most people. In many cases, 3 to 4 categories are enough. Some banners offer a button like “Only necessary” next to “Reject all” and “Accept all”. That’s fine, though with a clear “Reject all” it is arguably redundant (rejecting implies only necessary remains). The key is that the user should not be forced into unnecessary clicks or searching to refuse something. Keep it simple.
• Ability to review and withdraw: A good cookie implementation lets users change or withdraw their choice later without hassle. Legally, it must be just as easy to withdraw consent as it is to give it. In practice you can solve this by adding a small “cookie settings” link or button in the footer, or a persistent icon. That way someone who changes their mind (or clicked accept by accident) can easily adjust settings. Many CMPs provide this by default: a “Change cookie preferences” link that reopens the banner. Don’t forget: if someone withdraws consent, you must immediately stop processing that data and, for example, delete tracking cookies. You need to have that in place too.
• No penalty for refusal: If someone chooses not to accept (certain) cookies, respect that choice properly. A correct banner ensures the site remains usable. Perhaps some personalized content won’t work, but access to information or basic functionality must remain (no cookie wall). You can show users who refuse everything a neutral message instead of an embedded YouTube video (“Enable marketing cookies to watch this video”) — but don’t keep showing pop-ups to push them into accepting anyway. It’s about finding balance: as a site owner you have the right to monetize content, but the user has a right to privacy and access. A transparent approach (“You see generic instead of personalized ads because you refused marketing cookies”) builds understanding and trust.

Practical guidelines (summary)

Let’s list the key tips and points of attention. These do’s and don’ts help you move toward a correct cookie banner.

Minimum you should do

1. Map which cookies and trackers your site uses. You can only be compliant if you know exactly which cookies exist, what they do, and who they come from. Make a list of all cookies, including third-party ones (e.g. Google, Facebook, Hotjar, etc.).
2. Determine per cookie whether consent is required. Functional cookies and strictly anonymous statistics can be used without consent; everything else falls under consent. Unsure about a specific cookie? When in doubt, ask consent — better too much than too little, except for truly necessary items. Also document which basis you use for placing certain cookies (consent or exception).
3. Create a clear cookie statement. Describe per category (and ideally per cookie) what it does, what data is collected, with whom it is shared, and how long it remains. This is required for transparency. You can put details here so the banner itself can stay concise.
4. Implement a consent management solution. This can be a commercial CMP or a custom solution. What matters is that before consent is given, no unnecessary cookies are set, and after the choice the right cookies do/don’t load. Test this. For example, use your browser’s developer tools to inspect cookies and network traffic before and after clicking.
5. On the first visit, show a clear banner with at least two options: “Accept all” and “Reject all”, plus a link or button to detailed settings. Make sure the banner appears immediately on load and is prominent (but not so intrusive that it can’t be dismissed at all — cookie walls are not allowed).
6. Make rejecting easy. For example: give the “Reject” button the same styling as the “Accept” button (e.g. both as equivalent buttons). Also label it clearly (“Reject all” or “Only necessary cookies”) so the outcome is immediately clear.
7. Use plain language and avoid distractions. Keep the texts short and clear (“Choose your preferences”, “Non-essential cookies for… [purposes]”). Avoid marketing stories or threatening language. Also avoid technical abbreviations without explanation.
8. Respect and confirm the choice. If someone refuses, you can briefly confirm (“Your preference has been saved. You can now use the site with minimal cookies.”). Store the preference, preferably in a cookie that does nothing else (this preference cookie is functional and can remain for a reasonable period, e.g. 6 months so you don’t ask every time).
9. Provide a way to review. Place a “Cookie settings” link in the footer or a small icon so users can adjust their preference later. This is not only user-friendly but also a GDPR requirement (withdrawing consent must be as easy as giving it).
10. Keep a consent log (optional but sensible). Especially for larger sites it can be useful to keep track of how many people consented to what, so you can demonstrate consent during an audit. CMPs often do this automatically (with a timestamp, banner version, etc.).

Better avoid

• Pre-ticked checkboxes or implicit consent. Everything must be opt-in, so no tricks like “By visiting our site you agree to cookies” without an active click — the EDPB has declared this invalid.
• Only a notice without choices. A bar saying “We use cookies, click here to continue” is insufficient. There must be a choice if there are non-essential cookies. Informing alone is not enough if consent is required.
• Ignoring cookie banners because you think “I’ll get away with it”. Aside from potential fines (which can be substantial), you undermine visitors’ trust. The chances are high you’ll be forced to fix it later anyway (for example due to browser changes or enforcement).
• Settings that are too complex. As mentioned earlier, avoid 20 toggles and endless vendor lists that no one can make sense of. It backfires: people will just click “accept all” because it’s too complex. Keep it short on the surface.
• Using legitimate interest as an excuse. Don’t wrongly label cookies as “Based on legitimate interest” unless it truly applies and you can substantiate it. In most marketing cases it doesn’t, and it only creates confusion and risk.
• Tracking in embedded external content without a solution. Do you embed YouTube videos or social media feeds? Be careful: these services often set tracking cookies. You should ask before that content loads. Many CMPs offer solutions (e.g. a placeholder that loads the video only after consent). Don’t let third parties quietly set cookies outside your control — ultimately you are responsible as the website owner for what happens through your site.

Extra considerations for Google Analytics & Ads

Many Dutch websites use Google Analytics for statistics and Google Ads (or Facebook/LinkedIn Ads) for advertising and conversion measurement. These tools often raise questions:

• Can I use Google Analytics without cookies? With Analytics 4 and Consent Mode, Google has taken steps toward “cookieless” tracking. In Consent Mode you can set analytics_storage to denied until consent is given. That means GA4 doesn’t set or read cookies if someone does not agree. In that case Google will still register an anonymous hit and use modeling to provide aggregated statistics. However, even without cookies, GA still sends data (such as an IP address, which you can anonymize) to Google’s servers. So without cookies you may not need a cookie banner under the Telecommunications Act, but you still have GDPR aspects (personal data and potential transfers to the US). In early 2022 the AP ruled that standard Google Analytics can conflict with the GDPR due to transfers to the US, even with IP anonymization. A new EU–US data framework is being worked on and Google promises better protections, but it’s not certain. Bottom line: you can configure GA so cookies aren’t used before consent (recommended), but working entirely without a banner is only responsible if you are sure the analytics in use is truly fully anonymous. In practice it comes down to either asking consent for GA, or switching to an alternative that can be used without consent (for example a self-hosted solution that only uses anonymized data).
• Is a cookie banner always required? No. If your website only uses functional cookies and no tracking or external analytics, you don’t have to show a banner. In fact, adding banners “just in case” can be counterproductive. The law requires a banner only when consent is needed. So if you only have a login cookie and a cookie to remember a preference (e.g. language), that falls under strictly necessary and you can suffice with a good privacy/cookie statement without a pop-up. Also if you only set analytics cookies with negligible privacy impact (e.g. a simple visitor counter that stores no personal data), a banner is not required. In all other cases — especially marketing cookies, third-party tracking, or extensive analytics — you do need to ask consent and therefore need a banner. Unsure? Then you can opt for the smallest possible banner that only informs that you use only necessary cookies. But again: a banner is not a general obligation; it’s the means to obtain consent. No cookies that require consent = no banner.
• What if someone refuses? Then you respect it. Concretely: the site must keep working, but you don’t load optional cookies/trackers. The user might see more general content or a less personalized experience, but should still have access to everything essential. You may not refuse access to the site just because someone refuses cookies (see the cookie wall point). You can show alternative content (“We can’t load this map because you refused analytics cookies”) or generic ads instead of targeted ones. Crucially: don’t keep nagging for consent after every click. A common irritation is sites that show the banner again on every page or every visit after you clicked “reject”. Don’t do that. Store the refusal (e.g. in a cookie or in localStorage) so the user is not constantly bothered. It’s reasonable to remember a refusal for a few months. Only if something changes (for example you start using new cookies), or after some time (say 6–12 months), can you ask again. Asking someone who clearly said “no” every week could be seen as exerting pressure.
• Do I need to ask for consent again? In general, once given consent remains valid until the user withdraws it or until you change something about the cookies they consented to. You don’t need to ask on every visit (that would be user-unfriendly). Many organizations use a renewal period: for example, ask again yearly, or after 6 months for refusals to see if the user changed their mind. There is no strict legal period, but guidance often mentions 6 to 12 months as a reasonable timeframe. As a best practice you can, for example, show the banner again after 1 year to check if the visitor still agrees — and of course if someone deletes cookies you have to ask again on the next visit (because you no longer have a record of the earlier choice). You also need to ask again if the scope changes: say you add a new tracking service that wasn’t covered by the original consent; then you must ask separately for those new cookies. In summary: you don’t need to ask again constantly, but plan periodic moments (for example yearly) and be transparent about it in your statement. And of course, always let users change their choice themselves via settings at any time.

FAQ – Frequently asked questions

Can I use Google Analytics without cookies?

Answer: Yes, in a sense you can configure Google Analytics so no cookies are placed without consent. Google’s Consent Mode and GA4 settings make it possible to block tracking cookies until the user agrees. In that mode, Analytics works with minimal data: for example, no client-ID cookies are set, and Google uses statistical models to still provide insight into visitor counts and conversions. However, “without cookies” does not automatically mean “fully privacy-friendly” or “GDPR-free”. Even without cookies, GA sends data (such as a partially anonymized IP address and device information) to Google. That falls under the GDPR, and you still need a legal basis for it and may still need consent. In addition, Google Analytics has had issues around data transfers to the US; the AP and other European regulators ruled in 2022 that this was not in line with the GDPR. In short: cookie-less GA can remove the need for a cookie banner from a Telecommunications Act point of view, but you must be sure that the data used no longer contains personal data or is otherwise lawful. A truly safe approach is either to work with consent (show a banner for GA), or to use an alternative that collects no personal data at all. There are privacy-friendly analytics tools that work without cookies and without tracking (for example by only counting aggregated information). Those often work without a banner. But if you use Google Analytics in the regular way, the advice is: assume consent is needed, unless with expert help you’ve configured GA so it falls within the exceptions.

Is a cookie banner always required?

Answer: No — only if you use cookies or tracking technologies that require consent. If your website has no tracking cookies, no third-party analytics, and only necessary cookies, then a banner is not required. You do still need to inform visitors (for example via a privacy/cookie statement) about those necessary cookies, but you don’t need consent. So the banner is not a goal in itself; it’s the means to obtain consent when the law requires it. In other words: no consent needed = no banner needed. Many small websites that only have, for example, a contact form and a login cookie can easily operate without a banner. Only when you use things like Google Analytics, social media embed scripts, advertising trackers, or other non-essential cookies does the banner come into play. Unsure? Walk through the categories: functional and strictly necessary — no banner; limited and fully anonymous analytics — no banner needed (but mind the GDPR); everything else — banner needed. A rule of thumb: if you use marketing or personalization cookies, a banner is essentially always required.

What if someone refuses?

Answer: Then you must respect that choice and implement it. Concretely that means:

• Don’t activate tracking or marketing. Make sure that when someone refuses, all those scripts stay off. So don’t collect Google Analytics data (unless you run an anonymized variant without consent, but with a refusal the default is usually “nothing at all”), don’t load remarketing pixels, etc.
• Keep the site accessible. You may not punish the user for refusing. The website (or app) must still offer basic functionality and content. Some personalized things may be missing (for example “recommended for you” sections or personalized ads), but core content must remain available. That means: no cookie wall blocking access.
• Optionally show neutral replacements for content. If you have elements that truly can’t work without cookies (e.g. a YouTube embed), you can show an alternative. For example: “You refused cookies, so we can’t show this video. Adjust your preferences to watch it anyway.” That’s fine, because the user made that choice. What you may not do is keep showing pop-ups to push acceptance; once refused, refused means at least for a reasonable period (usually a refusal is remembered for a few months).
• Store the preference. Don’t forget to remember the refusal itself (e.g. via a functional cookie). Nothing is more annoying than getting the same question on every page because the site doesn’t know you already said “no”. You can set that preference cookie and it doesn’t need consent — it’s necessary to respect the refusal. Just make sure it doesn’t expire too quickly; 6 months is common so the user isn’t confronted again after a day.
• Offer alternatives where possible. This is more about being visitor-friendly: if someone refuses marketing, you could show generic ads instead of personalized ones so you still generate revenue without tracking. Or you can offer a paid version of your service (like some newspapers: no cookies if you subscribe). This is slightly beyond scope, but it fits the idea of not leaving refusers out in the cold.

In short: with refusal, “no means no”: no consent = no tracking. But keep providing the service as much as possible.

Do I need to ask for consent again?

Answer: In general you don’t need to ask again on every visit. Consent remains valid until it is withdrawn, or until something changes in the circumstances. It is common to let given consent remain valid for some time. Many sites use a 6 to 12 month period for the validity of consent. After that, you may proactively ask again to ensure the consent is still up to date. This is not a strict rule, but a best practice; for example, the French privacy authority recommended half a year for refusals and at most a year for given consents before renewing.

There are a few situations where you do need to ask again:

• Significant changes: if you add new cookies or purposes that were not covered by the original consent. For example: you started with only analytics, but now you want to use remarketing cookies — that needs to be presented separately.
• Changes in your privacy policy or responsible parties: for example, if your analytics data suddenly gets shared with a third party, or you switch to a very different advertising platform, it’s proper (and often required) to ask users to consent again under the new conditions.
• User withdrawal: if someone withdraws consent in the settings, you of course can’t start placing those cookies again on a later visit unless they consent again.

In practice you can approach it like this: store the consent status (for example in a cookie called consent_given=true) with a timestamp. Set a validity period, for example 12 months. If that period has passed, show the banner again to get a fresh confirmation. For refusals you can choose a shorter period if you want to try again, but be careful not to make it feel like harassment. Think ~6 months for another attempt. Communicate this in your privacy statement (“We store your choice for 6 months”).

Important: if the user deletes cookies or uses a different browser/device, you don’t have that historical info and you will of course show the banner again — that’s logical. Finally, keep an eye on developments: if new legal requirements appear (for example if the ePrivacy Regulation eventually changes timelines or rules), you need to adjust. For now, the approach above is generally accepted.

Wrap-up

Creating a good cookie consent banner may seem like a lot of work, but it comes down to transparency and respect for the visitor. In summary, we’ve seen that you can categorize cookies, that you need consent for most marketing and tracking tools, and that consent must be freely given, specific, and informed. By creating a banner that is clear, honest, and not pushy, you not only comply with GDPR and ePrivacy rules, you also build trust.

Don’t forget: privacy compliance is not just a legal checkbox exercise. It’s about users feeling in control of their data. A visitor who notices that your site handles cookies properly — for example because rejecting is easy and no sneaky trackers are running — is more likely to trust you and may later still allow certain cookies if they add value. Transparency and trust are more important than simply following the rules. In fact: if you act from those values, you’ll naturally comply.

Don’t see the cookie banner as an annoying obligation, but as an opportunity: an opportunity to show that your business is transparent and customer-focused. In an online world full of irritating pop-ups, your correct and user-friendly cookie consent banner can stand out in a positive way — and that is worth gold for both your visitor experience and your legal peace of mind.