Eine Website-Suche wirkt harmlos: Besucher geben einen Begriff ein, die Seite liefert passende Inhalte, alle sind schneller am Ziel. Für Website-Betreiber ist die interne Suchfunktion aber nicht nur ein Komfortfeature. Suchbegriffe können viel über Absichten, Probleme, Interessen oder sensible Situationen verraten. Wer auf einer Kanzlei-, Arzt-, Beratungs-, Shop- oder Vereinswebsite nach bestimmten Themen sucht, hinterlässt möglicherweise mehr Kontext als in einem normalen Seitenaufruf.

Datenschutzrechtlich wird es besonders relevant, wenn Suchanfragen zusammen mit IP-Adressen, Nutzerkonten, Cookie-IDs, Session-IDs, Gerätedaten oder Analytics-Profilen gespeichert werden. Dann entstehen Query-Logs, die personenbezogene Daten enthalten können oder sich zumindest mit anderen Daten auf Personen beziehen lassen. Dieser Beitrag zeigt, wie Website-Betreiber in Deutschland ihre Website-Suche pragmatisch prüfen können, ohne das Feature vorschnell abzuschalten. Er ersetzt keine individuelle Rechtsberatung, hilft aber bei einer strukturierten Bestandsaufnahme.

Warum Suchbegriffe sensibler sein können als Klicks

Ein Klick auf eine Kategorie sagt meist nur, dass jemand eine Seite geöffnet hat. Eine Suchanfrage ist aktiver und konkreter. Sie kann ein Problem, eine Beschwerde, einen Namen, eine Krankheit, ein Produktinteresse, eine Zahlungsfrage oder eine interne Bezeichnung enthalten. Gerade auf spezialisierten Websites tippen Menschen Begriffe ein, die sie in keinem Kontaktformular preisgeben würden.

Das Risiko entsteht nicht allein durch den Suchbegriff. Entscheidend ist der Kontext: Wird die Anfrage nur flüchtig verarbeitet oder dauerhaft gespeichert? Gibt es eine Nutzeranmeldung? Werden die Begriffe an ein Analyse-Tool übergeben? Läuft die Suche über einen externen Anbieter? Werden Autocomplete-Vorschläge schon während des Tippens gesendet? Je mehr Datenpunkte zusammenkommen, desto eher muss die interne Suche wie ein eigener Verarbeitungsvorgang behandelt werden.

Für die Datenschutzerklärung heißt das: Wenn Suchanfragen gespeichert, ausgewertet oder an Dritte übermittelt werden, sollte das nicht irgendwo zwischen allgemeinen Server-Logfiles verschwinden. Der Datenschutz Generator kann nur dann passende Texte liefern, wenn die tatsächliche Suche und ihre Datenflüsse bekannt sind.

Interne Suche, externe Suche oder Plugin?

Viele WordPress-Websites nutzen die eingebaute Suche oder ein Such-Plugin. Andere binden Dienste wie eine programmierbare Suchmaschine, externe Suchindizes, Shop-Suchanbieter oder Cloud-Komponenten ein. Diese Varianten unterscheiden sich deutlich. Eine lokal betriebene Suche kann Suchbegriffe in der eigenen Datenbank oder nur temporär verarbeiten. Ein externer Dienst kann Suchanfragen, IP-Adressen, Browserdaten und technische Nutzungsdaten auf eigenen Servern verarbeiten. Ein Plugin kann zusätzliche Logs, Rankingdaten oder Suchstatistiken anlegen.

Deshalb ist die erste Prüfentscheidung schlicht: Wer sieht die Suchanfrage? Nur der eigene Server, ein Hosting-Dienstleister, ein Plugin-Anbieter, ein externer Suchanbieter oder zusätzlich ein Analytics-System? Diese Frage wirkt banal, ist aber der Kern. Sie entscheidet darüber, ob Auftragsverarbeitung, Drittlandtransfer, Consent-Konfiguration, Datenschutzhinweise und Löschfristen aktualisiert werden müssen.

Auch aus Online-Marketing-Sicht sind Suchbegriffe wertvoll. Sie zeigen, welche Inhalte fehlen oder wie Nutzer Produkte benennen. Wer diese Daten für Content-Optimierung nutzt, sollte den Zweck sauber trennen: technische Bereitstellung der Suche, Sicherheitsdiagnose, Verbesserung der Suchergebnisse und Marketing-/Content-Analyse sind nicht automatisch derselbe Zweck. Für SEO- und Content-Teams kann der Abgleich mit Online Marketing-Zielen sinnvoll sein, sollte aber nicht zu einer stillen Profilbildung werden.

Query-Logs brauchen einen Zweck

Die DSGVO verlangt nicht, dass jede Suchanfrage sofort gelöscht wird. Sie verlangt aber einen nachvollziehbaren Zweck, eine passende Rechtsgrundlage, transparente Information und Datenminimierung. Wenn Suchlogs genutzt werden, um Fehler zu erkennen, Spam zu bekämpfen oder die Suchqualität zu verbessern, sollte klar dokumentiert sein, welche Daten dafür wirklich nötig sind. Oft reicht eine gekürzte oder gehashte IP-Adresse, eine grobe Zeitangabe oder eine aggregierte Auswertung.

Ein häufiger Fehler ist die unbegrenzte Speicherung kompletter Suchbegriffe mit vollständiger IP-Adresse und Session-ID. Das ist bequem, aber selten erforderlich. Sinnvoller ist eine abgestufte Lösung: kurzfristige technische Logs für Fehlersuche, danach Aggregation oder Löschung; separate Auswertung von häufigen Suchbegriffen ohne Personenbezug; keine Verbindung mit Marketing-IDs, wenn das für die Suchfunktion nicht nötig ist.

Wer bereits Server-Logfiles dokumentiert, kann die Suche in diesen Prozess einhängen. Der Beitrag zu Server-Logfiles und Datenschutz zeigt, warum Speicherdauer, Zugriff und Zweckbindung nicht erst beim Webserver beginnen. Query-Logs sind meist näher am Nutzerinteresse und verdienen deshalb eine eigene Zeile im Verzeichnis oder zumindest in der technischen Datenschutzdokumentation.

Autocomplete und Live Search gesondert prüfen

Autocomplete, Live Search und Vorschläge während des Tippens erhöhen den Komfort, erzeugen aber mehr Datenpunkte. Jede Teilanfrage kann an den Server oder einen externen Anbieter gesendet werden. Aus einer einzigen Suche werden dann mehrere Requests: “dat”, “daten”, “datenschutz”, “datenschutzerklärung”. Wenn diese Requests mit Zeitstempeln und technischen Kennungen gespeichert werden, entsteht ein genaueres Nutzungsprofil.

Betreiber sollten daher prüfen, ob Live Search wirklich gebraucht wird. Für viele KMU-Websites reicht eine klassische Suche nach dem Absenden. Wenn Autocomplete wichtig ist, kann Debouncing helfen, also das verzögerte Senden erst nach einer kurzen Pause. Auch Mindestzeichenlängen, lokale Vorschlagslisten oder serverseitige Begrenzungen reduzieren unnötige Daten. Bei externen Diensten ist zusätzlich zu prüfen, ob bereits die Tippvorschläge übermittelt werden.

Wenn Cookies, Local Storage oder ähnliche Technologien zur Suchfunktion gehören, kann zusätzlich § 25 TDDDG relevant werden. Der Consent Manager sollte dann nicht nur klassische Tracking-Dienste kennen, sondern auch Such- und Vorschlagsfunktionen, soweit sie nicht technisch unbedingt erforderlich sind oder externe Einbindungen auslösen.

Transparenz in der Datenschutzerklärung

Eine gute Datenschutzerklärung beschreibt nicht nur Anbieterlisten, sondern verständliche Prozesse. Bei der Website-Suche sollten Nutzer erkennen können, ob Suchbegriffe gespeichert werden, ob externe Anbieter beteiligt sind, welche Datenkategorien betroffen sind, wie lange Logs aufbewahrt werden und ob Suchdaten für Analyse oder Optimierung genutzt werden. Das muss nicht überkompliziert sein. Ein klarer Absatz ist besser als ein technischer Nebensatz, der die eigentliche Verarbeitung verschleiert.

Der jüngste Beitrag zu DSGVO-Transparenzpflichten auf Websites passt hier gut: Transparenz wird prüfbarer, wenn Text, Technik und Prozess zusammenpassen. Wer in der Datenschutzerklärung schreibt, Suchdaten würden nur kurzfristig verarbeitet, sollte keine Plugin-Tabelle mit mehrjährigen Query-Logs betreiben. Wer externe Suchanbieter nutzt, sollte nicht so formulieren, als laufe alles ausschließlich lokal.

Bei umfangreichen Websites kann eine gemeinsame Prüfung von Datenschutzerklärung, Consent-Konfiguration, Plugins und Log-Routinen sinnvoll sein. Das Business Paket ist genau für solche Fälle hilfreich, weil es die einzelnen Bausteine nicht isoliert betrachtet.

Betroffenenrechte nicht vergessen

Suchlogs können bei Auskunfts- oder Löschanfragen relevant werden. Wenn ein Nutzer angemeldet war oder Suchanfragen über Kennungen einer Person zugeordnet werden können, können diese Daten vom Auskunftsrecht erfasst sein. Der EDPB weist in seinen Leitlinien zum Auskunftsrecht ausdrücklich darauf hin, dass personenbezogene Daten in Logfiles grundsätzlich vom Auskunftsrecht umfasst sein können. Das ist für Website-Teams wichtig, weil Logs oft als “technisch” und damit als weniger relevant behandelt werden.

Praktisch heißt das: Betreiber sollten wissen, ob und wie Suchdaten einer Person zugeordnet werden können. Sie brauchen keinen riesigen Exportprozess für Daten, die gar nicht personenbezogen gespeichert werden. Aber wenn Query-Logs mit Nutzerkonten, Tickets, Bestellungen oder eindeutigen IDs verbunden sind, muss der Prozess für Betroffenenrechte mitgedacht werden. Der Beitrag zu Auskunftsanfragen über die Website zeigt, warum solche Zuständigkeiten besser vor dem Ernstfall geklärt werden.

Checkliste für Website-Betreiber

Für einen ersten Review reicht eine kompakte technische und organisatorische Liste. Erstens: Welche Suchfunktion ist aktiv? Zweitens: Wo werden Suchbegriffe verarbeitet? Drittens: Welche Logs entstehen automatisch? Viertens: Welche Anbieter erhalten Daten? Fünftens: Wie lange werden Suchdaten gespeichert? Sechstens: Sind Datenschutzerklärung und Consent-Konfiguration passend?

  • WordPress-Core-Suche, Plugin, Shop-Suche und externe Suche einzeln erfassen.
  • Prüfen, ob Suchbegriffe mit IP-Adresse, Konto, Session, Cookie-ID oder Analytics-ID gespeichert werden.
  • Autocomplete und Live Search auf Teilanfragen, externe Requests und Speicherdauer testen.
  • Query-Logs nur so lange speichern, wie der dokumentierte Zweck es trägt.
  • Häufige Suchbegriffe möglichst aggregiert oder anonymisiert für Content-Optimierung nutzen.
  • Externe Suchanbieter auf Verträge, Datentransfers, Anbietertexte und technische Einbindung prüfen.
  • Datenschutzerklärung, Consent Manager und Plugin-Konfiguration nach jeder Änderung abgleichen.

Wer diese Punkte einmal sauber dokumentiert, hat nicht nur Datenschutzvorteile. Die Suche wird oft auch fachlich besser, weil unnötige Logs verschwinden, echte Nulltreffer sichtbar werden und Content-Lücken klarer werden.

Fazit: Suche ist ein kleines Feature mit großem Kontext

Die Website-Suche sitzt an einer interessanten Schnittstelle: Nutzer sagen dort sehr direkt, was sie brauchen. Genau deshalb ist sie für Content, Support und Shop-Optimierung wertvoll. Gleichzeitig können Suchbegriffe sensibler sein als normale Seitenaufrufe. Datenschutz beginnt hier mit einer nüchternen Frage: Welche Suchdaten brauchen wir wirklich?

Betreiber sollten Suchfunktion, Query-Logs, Autocomplete, externe Anbieter und Datenschutzhinweise gemeinsam prüfen. Wer Suchdaten kurz hält, Personenbezug reduziert, Zwecke trennt und die Datenschutzerklärung aktuell hält, kann eine gute Suche anbieten, ohne unnötige Datenberge aufzubauen.

Quellen und weiterführende Hinweise