Impressum und Datenschutzerklärung: Was deine EmDash-Site vor dem Launch braucht

Am Ende von Kevins Einstiegsartikel läuft deine Site auf Cloudflare, und der erste Beitrag ist veröffentlicht. Bevor du die Adresse an Freunde, Kunden oder in die Welt schickst, kommt meist eine Frage: Darf ich die so online stellen, oder fehlt da noch etwas?

In Deutschland und der Schweiz fehlen fast immer zwei Seiten, das Impressum und die Datenschutzerklärung. In diesem Artikel kläre ich zuerst, wann welche Pflicht greift. Dann legst du beide Seiten in EmDash an und verlinkst sie im Footer, ohne eine Zeile Code. Zum Schluss gehe ich durch, welche Daten eine EmDash-Site auf Cloudflare wirklich verarbeitet, denn genau das muss in der Datenschutzerklärung stehen. Als Beispiel dienen unsere eigenen Seiten hier auf The Weekly Dash.

Vorweg das Wichtigste: Ich bin kein Anwalt, und das hier ist keine Rechtsberatung. Ich nenne dir die Vorschriften, damit du sie selbst nachlesen kannst, und sage dir, wo die Antwort nicht eindeutig ist. Für eine Site, mit der du Geld verdienst, lass die Texte von jemandem prüfen, der das beruflich macht.

Die Schritte im Adminbereich bin ich mit EmDash 1.1.0 auf einer frischen Blog-Vorlage für Cloudflare durchgegangen, angelegt mit npm create emdash@latest. Die Screenshots stammen aus dieser lokalen Site, der zu den Übersetzungen aus einer Kopie, in der ich zusätzlich Deutsch und Englisch als Sprachen eingerichtet habe.

Brauche ich das überhaupt?

Für das Impressum lautet die Antwort in Deutschland fast immer ja. In der Schweiz hängt es davon ab, ob du etwas anbietest. Eine Datenschutzerklärung brauchst du in beiden Ländern praktisch immer.

Das Impressum in Deutschland

Zwei Vorschriften verlangen eine Anbieterkennzeichnung, und sie greifen unterschiedlich weit.

§ 5 DDG gilt für „geschäftsmäßige, in der Regel gegen Entgelt angebotene“ digitale Dienste. Das Digitale-Dienste-Gesetz hat im Mai 2024 das Telemediengesetz abgelöst, die Pflicht stand vorher fast gleich in § 5 TMG. Geschäftsmäßig ist deine Site schnell. Es reicht, wenn sie für dein Unternehmen oder deine Selbstständigkeit wirbt, Werbung zeigt, Affiliate-Links enthält oder gesponserte Beiträge bringt. Dann gehören hinein:

• dein Name und eine Anschrift, unter der du niedergelassen bist, also kein Postfach,
• eine E-Mail-Adresse und ein zweiter schneller Weg, mit dir in Kontakt zu treten,
• bei einer Firma die Rechtsform, die vertretungsberechtigte Person und, je nach Fall, Registereintrag, Umsatzsteuer-ID und weitere Angaben.

Für den zweiten Weg reicht in der Regel ein Kontaktformular, eine Telefonnummer musst du nicht angeben (EuGH, Urteil vom 16. Oktober 2008, C-298/07). Bei uns sind es die E-Mail-Adresse und das Kontaktformular.

§ 18 Abs. 1 MStV reicht weiter. Der Medienstaatsvertrag verlangt Name und Anschrift von allen Anbietern, deren Angebot „nicht ausschließlich persönlichen oder familiären Zwecken“ dient. Ein Blog, den jeder lesen kann, dient in aller Regel nicht mehr nur deiner Familie. Damit brauchst du auch für einen privaten Blog ohne einen Cent Einnahmen deinen Namen und deine Anschrift auf der Site. Ausgenommen ist zum Beispiel ein passwortgeschütztes Familienblog.

§ 18 Abs. 2 MStV kommt bei „journalistisch-redaktionell gestalteten Angeboten“ dazu. Dann nennst du zusätzlich eine verantwortliche Person mit Name und Anschrift. Wo genau ein Blog journalistisch-redaktionell wird, ist nicht scharf definiert. Schreibst du regelmäßig Artikel zu aktuellen Themen, rechne damit. Wir nennen auf The Weekly Dash deshalb eine verantwortliche Person.

Wie das Impressum zu finden sein muss, steht in beiden Vorschriften gleich: „leicht erkennbar, unmittelbar erreichbar und ständig verfügbar“. Der Bundesgerichtshof hat 2006 entschieden, dass ein Link mit der Aufschrift „Impressum“ oder „Kontakt“ reicht und zwei Klicks bis zu den Angaben in Ordnung sind (BGH, Urteil vom 20. Juli 2006, I ZR 228/03). In der Praxis heißt das: ein Link im Footer, und zwar auf jeder Seite.

Das Impressum in der Schweiz

Die Schweiz kennt keine allgemeine Impressumspflicht. Art. 3 Abs. 1 lit. s UWG verlangt „klare und vollständige Angaben“ über Identität und Kontaktadresse samt E-Mail nur von denen, die im elektronischen Geschäftsverkehr Waren, Werke oder Leistungen anbieten. Ein Shop, eine Agentur-Website oder ein Blog, über den du Workshops verkaufst, fällt darunter. Ein reiner Hobbyblog nicht.

Ein kurzes Impressum schadet trotzdem nicht. Die Datenschutzerklärung muss ohnehin sagen, wer verantwortlich ist und wie man dich erreicht. Bei The Weekly Dash sitzt Kevin in der Schweiz und ich in München, wir richten uns deshalb nach dem deutschen Recht.

Die Datenschutzerklärung

Hier ist die Antwort kürzer. Sobald jemand deine Site aufruft, verarbeitet dein Hoster seine IP-Adresse, und die gilt als personenbezogenes Datum (EuGH, Urteil vom 19. Oktober 2016, C-582/14, Breyer). Die Ausnahme für rein persönliche oder familiäre Tätigkeiten in Art. 2 Abs. 2 lit. c DSGVO hilft dir bei einer öffentlichen Website nicht. Der EuGH hat schon 2003 entschieden, dass eine Veröffentlichung im Internet für unbegrenzt viele Menschen nicht darunter fällt (Urteil vom 6. November 2003, C-101/01, Lindqvist).

Also musst du die Leute informieren. In der EU verlangt das Art. 13 DSGVO: wer verantwortlich ist, welche Daten zu welchem Zweck und auf welcher Rechtsgrundlage verarbeitet werden, wer sie bekommt, ob sie in ein Drittland gehen, wie lange sie gespeichert bleiben und welche Rechte die Besucher haben. In der Schweiz verlangt Art. 19 DSG seit dem 1. September 2023 Ähnliches, etwas schlanker: Identität und Kontakt des Verantwortlichen, Zweck, Empfänger und, wenn Daten ins Ausland gehen, den Staat und die Garantien dafür.

Betreibst du die Site aus der Schweiz und richtest dich an Leser in der EU, kann zusätzlich die DSGVO gelten. Eine Erklärung, die beides abdeckt, ist dann der einfachste Weg. So haben wir es gemacht.

Die beiden Seiten in EmDash anlegen

In EmDash sind Impressum und Datenschutzerklärung ganz normale Einträge im Inhaltstyp Pages, den die Blog-Vorlage mitbringt. Der Eintrag heißt auch im deutschen Adminbereich „Pages“, weil die Bezeichnung aus der Vorlage kommt und nicht übersetzt wird.

Unter Inhalt → Pages klickst du auf Neu hinzufügen. Der Editor heißt dann „Page erstellen“. Ins Feld Title schreibst du „Impressum“, darunter unter Content den Text. Rechts unter URL & Sprache füllt EmDash den Slug aus dem Titel, hier impressum.

Den Text schreibst du entweder direkt in den Editor oder kopierst ihn aus einem Generator oder einer Vorlage deines Anwalts. Zwischenüberschriften setzt du mit dem H-Knopf in der Werkzeugleiste oder tippst am Anfang einer Zeile ## und ein Leerzeichen. Kopierst du Text hinein, nimm ihn aus einer gerenderten Ansicht, also aus dem Browser oder einer Markdown-Vorschau. Markdown-Zeichen wandelt der Editor beim Einfügen nicht in Formatierungen um.

Dann klickst du oben rechts auf Speichern. Erst danach erscheint der Knopf Jetzt veröffentlichen. EmDash fragt noch einmal nach („Dieser Inhalt ist sofort auf der Website sichtbar.“), und mit Jetzt veröffentlichen im Dialog ist die Seite online.

Bei der Datenschutzerklärung musst du beim Slug aufpassen. Aus dem Titel „Datenschutzerklärung“ macht EmDash datenschutzerklärung, mit Umlaut. Das funktioniert, sieht aber in der Adresszeile kodiert aus und ist schlecht abzutippen. Ich trage deshalb datenschutz von Hand ein, bevor ich speichere. Den Slug kannst du später zwar noch ändern, dann brechen aber Links, die schon draußen sind.

Wo die Seiten liegen

Die Blog-Vorlage liefert Seiten unter /pages/ aus. Das URL-Muster des Inhaltstyps ist /pages/{slug}, und die passende Astro-Route liegt in src/pages/pages/[slug].astro. Dein Impressum steht also unter /pages/impressum, die Datenschutzerklärung unter /pages/datenschutz. Rechtlich ist das völlig in Ordnung, denn es zählt der Link, nicht die Adresse.

Hier auf The Weekly Dash liegen die Seiten direkt unter /impressum und /datenschutz, weil wir die Vorlage umgebaut haben. Wenn du das auch willst, brauchst du eine eigene Route und ein anderes URL-Muster, also Code. Wie das grundsätzlich geht, zeige ich im Artikel Dein erster eigener Inhaltstyp.

Eine englische Fassung

Für eine deutsche Site ist ein deutsches Impressum genug. Hast du eine zweisprachige Site, legst du die englischen Seiten als Übersetzungen an. Das geht aber erst, wenn deine Site mehrsprachig ist. EmDash liest die Sprachen aus der i18n-Konfiguration von Astro, und in der Blog-Vorlage ist die nicht eingerichtet. Wie du die Vorlage mehrsprachig machst, ist ein eigenes Thema.

Ist sie es, steht im Editor rechts der Bereich Übersetzungen. Neben jeder fehlenden Sprache findest du Übersetzen. EmDash legt dann einen neuen Eintrag in dieser Sprache an und kopiert Inhalt und Slug des Originals. Den Slug änderst du unter URL & Sprache, bei uns heißen die englischen Seiten legal-notice und privacy. Das geht, weil ein Slug nur pro Sprache eindeutig sein muss.

Über unsere englische Datenschutzerklärung haben wir einen Satz gesetzt, dass bei Abweichungen die deutsche Fassung gilt. So musst du nicht zwei Texte juristisch gleich wasserdicht halten.

Von jeder Seite aus erreichbar: der Link im Footer

Die Seiten sind online, verlinkt sind sie noch nirgends. Die Blog-Vorlage hat dafür zwei Stellen, die du ohne Code füllen kannst.

Die erste ist die Spalte „Navigate“ im Footer. Sie zeigt das Menü Primary Navigation, und genau dieses Menü steht auch in der Kopfzeile. Fügst du Impressum und Datenschutzerklärung dort hinzu, stehen sie oben neben Home, About und Posts. Das ist erlaubt, aber für die meisten Sites zu prominent.

Die zweite Stelle ist der Widget-Bereich Footer. Dort steht in der Vorlage der kurze „About“-Text, und dort habe ich ein eigenes Menü für die beiden Seiten eingehängt. Das sind zwei Schritte.

Ein Menü „Rechtliches“

Unter Verwalten → Menüs klickst du auf Menü erstellen. Als Bezeichnung trägst du „Rechtliches“ ein, als Name legal. Der Name ist die feste Kennung, unter der deine Site das Menü abruft, er lässt sich später nicht ändern. Mit Erstellen landest du im leeren Menü.

Jetzt klickst du auf Inhalt hinzufügen. Im Dialog Inhalt auswählen siehst du alle veröffentlichten Pages, ein Klick auf „Impressum“ fügt sie hinzu. Dasselbe machst du mit der Datenschutzerklärung. Den Text eines Menüpunkts änderst du bei Bedarf über Bearbeiten.

Nimm hier Inhalt hinzufügen und nicht Benutzerdefinierten Link hinzufügen. Ein Menüpunkt, der auf einen Eintrag zeigt, merkt sich den Eintrag und nicht die Adresse. EmDash baut die URL bei jedem Aufruf aus dem URL-Muster neu, und auf einer mehrsprachigen Site nimmt es die Übersetzung in der jeweiligen Sprache. Ein selbst eingetippter Link /pages/impressum bricht dagegen, sobald sich der Slug oder das Muster ändert.

Das Menü in den Footer hängen

Unter Verwalten → Widgets siehst du links die Verfügbaren Widgets und rechts die Bereiche Footer und Sidebar. Zieh das Widget Menü mit der Maus in den Bereich Footer, unter den About-Eintrag. Klick dann auf den neuen Eintrag, damit er aufklappt. Unter Titel schreibst du „Rechtliches“, unter Menü wählst du dein Menü aus, dann Speichern.

Beim nächsten Aufruf steht der Block in jedem Footer der Site, weil alle Seiten der Vorlage dasselbe Layout nutzen. Ich habe es ausgeloggt auf der Startseite, auf einem Beitrag und auf dem Impressum selbst geprüft.

Schön ist es noch nicht. Die Vorlage gestaltet Menü-Widgets nicht wie die anderen Footer-Spalten, deshalb stehen die Links mit Aufzählungspunkten und in Linkfarbe unter dem About-Text. Rechtlich ist das egal, die Links sind auf jeder Seite da. Wer es angleichen will, braucht ein paar Zeilen CSS.

Auf The Weekly Dash haben wir einen dritten Weg genommen. Unser Footer ist eigener Code, und die Links zu Impressum und Datenschutz stehen fest im Layout, mit den Slugs pro Sprache in einer kleinen Tabelle. Das lohnt sich erst, wenn du das Layout ohnehin selbst baust.

Was in die Datenschutzerklärung gehört

Jetzt zum Teil, bei dem die meisten Generatoren raten müssen. Eine Datenschutzerklärung beschreibt, was deine Site tatsächlich tut. Ein Generator kennt deine Site aber nicht. Er fragt dich nach Diensten, und wenn du nicht weißt, was EmDash und Cloudflare im Hintergrund machen, kreuzt du zu viel oder zu wenig an. Deshalb habe ich nachgesehen, statt zu raten.

Zuerst habe ich theweeklydash.com mit einem Browser ohne Bedienoberfläche (headless) aufgerufen, ausgeloggt, so wie ein neuer Besucher. Auf fünf Seiten, darunter Startseite, Impressum und Datenschutzerklärung, hat die Site keinen einzigen Cookie gesetzt und nichts im Local Storage oder Session Storage abgelegt. Geladen hat der Browser nur von zwei Adressen, von theweeklydash.com selbst und von static.cloudflareinsights.com. Auf der frischen Blog-Vorlage lokal war es noch weniger: kein Cookie und keine fremde Adresse, auch nicht auf einem Beitrag mit Kommentarformular. Danach habe ich im Quelltext von EmDash 1.1.0 nachgesehen, woher das kommt.

Daraus ergeben sich die Bausteine für eine typische EmDash-Site auf Cloudflare.

Hosting bei Cloudflare

Deine Site läuft als Worker, die Datenbank ist D1, die Bilder liegen in R2. Bei jedem Aufruf verarbeitet Cloudflare, was jeder Browser mitschickt: IP-Adresse, Zeitpunkt, aufgerufene Adresse, Referrer und Browserkennung. Das gehört in die Erklärung, mit dem Zweck (die Seite ausliefern und schützen) und der Rechtsgrundlage, meist das berechtigte Interesse nach Art. 6 Abs. 1 lit. f DSGVO.

Cloudflare ist dabei dein Auftragsverarbeiter, und dafür brauchst du einen Vertrag nach Art. 28 DSGVO. Den musst du bei einem normalen Konto nicht extra unterschreiben. Das Self-Serve Subscription Agreement, dem du beim Anlegen deines Kontos zustimmst, bindet Cloudflares Data Processing Addendum ausdrücklich ein. Es deckt auch das Schweizer DSG ab. Leg dir trotzdem die aktuelle Fassung als PDF zu deinen Unterlagen, damit du sie zeigen kannst, wenn jemand fragt.

Daten können dabei in die USA gehen. Cloudflare ist nach dem EU-U.S. Data Privacy Framework zertifiziert, für die Schweiz nach dem Swiss-U.S. Data Privacy Framework, und hat zusätzlich die Standardvertragsklauseln vereinbart. Auch das gehört in die Erklärung.

Wo deine Datenbank und deine Bilder liegen, entscheidest du beim Anlegen. Mit einem Location Hint landen D1 und R2 zum Beispiel in Westeuropa, warum sich das auch für die Ladezeit lohnt, steht in Wo steht deine Datenbank?. Schreib aber nicht „alle Daten bleiben in der EU“. Cloudflare beantwortet jeden Aufruf im Rechenzentrum, das deinem Besucher am nächsten ist, und das kann überall auf der Welt stehen.

Bleiben die Protokolle. Cloudflare speichert die Logs deines Workers mit Workers Logs, und das ist laut Doku bei jedem neu angelegten Worker voreingestellt. In der wrangler.jsonc der Blog-Vorlage steht kein observability-Eintrag. Wrangler schickt beim Deploy dann nichts dazu mit, und es gilt Cloudflares Voreinstellung. Nach dem ersten npm run deploy laufen Workers Logs also. Aufbewahrt werden sie heute im Free-Plan drei Tage und im Paid-Plan sieben. Ab dem 1. Dezember 2026 gilt Cloudflares neues Observability-Preismodell, dann sind es auch im Free-Plan sieben Tage. In unserer Erklärung steht deshalb, dass Protokolle zur Fehlersuche nach spätestens sieben Tagen gelöscht werden. Willst du gar keine Logs, trägst du "observability": { "enabled": false } in die wrangler.jsonc ein und deployst neu.

Besucherstatistik mit Cloudflare Web Analytics

Die zweite Adresse aus meiner Messung, static.cloudflareinsights.com, gehört zu Cloudflare Web Analytics, intern auch RUM genannt. Das Skript bindest du nicht selbst ein. Liegt deine Domain als Zone bei Cloudflare, fügt Cloudflare es beim Ausliefern in jede Seite ein. Laut Doku ist das bei Zonen im Free-Plan sogar automatisch eingeschaltet, dort mit Ausnahme von Besuchern aus der EU. Läuft deine Site noch unter einer workers.dev-Adresse, wie am Ende von Kevins Artikel, gibt es keine Zone und kein solches Skript.

Ob und wie es bei dir läuft, siehst du im Cloudflare-Dashboard unter Web Analytics beim Eintrag deines Hostnamens. Läuft es, gehört es in die Erklärung. Das Skript misst Ladezeiten und schickt sie mit Adresse, Referrer, Browser und Gerätetyp an Cloudflare. Laut Cloudflare speichert es nichts im Browser, setzt keine Cookies und verwirft die IP-Adresse im nächsten Rechenzentrum.

Ohne Cookies heißt allerdings nicht automatisch ohne Einwilligung. § 25 TDDDG verlangt eine Einwilligung nicht nur fürs Speichern im Browser, sondern auch für den Zugriff auf Informationen, die schon im Endgerät liegen. Das Skript liest Messwerte aus dem Browser aus. Ob das unter § 25 fällt und ob dann die Ausnahme für „unbedingt erforderliche“ Zugriffe greift, wird unterschiedlich beurteilt. Wir setzen Web Analytics ohne Banner ein und begründen es mit unserem berechtigten Interesse. Willst du auf Nummer sicher gehen, schalte Web Analytics ab. Die Zahlen zu Anfragen und Datenmenge im Dashboard deiner Zone bekommst du trotzdem, denn die misst Cloudflare auf dem Server.

Schriften

Die Blog-Vorlage holt ihre Schriften über fontProviders.google(). Das klingt nach Google, ist es für deine Besucher aber nicht. Astros Fonts API lädt die Dateien beim Build herunter und liefert sie von deiner eigenen Domain unter /_astro/fonts/ aus. Auf theweeklydash.com habe ich das im ausgelieferten HTML nachgesehen, dort steht weder fonts.googleapis.com noch fonts.gstatic.com. Den Hintergrund erkläre ich im Artikel Logo, Farben, Schrift.

Das ist wichtig, weil das Landgericht München I 2022 einem Besucher Schadensersatz zugesprochen hat, dessen IP-Adresse eine Website über dynamisch eingebundene Google Fonts an Google weitergegeben hatte (Urteil vom 20. Januar 2022, 3 O 17493/20). Mit der Vorlage passiert das nicht. In die Erklärung musst du dazu nichts schreiben, ein Satz wie „Die Schriften liefern wir selbst aus“ schafft aber Klarheit.

Kommentare

Die Vorlage zeigt unter jedem Beitrag ein Kommentarformular. Schickt jemand einen Kommentar ab, speichert EmDash in deiner Datenbank:

• Name und E-Mail-Adresse, beides Pflichtfelder,
• den Text und den Zeitpunkt,
• einen gesalzenen Hash der IP-Adresse und die Browserkennung (User-Agent), um Spam und Missbrauch abzuwehren,
• den Status, also ob der Kommentar wartet, freigegeben oder abgelehnt ist.

Öffentlich zeigt die Vorlage Name, Text und Datum. Pro IP-Hash nimmt EmDash höchstens fünf Kommentare in zehn Minuten an. Die Einträge dafür räumt es nach frühestens einer Stunde auf. Den Hash und die Browserkennung am Kommentar selbst löscht EmDash dagegen nicht von allein, sie bleiben, solange der Kommentar bleibt. Das gehört so in die Erklärung.

Wie streng moderiert wird, stellst du unter Admin → Inhaltstypen → Posts im Abschnitt Kommentare ein. Voreingestellt ist Nur Erstkommentatoren. Der erste Kommentar einer E-Mail-Adresse wartet auf deine Freigabe, weitere erscheinen sofort. Willst du keine Kommentare, schaltest du dort Kommentare aktivieren aus, und der ganze Abschnitt entfällt in deiner Erklärung.

EmDash hat außerdem Cloudflare Turnstile als Spamschutz eingebaut, in der Vorlage ist er aber aus. Schaltest du ihn ein, lädt das Formular ein Skript von challenges.cloudflare.com, und das gehört dann ebenfalls in die Erklärung. Wie wir das gelöst haben, steht in unserer Datenschutzerklärung in Abschnitt 6. Ausführlich geht es um Kommentare in einem späteren Teil dieser Reihe.

Kontakt per E-Mail

Im Impressum steht deine E-Mail-Adresse. Wer dir schreibt, schickt dir Daten, und die Erklärung sagt, was du damit tust. Nutzt du Cloudflare Email Routing, nimmt Cloudflare die Mail an und leitet sie an dein eigentliches Postfach weiter. Dann nennst du beide, Cloudflare und den Anbieter deines Postfachs. Bei uns landen die Mails in einem gemeinsamen Postfach, das wir in unserem eigenen Cloudflare-Konto betreiben, deshalb nennen wir nur Cloudflare.

Nimmst du als zweiten Kontaktweg ein Kontaktformular, gehört auch das hinein: welche Felder es abfragt, wohin die Nachricht geht und wie lange du sie aufhebst. Die Blog-Vorlage bringt kein Formular mit. Unseres schickt die Nachricht als Mail in dasselbe Postfach, speichert auf der Site selbst nichts und ist wie die Kommentare mit Turnstile geschützt.

EmDash selbst verschickt nur Mails, wenn du ein E-Mail-Plugin einrichtest, etwa für Einladungen, Anmeldelinks oder Benachrichtigungen über neue Kommentare. Die Blog-Vorlage hat keins. Richtest du später eins ein, zum Beispiel über Cloudflare Email Sending, ergänzt du die Erklärung.

Anmeldung im Adminbereich

Der Adminbereich setzt nach der Anmeldung mit Passkey ein Sitzungscookie namens astro-session. Es ist httpOnly und gilt nur, bis der Browser geschlossen wird. Das betrifft nur dich und deine Redaktion, Besucher bekommen es nie. In eine Datenschutzerklärung für Besucher gehört es deshalb nicht. Schreiben mehrere Leute auf deiner Site, informierst du sie besser direkt.

Cookies, und brauche ich ein Banner?

Für einen Besucher setzt EmDash 1.1.0 auf öffentlichen Seiten kein Cookie. Ich habe im Quelltext nach jedem Cookie gesucht. Alle, die es gibt, betreffen angemeldete Benutzer, die Einrichtung oder den WordPress-Import.

Ein Cookie kommt aus der Vorlage selbst. Wählt jemand im Footer ausdrücklich das helle oder dunkle Farbschema, merkt sich die Site das in einem Cookie theme für ein Jahr. Bei „System“ wird es wieder gelöscht. Dieses Cookie speichert eine Einstellung, um die der Besucher selbst gebeten hat. Damit fällt es unter die Ausnahme in § 25 Abs. 2 Nr. 2 TDDDG und braucht keine Einwilligung, gehört aber in die Erklärung. Außerdem kann Cloudflare Sicherheitscookies wie __cf_bm setzen, wenn du Funktionen gegen Bots einschaltest.

Ein Cookie-Banner brauchst du, wenn du etwas einsetzt, das eine Einwilligung braucht. Das sind vor allem Tracking, Werbung und eingebettete Inhalte von anderen Anbietern, also YouTube-Videos, Karten oder Social-Media-Posts. Die Vorlage bringt nichts davon mit. Mit dem Aufbau aus diesem Artikel brauchst du also kein Banner, mit der Einschränkung bei Web Analytics von oben. Ein Banner, das nichts abfragt, schützt dich nicht, es nervt nur deine Leser.

In der Schweiz ist es lockerer. Bearbeitest du Daten auf dem Gerät deiner Besucher, setzt du also etwa ein Cookie, verlangt Art. 45c lit. b des Fernmeldegesetzes (FMG, SR 784.10) keine Einwilligung vorab. Es reicht, wenn du über die Bearbeitung und ihren Zweck informierst und darauf hinweist, dass man sie ablehnen kann.

So ist unsere aufgebaut

Unsere Datenschutzerklärung folgt genau diesen Datenflüssen. Sie hat zwölf Abschnitte:

1. Verantwortliche, bei uns zwei, weil wir die Site gemeinsam betreiben (Art. 26 DSGVO)
2. Das Wichtigste in Kürze, vier Sätze für alle, die nicht weiterlesen
3. Hosting und Auslieferung über Cloudflare, mit Auftragsverarbeitung und Data Privacy Framework
4. Besucherstatistik mit Cloudflare Web Analytics
5. Kommentare
6. Spamschutz mit Cloudflare Turnstile, für Kommentare und das Kontaktformular
7. Suche
8. Cookies, also theme und mögliche Sicherheitscookies von Cloudflare
9. Kontakt per E-Mail und über das Kontaktformular
10. Links zu sozialen Netzwerken, die erst beim Klick etwas laden
11. Ihre Rechte, mit den Aufsichtsbehörden in Bayern und der Schweiz
12. Änderungen

Ganz oben steht ein Datum. Ändert sich an der Site etwas, das Daten betrifft, etwa ein Video-Embed oder ein Newsletter, passen wir die Erklärung im selben Schritt an. Unser Impressum ist kürzer: die Angaben nach § 5 DDG mit beiden Namen und Anschriften, als Kontakt eine E-Mail-Adresse und das Kontaktformular unter /kontakt, dazu die verantwortliche Person nach § 18 Abs. 2 MStV.

Generator, Vorlage oder Anwalt?

Für beide Seiten gibt es Generatoren, kostenlose und bezahlte, für Deutschland und die Schweiz. Für eine kleine Site sind sie ein brauchbarer Anfang, wenn du ihnen die richtigen Antworten gibst. Mit diesem Artikel weißt du, welche Dienste deine Site wirklich nutzt. Prüf das Ergebnis trotzdem Absatz für Absatz und streich, was nicht auf dich zutrifft. Ein Absatz über Google Analytics, das du gar nicht nutzt, ist falsch, auch wenn er gut gemeint ist.

Verdienst du mit der Site Geld, ob als Firma, als Selbstständiger oder über Werbung und Affiliate-Links, lass beide Texte von einer Anwältin oder einem Anwalt prüfen. Bei Abmahnungen geht es dann um echtes Geld, und eine Prüfung kostet meist weniger als eine einzige.

Checkliste vor dem Launch

• Impressum angelegt, mit Name, ladungsfähiger Anschrift, E-Mail-Adresse und einem zweiten schnellen Kontaktweg, bei einer Firma mit den zusätzlichen Angaben.
• Datenschutzerklärung angelegt, mit Datum und mit genau den Diensten, die deine Site nutzt.
• Slugs geprüft, also datenschutz statt datenschutzerklärung.
• Beide Seiten veröffentlicht, nicht nur gespeichert.
• Im Footer verlinkt, und ausgeloggt auf Startseite, Beitrag und 404-Seite nachgesehen.
• Web Analytics geprüft, im Dashboard deiner Zone, und Erklärung und Einstellung passen zusammen.
• Kommentare entschieden, an mit passendem Abschnitt in der Erklärung oder aus.
• Keine Embeds ohne Plan, also kein YouTube-Video und keine Karte, solange du keine Einwilligung einholst.
• Data Processing Addendum von Cloudflare in der aktuellen Fassung abgelegt.
• Englische Fassung, falls du eine hast, verlinkt aus dem englischen Footer.

Fazit

Zurück zur Frage vom Anfang. Online stellen darfst du deine Site, sobald zwei Seiten stehen. Ein Impressum brauchst du in Deutschland fast immer, wegen § 18 MStV auch für einen privaten Blog. In der Schweiz brauchst du es, wenn du etwas anbietest. Eine Datenschutzerklärung brauchst du in beiden Ländern, weil schon die Auslieferung jeder Seite IP-Adressen verarbeitet.

In EmDash sind beide Seiten zwei Einträge unter Pages. Verlinkt werden sie über ein eigenes Menü, das als Widget im Footer jeder Seite steht. Code brauchst du dafür keinen. Und eine EmDash-Site auf Cloudflare verarbeitet weniger, als viele Generatoren annehmen: kein Cookie für Besucher, keine Schriften von Google, keine fremden Dienste außer Cloudflare selbst. Schreib genau das hinein, nicht mehr und nicht weniger.