Suchprotokolle sollten OpenSearch-Platzhalterbegriffe ignorieren und optional KI-Agent-Suchen kennzeichnen

Merkmal
,
1

Zusammenfassung

Der Bericht Beliebte Suchbegriffe wird durch Platzhalter für OpenSearch-URL-Vorlagen (z. B. {searchTerms}) verunreinigt, die keine echten Suchanfragen sind. Dies führt dazu, dass das Dashboard irreführend ist (oft wird {searchTerms} als „beliebtester Suchbegriff“ mit 0 % Klickrate angezeigt).

Darüber hinaus wäre es angesichts der zunehmenden KI-gesteuerten Navigation nützlich, von KI-Agenten initiierte Suchanfragen optional in der Suchanalyse separat zu kennzeichnen.

Problem 1: OpenSearch-Platzhalter-Rauschen in SearchLog

Auf meiner Seite erscheint {searchTerms} als beliebtester Suchbegriff mit Tausenden von Einträgen und 0 % Klickrate. Diese Einträge stammen von Crawlern/Bots (z. B. Googlebot, Bingbot usw.), die /opensearch.xml crawlen und den Such-Endpunkt mit der wörtlichen Platzhalterzeichenfolge anstelle einer echten Abfrage aufrufen.

Dies wurde bereits diskutiert:

Aber die Platzhalterbegriffe erscheinen weiterhin in der Analyse.

Schritte zur Reproduktion

  1. OpenSearch aktivieren/bereitstellen (z. B. /opensearch.xml) für die Seite
  2. Crawlern den Zugriff erlauben (Standardverhalten öffentlich)
  3. Warten, bis Crawler die OpenSearch-Vorlage abrufen und den Such-Endpunkt aufrufen
  4. Admin → Berichte → Beliebte Suchbegriffe aufrufen
  5. Beobachten, wie Platzhalterwerte wie {searchTerms} den Bericht dominieren

Erwartetes Verhalten

Platzhalter-/Vorlagenzeichenfolgen, die von OpenSearch-Clients verwendet werden, sollten nicht als echte Suchanfragen protokolliert werden und nicht in den Beliebten Suchbegriffen erscheinen.

Tatsächliches Verhalten

Platzhalterzeichenfolgen (z. B. {searchTerms}) werden in SearchLog gespeichert und als echte Suchbegriffe angezeigt, wodurch die Analyse verunreinigt wird.

Vorgeschlagene Lösung

Bekannte OpenSearch-Platzhalterzeichenfolgen filtern, bevor sie in SearchLog protokolliert werden, zum Beispiel:

  • {searchTerms}
  • {search_term_string}

(Wenn es andere gängige Varianten gibt, wäre deren Hinzufügung ebenfalls in Ordnung.)

Dies ist im Grunde „Bot-Rauschen“, niemals eine legitime menschliche Abfrage, und es beeinträchtigt die Nützlichkeit des Berichts.

Größere Chance: KI-Ära Suchanalyse (Optional / Mittelfristig – Langfristig)

Das Problem mit {searchTerms} hebt eine breitere Lücke hervor: Ein wachsender Teil der Suchanfragen wird von KI-Agenten im Auftrag von Benutzern durchgeführt (z. B. wenn ein Benutzer einen Assistenten bittet, „dieses Forum nach X zu durchsuchen“). Diese Suchanfragen können eine echte Benutzerabsicht darstellen, sind aber derzeit mit allem anderen Datenverkehr vermischt und schwer zu verstehen.

Mittelfristig (Optional)

Suchanfragen, die wahrscheinlich von KI-Agenten initiiert wurden, mithilfe von User-Agent-Heuristiken kennzeichnen (nur Beispiele):

  • ChatGPT-Browsing / Agenten-UA-Varianten
  • Perplexity-Bots
  • Claude-bezogene Agenten
  • Google AI-bezogene UAs (z. B. GoogleOther usw.)

Dies müsste nicht perfekt sein – nur gut genug, um Administratoren Einblick zu geben.

Langfristig (Optional)

Einen Filter/Tab „KI-Suche“ im Bericht Beliebte Suchbegriffe hinzufügen, damit Administratoren sehen können:

  • Menschliche Suchanfragen
  • KI-Agenten-Suchanfragen
  • Alles kombiniert

Warum das wichtig ist

  • Die Platzhalter-Verunreinigung macht das Dashboard weniger vertrauenswürdig und kann die „Beliebten“ dominieren
  • Administratoren sollten Analysen nicht manuell bereinigen oder fehlerhafte Top-Einträge ignorieren müssen
  • Der durch KI vermittelte Suchverkehr nimmt zu, und Website-Betreiber profitieren von Einblicken in diese Absichten