In a headless CMS architecture, cookie consent belongs to the frontend, not the CMS. The content API that serves your pages rarely sets cookies at all - the consent banner, the script blocking and the record of each visitor's choice all live in the presentation layer your team builds and deploys separately from the content backend.
That one architectural fact drives every practical decision that follows: where the banner is injected, who gates the embeds editors paste into rich text, and how a refusal actually stops trackers across a decoupled stack.
The public delivery APIs of Contentful, Strapi, Sanity and similar platforms are typically cookieless; tracking enters through the frontend build, tag managers, embeds and personalisation SDKs.
Article 5(3) of the ePrivacy Directive is technology neutral - the EDPB confirmed in 2024 that it covers local storage and other client-side storage mechanisms that headless frontends use heavily.
Embeds pasted into rich text are a compliance decision executed by your renderer, and the Court of Justice of the EU's Fashion ID ruling makes the site operator jointly responsible for what those embeds transmit.
Preview cookies such as the Next.js
__prerender_bypasscookie are strictly necessary for the service the editor requested and do not need consent, but a publicly reachable staging site still needs a banner.Consent withdrawal must actually stop trackers: the French CNIL fined American Express Carte France EUR 1.5 million in November 2025 partly because trackers kept operating after visitors said no.
Why Is Cookie Consent Different in a Headless CMS?
A headless CMS separates content storage from presentation, so consent tooling that assumes a monolithic platform - a WordPress plugin, a Shopify app, a theme snippet - has no slot to occupy. Consent becomes part of your frontend codebase: a dependency you install, configure and ship like any other.
The pattern is the same whether the backend is Contentful, Storyblok, Sanity, Strapi, Prismic or WordPress running headless over the REST API or WPGraphQL. Content is fetched as JSON and rendered by a framework such as Next.js, Nuxt, Astro or SvelteKit. The CMS admin panel where editors work and the page a visitor receives are two different applications that may never share a domain.
The legal obligations do not change. The ePrivacy Directive and the General Data Protection Regulation (GDPR) apply to what happens in the visitor's browser, wherever the HTML was assembled. Article 5(3) of the ePrivacy Directive requires prior consent before information is stored or read on a user's device unless the operation is strictly necessary for a service the user explicitly requested. What changes in a headless setup is who can implement that rule. The CMS can't do it. Only the frontend can.
Who Actually Sets Cookies in a Headless Stack?
Responsibility splits across layers, and each layer has a different consent status. Public content delivery is usually storage-free, preview tooling relies on strictly necessary cookies, and everything visitors would recognise as tracking arrives through scripts and embeds that the frontend chooses to load.
| Layer | Typical storage | Consent status |
|---|---|---|
| CMS delivery API (published content) | Usually none - anonymous requests authenticated by API token | Nothing stored on the device, so no consent question arises |
| CMS preview and draft mode | __prerender_bypass (Next.js), CMS preview session cookies | Strictly necessary for the preview the editor requested |
| Frontend application | Session IDs, CSRF tokens, language preference | Security tokens are exempt; preference cookies often need consent in the EU |
| Analytics and tag managers | _ga, tags injected by Google Tag Manager | Consent required before firing |
| Embeds inside rich text | YouTube, Vimeo and social media identifiers | Consent required before the iframe loads |
| Personalisation SDKs from the CMS vendor | Audience and experiment identifiers, often in local storage | Consent required |
The delivery layer deserves a closer look, because it explains why the CMS itself is rarely the problem. Published content is fetched over a CDN with a read-only token in the request headers or the URL. No Set-Cookie header, no browser state. That design is deliberate: cacheable, anonymous responses are what make headless delivery fast.
Storage beyond cookies is where headless frontends need the most attention. Framework code and vendor SDKs lean on local storage and session storage for identifiers, experiment assignments and consent state itself. The EDPB's Guidelines 2/2023, adopted in final form in October 2024, confirm that Article 5(3) covers these mechanisms too - the rule protects the terminal equipment, not one particular storage API. An identifier written to local storage by a personalisation SDK needs the same prior consent as a tracking cookie.
Where Does the Banner Live When There Is No Theme?
The consent layer belongs in the root layout of the frontend application - the shared shell that wraps every route. Load the consent management platform (CMP) script there, before any script capable of writing to the device, so the default state is applied ahead of anything it needs to control.
Placement order matters more in a headless build than in a monolith, because you assemble the document yourself. There's no platform quietly injecting a compliance layer for you. The CMP script, the default-deny configuration and the logic to conditionally load third-party scripts are all code you own, reviewed in the same pull requests as the rest of the frontend.
Verification has to target the right artefact. Run a cookie scanner against the deployed frontend URL, not the CMS admin, and re-run it when the frontend dependencies change - a framework upgrade or a new SDK can alter what loads before consent even when no editor touched the content.
How Do You Control Embeds That Editors Paste into Rich Text?
The renderer is the enforcement point. An editor drops a video URL into a rich text field in the CMS; whether that becomes a tracking iframe or a consent-gated placeholder is decided entirely by the component your frontend maps to that node. The compliance decision has moved from the person writing the content to the code rendering it.
That transfer of responsibility carries legal weight. In Fashion ID (Case C-40/17), the Court of Justice of the EU held that a website operator embedding a third-party component is a joint controller for the collection and transmission of visitor data that the embed triggers. You can't point at the editor, and you can't point at the video platform. The site that ships the iframe answers for it.
The practical pattern is a facade. Rich text renderers in headless setups - Sanity's Portable Text serialisers, Storyblok's resolvers, Contentful's rich text mappers - let you intercept embed nodes and render a placeholder component instead of the raw iframe. The placeholder shows a thumbnail and a notice; the real embed loads only after the visitor grants the relevant category. This matters even for the privacy-enhanced player, because YouTube embeds in nocookie mode still write identifiers to local storage the moment the page loads.
One structural improvement pays for itself here: model embeds as dedicated content types rather than free-form HTML. A structured video field tells every renderer exactly what it's dealing with; a raw HTML field forces each channel to parse and guess.
Do Preview and Draft Cookies Need Consent?
No - when they exist solely to deliver the draft content the editor asked to see, they fall squarely under the strictly necessary exemption in Article 5(3). The editor clicked a preview link; the cookie is what makes the requested service work.
Next.js draft mode is the clearest example. According to the Next.js documentation, enabling draft mode sets an HttpOnly cookie named __prerender_bypass, and requests carrying it skip the static cache so the page fetches the latest draft from the CMS. A new cookie value is generated on each build so it can't be guessed. Sanity, Contentful and DatoCMS preview integrations all ride on this mechanism or set equivalent preview session cookies of their own.
Two caveats stop this from becoming a blanket pass. Staging and preview environments that are publicly reachable often run the same analytics configuration as production, and an editor's device is protected terminal equipment like anyone else's - so a staging site that loads trackers needs a banner too. And exempt does not mean invisible: preview cookies still belong in your cookie policy, categorised as necessary.
How Does Consent Survive Static Generation and Edge Caching?
Consent is evaluated in the visitor's browser, or at the edge, never baked into cached HTML. A statically generated page is one artefact served to everyone, so the shipped bundle must default to denied and upgrade client-side after a choice - varying pre-rendered HTML on a consent cookie risks a CDN serving one visitor's variant to another.
This is where Google Consent Mode v2 fits a headless build: the default denied state is set in the shipped JavaScript before the tag loads, and the update call fires after the visitor decides. Because the decision lives client-side, it survives incremental static regeneration and CDN purges without any server round trip.
Geography is the one thing worth resolving before the page renders. Edge middleware can read the request's region and decide which banner regime applies - opt-in for an EU visitor, a different model elsewhere - without touching the cached content itself. Kukie.io handles this with geo-detection at request time, serving the matching consent model per region. Teams moving analytics off the client entirely should note that server-side tagging changes where tags execute, not whether consent is needed for the identifiers they rely on.
What About Channels Beyond the Browser?
A headless content model feeds more than websites - the same entries render in native apps, kiosks and smart displays. Article 5(3) follows the content, because it protects terminal equipment of any kind, a point the EDPB's 2024 guidelines make explicit for connected devices well beyond the desktop browser.
Each channel needs its own consent surface. A native app pairs regional consent requirements with platform rules such as Apple's App Tracking Transparency prompt for cross-app tracking. A kiosk in a shop window can't rely on a cookie banner designed for a mouse. The content stays shared; the consent implementation does not.
Structured content helps here as well. If the model records which entries carry third-party media or tracking-capable components, every channel's renderer can make the gating decision from data instead of parsing HTML strings and hoping.
Withdrawal Has to Reach Every Layer
A visitor who withdraws consent must see trackers actually stop - recording the changed preference while tags keep firing is itself a violation. The CNIL made that explicit when it fined American Express Carte France EUR 1.5 million in November 2025 under Article 82 of the French Data Protection Act, the national transposition of the ePrivacy rules.
Enforcement pressure is not easing. As of August 2026, the CNIL's annual report counts 83 sanctions totalling roughly EUR 486.8 million for 2025, with cookie and tracker violations - including the EUR 325 million Google decision - accounting for a large share of that figure.
In a decoupled frontend, withdrawal is a state propagation problem. The banner writes the new decision, and every consumer of that decision - the tag manager, the embed facades, any SDK holding identifiers - has to react without a full page load. Client-side routing makes this harder than it sounds; managing consent state in a single-page application is its own discipline of subscriptions, storage events and route change checks. Test the withdrawal path with the same rigour as the acceptance path: open the network tab, revoke, and watch what still fires.
Frequently Asked Questions
Does a headless CMS set cookies on my website?
The public delivery APIs of platforms like Contentful, Strapi and Sanity generally do not - they authenticate with API tokens, not browser cookies. Cookies enter through preview modes, embedded assets, tag managers and vendor personalisation SDKs, so scan the deployed frontend to see what actually loads.
Do I still need a cookie banner on a fully static site?
Yes, if any script or embed stores or reads information on the visitor's device. Static generation changes where the HTML is built, not what runs in the browser once it arrives.
Is the Next.js draft mode cookie exempt from consent?
Yes. The __prerender_bypass cookie exists only to deliver the draft content the editor explicitly requested, which fits the strictly necessary exemption in Article 5(3) of the ePrivacy Directive. It should still be documented in your cookie policy.
How do I stop YouTube embeds from setting cookies before consent?
Gate them in the renderer: replace the iframe with a placeholder until the visitor grants the relevant category, then load the embed. Privacy-enhanced mode alone is not enough, because it still writes identifiers to local storage on page load.
Can the CMS inject the consent banner instead of the frontend?
Not in a decoupled setup. The CMS never touches the page that reaches the visitor's browser, so anything that must run client-side - the banner, script blocking, consent storage - has to ship with the frontend build.
Scan the Frontend Your Visitors Receive
If your stack is decoupled, your compliance surface is the deployed frontend - the CMS admin will always scan clean. Kukie.io scans the site your visitors actually receive, categorises what it finds, and blocks non-essential scripts and embeds until consent is given, with geo-detection to match the rules of each visitor's region.
