Ich habe am 24. August 2026 die Konsole meines eigenen Blogs geöffnet und document.cookie eingetippt. Heraus kam ein leerer String. Kein _pk_id, kein _pk_ses, kein _pk_ref — und das, obwohl auf bloggen.xyz Matomo mitzählt. Ein Einwilligungsbanner, das ich vorher hätte wegklicken müssen, lief zu diesem Zeitpunkt auf der Seite noch nicht — inzwischen ist eines im Einsatz, aber an der Matomo-Messung ändert das nichts. Für einen Moment fühlte sich das an wie ein Trick, der zu schön ist, um wahr zu sein.
Ist es nicht. Matomo kennt einen dokumentierten cookielosen Betrieb, und der Preis dafür steht ebenfalls in der Dokumentation — er wird nur deutlich leiser vorgetragen als das Versprechen. Ich zeige dir in diesem Beitrag, was Matomo normalerweise im Browser ablegt, wie du den cookielosen Betrieb einschaltest, was dich das an Messgenauigkeit kostet und wie du selbst nachmisst, ob es bei dir tatsächlich greift. Und ich sage dir, was cookielos ausdrücklich nicht bedeutet.
Matomo ohne Cookies auf einen Blick
- Matomo setzt im Normalbetrieb eigene Cookies. Die Matomo-Dokumentation nennt unter anderem
_pk_idmit 13 Monaten Laufzeit,_pk_sesmit 30 Minuten und_pk_refmit 6 Monaten. - Matomo bietet einen dokumentierten cookielosen Modus. Im Tracking-Code wird dafür laut Matomo-FAQ
disableCookiesaufgerufen, und zwar vor dem Aufruf vontrackPageView. - Matomo lässt sich auch ohne Code-Eingriff cookielos schalten. Im WordPress-Plugin gibt es laut Matomo eine Checkbox „Disable cookies“ in den Einstellungen; serverseitig gibt es die Option „Force tracking without cookies“.
- Matomo erkennt ohne Cookies wiederkehrende Besucher schlechter. Die Matomo-Dokumentation sagt selbst, dass die Zuordnung dann über IP-Adresse und weitere Spuren erfolgt und ungenau ist.
- Matomo ohne Cookies ist nicht Matomo ohne Daten. Die IP-Adresse wird weiterhin verarbeitet, der Zählaufruf findet weiterhin statt — es entfällt nur das Speichern auf dem Endgerät.
- Matomo lässt sich in zwei Minuten nachmessen.
document.cookiein der Browser-Konsole und der Reiter „Anwendung“ zeigen dir, ob wirklich nichts abgelegt wird.

Was Matomo im Browser überhaupt ablegt
Bevor du etwas abschaltest, solltest du wissen, was du abschaltest. Matomo ist im Auslieferungszustand kein cookieloses System. Es legt eine Handvoll eigener Cookies an, und jedes davon hat eine klar benannte Aufgabe.
Die Cookies der Standardinstallation
Die Matomo-Übersicht zu den eigenen Cookies listet die Namen samt Zweck und Lebensdauer auf. Die vier, die dir im Alltag begegnen, sind diese:
| Cookie | Zweck laut Matomo | Laufzeit |
|---|---|---|
_pk_id | Speichert eine eindeutige Besucher-ID | 13 Monate |
_pk_ses | Session-Cookie, hält die Daten des laufenden Besuchs | 30 Minuten |
_pk_ref | Merkt sich, woher der Besuch kam | 6 Monate |
_pk_cvar | Session-Cookie für benutzerdefinierte Variablen | 30 Minuten |
Der entscheidende Eintrag ist _pk_id: Er ist der Grund, warum Matomo dir sagen kann, dass jemand zum dritten Mal da war. Dreizehn Monate lang liegt dafür eine Kennung auf dem Endgerät. Daran hängt der ganze Rest der Diskussion — technisch wie rechtlich.
Was bei mir tatsächlich im Browser stand
Auf bloggen.xyz sieht die Sache anders aus, und ich habe sie am 24. August 2026 im laufenden Browser nachgesehen statt aus einer Einstellungsseite abgelesen. Der Zählaufruf geht an die eigene Domain, an /wp-content/plugins/matomo-tracker/inc/frontend/piwik.php. Kein fremder Host wird kontaktiert — die Messung verlässt meinen Server nicht.
Auffällig war der zweite Befund: window.Matomo ist undefined. Der große Matomo-JavaScript-Tracker wird auf der Seite gar nicht erst geladen. Was tatsächlich passiert, sind vier Einträge in der _paq-Warteschlange:
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);
_paq.push(['setTrackerUrl', '//bloggen.xyz/wp-content/plugins/matomo-tracker/inc/frontend/piwik.php']);
_paq.push(['setSiteId', '2']);
Und das Ergebnis, um das es geht: document.cookie ist leer. Kein _pk_id, kein _pk_ses, kein _pk_ref. Ich behaupte hier nicht mehr, als ich gemessen habe: Die Abwesenheit der Cookies habe ich gesehen. Welche Ursache sie erzeugt hat — eine gesetzte Cookie-Option oder der Umstand, dass der Tracker in diesem Moment nicht ausgeführt wurde — lässt sich allein aus dem Browser nicht sicher sagen. Auf diesen Unterschied komme ich im letzten Kapitel zurück.
Es gibt zwei Wege, und sie schließen sich nicht aus: einen im Tracking-Code, einen in der Oberfläche. Welchen du nimmst, hängt davon ab, ob du den Zählcode selbst in der Hand hast.
Der Weg über das Tracking-JavaScript
Matomo beschreibt das in der FAQ zum cookielosen Betrieb. Der Aufruf heißt disableCookies und muss laut dieser Seite in der Zeile vor trackPageView stehen. Die Reihenfolge ist nicht kosmetisch: Was nach dem Seitenaufruf-Befehl kommt, greift für diesen Aufruf zu spät.
// disableCookies vor trackPageView aufrufen
_paq.push(['disableCookies']);
_paq.push(['trackPageView']);
Wenn du deinen Tracking-Schnipsel von Hand im Theme oder über ein Snippet-Plugin einbindest, ist das die kürzeste Strecke: eine Zeile, an der richtigen Stelle. Wenn der Code dagegen von einem Plugin erzeugt wird, ist der zweite Weg der bessere — sonst überschreibt dir das nächste Update deine Änderung.
Der Weg über die Oberfläche
Für das WordPress-Plugin nennt dieselbe Matomo-FAQ einen Klickpfad: du öffnest den Bereich „Matomo Analytics“, gehst auf die Seite „Settings“ und setzt dort den Haken bei „Disable cookies“. Danach speicherst du mit „Save changes“. Kein Code, kein Update-Risiko.
Es gibt darüber hinaus eine serverseitige Variante, die nicht auf den Goodwill des einzelnen Zählcodes angewiesen ist. Matomo beschreibt sie in der FAQ zum Erzwingen des cookielosen Trackings: Als Superuser gehst du auf „Administration“, dann „Privacy“, dann „Anonymize data“, und aktivierst dort „Force tracking without cookies“. Das ist die robustere Lösung, weil sie für alle Zählcodes gilt, die auf diese Matomo-Instanz zeigen — auch für die, die du vor drei Jahren irgendwo eingebaut und vergessen hast.
Eine Einschränkung in eigener Sache: Ob und unter welchem Namen sich dasselbe direkt in einer Konfigurationsdatei setzen lässt, konnte ich auf matomo.org nicht belegen. Ich rate hier keine Syntax. Willst du es in einer Datei verankern, sieh in der Matomo-Dokumentation nach, statt dich auf einen Schlüsselnamen aus einem Blogbeitrag zu verlassen — meinen eingeschlossen.
Hier kommt der Teil, den die meisten Anleitungen in einem Halbsatz abhandeln. Er ist aber der eigentliche Kern: du tauschst nicht Banner gegen nichts, du tauschst Banner gegen Unschärfe.
Wiederkehrende Besucher verschwimmen
Ohne _pk_id fehlt Matomo die Kennung, an der es einen zweiten Besuch als zweiten Besuch erkennt. Matomo schreibt dazu in der FAQ zur Genauigkeit bei deaktivierten Cookies unmissverständlich, dass eindeutige Besucher dann anhand der IP-Adresse und weiterer Spuren bestimmt werden — und dass dies ungenau sei.
Was das praktisch heißt, hängt von deinem Publikum ab, und deshalb nenne ich dir hier keine Prozentzahl. Wer aus einem großen Büronetz kommt, teilt sich seine öffentliche Adresse mit vielen anderen — mehrere echte Menschen verschmelzen zu einem. Wer unterwegs zwischen WLAN und Mobilfunk wechselt, wird umgekehrt zu mehreren. Beide Fehler gehen in entgegengesetzte Richtungen und heben sich nicht sauber auf.
Welche Berichte Matomo selbst als ungenau bezeichnet
Die genannte FAQ wird konkret und listet auf, was leidet. Das ist keine Vermutung von mir, sondern die Auskunft des Herstellers:
- Eindeutige Besucher sowie neue und wiederkehrende Besucher
- Tage seit dem letzten Besuch
- Besuche nach Besuchsanzahl
- Besuche bis zur Conversion und Tage bis zur Conversion
- Ziele und E-Commerce-Conversions, die dann allein dem Kanal des konvertierenden Besuchs gutgeschrieben werden
- Mehrkanal-Attribution und Kohortenberichte, die ohne Wiedererkennung nicht arbeiten können
Sieh dir diese Liste ehrlich an und frag dich, was davon du wirklich benutzt. Bei mir lautet die Antwort: fast nichts. Ich will wissen, welche Beiträge gelesen werden, woher die Leute kommen und ob eine Überschrift funktioniert. Dafür brauche ich keine Wiedererkennung über dreizehn Monate. Wenn du dagegen einen Shop betreibst und wissen musst, ob der Newsletter vom Dienstag den Kauf vom Freitag ausgelöst hat, kostet dich der cookielose Betrieb nicht Komfort, sondern die Frage selbst. Diese Abwägung ist eine Entscheidung darüber, welche Zahlen dein Blog überhaupt braucht — ähnliche Aufräumarbeit wie die nüchterne Bestandsaufnahme der eigenen SEO-Fehler.
Kurz zur Rechtslage, und ausdrücklich als das, was es ist: keine Rechtsberatung, sondern eine Einordnung, für die du im Zweifel jemanden mit Zulassung fragst. Cookielos heißt nicht datenschutzfrei. Wenn nichts mehr auf dem Endgerät gespeichert oder ausgelesen wird, entfällt der Anknüpfungspunkt des § 25 TDDDG — diese Norm hängt genau daran. Damit ist die Sache aber nicht erledigt, sondern nur verschoben: Der Zählaufruf verarbeitet weiterhin die IP-Adresse, und die Frage nach der Rechtsgrundlage stellt sich weiterhin, dann eben nach der DSGVO. Matomo selbst führt in seiner FAQ zum Betrieb ohne Consent-Banner nicht eine, sondern zwölf Bedingungen auf, von denen das Deaktivieren der Cookies nur die erste ist; das Anonymisieren der IP-Adresse um mindestens zwei bis drei Bytes ist eine weitere. Ich behaupte hier ausdrücklich nicht, dass cookieloses Tracking rechtssicher oder einwilligungsfrei zulässig sei — das ist eine Bewertung, die ich nicht treffe. Wenn du am Ende doch eine Einwilligung einholen willst, ist die Frage nur noch, womit du das Banner baust.
Nachmessen, ob Matomo wirklich ohne Cookies läuft
Eine gesetzte Checkbox ist eine Absichtserklärung, ein leerer Cookie-Speicher ein Befund. Beide fallen erstaunlich oft auseinander, weil ein zweites Plugin, ein Caching-Layer oder ein alter Zählcode dazwischenfunkt. Also messen wir nach.
Öffne deine Seite in einem frischen privaten Fenster, warte ein paar Sekunden, klicke einmal auf einen internen Link und tippe dann in der Konsole der Entwicklerwerkzeuge:
document.cookie
Kommt ein leerer String zurück, liegt kein für JavaScript lesbares Cookie auf dieser Domain. Taucht darin _pk_id oder _pk_ses auf, ist der cookielose Betrieb nicht aktiv — egal, was die Einstellungsseite behauptet. Der Klick auf den internen Link ist wichtig: Manches wird erst beim zweiten Seitenaufruf angelegt.
Eine Grenze musst du kennen. document.cookie zeigt nicht alles. Cookies mit dem Attribut HttpOnly sind für JavaScript unsichtbar, und zwar mit Absicht — das steht so in der MDN-Dokumentation zu document.cookie. Ein leerer String ist also ein starkes, aber kein vollständiges Indiz.
Reiter Anwendung für die HttpOnly-Fälle
Für den Rest gehst du in den Entwicklerwerkzeugen auf den Reiter „Anwendung“ und dort links auf „Cookies“. Diese Ansicht listet auch die Einträge, die JavaScript nicht sehen darf, samt Laufzeit und Flags. Erst wenn hier für deine Domain nichts von Matomo steht, hast du wirklich nachgewiesen, dass nichts abgelegt wird.
Wirf im selben Aufwasch einen Blick in den Netzwerk-Reiter und filtere nach piwik oder matomo. Du siehst dann, wohin der Zählaufruf tatsächlich geht. Bei mir landet er auf der eigenen Domain, kein fremder Host taucht auf — eine zweite Eigenschaft, die mit der Cookie-Frage nichts zu tun hat, für die Datenschutzerklärung aber genauso zählt. Wie du so eine Messung systematisch durchziehst, habe ich in der Anleitung zum Cookies selbst messen aufgeschrieben; die Werkzeuge dafür stehen in meiner Sammlung an Blogger-Tools.
Und dann noch ein letzter Hinweis, weil er mir bei meiner eigenen Messung aufgefallen ist: Ein leerer Cookie-Speicher kann auch daher rühren, dass der Tracker gar nicht ausgeführt wurde. Wenn window.Matomo bei dir undefined ist, prüfe im Netzwerk-Reiter, ob überhaupt ein Zählaufruf rausgeht. Sonst feierst du am Ende einen Datenschutzerfolg, der in Wahrheit eine kaputte Statistik ist.


Schreibe einen Kommentar