Ghost is unusual among publishing platforms: its own analytics doesn't need a cookie banner. The native web analytics that shipped with Ghost 6.0 in August 2025 is fully first-party and cookie-free. It counts unique visitors in 24-hour windows without persistent browser storage, and Ghost states plainly that "web analytics in Ghost are cookie-free, and therefore do not require the use of a cookie banner when enabled" (Ghost native analytics).

So where does consent come in? The instant you add anything else, Google Analytics, a Meta pixel, Disqus comments, an embedded video, a chat widget, you're setting third-party cookies that GDPR and ePrivacy require consent for. Most of those get added through Ghost's Code Injection, and Code Injection runs on every page with no gating of its own. That gap is yours to close.

What Ghost sets without your help

Two things worth knowing before you add a banner. First, native analytics: cookie-free by design, served through your own domain, with IP addresses and user agents anonymized (Ghost analytics privacy). If that's your only measurement, you may not need a banner at all in some jurisdictions, though you should still document it in a privacy notice. Second, membership: if you use Ghost's Portal for paid or free subscriptions, logged-in members carry a session cookie. That's a strictly necessary functional cookie, not something consent is required for, but it does belong in your cookie policy.

How Code Injection works

Ghost's Code Injection lives under Settings › Advanced › Code Injection and has two fields. Code in Site Header is output inside the <head> of every page (rendered by the theme's {{ghost_head}} helper). Code in Site Footer is placed just before the closing </body> tag (via {{ghost_foot}}). There's also per-post injection in each post's settings, for a script you only want on one page. Anything you add here appears site-wide without editing theme files.

Where the consent loader goes

Paste the loader into Site Header, and make it the first thing there, before any analytics or pixel snippet you've added. Order matters: the consent script has to run before the tags it's meant to hold back.

<!-- Settings > Advanced > Code Injection > Site Header (FIRST) -->
<script async src="https://cdn.cookiebeam.com/banner/YOUR_BANNER_ID/default/loader.js"></script>

Replace YOUR_BANNER_ID with your banner's public ID from the dashboard.

Block trackers until consent

Any tracker you've dropped into Site Header runs on load. To gate it, load it disabled and let the consent runtime switch it on. CookieBeam activates scripts tagged type="text/plain" with a data-category once the visitor accepts that category:

<!-- Site Header, after the loader -->
<script
  type="text/plain"
  data-category="analytics"
  data-cookiebeam-managed="true"
  src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX">
</script>

The browser skips a text/plain script until consent is granted, so a rejected visit loads nothing. See how to block scripts before consent for the technique.

The usual sources of cookies on a Ghost site

Publishers tend to add the same handful of tools, and every one of these needs to wait for consent:

Google Analytics 4 and GTM: the most common addition, route it through the blocking pattern above.
Meta, LinkedIn, or X pixels: marketing tags that set cookies on load.
Disqus or other third-party comments: these embed their own tracking. Ghost's built-in comments are a cookie-free alternative for members.
Embedded YouTube or Vimeo: use the privacy-enhanced (no-cookie) embed, or gate the embed.
Newsletter and ad network scripts: if you monetize, see the publisher consent and ad revenue guide.

Consent Mode v2 with GTM

If you run Google Ads or GA4 for EEA or UK readers, Consent Mode v2 has been required since March 2024. Set defaults to denied in Site Header before GTM loads, then let the banner push the update on acceptance:

<!-- Site Header, after the loader -->
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent', 'default', {
    ad_storage: 'denied',
    analytics_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied',
    wait_for_update: 500
  });
</script>
<!-- GTM container snippet goes here -->

CookieBeam applies these defaults and fires the update call for you. If tags misfire, the Consent Mode v2 troubleshooting guide lists the common causes.

Policy and testing

Publish a cookie policy page in Ghost and link it from the banner and footer. List the native session cookie, plus whatever third-party tools you've added. A scanner keeps that table current so it doesn't drift every time you add an embed (scanning versus manual audits). Then test:

Open a fresh private window from an EU IP and check the Application › Cookies panel before you click. Only necessary cookies should exist.
Reject, and confirm no _ga or _fbp appears and no beacons fire.
Accept, and confirm the tags load and Consent Mode reports granted.

CookieBeam blocks unknown scripts by default and keeps a timestamped consent record, so a Ghost site clears the same audit a purpose-built platform would, without touching theme code. Not sure whether you even need a banner yet? Start with do I need a cookie banner.