Cookie Consent Banner DSGVO konform mit Alpine.js

1. Warum ein Cookie Consent Banner rechtlich mehr sein muss als ein Hinweis

Ein Cookie Consent Banner ist keine reine Design-Frage, sondern ein rechtlich bindendes Bauteil der Website. Nach DSGVO und TTDSG braucht jede Website, die nicht technisch notwendige Cookies oder Tracking-Skripte einsetzt, eine informierte, aktive und widerrufbare Einwilligung, bevor diese Skripte geladen werden. Ein Cookie Consent Banner, der nur einen Schließen-Button ohne echte Auswahl anbietet, erfüllt diese Anforderung nicht, selbst wenn er optisch professionell wirkt.

Der zentrale Unterschied zu einem simplen Hinweis-Banner: ein rechtskonformer Cookie Consent Banner muss granulare Kategorien anbieten, Ablehnung genauso leicht ermöglichen wie Zustimmung, und darf Skripte erst nach expliziter Einwilligung laden, nicht vorher mit nachträglichem Blockieren. Genau dieses Vorher-Nachher-Verhalten ist technisch der schwierigste Teil, und genau hier hilft Alpine.js, weil es reaktiven State direkt mit dem DOM verbindet, ohne dass ein schweres Consent-Management-Framework nötig wird.

In den folgenden Abschnitten entsteht ein vollständiger Cookie Consent Banner, der Kategorien trennt, Zustimmung im Browser speichert, Skripte gated nachlädt und dem Nutzer jederzeit erlaubt, seine Entscheidung zu ändern, ohne die Seite neu zu laden.

2. Kategorien statt Alles-oder-Nichts: der State des Banners

Ein rechtssicherer Cookie Consent Banner unterscheidet mindestens drei Kategorien: notwendige Cookies, die ohne Einwilligung geladen werden dürfen, Statistik-Cookies für Analyse-Tools, und Marketing-Cookies für Tracking-Pixel und Retargeting. Jede Kategorie braucht einen eigenen booleschen Wert im x-data Objekt, wobei die notwendige Kategorie fest auf true steht und nicht deaktivierbar ist, was im Markup auch visuell klar gemacht werden sollte, etwa durch eine deaktivierte Checkbox.

Zusätzlich zum eigentlichen Zustimmungs-State braucht ein Cookie Consent Banner einen Sichtbarkeits-State, der unterscheidet, ob überhaupt schon eine Entscheidung getroffen wurde. Ohne diese Trennung würde der Banner bei jedem Seitenaufruf erneut erscheinen, selbst wenn der Nutzer bereits entschieden hat. Der Sichtbarkeits-State wird beim Laden der Seite gegen den gespeicherten Consent geprüft, und der Banner erscheint nur, wenn noch keine gültige Entscheidung vorliegt.

// cookieConsent.js — Alpine.data component for the consent banner
document.addEventListener('alpine:init', () => {
  Alpine.data('cookieConsent', () => ({
    visible: false,
    settingsOpen: false,
    consent: {
      necessary: true,   // always true, not user-configurable
      statistics: false,
      marketing: false
    },

    init() {
      const stored = this.loadConsent();
      if (stored) {
        this.consent = { ...this.consent, ...stored };
        this.applyConsent();
      } else {
        // No decision on file yet — show the banner
        this.visible = true;
      }
    }
  }));
});

3. Zustimmung persistent speichern: localStorage und Ablaufdatum

Die Entscheidung eines Nutzers muss über Sitzungen hinweg gespeichert werden, sonst erscheint der Cookie Consent Banner bei jedem Besuch erneut, was Nutzer zu Recht als aufdringlich empfinden. localStorage ist dafür der richtige Speicherort, weil er im Gegensatz zu einem Session-Cookie über Browser-Neustarts hinweg erhalten bleibt. Wichtig ist, zusammen mit der Entscheidung selbst auch einen Zeitstempel zu speichern, damit die Einwilligung nach einer bestimmten Frist, üblicherweise zwölf Monate, automatisch abläuft und der Cookie Consent Banner erneut eingeholt wird.

Neben dem Ablaufdatum gehört auch eine Versionsnummer der Consent-Konfiguration in den gespeicherten Datensatz. Ändert sich die Liste der eingesetzten Kategorien oder Dienste, etwa weil ein neues Marketing-Tool hinzukommt, muss der Cookie Consent Banner erneut erscheinen, selbst wenn die vorherige Einwilligung noch nicht abgelaufen ist. Ein einfacher Versionsvergleich beim Laden entscheidet darüber, ob die gespeicherte Zustimmung noch gültig ist.

const CONSENT_VERSION = 2;
const CONSENT_KEY = 'cookie_consent_v1';
const CONSENT_TTL_DAYS = 365;

function loadConsent() {
  const raw = localStorage.getItem(CONSENT_KEY);
  if (!raw) return null;

  const parsed = JSON.parse(raw);
  const ageInDays = (Date.now() - parsed.timestamp) / 86400000;

  // Expired or outdated config version — treat as no decision
  if (ageInDays > CONSENT_TTL_DAYS || parsed.version !== CONSENT_VERSION) {
    return null;
  }
  return parsed.consent;
}

function saveConsent(consent) {
  localStorage.setItem(CONSENT_KEY, JSON.stringify({
    version: CONSENT_VERSION,
    timestamp: Date.now(),
    consent
  }));
}

4. Gated Script-Loading: Skripte erst nach Einwilligung nachladen

Der technisch kritischste Teil eines Cookie Consent Banner ist das eigentliche Gating der Skripte. Analytics- und Marketing-Skripte dürfen im HTML nicht als reguläres <script src="…"> Tag stehen, weil der Browser dieses sofort beim Parsen lädt, unabhängig von der Consent-Entscheidung. Stattdessen wird der Skript-Tag mit type="text/plain" deaktiviert und erst dynamisch per JavaScript aktiviert, sobald die passende Kategorie im Cookie Consent Banner zugestimmt wurde.

Alpine.js übernimmt dabei die Rolle des Vermittlers zwischen Consent-State und Skript-Aktivierung. Über einen watch auf die jeweilige Kategorie im x-data Objekt wird beim Wechsel von false zu true eine Funktion ausgelöst, die das entsprechende Skript-Element erzeugt und in den DOM einfügt. Wird eine Kategorie später widerrufen, muss zusätzlich sichergestellt werden, dass bereits gesetzte Cookies dieser Kategorie aktiv gelöscht werden, denn das reine Nicht-Nachladen neuer Skripte reicht für einen konformen Cookie Consent Banner nicht aus.

Alpine.data('cookieConsent', () => ({
  consent: { necessary: true, statistics: false, marketing: false },

  init() {
    // React to any change in consent state — activate or deactivate scripts
    this.$watch('consent.statistics', (value) => {
      value ? this.loadScriptsForCategory('statistics') : this.purgeCookiesForCategory('statistics');
    });
    this.$watch('consent.marketing', (value) => {
      value ? this.loadScriptsForCategory('marketing') : this.purgeCookiesForCategory('marketing');
    });
  },

  loadScriptsForCategory(category) {
    // Activate all gated <script type="text/plain" data-category="…"> tags
    document.querySelectorAll(`script[type="text/plain"][data-category="${category}"]`)
      .forEach((placeholder) => {
        const script = document.createElement('script');
        script.textContent = placeholder.textContent;
        placeholder.replaceWith(script);
      });
  },

  purgeCookiesForCategory(category) {
    // Explicit cookie removal — required, not optional, on withdrawal
    const cookieNames = category === 'statistics' ? ['_ga', '_gid'] : ['_fbp', '_gcl_au'];
    cookieNames.forEach((name) => {
      document.cookie = `${name}=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/`;
    });
  }
}));

5. Globaler Alpine Store für konsistenten Consent-Status

Sobald mehrere Komponenten auf der Seite den Consent-Status kennen müssen, etwa ein eingebettetes YouTube-Video und ein Marketing-Widget im Footer, reicht ein lokaler x-data State im Banner selbst nicht mehr aus. Ein globaler Alpine Store zentralisiert den Cookie Consent Banner Status, sodass jede Komponente auf der Seite denselben aktuellen Stand lesen kann, ohne dass Zustände dupliziert oder über Events synchronisiert werden müssen.

Der Store wird einmalig beim Laden der Seite initialisiert und bleibt danach die einzige Quelle der Wahrheit für den Consent-Status. Jede Komponente, die auf Zustimmung angewiesen ist, etwa ein eingebettetes Video, prüft direkt Alpine.store('consent').marketing, statt eine eigene Kopie des Zustands zu führen. Das verhindert, dass ein Cookie Consent Banner und ein Video-Embed unterschiedliche Vorstellungen vom aktuellen Einwilligungsstatus haben.

6. Widerruf jederzeit: das Einstellungs-Panel nach der ersten Entscheidung

Ein weiterer Aspekt, der bei der Store-basierten Umsetzung eines Cookie Consent Banner leicht übersehen wird, ist die Reihenfolge der Initialisierung. Der Store muss vor allen Komponenten, die auf ihn zugreifen, registriert werden, sonst wirft Alpine beim Seitenaufbau einen Fehler, weil Alpine.store('consent') noch undefined ist. In der Praxis bedeutet das, den Store-Aufruf im Layout möglichst früh im head oder direkt zu Beginn des body zu platzieren, deutlich vor eingebetteten Videos oder anderen Consent-abhängigen Widgets.

Die DSGVO verlangt ausdrücklich, dass ein Widerruf genauso leicht möglich sein muss wie die ursprüngliche Zustimmung. Ein Cookie Consent Banner, der nach der ersten Entscheidung komplett verschwindet und keinen Weg zurück bietet, verstößt gegen diese Anforderung. Die Lösung ist ein permanent sichtbarer, unaufdringlicher Link oder Button, meist im Footer platziert, der das Einstellungs-Panel des Banners jederzeit wieder öffnet.

Technisch handelt es sich dabei um dieselbe Komponente wie beim Erstbesuch, nur mit einem anderen Trigger. Statt automatisch beim fehlenden Consent zu erscheinen, wird der Cookie Consent Banner hier über einen expliziten Klick geöffnet, zeigt aber die zuvor gespeicherten Einstellungen vorausgefüllt an. Nach einer Änderung wird die neue Entscheidung wieder mit aktuellem Zeitstempel und Version gespeichert, exakt wie beim Erstbesuch.

// Reopen the same banner component via the footer settings link
Alpine.data('cookieConsent', () => ({
  visible: false,
  consent: { necessary: true, statistics: false, marketing: false },

  openSettings() {
    // Pre-fill with the previously stored decision, then show again
    const stored = this.loadConsent();
    if (stored) this.consent = { ...this.consent, ...stored };
    this.visible = true;
  },

  saveAndClose() {
    this.saveConsent(this.consent);
    this.visible = false;
  }
}));

7. Barrierefreiheit und Fokus-Management im Banner

Ein Cookie Consent Banner, der beim Erscheinen den Fokus nicht behandelt, ist für Tastatur- und Screenreader-Nutzer schwer bedienbar. Beim Öffnen sollte der Fokus explizit auf das erste interaktive Element im Banner gesetzt werden, meist den Alle-akzeptieren-Button oder den Link zu den Einstellungen. Solange der Banner sichtbar ist, sollte der Fokus per Fokus-Trap innerhalb des Banners gehalten werden, damit Tab-Navigation nicht versehentlich in dahinterliegende Seiteninhalte springt.

Zusätzlich sollte der Cookie Consent Banner mit role="dialog" und aria-modal="true" ausgezeichnet werden, wenn er den Rest der Seite blockiert, oder mit einer weniger aufdringlichen Rolle, wenn er nur als Leiste am unteren Rand erscheint und die Seite dahinter weiter bedienbar bleibt. Beide Varianten sind DSGVO-konform, solange die eigentliche Einwilligungslogik korrekt implementiert ist, die Wahl ist eine reine UX-Entscheidung.

<!-- Focus trap and dialog semantics for the visible banner -->
<div
  x-data="cookieConsent()"
  x-show="visible"
  x-trap.noscroll="visible"
  role="dialog"
  aria-modal="true"
  aria-label="Cookie Einstellungen"
>
  <button x-ref="acceptAll" @click="acceptAll()" autofocus>Alle akzeptieren</button>
  <button @click="settingsOpen = true">Einstellungen</button>
</div>

8. Nachweispflicht: Einwilligung protokollieren und versionieren

Im Streitfall muss ein Website-Betreiber nachweisen können, dass eine gültige Einwilligung vorlag, wann sie erteilt wurde und welche Kategorien konkret zugestimmt wurden. Ein Cookie Consent Banner, der die Entscheidung nur im Browser des Nutzers speichert, reicht für diese Nachweispflicht allein oft nicht aus, insbesondere bei größeren Websites mit rechtlichem Risiko. Ergänzend empfiehlt sich, die Entscheidung optional und anonymisiert auch serverseitig zu protokollieren, etwa mit einem Hash des Nutzers, Zeitstempel und gewählten Kategorien.

Die Versionierung der Consent-Konfiguration selbst, wie in Abschnitt drei beschrieben, ist ebenfalls Teil der Nachweispflicht. Wird eine neue Kategorie oder ein neuer Dienst eingeführt, muss nachvollziehbar sein, ab welchem Zeitpunkt welche Version des Cookie Consent Banner aktiv war und welche Nutzer unter welcher Version zugestimmt haben.

9. Cookie Consent Lösungen im direkten Vergleich

Für die Umsetzung eines Cookie Consent Banner gibt es mehrere gängige Wege, mit deutlichen Unterschieden bei Kosten, Kontrolle und technischer Integration.

Der Vergleich zeigt: ein selbst gebauter Cookie Consent Banner mit Alpine.js vermeidet laufende Lizenzkosten eines SaaS-CMP und bietet gleichzeitig volle Kontrolle über Design und Ladeverhalten, ohne dass ein zusätzliches, extern gehostetes Skript in die Content Security Policy aufgenommen werden muss.

10. Zusammenfassung

Ein DSGVO konformer Cookie Consent Banner braucht klar getrennte Kategorien, eine echte Vorher-Entscheidung statt nachträglichem Blockieren, persistente Speicherung mit Ablaufdatum und Versionierung sowie einen jederzeit erreichbaren Weg zum Widerruf. Mit Alpine.js entsteht ein solcher Cookie Consent Banner ohne teures CMP-Abo, dafür mit voller Kontrolle über Design, Ladeverhalten und Datenschutzlogik.

Technisch entscheidend ist das gated Script-Loading: Skripte dürfen erst nach expliziter Zustimmung aktiviert werden, und bei Widerruf müssen bereits gesetzte Cookies aktiv entfernt werden. Ein globaler Alpine Store hält den Consent-Status für alle Komponenten der Seite konsistent, von eingebetteten Videos bis zu Marketing-Widgets. Barrierefreiheit und eine nachvollziehbare Protokollierung runden einen produktionsreifen Cookie Consent Banner ab.

11. FAQ: Cookie Consent Banner DSGVO konform mit Alpine.js