Source: https://bscan.info/de/blog/can-websites-see-browsing-history
Language: de

Keine Seite bekommt eine Liste deiner besuchten Websites. Referrer, Tracker und dein ISP sehen je einen Ausschnitt. Teste live, wer in deinem Browser was sieht.

# Können Websites deinen Browserverlauf sehen? Live-Test

Veröffentlicht 12\. November 2026

Du hast dir einmal Wanderstiefel angesehen, auf der Seite eines einzigen Shops. Jetzt will dir jede Seite, die du öffnest, Wanderstiefel verkaufen. Naheliegend wäre der Schluss, dass Websites deinen Browserverlauf lesen und weitergeben. Das können sie nicht. In aktuellen Browsern kann keine Website die Liste der Websites auslesen, die du besucht hast, und trotzdem wirst du verfolgt.

Das Widget auf dieser Seite fragt deinen eigenen Browser, was er einer Seite darüber verrät, wo du warst. Fast nichts, und das mit Absicht.

**Die Kurzfassung:** Eine Seite kann deinen Browserverlauf nicht lesen, also die Liste der Websites, die du besucht hast. Der Trick, der früher einen nachbaute, das Abfragen von `:visited`\-Links, ist seit 2010 Schritt für Schritt abgeschaltet worden. Was eine Seite noch lesen kann, ist wenig: die Website, von der du kommst, wie viele Schritte dein Zurück-Button zurückgeht und ihre eigenen Aufzeichnungen über dich. Den Rest des Bildes setzen Tracker zusammen, die auf vielen Websites sitzen, und die Netze, die deinen Datenverkehr transportieren.

## Keine API gibt deinen Verlauf heraus

Sieh dir an, was `window.history` einem Skript bietet: `back()`, `forward()`, `go()`, `pushState()`, `replaceState()`, `state`, `scrollRestoration` und eine `length`. Nichts davon liefert eine Adresse. `history.length` zählt die Einträge des aktuellen Tabs und ist in Chrome und Firefox bei 50 gedeckelt (Safari speichert bis zu 100), sagt also wenig darüber aus, wie viel du gesurft bist.

Die neuere Navigation API, `navigation.entries()`, liefert zwar Adressen, aber nur für Einträge im aktuellen Tab, die denselben Origin wie die Seite haben, und nur den ununterbrochenen Abschnitt davon. Eine Seite liest nur ihre eigene Spur, nie die einer anderen. In meinem Test mit Chromium 156 meldete `history.length` den Wert 2, nachdem ich einem Link von einem anderen Origin auf diese Seite gefolgt war, und `navigation.entries()` listete einen Eintrag, die aktuelle Seite. Firefox und Safari habe ich nicht getestet.

## Der :visited-Trick und wie er starb

Jahrelang gab es eine Hintertür. Browser stellen besuchte Links in einer anderen Farbe dar, und eine Seite durfte abfragen, welche Farbe ein Link am Ende hatte. Ein Skript legte deshalb einen unsichtbaren Link auf die Login-Seite einer Bank an, las seine berechnete Farbe aus und wusste, ob du dort gewesen warst. Mozilla bezifferte das Tempo auf Hunderttausende Links pro Minute, ohne Rückfrage und ohne dass du etwas bemerkt hättest.

Im März 2010 [kündigte Mozilla die Korrektur an](https://blog.mozilla.org/security/2010/03/31/plugging-the-css-history-leak/): `getComputedStyle` antwortet seither so, als wäre jeder Link unbesucht, und besuchte Links lassen sich nur noch über wenige Farbeigenschaften gestalten. Jede große Engine arbeitet heute so. Die erste Zeile des Widgets zeigt es. Es fragt nach einem Link auf die Seite, die du gerade liest und die du per Definition besucht hast, und dein Browser sagt Nein.

Eine Lüge über Farben schließt nur den direkten Weg. Forscher fanden immer wieder Seitenkanäle, etwa Paul Stones Angriff von 2013, der misst, wie lange ein besuchter Link zum Neuzeichnen braucht, und jeder davon brauchte einen eigenen Patch. Chromes Antwort, [seit Version 136 verfügbar](https://developer.chrome.com/blog/visited-links) auf Desktop und Android, ändert, wo Besuche gespeichert werden. Die Liste besuchter Links ist keine einzelne Liste mehr. Jeder Eintrag liegt unter einem Schlüssel aus drei Teilen: der Link-Adresse, der Top-Level-Site, auf der du warst, und dem Frame, der den Link angezeigt hat. Eine Seite auf `blog.example`, die nach der Bank fragt, schlägt jetzt unter einem anderen Schlüssel nach als dem, unter dem dein Bankbesuch gespeichert wurde, und findet nichts.

Was eine Abfrage mit versteckten Links herausfindet

Vor Chrome 136, sofern ein Seitenkanal funktioniert

Deine besuchten Links

-   `bank.example/login` besucht von bank.example
-   `news.example/story` besucht von einer Suchseite
-   `blog.example/post` besucht von blog.example

Eine Seite auf blog.example fragt nach drei Links

-   `bank.example/login` besucht: verraten
-   `news.example/story` besucht: verraten
-   `blog.example/post` besucht (wusste sie schon) ihre eigene Seite

Mit einer gemeinsamen Liste erfährt eine Seite, die irgendeinen Seitenkanal findet, wo du dein Banking erledigst und was du liest.

Die eigenen Seiten einer Website erscheinen weiterhin als besucht, egal wo du sie zuerst geöffnet hast, ebenso Links, die du von dieser Website aus angeklickt hast. Das kostet nichts, denn beides weiß die Website ohnehin. Soweit ich es prüfen konnte, haben Firefox und Safari kein Gegenstück zu dieser Trennung, und Chrome auf iOS ebenso wenig, denn es läuft auf WebKit. Auch die Regel von 2010 war nicht lückenlos: Apples [Hinweise zu Safari 26.6](https://support.apple.com/en-us/128073) vom Juli 2026 beheben einen WebKit-Fehler, durch den Websites erfahren konnten, ob du einen bestimmten Link besucht hattest.

## Was kann eine Website über dein Surfen sehen?

**Der Referrer.** Kommst du von einem Suchergebnis, erfährt die Seite womöglich, welche Website dich geschickt hat. Seit Chrome 85 und Firefox 87 ist für Navigationen zwischen verschiedenen Origins standardmäßig nur noch der Origin im Referrer, also `https://www.google.com/` und nicht deine Suchanfrage, es sei denn, die sendende Website legt eine eigene Richtlinie fest. Auch Safari kürzt Referrer bei websiteübergreifenden Navigationen. Im selben Chromium-156-Test hatte die Seite, von der ich kam, einen langen Pfad, und `document.referrer` gab nur ihren Origin zurück. Hast du die Adresse getippt oder ein Lesezeichen benutzt, ist der Referrer leer. Deshalb sieht eine Website, auf die du durchklickst, auch nicht, wonach du gesucht hast: Deine Suchen liegen bei der Suchmaschine und deinem Konto, nicht bei der Seite.

**Ihre eigenen Aufzeichnungen.** Das ist der größte Brocken, und er ist unspektakulär. Eine Website, die bei deinem Besuch letzten Dienstag ein Cookie gesetzt hat, erkennt dich diesen Dienstag wieder. Das ist der Verlauf einer einzelnen Website, nicht des Webs, und jede Website, die du besuchst, führt einen eigenen über dich. Der Betreiber sieht seine eigenen Besucher in seiner Analytics-Auswertung, mit Seitenadressen, IP-Adressen und Referrern, und dieser Blick endet am Rand der Website.

**Ein paar Lecks an den Rändern.** Mit websiteübergreifenden Tricks lässt sich manchmal feststellen, ob du anderswo eingeloggt bist: Man lädt etwas, das nur für angemeldete Nutzer funktioniert, und misst, was passiert. Das [XS-Leaks-Wiki](https://xsleaks.dev/) katalogisiert die ganze Familie. Sie verrät einer Seite jeweils ein Bit über eine Website, und manche Kanäle werden geschlossen, während neue auftauchen. Nichts davon ähnelt einer Liste.

## Wie Tracker trotzdem einen Browserverlauf von dir aufbauen

Die Werbung folgt dir meist deshalb, weil noch jemand anderes auf der Seite ist. Das Skript eines Werbenetzwerks sitzt im Schuhshop und auf der Nachrichtenseite. Erkennt es dich auf beiden wieder, besitzt es einen Browserverlauf von dir, Website für Website zusammengesetzt, ganz ohne Hilfe des Verlaufs in deinem Browser. Die US-Verbraucherschutzbehörde FTC hat eine verständliche [Übersicht darüber, wie Websites und Apps das erfassen](https://consumer.ftc.gov/articles/how-websites-and-apps-collect-and-use-your-information).

Safari blockiert Cookies von Drittanbietern komplett, und Firefox trennt sie pro Website. Stand November 2026 erlaubt Chrome sie standardmäßig weiterhin. Cookies sind nur eine Möglichkeit, dich wiederzuerkennen. Ein [Canvas-Fingerprint](https://bscan.info/de/blog/canvasHash) kann in den meisten Browsern auf jeder Website gleich bleiben, ohne dass etwas gespeichert wird, und deshalb hilft das Löschen deines Verlaufs dagegen nicht.

Das Skript eines Trackers läuft außerdem innerhalb der Seite, auf der er sitzt, und kann deshalb Adresse und Titel dieser Seite lesen, statt nur zu vermerken, dass du aufgetaucht bist. Unser Beitrag darüber, [was eine Seite während eines Besuchs beobachten kann](https://bscan.info/de/blog/can-websites-see-tab-switching), behandelt den Rest.

## Wer sonst noch deinen Browserverlauf sehen kann

Lass die Seite einmal weg und sieh dir alle anderen auf dem Weg zwischen dir und einer Website an. Die meisten sehen nur einen Teil. Die Ausnahme ist das synchronisierte Browser-Konto.

Wer welchen Ausschnitt deines Verlaufs sieht

Wer

Welche Websites

Welche Seiten und Suchen

Was die Seiten zeigen

Die Website, auf der du bist

Sieht einen Teil: Name der Vorgängerseite, falls gesendet

Sieht es nicht: nur die eigenen Seiten

Sieht es nicht: nur die eigenen Inhalte

Ein Tracker, der auf beiden Websites eingebunden ist

Sieht es: wo er eingebunden ist, wenn er dich erkennt

Sieht es: Adressen der Seiten, auf denen er sitzt, wenn sein Skript dort läuft

Sieht einen Teil: Seitentitel und alles, was sein Skript sonst liest

Dein ISP oder der WLAN-Betreiber

Sieht es: meist Domainnamen und die Server-IPs

Sieht es nicht: Pfade sind bei HTTPS verschlüsselt

Sieht es nicht: verschlüsselt

Dein synchronisiertes Browser-Konto

Sieht es: alles, wenn die Synchronisierung an ist und der Anbieter mitlesen kann

Sieht es: vollständige Adressen, wenn lesbar

Sieht es nicht: nicht gespeichert

-   Sieht es
-   Sieht einen Teil
-   Sieht es nicht

Die meisten Zeilen sehen einen Ausschnitt. Nur ein synchronisiertes Konto sieht alles, und nur wenn der Anbieter mitlesen kann. Ein VPN nimmt dem ISP seinen Ausschnitt nicht weg, es verlagert ihn zur VPN-Firma.

Dein ISP oder wer auch immer das WLAN im Hotel oder im Büro betreibt, kann bei HTTPS-Websites keine Seitenadressen lesen. Die Domainnamen sieht er meist trotzdem, denn die DNS-Abfrage und der Anfang der TLS-Verbindung nennen die Website. Verschlüsseltes DNS und Encrypted Client Hello können das bei manchen Websites verbergen, aber die IP-Adresse des Servers bleibt sichtbar. Ein VPN löscht diesen Ausschnitt nicht. Es reicht das meiste davon an die VPN-Firma weiter, und deinem ISP bleibt das Wissen, dass du eines nutzt. Wie Websites das erkennen, behandeln wir in [VPN-Erkennung](https://bscan.info/de/blog/vpn-detection).

Die Zeile, die man vergisst, ist das eigene Browser-Konto. Ist die Verlaufssynchronisierung an, kann eine vollständige Liste der Adressen, die du geöffnet hast, auf dem Server des Anbieters liegen. In Chrome kann Google den synchronisierten Verlauf lesen, solange du keine Synchronisierungs-Passphrase gesetzt hast, und mit einer werden nur die Adressen synchronisiert, die du in die Adressleiste getippt hast. Firefox Sync und iCloud verschlüsseln den Verlauf, die Anbieter können ihn also nicht lesen.

## Ändern Inkognito-Modus, gelöschter Verlauf oder ein Smartphone etwas?

Der private Modus verhindert, dass dein eigener Browser die Liste speichert, und startet dich mit leeren Cookies. Die Website, dein ISP und der WLAN-Betreiber sehen den Besuch trotzdem, und in den meisten Browsern erkennt dich ein Fingerprint weiterhin. Safari, Firefox in privaten Fenstern, Brave und Tor verrauschen oder vereinheitlichen die Messwerte, was das erschwert. Das Löschen deines Verlaufs löscht die Liste, die dein Browser führt, samt der synchronisierten Kopie, aber nicht das, was Websites, Tracker oder dein ISP schon haben. Ein Aktivitätsprotokoll im Konto, etwa Googles „Meine Aktivitäten“, behält seine eigene Kopie, bis du sie dort löschst. Ein Handy folgt derselben Logik: Die Seite bekommt dieselben wenigen Werte, und der Verlauf, auf den es ankommt, liegt im Konto oder im Netz, nicht im Browser. Geht es dir also um den Partner oder die Eltern, schau an zwei Stellen nach: bei einem Konto, das ihr beide öffnen könnt, mit Synchronisierung und Aktivitätsprotokoll, und bei dem Netz, über das der Datenverkehr läuft.

## Was du konkret tun kannst

1.  **Sieh dir die erste Zeile des Widgets an.** Dort sollte „Geschlossen“ stehen. Steht dort „Undicht“, ist dein Browser älter als die Korrektur von 2010 oder es fehlt ein Patch. Aktualisiere ihn, und achte unter Safari darauf, dass du Version 26.6 oder neuer hast.
2.  **Prüfe, was du synchronisierst.** Öffne die Sync-Einstellungen deines Browsers und entscheide, ob der Verlauf im Konto liegen muss. In Chrome verhindert eine Sync-Passphrase, dass Google ihn liest. Firefox Sync und iCloud verschlüsseln den Verlauf standardmäßig.
3.  **Das Löschen des Verlaufs stoppt das Tracking nicht.** Es entfernt die Liste, die dein Browser führt, samt der synchronisierten Kopie. Cookies und Websitedaten fasst es nicht an, und was Websites, Tracker oder dein ISP schon haben, erreicht es nicht. Das Löschen der Cookies kappt die Cookie-Hälfte des Trackings, und in den meisten Browsern überlebt die Fingerprint-Hälfte beides.
4.  **Halte Identitäten bewusst getrennt.** Tracker funktionieren durch Verknüpfung, also braucht alles, was nicht verknüpft werden soll, eigene Cookies, einen eigenen Speicher und einen eigenen Fingerprint. Betreibst du mehrere Konten auf diese Weise, gibt [Incogniton](https://www.incogniton.com/?utm_source=bscanInfo&utm_medium=Website&utm_campaign=BrowsingHistoryBlog) jedem Profil ein eigenes Set davon, sodass ein Tracker, der auf zwei Websites sitzt, zwei Fremde sieht, solange du jede Website aus einem anderen Profil öffnest und jedem Profil über einen Proxy eine eigene IP-Adresse gibst.

Das Widget prüft, was eine Seite lesen kann. Der [komplette Browser-Scan](https://bscan.info/de) prüft, was eine Seite aus Eigenschaften über dich ableiten kann, die für sich genommen harmlos aussehen: die Fingerprint-Hashes, die Lecks rund um deine IP-Adresse und ob dein Browser eine stimmige Geschichte erzählt.

[Kompletten Browser-Scan starten](https://bscan.info/de)

## Weiterlesen

[

![Can Websites Detect Remote Desktop? Test the Clues](https://bscan.info/remoteDesktopCover.svg)

Can Websites Detect Remote Desktop? Test the Clues

](https://bscan.info/blog/can-websites-detect-remote-desktop)[

![Erkennt eine Website Inspect Element und offene DevTools?](https://bscan.info/devtoolsCover.svg)

Erkennt eine Website Inspect Element und offene DevTools?

](https://bscan.info/de/blog/detect-devtools)[

![Können Websites deinen Computernamen sehen?](https://bscan.info/computerNameCover.svg)

Können Websites deinen Computernamen sehen?

](https://bscan.info/de/blog/computer-name)

---
This is the page's server-rendered documentation. Interactive browser tests, file processing and permission prompts require the HTML page; Markdown does not contain live measurements or process files.
