Anleitungen
Konkrete Wege, unnötige Speicherung von Besucher-IP-Adressen und anderen Kennungen zu vermeiden. Nicht jede Variante passt zu jedem Hostingtarif – bei Shared Hosting gelten zusätzlich die Möglichkeiten des Anbieters.
Grundlagen & Prüfen
- IP-Verarbeitung und IP-Speicherung: der entscheidende Unterschied
Eine Website kann ohne IP-Verarbeitung nicht ausgeliefert werden. Daraus folgt aber nicht, dass die Adresse dauerhaft gespeichert werden muss. - IP anonymisieren oder gar nicht speichern?
Anonymisierung kann sinnvoll sein; wenn die Adresse für den Zweck überhaupt nicht benötigt wird, ist Nicht-Speichern die datensparsamere Architektur. - Cookielos ist nicht automatisch trackingfrei
Auch ohne Cookies können Local Storage, Session Storage, IP-basierte Hashes oder serverseitige Kennungen Besuche zusammenführen. - Unique Visitors ohne Wiedererkennung: warum das nicht exakt geht
Exakte eindeutige Besucher setzen voraus, dass mehrere Seitenaufrufe zumindest zeitweise derselben Instanz zugeordnet werden können. - Was speichert mein Hoster über Website-Besucher?
Websitebetreiber müssen Anwendung, Webserver und Hosting-/Security-Ebene getrennt betrachten. - Prüfcheckliste: speichert meine Website unnötige Besucherdaten?
Eine praktische Prüfung von Browser-Speicher über Netzwerkrequests bis zu Server-, Provider- und Sicherheitslogs. - Linux: eigene Test-IP in Logdateien finden
Mit einer eigenen Test-IP lässt sich kontrollieren, in welchen zugänglichen Serverlogs ein einzelner Seitenaufruf landet. - MySQL/MariaDB: mögliche IP- und Besucher-Spalten finden
Eine reine Schema-Abfrage findet verdächtige Spaltennamen, ohne gespeicherte Besucherdaten auszulesen. - PHP: REMOTE_ADDR und weitergereichte Client-IP prüfen
Quellcodesuche zeigt Stellen, die Besucher-IP oder Proxy-Header verwenden; ein Treffer beweist noch keine Speicherung. - Set-Cookie-Header mit curl prüfen
curl macht serverseitig gesetzte Cookies sichtbar, auch wenn JavaScript sie wegen HttpOnly nicht lesen kann. - Cookies, localStorage und sessionStorage selbst prüfen
Browser-Entwicklerwerkzeuge zeigen gespeicherte Kennungen, die ein reiner HTML-Scanner nicht vollständig erkennen kann. - Drittanbieter-Requests mit Browser-DevTools prüfen
Die Netzwerkansicht zeigt auch Requests, die JavaScript erst nach dem Laden erzeugt und die im HTML nicht sichtbar sind. - WordPress: Datenschutz-Selbsttest mit WP-CLI
WP-CLI listet aktive Plugins und relevante Optionen ohne Änderung der Installation auf. - Reverse Proxy: Weitergabe der Besucher-IP am Origin prüfen
Konfigurationen und Header zeigen, ob ein Proxy die ursprüngliche Client-IP bis zum Origin weiterreicht.
Webserver, Reverse Proxy & CDN
- Apache ohne Besucher-IP im Access-Log
Aktuelle Apache-2.4-Konfiguration: Access-Logs vermeiden oder ein LogFormat ohne Client-IP verwenden. - nginx ohne Besucher-IP im Access-Log
Access-Logging abschalten oder ein eigenes nginx-Logformat ohne remote_addr und Forwarded-IP verwenden. - Caddy: IP-Adressen in Access-Logs reduzieren
Caddy-Logs mit aktuellen Filterfunktionen minimieren und remote_ip, client_ip sowie Forwarded-Header berücksichtigen. - Traefik: Access-Logs datensparsam konfigurieren
Client-IP, Header und Queryparameter aus Traefik-Access-Logs entfernen. - HAProxy: Logs ohne dauerhafte Client-IP
HAProxy als vorgeschaltete Sicherheitsebene nutzen, ohne die Besucher-IP unnötig in normalen Request-Logs zu verewigen. - Cloudflare: Besucher-IP nicht an den Origin weitergeben
Cloudflare verarbeitet die IP am Edge; mit Remove visitor IP headers lässt sich ihre Weitergabe an den Origin begrenzen. - Caddy: Original-IP hinter Reverse Proxy nur bei Bedarf rekonstruieren
Caddy wertet Client-IP-Header nur bei konfigurierten trusted_proxies aus; dadurch lässt sich bewusst entscheiden, ob der Origin die Besucher-IP benötigt.
WordPress
- WordPress: Statify als einfacher datensparsamer Seitenaufrufzähler
Statify zählt Seitenaufrufe statt Besucher und speichert laut Projektdokumentation keine IP-Adressen oder Besucherprofile. - WordPress: Koko Analytics möglichst datensparsam einstellen
Koko bietet Cookie-, cookielose und reine Pageview-Modi. Für maximale Datenminimierung ist Pageview-only die klarste Variante. - WordPress: Burst Statistics datensparsam konfigurieren
Burst ist self-hosted, bietet aber unterschiedliche Erkennungsmodi. Für „Wir speichern nicht!“ muss die Privacy-Einstellung bewusst gewählt werden. - WordPress: Independent Analytics datenschutzbewusst einordnen
Independent Analytics speichert keine rohe IP, erzeugt aber aus IP, User-Agent und Salt eine wiederverwendbare Besucher-ID. - WordPress: Antispam Bee datensparsam einsetzen
Kommentar-Spam lokal filtern, Drittanbieter vermeiden und IP-abhängige Optionen bewusst behandeln. - WordPress: Kommentar-IP nicht dauerhaft speichern
WordPress-Kommentare so anpassen, dass die normale Kommentar-IP nicht dauerhaft als Metadatum erhalten bleibt. - WordPress: Gravatar-Drittverbindungen vermeiden
Avatare können beim Seitenaufruf eine Verbindung zu Gravatar erzeugen; lokale Avatare oder deaktivierte Anzeige vermeiden diese Anfrage. - WordPress: Contact Form 7 ohne unnötige Zusatzdienste
Contact Form 7 selbst schlank halten und optionale reCAPTCHA-, Flamingo- und weitere Integrationen separat auf Speicherung prüfen. - WordPress: WP Statistics möglichst datensparsam konfigurieren
WP Statistics arbeitet lokal und cookielos; Datenschutzoptionen verhindern zusätzliche personenbezogene Speicherung und Datenweitergabe. - WordPress: MailPoet ohne Öffnungs- und Klicktracking
MailPoet kann Engagement-Tracking für Newsletter reduzieren bzw. deaktivieren; Diagnose-Logging und optionale Datenweitergabe ebenfalls prüfen. - WordPress: Wordfence und IP-basierte Sicherheitsfunktionen einordnen
Wordfence nutzt IP-bezogene Sicherheitsdaten und externe Infrastruktur; Sicherheitszweck und normale Besucheranalyse sauber trennen. - WordPress: Solid Security Logs und IP-Erkennung minimieren
Solid Security protokolliert Sicherheitsereignisse und verwendet IP-Adressen für Sperren; Speicherort und Aufbewahrung sind konfigurierbar. - WordPress: WP Activity Log und gespeicherte IP-Adressen prüfen
WP Activity Log speichert zu Ereignissen unter anderem die Quell-IP; für strenge Datensparsamkeit Umfang und Zweck kritisch prüfen. - WordPress: Login-Sperren und IP-Speicherung bewusst konfigurieren
Login-Limiter arbeiten typischerweise IP-basiert; Angriffsabwehr rechtfertigt nicht automatisch unbegrenzte Speicherung. - WordPress: Gravity Forms ohne gespeicherte Einsender-IP
Gravity Forms kann die Speicherung der IP bei Formularübermittlungen abschalten und Einträge automatisch nach einer Frist löschen. - WordPress: Fluent Forms IP-Logging und Ländererkennung abschalten
Fluent Forms stellt Filter bereit, um IP-Logging und die aus Request-Headern abgeleitete Ländererkennung zu deaktivieren. - WordPress: SlimStat IP-Anonymisierung ausdrücklich aktivieren
SlimStat speichert in aktuellen Versionen standardmäßig wieder vollständige IP-Adressen; Anonymisierung oder Hashing muss bewusst aktiviert werden. - WordPress: Jetpack Stats verarbeitet Besucher-IP trotz aggregierter Anzeige
Jetpack zeigt Websitebetreibern aggregierte Statistiken, Automattic hält Stats-Logs mit Besucher-IP jedoch zeitweise vor.
WooCommerce
- WooCommerce: freiwilliges Usage Tracking abschalten
WooCommerce bietet freiwillige Nutzungsdatenübermittlung; sie lässt sich in den erweiterten Einstellungen deaktivieren. - WooCommerce: IP-Geolocation nur einsetzen, wenn sie benötigt wird
WooCommerce kann die Kunden-IP lokal mit MaxMind-Daten geolokalisieren; der Cache-Modus erzeugt zusätzlich einen IP-basierten URL-Hash.
Sicherheit & Fehlerdiagnose
- CrowdSec: Angriffs-IP als Sicherheitsdaten statt Besucherstatistik
CrowdSec verarbeitet IP-Adressen erkannter Angreifer gezielt für Sicherheitsentscheidungen und hat dafür definierte Aufbewahrungs- und Degradationsregeln. - Bugsnag: IP nicht als automatische Browser-User-ID verwenden
Bugsnag verwendet im JavaScript-SDK standardmäßig die IP-Adresse als User-ID; collectUserIp kann diese Erfassung verhindern. - Sentry: personenbezogene Fehlerdaten vor dem Versand entfernen
Sentry bietet SDK-Scrubbing, serverseitige Regeln und Relay; wenn Daten das eigene System nie verlassen sollen, müssen sie vor dem Versand entfernt werden. - Rollbar: IP-basierte Fehlerhistorie als personenbezogene Diagnosefunktion
Rollbar kann Ereignisse nach IP gruppieren und Standortinformationen anzeigen; diese Funktion ist für strenge Datensparsamkeit kritisch zu prüfen.
Weitere CMS
- Drupal: anonyme Seitenaufrufe mit Statistics
Das aktuelle Statistics-Modul für Drupal 10.3+/11 konzentriert sich auf anonyme Inhaltsaufrufe statt Besucherprofile. - Joomla: Datenschutzfunktionen nutzen und Erweiterungen getrennt prüfen
Joomlas Privacy-Funktionen helfen bei Auskunft und Einwilligungen, ersetzen aber keine Prüfung von Logs, Erweiterungen und Drittressourcen. - Joomla: User Actions Log ohne IP-Adresse
Joomla kann Benutzeraktionen protokollieren, ohne dabei zusätzlich die IP-Adresse in das Actions Log aufzunehmen. - TYPO3: IP-Anonymisierung und Logs richtig konfigurieren
TYPO3 hat eine aktuelle ipAnonymization-Einstellung – sie wirkt aber nicht beim Erzeugen neuer Logeinträge und ersetzt keine Log-Prüfung.
Statistik & Analytics
- Matomo datensparsam einrichten
IP-Anonymisierung, Tracker Proxy und Webserver-Logs gemeinsam betrachten – nicht nur die Matomo-Datenbank. - Matomo: Original-IP schon vor dem Tracker entfernen
Der Matomo Tracker Proxy kann die Besucher-IP entfernen, bevor Matomo sie verarbeitet – strenger als bloßes nachträgliches IP-Masking. - Umami: cookielos heißt nicht ohne Besucherkennung
Umami speichert keine IP als Metrik, bildet Sessions aber aus IP, User-Agent und Website-ID. Distinct IDs können Profile zusätzlich verbinden. - Plausible: IP-Verarbeitung und tägliche Besucherkennung verstehen
Plausible speichert die rohe IP nicht, verarbeitet IP und User-Agent aber für Standort und eine täglich wechselnde Besucher-ID. - GoatCounter: Sessions, IP-Verarbeitung und Aggregate richtig einordnen
GoatCounter speichert standardmäßig Aggregate; IP und User-Agent werden zur Sessionerkennung bis zu acht Stunden im RAM verarbeitet. - GoAccess: IP-Adressen bei der Logauswertung anonymisieren
GoAccess kann Client-IP-Adressen beim Einlesen maskieren; das ursprüngliche Webserver-Log muss trotzdem separat datensparsam konfiguriert werden. - PostHog: Cookieless-Modus richtig einordnen
Cookieless bedeutet bei PostHog keine Browser-ID, aber serverseitige tägliche Wiedererkennung aus IP und User-Agent. - Countly: IP-Verarbeitung für Geolocation verstehen
Countly speichert laut Dokumentation keine rohe IP, verarbeitet sie aber zunächst zur Standortbestimmung. - Simple Analytics: Analytics ohne Besucherkennung einordnen
Simple Analytics dokumentiert keine Cookies, keine Local-Storage-Kennung und kein Speichern oder Hashen von IP-Adressen. - Fathom Analytics: cookielos, aber mit kurzzeitiger IP-Verarbeitung
Fathom setzt keine Analytics-Cookies, verarbeitet jedoch IP und User-Agent für täglich rotierende Besucher-Signaturen. - Microsoft Clarity: Consent Mode verhindert Cookies, nicht jede Messung
Clarity kann vor Einwilligung ohne Cookies arbeiten, führt aber weiterhin Requests und Basis-Messungen aus. - Pirsch: cookielos mit täglicher Besucher-ID aus IP und User-Agent
Pirsch speichert die IP nicht, verarbeitet sie aber mit User-Agent, Datum und Salt zu einer bis zu 24 Stunden verwendbaren Besucher-ID. - Piwik PRO: ohne Cookies und ohne Session-Hash messen
Piwik PRO kann Cookies und Session-Hash abschalten; dann wird jedes Ereignis als neue Session behandelt und Besucher werden nicht wiedererkannt. - Cloudflare Web Analytics: cookielose RUM-Verbindung einordnen
Cloudflare Web Analytics nutzt einen externen Beacon und beschreibt die Messung als ohne personenbezogene Endnutzerprofile; der Netzwerkrequest bleibt dennoch bestehen. - Plausible Proxy: Besucher-IP wird weiterhin an Analytics weitergereicht
Ein First-Party-Proxy versteckt den Analytics-Request optisch, beseitigt aber die IP-Verarbeitung durch Plausible nicht.
Formulare, CAPTCHA & Spam-Schutz
- Kontaktformular ohne Tracking und unnötige IP-Speicherung
Kontaktformulare lokal verarbeiten, nur notwendige Felder erheben und Spam-Schutz ohne unnötige Drittanbieter-Verbindungen aufbauen. - CAPTCHA und Spam-Schutz: erst lokal, dann extern
Honeypot, Zeitprüfung und serverseitige Regeln vor externen CAPTCHA-Diensten einsetzen und Drittanbieter-Verbindungen sichtbar machen. - Cloudflare Turnstile: CAPTCHA-Ersatz ist trotzdem ein Drittanbieter
Turnstile vermeidet klassische Bild-CAPTCHAs, baut aber eine Cloudflare-Kommunikation auf und ist deshalb getrennt von lokalem Spam-Schutz zu bewerten. - Google reCAPTCHA: Drittanbieter-Verbindung bewusst bewerten
reCAPTCHA bindet Google in die Bot-Prüfung ein; lokale Spam-Abwehr ist für datensparsame Formulare die erste Wahl. - hCaptcha: datensparsam integrieren und Drittverbindung erkennen
hCaptcha ist ebenfalls ein externer Challenge-Dienst; nur dort laden, wo der Schutz erforderlich ist, und Serverprüfung getrennt konfigurieren. - Getform: Formulardienst sammelt zusätzliche Besucherdaten
Getform dokumentiert neben Formularfeldern auch IP-Adresse, Standort, Betriebssystem, Browser und Gerätetyp. - Brevo-Formulare: CAPTCHA bedeutet zusätzliche Drittanbieter-Verarbeitung
Brevo bietet Google reCAPTCHA oder Cloudflare Turnstile für Formulare; beide Optionen binden einen zusätzlichen externen Dienst ein.
Newsletter & E-Mail-Tracking
- Newsletter ohne Öffnungs- und Klicktracking
Newsletter versenden, ohne unsichtbare Zählpixel und personalisierte Trackinglinks für jeden Empfänger einzubauen. - Brevo: Öffnungs- und Klicktracking anonymisieren
Brevo ordnet Öffnungen und Klicks standardmäßig Empfängern zu; anonymes Tracking trennt diese Ereignisse von konkreten Kontakten. - Mailchimp: Öffnungs- und Klicktracking abschalten
Mailchimp aktiviert Öffnungs- und Klicktracking standardmäßig; beide Funktionen können pro E-Mail deaktiviert werden. - MailerLite: Open Tracking gezielt deaktivieren
MailerLite erlaubt das Abschalten der Öffnungsmessung; andere Messungen wie Klick- oder E-Commerce-Tracking müssen separat kontrolliert werden. - Buttondown: Open Tracking ist opt-in
Buttondown aktiviert Öffnungstracking nicht zwingend; bei Aktivierung wird ein empfängerspezifisches Tracking-Pixel eingefügt.
Website-Baukästen
- IONOS Website Builder: Besucherlogs und WebAnalytics einordnen
IONOS dokumentiert für Website Builder direkt anonymisierte IP-Adressen und 21 Tage Speicherung bestimmter Besuchsdaten. - STRATO Homepage-Baukasten: Statistik, Cookies und externe Inhalte prüfen
STRATO dokumentiert eigene Besucherstatistik, Cookie-Steuerung und externe Inhalte als gesonderte Funktionen. - Squarespace: Analytics-Cookies und Unique Visitors reduzieren
Squarespace Analytics nutzt unter anderem Cookies bis zu zwei Jahre für eindeutige Besucher; Analytics-Cookies lassen sich deaktivieren. - Webflow Analyze: cookielos heißt hier Local Storage
Webflow Analyze verwendet keine Cookies zur Besucherkennung, aber Local Storage und anonyme Kennungen. - Jimdo Creator: Statistiken bewusst aktivieren oder deaktivieren
Jimdo Creator Statistics ist cookielos und anonymisiert; die Funktion kann vollständig deaktiviert werden. - one.com Website Builder: Consent-Banner und Tracking-Integrationen prüfen
one.com bietet einen Consent-Banner; zusätzliche Analytics- und Werbeintegrationen müssen getrennt bewertet werden. - Wix: Cookies, Analytics und Session-Aufzeichnungen minimieren
Wix unterscheidet essenzielle und zustimmungspflichtige Analytics-Cookies; Session Recordings sind eine zusätzliche, separat aktivierte Funktion. - Hostinger Website Builder: Tracking-Integrationen nur gezielt aktivieren
Google Analytics, Hotjar, Meta Pixel und weitere Trackingdienste sind optionale Integrationen des Builders.
PHP & Website-Ressourcen
- PHP-Sessions: nur verwenden, wenn Zustand wirklich benötigt wird
PHP-Sessions erzeugen typischerweise eine wiedererkennbare Session-ID; Lebensdauer, Cookie-Eigenschaften und serverseitige Daten minimieren. - Externe Fonts und CDNs: unnötige Drittverbindungen vermeiden
Schriften, JavaScript und CSS lokal ausliefern, wenn kein technischer Grund für einen externen Abruf besteht. - YouTube, Karten und andere Embeds erst nach Bedarf laden
Externe Medien nicht automatisch beim Seitenaufruf verbinden; Vorschaubild oder Platzhalter lokal anzeigen und Embed erst nach Aktion laden. - Disqus: Drittanbieter-Kommentare und Tracking getrennt bewerten
Disqus verarbeitet bei eingebetteten Kommentaren technische Daten und Tracking-Signale; Publisher können Data Sharing deaktivieren. - YouTube nocookie: Datenschutzmodus ersetzt keine Zwei-Klick-Lösung
youtube-nocookie reduziert bestimmte Speicherungen, stellt beim Laden des Players aber weiterhin eine Drittanbieter-Verbindung her. - Cloudflare Zaraz: serverseitiges Tagging ist weiterhin Drittanbieter-Verarbeitung
Zaraz kann Marketing- und Analytics-Werkzeuge anders laden, beseitigt aber deren Datenverarbeitung nicht automatisch.