Cookies selbst messen: Wie viele setzt meine Seite wirklich?

Ich habe lange geglaubt, ich wüsste, was mein Blog beim Aufruf so treibt. Kein Werbenetzwerk, kein Facebook-Pixel, kein Tracking-Riese im Hintergrund — also wird da schon nicht viel passieren. Am 24. August 2026 habe ich aufgehört zu glauben und angefangen zu messen. Drei Seiten von bloggen.xyz, ein privates Browserfenster, die Entwicklerwerkzeuge auf. Dauer: keine zwanzig Minuten.

Das Ergebnis war zweigeteilt. Bei den Cookies: nichts. Null. Auf allen drei geprüften Seiten. Und trotzdem war das Ergebnis unangenehm — denn die Cookies waren gar nicht die interessante Stelle. Ich zeige dir in diesem Werkstattbericht erst, was ich gefunden habe, und dann Schritt für Schritt, wie du dieselbe Messung auf deiner eigenen Seite machst. Ohne Online-Scanner, ohne Plugin, nur mit dem Browser, den du ohnehin offen hast.

Was ich gemessen habe — und was dabei herauskam

Drei Seiten, dreimal dasselbe Ergebnis

Ich habe bewusst drei verschiedene Seitentypen genommen, weil ein Blog nicht überall gleich aussieht: die Startseite mit ihrer Beitragsliste, einen neu veröffentlichten Beitrag ohne jede Interaktion darunter, und einen älteren Beitrag, unter dem Kommentare stehen. Auf jeder dieser Seiten habe ich in der Konsole document.cookie abgefragt.

document.cookie
// Ergebnis auf allen drei Seiten: ''

Ein leerer String. Kein _pk_id, kein _pk_ses, kein _pk_ref, wie man sie von einer klassischen Matomo-Installation kennt. Auch sonst nichts. Für einen Moment war ich zufrieden mit mir — und genau dieser Moment ist der Fehler, um den es in diesem Beitrag geht.

Was document.cookie nicht zeigt

Bevor ich weitergehe, die Einschränkung, die zu jedem ehrlichen Messbericht gehört: document.cookie zeigt dir ausschließlich die Cookies, die per JavaScript lesbar sind. Cookies mit dem Attribut HttpOnly — eine PHP-Session ist der Klassiker — bleiben unsichtbar. Ein leeres Ergebnis in der Konsole heißt also nicht automatisch, dass gar nichts gespeichert ist. Es heißt: nichts, was JavaScript lesen darf. Die Dokumentation bei MDN ist an dieser Stelle deutlich.

Zweite Einschränkung: Ich habe als Besucher gemessen, im privaten Fenster, nicht angemeldet. Für angemeldete Redakteure setzt WordPress selbstverständlich Anmelde-Cookies — anders funktioniert ein Login nicht. Das betrifft aber niemanden, der deinen Blog einfach nur liest. Wenn du deine eigene Seite im normalen Fenster prüfst, misst du deine Redaktionssitzung mit und wunderst dich über Cookies, die kein Besucher je bekommt.

So misst du selbst nach — Schritt für Schritt

Privates Fenster, Konsole, Anwendung

Der Ablauf ist in jedem modernen Browser praktisch identisch. Ich beschreibe ihn so, wie ich ihn gemacht habe:

1. Privates Browserfenster öffnen. Sonst schleppst du alte Cookies aus früheren Besuchen mit und weißt hinterher nicht, was von diesem Aufruf stammt und was seit Wochen herumliegt.
2. Die Seite aufrufen, dann die Entwicklerwerkzeuge öffnen — F12 oder Rechtsklick und Untersuchen. Danach die Seite einmal neu laden, damit die Werkzeuge den kompletten Aufbau mitbekommen.
3. Reiter Konsole: document.cookie eingeben und Enter drücken. Ein leerer String bedeutet: keine per JavaScript lesbaren Cookies.
4. Reiter Anwendung beziehungsweise Application, links Cookies: Hier stehen auch die HttpOnly-Cookies, die die Konsole dir vorenthält. Erst dieser Blick ist vollständig.
5. Reiter Netzwerk: Alle Anfragen ansehen und nach fremden Hosts sortieren. Dazu gleich mehr, denn hier lag bei mir die eigentliche Ausbeute.
6. Alles auf mehreren Seitentypen wiederholen: Startseite, ein Beitrag mit Kommentaren, eine Kontakt- oder Formularseite. Einbindungen, die nur an einer Stelle vorkommen, findest du sonst nie.
7. Ergebnis mit der eigenen Datenschutzerklärung abgleichen. Steht dort etwas, das du nicht mehr einsetzt? Fehlt umgekehrt etwas, das du gerade gemessen hast?

Der Netzwerk-Blick: ein Einzeiler für alle Fremdhosts

Den Netzwerk-Reiter von Hand durchzuscrollen ist mühsam, gerade wenn eine Seite achtzig Anfragen absetzt. Deshalb benutze ich in der Konsole ein kurzes Schnipsel, das mir alle Hosts auflistet, die nicht meine eigene Domain sind. Es liest die Performance-API des Browsers aus und braucht keinerlei Werkzeug von außen:

[...new Set(performance.getEntriesByType('resource').map(r => new URL(r.name).host))].filter(h => h !== location.host)

Heraus kommt eine schlichte Liste von Hostnamen. Wenn du zusätzlich sehen willst, was genau von dort geladen wird, hilft eine etwas gesprächigere Variante, die pro Anfrage Host und Dateinamen zeigt:

performance.getEntriesByType('resource')
  .filter(r => new URL(r.name).host !== location.host)
  .map(r => new URL(r.name).host + ' -- ' + r.name.split('/').pop())

Zwei Dinge dazu. Erstens: Die Performance-API erfasst nur, was tatsächlich geladen wurde — lade die Seite also neu, bevor du das Schnipsel ausführst, sonst ist die Liste unvollständig. Wer nachlesen mag, wie getEntriesByType arbeitet, findet das bei MDN. Zweitens: Der Netzwerk-Reiter bleibt trotzdem wichtig, denn nur dort siehst du den HTTP-Statuscode. Genau der hat mir den interessantesten Fund geliefert.

Die eigentliche Fundstelle: drei fremde Anbieter

Schriften, Avatare und ein kaputtes Banner

Null Cookies — und trotzdem sprach mein Blog beim Aufruf mit drei fremden Anbietern unter vier Hostnamen. Jeder dieser Aufrufe überträgt die IP-Adresse des Besuchers dorthin, ganz ohne etwas zu speichern. Das ist die Tabelle, die ich mir aus der Messung gezogen habe:

Der Gravatar-Eintrag ist das Argument für Schritt sechs der Anleitung. Auf der Startseite und im frischen Beitrag war dieser Host nicht dabei — er kam erst dazu, als ich einen Beitrag mit Kommentaren geöffnet habe. Hätte ich nur die Startseite gemessen, wäre er mir schlicht entgangen, und ich hätte guten Gewissens das Falsche behauptet.

Der schönste Fund ist aber das Werbebanner. Der Aufruf zu www.netcup.de antwortete mit HTTP 503 — der Server war nicht bereit, das Bild kam nie an, im Layout blieb eine leere Stelle. Ein kaputtes Werbebanner ist damit doppelt sinnlos: Es zeigt nichts, und es kontaktiert trotzdem einen Dritten. Der Fremdzugriff findet statt, sobald der Browser die Anfrage abschickt. Ob eine Antwort zurückkommt, ändert daran nichts. Solche Karteileichen findet man nur, wenn man selbst nachmisst — im gerenderten Layout sieht man eine leere Stelle und denkt an einen CSS-Fehler. In dieselbe Kategorie gehören übrigens viele der Dinge, die ich in meinem Beitrag über SEO-Fehler im eigenen Blog aufgeschrieben habe: Kleinigkeiten, die man nur bemerkt, wenn man den eigenen Laden einmal von außen betrachtet.

Matomo lief — aber ohne Cookie

Bleibt die Frage, warum überhaupt keine Analyse-Cookies auftauchten, obwohl auf bloggen.xyz Matomo zählt. Die Antwort steckte im Netzwerk-Reiter: Die Zählung läuft über die eigene Domain, konkret über den Pfad /wp-content/plugins/matomo-tracker/inc/frontend/piwik.php. Der eigentliche Matomo-JavaScript-Tracker wird dabei gar nicht geladen. Ich habe das in der Konsole gegengeprüft:

window.Matomo
// undefined

Es bleibt bei vier abgesetzten _paq-Befehlen — der Warteschlange, die ein Matomo-Tracker normalerweise abarbeiten würde. Weil das Skript, das Cookies setzen würde, nie zum Einsatz kommt, gibt es auch keine _pk_id, _pk_ses und _pk_ref. Cookielose Zählung über die eigene Domain, ob nun bewusst so konfiguriert oder als Nebenwirkung — gemessen ist gemessen. Ein Einwilligungsbanner lief zum Zeitpunkt dieser Messung auf der Seite noch nicht. Nachtrag: Inzwischen ist eines im Einsatz — eine der freien Varianten, die ich in meinem Beitrag über kostenlose Open-Source-Consent-Plugins nebeneinandergelegt habe. Es speichert selbst ein Cookie, aber erst dann, wenn im Banner eine Auswahl getroffen wurde. Wer die Messung heute wiederholt, sieht also genau ein Cookie mehr als ich — und das ist ein gutes Beispiel dafür, warum eine Messung immer ein Datum braucht.

Warum die Cookies gar nicht das Thema sind

Speichern ist nicht dasselbe wie übertragen

Hier kommt die Pointe der ganzen Messung. Cookies wären eine Frage von § 25 TDDDG, der ans Speichern von Informationen auf dem Endgerät und an den Zugriff darauf anknüpft — nachlesbar im Gesetzestext bei gesetze-im-internet.de. Eine eingebettete Schriftart oder ein Avatarbild speichert auf dem Endgerät des Besuchers nichts. Sie überträgt aber dessen IP-Adresse an einen Dritten, und zwar bevor der Besucher irgendetwas anklicken konnte. Wer seine Seite ausschließlich auf Cookies abklopft, übersieht genau diese Aufrufe — und das war bei mir die gesamte Ausbeute. Das ist keine Rechtsberatung, ich bin kein Anwalt, und ich lege hier bewusst keine Norm aus. Was ich sagen kann: Die Messung zeigt mir, worüber ich mit jemandem sprechen müsste, der das darf.

Der praktische Nutzen ist davon unabhängig. Eine Seite, die Schriften und Bilder von fremden Servern zieht, ist langsamer, verletzlicher gegenüber fremden Ausfällen — siehe das 503er-Banner — und schwerer zu erklären. Drei Aufrufe weniger sind drei Abhängigkeiten weniger.

Meine Aufräumliste nach der Messung

• Erledigt: Google Fonts lokal eingebunden. Die Schriftdateien liegen seit dem 28.08.2026 im Theme, die Aufrufe zu fonts.googleapis.com und fonts.gstatic.com sind ersatzlos verschwunden — nachgemessen mit demselben Einzeiler von oben.
• Gravatar abschalten oder ersetzen. WordPress bringt lokale Standard-Avatare mit, die keinen fremden Host brauchen.
• Erledigt: das kaputte Banner rausgenommen. Inzwischen liegt an seiner Stelle ein Banner, dessen Bilddatei vom eigenen Server kommt — ein Fremdaufruf weniger. Der Anlass war die Messung: Das alte Banner lieferte nur noch einen 503er — ein Bild, das niemand sieht, muss auch niemand laden.
• Datenschutzerklärung nachziehen. Nicht nach Gefühl, sondern gegen die gemessene Liste.
• Nach jeder Theme- oder Plugin-Änderung neu messen. Die zwei Konsolenzeilen von oben dauern eine Minute.

Zwei dieser Punkte habe ich inzwischen erledigt, einer ist noch offen, und auch das schreibe ich absichtlich hin: Ein Werkstattbericht, in dem am Ende alles erledigt ist, ist meistens geschönt. Die Messung selbst kostet fast nichts — das Aufräumen kostet die Zeit. Wenn du beim Prüfen deiner eigenen Seite in ein Formular gerätst, das sich seltsam verhält, hilft dir vielleicht mein Beitrag über ein Formular ohne form-Tag. Und was ich sonst so an Werkzeugen benutze, steht gesammelt bei den Blogger-Tools.

Häufige Fragen zu Cookies und Einbindungen

Fragen zum Messen

Fragen zu den Fremdhosts