Konfiguration des Such-Moduls - WEBSALE Dokumentation

Die Konfiguration des Suchmoduls ist derzeit noch nicht direkt im OSB verfügbar, weder über eine grafische Oberfläche noch über eine Code-basierte Eingabe. Aktuell kann die Einrichtung ausschließlich über WEBSALE vorgenommen werden. In Kürze wird die Möglichkeit zur Konfiguration per Code bereitgestellt. Wir bitten bis dahin noch um etwas Geduld und informieren Sie, sobald diese Option zur Verfügung steht. Bis dahin teilen Sie bitte Ihre gewünschten Einstellungen Ihrem WEBSALE-Ansprechpartner mit, damit die Anpassungen im Suchmodul für Sie vorgenommen werden können. Diese Seite führt Sie vom Zusammenspiel der beiden Module über die Konfigurationshierarchie bis zu den einzelnen Parametern. Zuerst klären wir, welche Aufgabe Importmodul und Suchmodul jeweils haben. Danach folgt der Aufbau der Konfiguration in drei Ebenen. Im Anschluss werden die Einstellungen des Importmoduls beschrieben, zum Schluss die des Suchmoduls.

Importkonfiguration & Konfiguration des Suchmoduls

Damit das Suchmodul WEBSALE | search korrekt funktioniert, müssen sowohl das zugehörige Importmodul („Bereitstellen”) als auch das Suchmodul selbst konfiguriert werden. Beide Bereiche sind eng miteinander verknüpft, erfüllen jedoch unterschiedliche Aufgaben.

Importmodul der Suche

Im Importmodul werden die Daten für die Suche bereitgestellt. Hier wird definiert, welche Daten importiert und verfügbar gemacht werden, beispielsweise Produkt- und Kategoriedatenfelder, JSON-Dateien für Inhalte wie AGB, Kontakt oder FAQ, Stoppwörter und andere Suchparameter. Es reicht jedoch nicht aus, die Daten lediglich bereitzustellen. Im Suchmodul selbst muss zusätzlich konfiguriert werden, ob und wie diese Daten berücksichtigt werden sollen. Werden die bereitgestellten Daten im Suchmodul nicht aktiviert oder eingebunden, haben sie keinen Einfluss auf die Suchfunktion.

Suchmodul

Im Suchmodul wird festgelegt, wie die bereitgestellten Daten bei der Suche im Shop berücksichtigt werden, also zur Laufzeit. Das bedeutet, dass beispielsweise importierte Stoppwörter, Filterregeln oder Datenfelder aktiv in der Such- und Filterlogik verwendet werden. Erst die Kombination aus bereitgestellten Daten (Importmodul) und deren Aktivierung im Suchmodul stellt sicher, dass die gewünschte Suchkonfiguration vollständig und wirksam ist.

Datenfeed im Dataflow Manager

Der Datenfeed bildet die Grundlage für das Importmodul. Der Datenfeed wird im Onlineservicebereich des DataflowManagers erstellt und enthält alle Produktinformationen, die im Suchindex berücksichtigt werden. Über den Datenfeed werden sämtliche Produktdaten bereitgestellt, die durchsucht, gefiltert oder sortiert werden sollen. Dazu müssen im Dataflow Manager alle relevanten Produktfelder enthalten sein, beispielsweise Name, Beschreibung, Kategorien, Preis, Lagerbestand und Attribute. Das Importmodul greift anschließend auf diesen Feed zu und wandelt die enthaltenen Daten in das interne JSON-Format für den Elasticsearch-Index um.

Konfigurationshierarchie (ab v1.12.x / v.1.11.x)

Die nachfolgend beschriebene Konfigurationshierarchie steht ab den Plugin-Versionen websale_search v.1.12.x und elasticsearch_manager v1.11.x zur Verfügung. Die Merge-Logik gilt für Suchmodul und Importmodul gleichermaßen.

Ab diesen Versionen unterstützen beide Module eine dreistufige Konfigurationshierarchie: global_configs → language_configs → subshop_configs. Dadurch können Einstellungen einmalig auf globaler Ebene definiert und bei Bedarf auf Subshop-Ebene gezielt überschrieben werden. So lassen sich Redundanzen in der Konfiguration vermeiden. Auf der obersten Ebene (Top-Level) werden grundsätzlich nur Infrastruktur-Aliase definiert, beispielsweise für Datenbankverbindungen oder Index-Namen. Diese werden über YAML-Aliase (*name) in die untergeordneten Blöcke eingebunden.

Aktuell gibt es hiervon noch Ausnahmen. Im elasticsearch_manager wird datafeed weiterhin direkt auf Top-Level-Ebene konfiguriert. In websale_search gilt das gleiche für filter_config und suggest_config. Alle übrigen Einstellungen folgen dem dreistufigen Modell über global_configs, language_configs und subshop_configs.

x-database: &database
  base_url: http://websale-search-es-connector-es-http:9200
  connections_per_node: 15
  timeout: 30
  retries: 10
  retry_timeout: true

x-keydb: &keydb
  host: websale-search-keydb-connector
  port: 6379
  mapping:
    deutsch: 0
    englisch: 1

x-indices: &indices
  product: product
  category: category
  completion: completion
  content: content
  statistics: statistics_data
  archive: statistics_archive
  suggest: aggregated_statistics

Globale Konfiguration (`global_configs`)

global_configs bildet das unterste Level der Hierarchie. Hier definierte Werte gelten für alle Subshops, es sei denn, sie werden auf einer übergeordneten Ebene überschrieben. Suchmodul

database: *database
keydb: *keydb
indices: *indices
global_configs:
  search_config: {...}
  fields_config: {...}
  suggest_config: {...}
  filter_config: {...}
language_configs: {...}
subshop_configs: {...}

Importmodul

database: *database
keydb: *keydb
indices: *indices
global_configs:
  variant_fields: {...}
  index_configs: {...}
language_configs: {...}
subshop_configs: {...}

Sprachkonfiguration (`language_configs`)

language_configs bildet das mittlere Level der Hierarchie. Hier können Konfigurationen für Sprachgruppen definiert werden, die für alle Subshops dieser Sprache gelten. Sie können nur durch explizite Subshop-Konfigurationen überschrieben werden. Suchmodul

language_configs:
  de:
    lemmatization: {...}
    stopwords_filter: {...}
    fuzzy_filter: {...}
  en:
    lemmatization: {...}
    stopwords_filter: {...}
    fuzzy_filter: {...}

Importmodul

language_configs:
  de:
    lemmatization: {...}
    stopwords: {...}
    synonyms: {...}
    punctuation_filter: {...}
  en:
    lemmatization: {...}
    stopwords: {...}
    synonyms: {...}
    punctuation_filter: {...}

Subshop-Konfiguration (`subshop_configs`)

subshop_configs bildet das höchste Level der Hierarchie. Hier kann jeder Konfigurationsparameter für einen einzelnen Subshop explizit überschrieben werden. Der Key language in den subshop_configs verknüpft den jeweiligen Subshop mit dem zu seiner Sprache zugehörigen language_configs-Block. Suchmodul

subshop_configs:
  deutsch:
    language: de  # lädt die Config "de" aus language_configs
    keyword_mappings: {...}
    wssearchdata_mappings: {...}
  englisch:
    language: en  # lädt die Config "en" aus language_configs
    keyword_mappings: {...}
    wssearchdata_mappings: {...}

Importmodul

subshop_configs:
  deutsch:
    language: de  # lädt die Config "de" aus language_configs
    datafeed_url: https://www.example-datafeed.de/example/download/path/file-deutsch.csv
  englisch:
    language: en  # lädt die Config "en" aus language_configs
    datafeed_url: https://www.example-datafeed.de/example/download/path/file-englisch.csv

Konfiguration des Importmoduls

Datenfeed-Konfiguration

Die Zuordnung und Verarbeitung des Feeds wird im Abschnitt datafeed der Konfiguration des Importmoduls festgelegt. Hier werden Format, Encoding, Speicherpfade und die Feldzuweisungen definiert, die der Suchindex beim Import benötigt. Standardkonfiguration

datafeed:
  format_config:
    format: csv
    field_separator: "\t"
  encoding: ISO-8859-1
  chunk_size: 1000
  dir_path: /data/subshop_data
  remove_na_values: true
  new_product_days: 365
  invalid_docs_max: 0
  log_percent: 10
  product_id: number
  base_id: prodindexbase
  is_base_product: isbaseproduct
  creation_date: creationdate
  api_store_id: StoreId
  es_store_id: storeid
  inventory: inventory
  inventory_active: inventory-active
  inventory_type: inventory-type
  category_str: allcategories
  category_ids: catids
  all_category_ids: allcatids
  category_separator: "/"
  value_separator: ">"
  index_category_hierarchy: false
  normalize_negative_prices: true

Parameterbeschreibung

Parameter	Beschreibung
`format_config`	Formatspezifische Parameter des Datenfeeds, darunter das Dateiformat `format` mit den Werten `csv`, `tsv` und `json` sowie bei CSV- und TSV-Feeds das Spaltentrennzeichen `field_separator`. Siehe Formatspezifische Parameter.
`encoding`	Zeichencodierung des Feeds, beispielsweise `ISO-8859-1`. Gilt nur für CSV- und TSV-Feeds. In der V8s werden dafür aktuell nur ISO-Codierungen unterstützt, `utf-8` wird nicht unterstützt. Bei JSON-Feeds wird `encoding` ignoriert. Der Feed muss dann in UTF-8 codiert sein.
`chunk_size`	Anzahl der Zeilen pro Verarbeitungsschritt (Chunk). Standardwert: `1000`.
`dir_path`	Pfad für die automatisch generierten temporären JSON-Dateien, die beim Import als Zwischenspeicher dienen, beispielsweise `/data/subshop_data`. Der Pfad wird bei der Einrichtung des Suchmoduls durch WEBSALE angegeben und kann nicht geändert werden.
`remove_na_values`	Entfernt ungültige oder leere Werte aus dem Feed. - `true` → Leere oder ungültige Werte werden beim Import entfernt. - `false` → Werte bleiben erhalten und werden in Elasticsearch importiert.
`new_product_days`	Legt fest, wie viele Tage ein Produkt nach seiner Erstellung als „neu” gilt, beispielsweise `365`. Diese Information wird benötigt, um Sortierungen oder Filter nach „neuesten Produkten” zu nutzen.
`invalid_docs_max`	Maximale Anzahl fehlerhafter Zeilen, bevor der Importprozess abgebrochen wird. Der Wert `0` bedeutet, dass der Prozess bei der ersten fehlerhaften Zeile stoppt. Damit der Prozess fortgeführt werden kann, müssen die Fehler behoben werden.
`log_percent`	Schwelle in Prozent, bei der der Fortschritt des Imports geloggt wird. Der Wert `10` bedeutet, dass nach jeweils 10 % der verarbeiteten Daten ein Log-Eintrag erfolgt. Die Logs stehen zum aktuellen Zeitpunkt nur der WEBSALE AG zur Verfügung und können bei Bedarf beziehungsweise auf Anfrage zugesendet werden.
`product_id`	CSV-Spaltenname, der auf das Produktdatenfeld mit der eindeutigen Produktnummer zeigt. Es muss der technische Feldname des Produktdatenfelds angegeben werden, das die Produktnummer enthält, beispielsweise `number`.
`base_id`	Basis-Produkt-ID. Es muss der technische Feldname des Produktdatenfelds angegeben werden, das die Basis-Produktnummer enthält, beispielsweise `prodindexbase`.
`is_base_product`	Es muss der technische Feldname des Produktdatenfelds aus dem Datenfeed angegeben werden, das die Information enthält, ob es sich um ein Basisprodukt handelt.
`creation_date`	Es muss der technische Feldname des Produktdatenfelds aus dem Datenfeed angegeben werden, das den Timestamp der Erstellung des Produktes enthält.
`api_store_id`	Name der Lagerbestands-ID aus der REST Lagerbestand Schnittstelle, beispielsweise `StoreId`.
`es_store_id`	Lagerbestands-ID im Suchindex. Es muss der technische Feldname des Produktdatenfelds aus dem Datenfeed angegeben werden, das diese Information enthält, beispielsweise `storeid`.
`inventory`	Gibt den Lagerbestand eines Produktes an. Es muss der technische Feldname des Produktdatenfelds aus dem Datenfeed angegeben werden, das diese Information enthält, beispielsweise `inventory`.
`inventory_active`	Gibt an, ob ein Produkt die Lagerbestandsverwaltung aktiviert hat. Es muss der technische Feldname des Produktdatenfelds aus dem Datenfeed angegeben werden, das diese Information enthält, beispielsweise `inventory-active`.
`inventory_type`	Angabe, ob die Lagerbestandsverwaltung statisch oder dynamisch ist. Es muss der technische Feldname des Produktdatenfelds aus dem Datenfeed angegeben werden, das diese Information enthält, beispielsweise `inventory-type`.
`category_str`	Enthält alle Kategorie-Strings (Kategorienamen) eines Produkts. Ist das Produkt nur einer Kategorie zugewiesen, ist es nur der eine Kategoriename. Bei mehreren Kategoriezuweisungen können alle übergeben werden. Es muss der technische Feldname des Datenfelds aus dem Datenfeed angegeben werden, das diese Information enthält, beispielsweise `allcategories`.
`category_ids`	Enthält die Kategorie-IDs des Produktes. Ist das Produkt nur einer Kategorie zugewiesen, ist es nur ein Index. Bei mehreren Kategoriezuweisungen können alle Indexe übergeben werden. Es muss der technische Feldname des Datenfelds aus dem Datenfeed angegeben werden, das diese Information enthält, beispielsweise `catids`.
`all_category_ids`	Enthält alle Kategorie-IDs des Produkts inklusive des Breadcrumbs, wenn ein Produkt mehreren Kategorien zugewiesen ist. Ist das Produkt nur einer Kategorie zugewiesen, ist es nur ein Index. Bei mehreren Kategoriezuweisungen können alle Indexe übergeben werden. Es muss der technische Feldname des Datenfelds aus dem Datenfeed angegeben werden, das diese Information enthält, beispielsweise `allcatids`.
`category_separator`	Liegen Produkte in mehreren Kategorien, muss hier das Trennzeichen angegeben werden, beispielsweise `/`, um die Daten korrekt voneinander zu trennen.
`value_separator`	Trennzeichen für mehrwertige Inhalte pro Feld, beispielsweise der Breadcrumb-Trenner für die Kategorie oder die Inhaltsstoffe bei Nahrungsmitteln. Beim Import werden die Werte des Feldes anhand dieses Separators in einzelne Einträge gesplittet. Das Trennzeichen muss mit der Feed-Erzeugung abgestimmt sein. Es darf nicht ungekennzeichnet im eigentlichen Wert vorkommen, stellen Sie dafür bei Bedarf Escaping oder Quoting im Feed sicher.
`index_category_hierarchy`	Legt fest, ob das Importmodul die Kategorie-Hierarchie automatisch aufbaut. Bei `true` reicht es, wenn Produkte nur in der untersten Kategorie eingeordnet sind, sie werden dann auch in übergeordneten Kategorien gefunden. Bei `false` wird die Hierarchie nicht automatisch erstellt. Gilt global für alle Subshops. Default: `false`
`normalize_negative_prices`	Aktiviert oder deaktiviert die Normalisierung negativer Preise. Wenn aktiviert, werden negative Preise auf 0.0 normalisiert.

Formatspezifische Parameter (format_config)

Alle Parameter, die nur für ein bestimmtes Dateiformat gelten, sind unter format_config zu finden. Bei CSV- und TSV-Feeds legt format_config neben format auch das Spaltentrennzeichen field_separator und die optionale Zeichenersetzungen character_replacements fest. Bei JSON-Feeds legt format_config die Position der Produkte und ihrer Varianten in der Datei fest.

Früher standen format, field_separator und character_replacements direkt unter datafeed. Diese Schreibweise wird aus Kompatibilitätsgründen weiterhin unterstützt, sodass bestehende Konfigurationen weiterhin funktionieren. Neue Konfigurationen nutzen hingegen format_config. Fehlt format_config oder ist es leer und steht field_separator oder character_replacements direkt unter datafeed, schreibt das Importmodul die Warnung FORMAT_STRUCTURE_DEPRECATED ins Log.

Beispielkonfiguration für einen JSON-Feed

datafeed:
  format_config:
    format: json                         # Datafeed-Format: csv, tsv oder json
    items_path: products.item            # Pfad zu den Produkten
    variants_path: metadata.variants     # Pfad zu den Varianten
    parent_id: id                        # ID des Basisprodukts, relativ zu items_path
    child_id: id                         # ID der Variante, relativ zu variants_path
  ...

Die Konfiguration passt zu einem Feed dieses Aufbaus:

{
  "products": [
    {
      "id": "12-2144",
      "name": "Cardigan 'Amelia'",
      "metadata": {
        "variants": [
          { "id": "12-2144-S", "size": "S" },
          { "id": "12-2144-M", "size": "M" }
        ]
      }
    }
  ]
}

Parameterbeschreibung

Parameter	Beschreibung
`format`	Dateiformat des Datenfeeds. Unterstützt werden `csv`, `tsv` und `json`.
`field_separator`	Nur bei `csv` und `tsv`: Zeichen, das die Spalten im Datenfeed voneinander trennt. Andere Trennzeichen wie `;` oder `,` sind möglich, müssen aber mit der tatsächlichen Feed-Struktur übereinstimmen. Default: `\t` (Tabulator)
`character_replacements`	Nur bei `csv` und `tsv`: Liste von Zeichenersetzungen, die beim Einlesen des Feeds angewendet werden. Default: `[]`
`items_path`	Nur bei `json`: Pfad zu den Produkten in der Datei, in Punkt-Notation. Ist das Element ein Array, wird `.item` angehängt. Im Beispiel ist `products` ein Array, der Pfad lautet deshalb `products.item`.
`variants_path`	Nur bei `json`: Pfad zu den Varianten eines Produkts, in Punkt-Notation.
`parent_id`	Nur bei `json`: Pfad zur ID des Basisprodukts, relativ zu `items_path`, in Punkt-Notation. Optional. Default: `id`
`child_id`	Nur bei `json`: Pfad zur ID der Variante, relativ zu `variants_path`, in Punkt-Notation. Optional. Default: `id`

Der häufigste Fehler bei JSON-Feeds ist ein fehlendes .item in items_path. Ohne diesen Zusatz findet das Importmodul keine Produkte, wenn sie in einem Array stehen.

Subshopkonfiguration im Importmodul

In diesem Abschnitt werden alle subshopspezifischen Einstellungen für das Importmodul definiert. Jeder Subshop wird dabei als eigener Konfigurationsblock unter dem Abschnitt subshop_configs angelegt. Über diese Konfiguration wird festgelegt, welche Daten je Subshop importiert und bereitgestellt werden. Dadurch kann das Suchmodul später pro Subshop gezielt auf die entsprechenden Daten zugreifen und die Suche individuell steuern. Standardkonfiguration für den Subshop Deutsch

subshop_configs:
  deutsch:
    nlp_lang: de
    datafeed_url: http://content.<shop-id>.websale.net/search/websale_search.csv
    variant_fields:
      enabled: true
      fields:
        - color
        - size
    index_configs:
      product:
        enabled: true
        custom_fields:
          - name: keyword_field123
            type: keyword
          - name: template_field456
            type: template
          - name: timestampcreatedat
            type: date
            format: strict_date_optional_time||epoch_second
          - name: float_field789
            type: double
      category:
        enabled: true
        custom_fields:
            - name: cat_descr
              type: template
        custom_config:
          search_fields:
            - field: cat_str
              boost: 2
            - field: cat_str_path
              boost: 1.5
          display_fields:
            - field: cat_id
            - field: cat_id_path
            - field: cat_str
            - field: cat_str_path
      content:
        ...
      completion:
        enabled: true
        fields:
          - name: name
            validate: False
          - name: descr
            validate: True
    stopwords: {...}      # siehe Abschnitt „Toleranz für das Ignorieren von Stoppwörtern (stopwords)"
    synonyms: {...}       # siehe Abschnitt „Synonyme (synonyms)"
    lemmatization: {...}  # siehe Abschnitt „Grammatikalische Flexion (lemmatization)"
    punctuation_filter: {...}  # siehe Abschnitt „Sonderzeichen-Handhabung (punctuation_filter)"
  englisch:
    {...}

Parameterbeschreibung

Parameter	Beschreibung
`nlp_lang`	Der Parameter `nlp_lang` legt fest, in welcher Sprache die textuelle Aufbereitung der Suchdaten erfolgt. Dabei werden sprachspezifische Modelle und Regeln aus den NLP-Bibliotheken spaCy und Simplemma verwendet. Diese sorgen dafür, dass die Suchdaten während des Imports sprachgerecht analysiert und verarbeitet werden, beispielsweise im Hinblick auf Wortstämme, Grundformen (Lemmata) und Stoppwörter. Aktuell verfügbare Sprachen: - Deutsch (`de`) = Standard - Englisch (`en`) - Spanisch (`es`) - Französisch (`fr`) - Italienisch (`it`) - Niederländisch (`nl`) - Portugiesisch (`pt`) - Dänisch (`da`) - Tschechisch (`cs`) - Polnisch (`pl`) - Finnisch (`fi`) - Indonesisch (`id`) - Slowakisch (`sk`) - Türkisch (`tr`) - Schwedisch (`sv`) - Norwegisch Bokmål (`nb`)
`datafeed_url`	URL des Datenfeeds. Wird vom WEBSALE Support eingerichtet und bereitgestellt.
`variant_fields`	Liste der technischen Produktdatenfelder, die Varianten eines Produktes beschreiben, beispielsweise Farbe (`color`) oder Größe (`size`). Siehe Abschnitt Variant Fields.
`enabled`	Verknüpft beim Import Basis-Produkte und ihre Varianten.
`fields`	Technische Namen der Variantenfelder eines Produkts, immer in Kleinbuchstaben.
`index_configs`	Indexspezifische Konfigurationen.
`product`	Hauptindex für die Produktsuche. Enthält die Produktdatenfelder für den Suchindex.
`enabled`	Aktiviert die Erstellung dieses Index im Import.
`custom_fields`	Individuell definierte Produktdatenfelder, die zusätzlich in den Suchindex aufgenommen werden. Angabe des technischen Namens des Produktdatenfeldes.
`name`	Technischer Name des Produktdatenfeldes, immer in Kleinbuchstaben.
`type`	Datentyp des Feldes. Verfügbare Typen: `text`, `keyword`, `integer`, `float`, `double`, `date`, `boolean`, `template`. `template` ist ein spezieller Feldtyp für Textfelder, die sowohl durchsuchbar als auch filterbar sein sollen.
`category`	Index für die Kategoriesuche. Ermöglicht es, Kategorien als eigenständigen Index zu durchsuchen. Wenn beim Import ein Kategorie-Index angelegt wurde, kann dieser in der Konfiguration des Suchmoduls aktiviert werden.
`enabled`	Aktiviert die Erstellung beziehungsweise Nutzung dieses Index. Muss sowohl in der Import-Konfiguration als auch in der Suchmodul-Konfiguration auf `true` gesetzt werden.
`custom_fields`	Individuell definierte Felder, die zusätzlich in den Kategorie-Index aufgenommen werden sollen, analog zu `product`. Siehe Abschnitt custom_fields des Produktindex. Im Default sind nur die Standard-Kategoriefelder enthalten (IDs und Name). Jedes Feld wird mit `name` (technischer Feldname, immer Kleinbuchstaben) und `type` (Datentyp, beispielsweise `text`, `keyword` oder `template`) angegeben.
`custom_config`	Konfigurationsblock für die Kategoriesuche. Hier wird festgelegt, welche Felder durchsucht und welche in der Antwort zurückgegeben werden. Dieser Key wird für zukünftige zusätzliche Indizes analog übernommen.
`search_fields`	Liste der Felder, die bei einer Kategoriensuche durchsucht werden, analog zu `product`. Sollte immer mindestens die Felder `cat_str` und `cat_str_path` enthalten. Pro Feld kann ein `boost`-Wert angegeben werden, um die Gewichtung zu steuern.
`field`	Technischer Name des zu durchsuchenden Feldes. Per Default verfügbar: `cat_str`, `cat_str_path`.
`boost`	Gewichtungsfaktor für das Feld bei der Suche. Höhere Werte erhöhen die Relevanz von Treffern in diesem Feld.
`display_fields`	Liste der Felder, die in der Suchantwort zurückgegeben werden, analog zu `product`. Benötigt wird mindestens `cat_id`. Per Default verfügbare Felder: `cat_id`, `cat_id_path`, `cat_str`, `cat_str_path`.
`field`	Technischer Name des Feldes, das in der Antwort enthalten sein soll.
`content`	Hauptindex für die Suche über Inhaltsseiten wie Impressum, Datenschutz oder AGB. Mehr Informationen dazu finden Sie im Abschnitt content. Sollen mehrere Content-Quellen durchsucht werden, siehe Abschnitt Mehrere Content-Quellen für die Suche.
`completion`	Index für Vorschläge (Autocomplete beziehungsweise Autovervollständigung).
`enabled`	Aktiviert die Erstellung dieses Index im Import.
`fields`	Liste der Produktdatenfelder aus dem Suchindex, die für Vorschläge verwendet werden.
`stopwords`	Definition der Stoppwort-Liste. Mehr Informationen dazu finden Sie im Abschnitt stopwords. Mehr Informationen zur Aktivierung der Funktion im Suchmodul finden Sie im Abschnitt stopwords_filter.
`synonyms`	Definition manueller Synonymlisten. Mehr Informationen dazu im Abschnitt synonyms.
`lemmatization`	Konfiguration der grammatikalischen Flexionen. Mehr Informationen dazu finden Sie im Abschnitt lemmatization. Mehr Informationen zur Aktivierung der Funktion im Suchmodul finden Sie im Abschnitt lemmatization.
`punctuation_filter`	Behandlung von Sonderzeichen beim Import. Mehr Informationen dazu finden Sie im Abschnitt punctuation_filter.

Toleranz für das Ignorieren von Stoppwörtern (stopwords)

Stoppwörter sind wenig aussagekräftige Wörter, beispielsweise Artikel oder einfache Präpositionen, die bei der Auswertung von Suchanfragen ignoriert werden können, um irrelevante Übereinstimmungen zu reduzieren. Ob diese Ignorierlogik zur Laufzeit angewendet wird, steuert das Suchmodul. Welche Wörter als Stoppwörter behandelt, ausgenommen (Whitelist) oder zusätzlich aufgenommen (Blacklist) werden, definiert das Importmodul. In diesem Abschnitt wird festgelegt, wie die Suchfunktion mit häufig vorkommenden, bedeutungsarmen Wörtern („Stoppwörtern”) umgeht. Als Grundlage dient die Standardliste von spaCy, die gängige Funktionswörter wie der, die, das, mit, von enthält. Für optionale Whitelist- und Blacklist-Einträge kann diese Liste individuell angepasst werden:

Die Whitelist entfernt Wörter aus der spaCy-Stoppwortliste, sodass sie nicht ignoriert und bei der Suche berücksichtigt werden.
Die Blacklist fügt Wörter zur spaCy-Liste hinzu, sodass sie bei der Suche ausgefiltert werden. Wird ein Wort blackgelistet, das bereits enthalten ist, bleibt die Wirkung unverändert.

Optional kann eine eigene .txt-Datei mit Stoppwörtern verwendet werden. Soll diese extern hinterlegt werden, beispielsweise auf einem Kundensystem, ist eine technische Abstimmung zur Einbindung der Datei erforderlich. Damit die konfigurierten Stoppwörter im Suchprozess tatsächlich berücksichtigt werden, muss im Suchmodul der Parameter stopwords_filter.enabled: true aktiviert sein. Siehe Abschnitt „Stoppwort-Filter im Suchmodul”. Standardkonfiguration stopwords

stopwords:
  path: ""        # optional: Pfad zu eigener .txt, sonst spacy-Default
  whitelist:      # Begriffe, die NICHT als Stopwort behandelt werden sollen
    - mit         # wichtig für Produktausprägungen, beispielsweise Jacke mit Kapuze
    - ohne        # wichtig für Tiernahrung, beispielsweise ohne Getreide
    - für         # wichtig für Zielgruppen, beispielsweise für Damen
    - in          # wichtig für Farben und Größen, beispielsweise in Blau, in 40
    - und         # wichtig für Kombinationen, beispielsweise Huhn und Reis
  blacklist:      # zusätzliche Stopwörter, die entfernt werden sollen
    - der
    - die
    - das
    - ein
    - eine
    - einer
    - eines
    - einem
    - einen
    - bei
    - nach
    - von
    - zu
    - zum
    - zur
    - auch
    - oder

Parameterbeschreibung stopwords

Parameter	Beschreibung
`path`	Pfad zu einer eigenen `.txt`-Datei mit Stoppwörtern (ein Wort pro Zeile), beispielsweise `/data/stopwords_de.txt`. Wird keine Datei angegeben, wird die Standardliste von spaCy verwendet.
`whitelist`	Wörter, die nicht als Stoppwort behandelt werden sollen, also Ausnahmen von der Standardliste. Eignet sich für fachlich relevante Begriffe wie „mit”, „ohne”, „für”, „in” oder „und”.
`blacklist`	Zusätzliche Wörter, die als Stoppwort entfernt werden sollen, also eine Ergänzung zur Standardliste von spaCy. Typisch sind Artikel und Präpositionen wie „der”, „die”, „das”, „ein”, „eine”, „einer”, „eines”, „einem”, „einen”, „bei”, „nach”, „von”, „zu”, „zum”, „zur”, „auch” und „oder”.

Die Funktion muss zusätzlich noch für das Suchmodul aktiviert werden.

Synonyme (synonyms)

Die Synonymfunktion ermöglicht es, Begriffe in der Suche miteinander zu verknüpfen. Dadurch erscheinen bei der Eingabe eines Begriffs auch Treffer zu gleichbedeutenden oder verwandten Begriffen. Synonyme können entweder bidirektional („Jacke” = „Jacket”) oder unidirektional („Turniersakko” → „Turnierjacke”) definiert werden. Optional lassen sich Synonymlisten als Datei hinterlegen oder direkt in der Konfiguration pflegen. Im Standard sind keine Synonyme hinterlegt. Die Funktion wird aktiv, sobald entweder eine Synonymliste (path) angegeben oder manuelle Synonyme (clouds) definiert werden. Beispielkonfiguration

synonyms:
    path: ""
    clouds:
      - src: # Beispiel 1
        - trenchcoat
        - kutte
        - caban
        - janker
        target:
          - mantel
          - jacke
        mode: bi
      - src: # Beispiel 2
          - kängoro
          - kängguhru
          - kengooroo
        target: känguru
        mode: uni

Beispiel 1 (mode: bi) Die Begriffe „trenchcoat”, „kutte”, „caban”, „janker”, „mantel” und „jacke” sind bidirektional miteinander verknüpft. Eine Suche nach einem dieser Begriffe führt auch zu Treffern, die einen der anderen Begriffe enthalten. Beispielsweise liefert eine Suche nach „Janker” auch Ergebnisse mit „Mantel” oder „Trenchcoat”, und umgekehrt.
Beispiel 2 (mode: uni) Die Begriffe „kängoro”, „kängguhru” und „kengooroo” werden einseitig auf den Begriff „känguru” gemappt. Eine Suche nach einer der Schreibvarianten führt zu Treffern mit „känguru”, nicht jedoch umgekehrt. Dieser Modus eignet sich vor allem für Tippfehler, Schreibvarianten oder vereinheitlichte Begriffe.

Parameterbeschreibung

Parameter	Beschreibung
`path`	Optional kann eine TXT-Datei mit Synonymen hinterlegt werden (ein Wort pro Zeile). Beim Parameter wird der Pfad der `txt`-Datei angegeben, beispielsweise `/data/synonyms_de.txt`. Änderungen an der Datei erfordern eine Neuindexierung. Falls die Datei extern hinterlegt werden soll, beispielsweise auf einem Server des Kunden, ist eine gesonderte technische Abstimmung erforderlich, um den Zugriff auf diese Datei sicherzustellen.
`clouds`	Liste mit manuell definierten Synonymgruppen. Jede Gruppe beschreibt eine Beziehung zwischen Quell- und Zielbegriffen.
`src`	Quellbegriffe, die ersetzt oder verknüpft werden sollen. Kann als einzelner String oder als Liste angegeben werden.
`target`	Zielbegriffe, auf die verwiesen wird. Kann als einzelner String oder als Liste angegeben werden.
`mode`	Verknüpfungsmodus: - `uni` → unidirektional. Nur `src → target`, das heißt bei Eingabe von `src` wird nach `target` gesucht, nicht umgekehrt. - `bi` → bidirektional. Alle Begriffe innerhalb von `src` und `target` gelten gegenseitig als Synonyme.

Hinweis: Nach Änderungen an Synonymen muss die Datenfeed-Generierung manuell gestartet werden, damit eine Neuindexierung erfolgt.

Grammatikalische Flexion (lemmatization)

In diesem Abschnitt wird festgelegt, ob und für welche Felder grammatikalische Wortformen beim Import auf ihre Grundform reduziert werden. Dadurch erkennt die Suche auch sprachliche Varianten, etwa dass „rote Hemden”, „rotes Hemd” oder „Hemd in Rot” denselben Begriff meinen. Die Funktion verbessert die sprachliche Erkennung und sorgt für natürlichere Suchergebnisse. Sie sollte für beschreibende Textfelder aktiviert werden, beispielsweise name oder descr. Für technische Felder wie product_id oder sku sollte sie deaktiviert bleiben. Standardkonfiguration

lemmatization:
  enabled: true
  language: de
  fields:
    - name
    - descr

Die grammatikalische Grundform-Erkennung ist aktiviert (enabled: true).
Es wird die deutsche Sprachlogik verwendet (language: de).
Die Felder name und descr werden beim Import auf ihre Grundformen reduziert.
Dadurch erkennt die Suche auch grammatikalisch oder in der Wortstellung abweichende Begriffe, beispielsweise „rotes Hemd” und „Hemd in Rot”.

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) die grammatikalische Reduktion von Suchbegriffen auf ihre Grundform. Grundlage sind die sprachspezifischen Wortstämme und Modelle der NLP-Bibliotheken spaCy und Simplemma. Bei deaktivierter Einstellung erfolgt eine wortgenaue Suche ohne sprachliche Vereinheitlichung.
`language`	Definiert die Sprache, für die der Lemmatizer angewendet wird. Aktuell verfügbar: - Deutsch (`de`) = Standard - Englisch (`en`) - Spanisch (`es`) - Französisch (`fr`) - Italienisch (`it`) - Niederländisch (`nl`) - Portugiesisch (`pt`) - Dänisch (`da`) - Tschechisch (`cs`) - Polnisch (`pl`) - Finnisch (`fi`) - Indonesisch (`id`) - Slowakisch (`sk`) - Türkisch (`tr`) - Schwedisch (`sv`) - Norwegisch Bokmål (`nb`) Je nach gewählter Sprache werden die entsprechenden Sprachmodelle von spaCy genutzt, um grammatikalische Varianten korrekt zu erkennen.
`fields`	Legt fest, welche Datenfelder aus dem Import sprachlich analysiert und lemmatisiert werden. Es müssen die technischen Feldnamen des Datenfeeds angegeben werden. Standardmäßig sind `name` (Produktname) und `descr` (Produktbeschreibung) hinterlegt. Änderungen an dieser Einstellung erfordern einen erneuten Import.

Die Funktion muss zusätzlich noch für das Suchmodul aktiviert werden.

Sonderzeichen-Handhabung (punctuation_filter)

Der punctuation_filter steuert die Behandlung von Sonderzeichen in Suchanfragen und indexierten Begriffen. Damit lassen sich Suchergebnisse vereinheitlichen und Null-Treffer aufgrund unterschiedlicher Schreibweisen vermeiden, beispielsweise bei “USB-C” und “USB C”. Der Filter wird wie stopwords, synonyms und lemmatization im Importmodul konfiguriert, global unter global_configs, je Sprache unter language_configs oder je Subshop unter subshop_configs.

Die Konfiguration des punctuation_filter im Importmodul steht ab der Plugin-Version elasticsearch_manager v1.18.0 zur Verfügung. Im Suchmodul ist punctuation_filter ab websale_search v1.21.0 veraltet (deprecated) und entfällt ab websale_search v1.23.0. Bestehende Einstellungen im Suchmodul sollten deshalb in die Konfiguration des Importmoduls übernommen werden.

Änderungen an der Konfiguration des Importmoduls werden erst nach einer Neuindexierung wirksam. Das gilt auch für den punctuation_filter.

Eine Anpassung ist erforderlich, wenn vom Standardverhalten abgewichen werden soll. Dies ist beispielsweise der Fall, wenn bestimmte Sonderzeichen, wie etwa das &-Zeichen bei Markennamen, zusätzlich erhalten bleiben sollen oder wenn weitere Zeichen entfernt werden müssen.

Verarbeitungsreihenfolge

Der Filter bearbeitet einen Begriff in festen Schritten:

Ersetzen durch Leerzeichen: Alle Zeichen aus replace_with_space werden durch ein Leerzeichen ersetzt.
Liste anwenden: Je nach type entfernt der Filter die Zeichen aus list (Blacklist) oder er entfernt alle Zeichen außer denen aus list (Whitelist).

Weil replace_with_space zuerst greift, setzt es sich gegenüber list durch. Steht ein Zeichen in beiden Listen, wird es immer durch ein Leerzeichen ersetzt.

Blacklist: bestimmte Zeichen entfernen

Mit type: black entfernt der Filter nur die Zeichen aus list. Alle anderen Zeichen bleiben erhalten.

punctuation_filter:
  enabled: true               # Aktivierung und Deaktivierung der Funktion
  replace_with_space:         # Zeichen, die durch ein Leerzeichen ersetzt werden
    - "-"
    - "/"
  type: black                 # white = Whitelist, black = Blacklist
  list:                       # Zeichen, die entfernt werden
    - "_"
    - "&"
    - "."

Eingabe	Ergebnis	Grund
`USB-C`	`USB C`	`-` wird durch ein Leerzeichen ersetzt.
`Herren/Hemd`	`Herren Hemd`	`/` wird durch ein Leerzeichen ersetzt.
`Winter_Pullover`	`WinterPullover`	`_` wird entfernt, ohne Leerzeichen.
`Jack&Jones`	`JackJones`	`&` wird entfernt, ohne Leerzeichen.
`PS.5`	`PS5`	`.` wird entfernt.
`50% Rabatt!`	`50% Rabatt!`	`%` und `!` stehen nicht in der Liste und bleiben erhalten.

Entfernte Zeichen hinterlassen keine Lücke und die Wortteile werden zusammengezogen. Wenn an dieser Stelle eine Wortgrenze bleiben soll, muss das Zeichen in replace_with_space stehen.

Whitelist: nur bestimmte Zeichen behalten

Mit dem Parameter type: white behält der Filter nur Buchstaben aller Sprachen, Ziffern, Leerzeichen sowie die Zeichen aus list. Diese Whitelist ist sinnvoll, wenn die Daten viele verschiedene Sonderzeichen enthalten, von denen nur wenige für die Suche relevant sind.

punctuation_filter:
  enabled: true
  replace_with_space:
    - "-"
  type: white
  list:                       # Zeichen, die zusätzlich erhalten bleiben
    - "_"
    - "&"

Eingabe	Ergebnis	Grund
`USB-C`	`USB C`	`-` wird durch ein Leerzeichen ersetzt, bevor die Whitelist greift.
`Jack&Jones`	`Jack&Jones`	`&` steht in der Whitelist.
`Winter_Pullover`	`Winter_Pullover`	`_` steht in der Whitelist.
`PS.5`	`PS5`	`.` steht nicht in der Whitelist und wird entfernt.
`50% Rabatt!`	`50 Rabatt`	`%` und `!` werden entfernt.
`Crème brûlée`	`Crème brûlée`	Buchstaben mit Akzent zählen als Buchstaben und bleiben erhalten.

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) die Sonderzeichen-Normalisierung. Bei `false` bleibt der Begriff unverändert.
`replace_with_space`	Liste von Zeichen, die nicht gelöscht, sondern durch ein Leerzeichen ersetzt werden. Sinnvoll für Trennzeichen, die eine Wortgrenze markieren sollen, beispielsweise `-` oder `/`. Wird vor `list` angewendet und setzt sich daher gegenüber `list` durch.
`type`	Legt fest, wie `list` interpretiert wird: - `black` = Blacklist: Nur die Zeichen aus `list` werden entfernt, alle anderen bleiben erhalten. - `white` = Whitelist: Buchstaben aller Sprachen, Ziffern, Leerzeichen und die Zeichen aus `list` bleiben erhalten, alle anderen werden entfernt. Bei einem anderen Wert legt das Importmodul keinen Filter an. Dann greift auch `replace_with_space` nicht, und das Importmodul schreibt lediglich eine Warnung ins Log.
`list`	Zeichenliste, die je nach `type` entfernt (Blacklist) oder zusätzlich behalten (Whitelist) wird.

Kategorien

Feste Felder im Category-Index

Feld	Beschreibung
`cat_id`	Kategorie-ID.
`cat_str`	Kategorie-Name.
`cat_id_path`	Kategorie-ID-Pfad.
`cat_str_path`	Vollständiger Kategorie-Pfad als String.
`cat_image`	Kategorie-Bild (optional).
`sort_field`	Wird automatisch von `cat_str_path` befüllt und kann über `custom_fields` überschrieben werden.

Inhaltsseiten in den Suchindex aufnehmen

Neben Produkten und gegebenenfalls Kategorien können auch statische Inhaltsseiten in die Suche einbezogen werden, beispielsweise „Über uns”, AGB, Impressum oder Datenschutzerklärung. Dafür wird im Importmodul der Content-Import aktiviert (content.enabled) und die Anbindung an die jeweilige Shop-API (VX oder v8) konfiguriert. Optional lassen sich die zu indexierenden Seiten gezielt einschränken, beispielsweise über included_content.

Category und Content sind spezielle Indizes, die, anders als der Produktindex, nicht frei um neue Felder erweitert werden können. Beide arbeiten mit einem festen Satz an Feldern, siehe unten. Der Parameter custom_fields dient hier ausschließlich dazu, das Elasticsearch-Mapping bestehender Felder zu überschreiben oder anzupassen, beispielsweise Analyzer oder Feldtyp. Er wurde vom Produktindex analog für andere Indizes übernommen, erweitert aber nicht die Indexierung um neue Datenfelder.

Feste Felder im Content-Index

Feld	Beschreibung
`source`	Pfad zur Content-Seite, beispielsweise `content/gtc.htm`.
`title`	Seitentitel.
`content`	Extrahierter Text-Inhalt der Seite.
`sort_field`	Wird automatisch von `title` befüllt und kann über `custom_fields` überschrieben werden.

Standardkonfiguration des Demoshops

content:
  enabled: true
  custom_fields: # analog zu product/category, im Default sind nur 'title' und 'content' enthalten
    - name: field_name
      type: field_type
  custom_config:
    host: demo.shop.websale.biz
    user: "example@websale.de"
    password: "<ihr-passwort>"
    endpoint: seo/urls/templates
    params:
      size: 300
      sort: resourceIdentifier:asc
    path_field: path
    source_field: resourceIdentifier
    content_id: "wsMainContent"
    included_content:
      - "content/aboutUs.htm"
      - "content/gtc.htm"
      - "content/imprint.htm"
      - "content/privacy.htm"
      - "content/return.htm"
      - "content/returnInquiry.htm"
    # folgende Keys sind für VX nicht relevant
    api_version: v8
    base_path: /api/
    auth_url: /authent/login/
    shop_url: www.myshop.de

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert den Import und das Indexieren von statischen Inhaltsseiten für die Suche.
`custom_fields`	Optionale Anpassung des Elasticsearch-Mappings für den Content-Index, analog zu `Product` und `Category`. Damit lassen sich bestehende Felder im Mapping überschreiben oder erweitern. Verändert nur das Mapping. Die Indexierung von `Content` und `Category` ist fest definiert und lässt sich nicht über die Konfiguration um neue Datenfelder erweitern.
`custom_config`	Technische Zusatzkonfiguration für das Importieren und Auslesen der statischen Inhalte. Unterscheidet sich zwischen VX und v8.
`host`	Host der API. - V8s: Host der v8-API, beispielsweise `websale.de`. - Neue Version: entspricht der Shop-ID-Domain, beispielsweise `common-id.shop.websale.net`.
`user`	Benutzername für die Authentifizierung an der Auth-API.
`password`	Passwort für die Authentifizierung an der Auth-API.
`endpoint`	API-Endpunkt, von dem die SEO-Template- und URL-Daten geladen werden. - V8s: `seo/templates` - Neue Version: `seo/urls/templates`
`encoding`	Zeichencodierung der abgerufenen Inhalte, beispielsweise `utf-8`.
`params`	Optionale URL-Parameter für den API-Call. Nur für die neue Version. - `size` — maximale Response-Größe, maximal 300 SEO-URLs pro Request. - `sort` — Sortierung der Response-Items, beispielsweise `resourceIdentifier:asc`.
`osbcommonid`	Nur für V8s. Common-ID für OSB, sofern für die jeweilige Umgebung erforderlich.
`path_field`	Feldname aus der API-Response, das den Pfad der Seite enthält, beispielsweise `/ueber-uns`. - V8s: `terms` - Neue Version: `path`
`source_field`	Feldname aus der API-Response, das die Quelle beziehungsweise Template-Referenz enthält, beispielsweise `content/aboutUs.htm`. - V8s: `template` - Neue Version: `resourceIdentifier`
`content_id`	Optionale ID eines HTML-Containers, aus dem der relevante Seiteninhalt extrahiert wird, beispielsweise `wsMainContent`. Wenn nicht gesetzt, wird standardmäßig `<main>` ausgelesen. Ist kein `<main>` vorhanden, wird die komplette Seite inklusive Header und Footer übernommen.
`included_content`	Optionale Positivliste. Importiert und indexiert nur die hier angegebenen „source”-Einträge, beispielsweise einzelne Templates oder Content-Dateien. Ohne Angabe werden alle verfügbaren Seiten berücksichtigt.
`api_version`	Nur V8s. Version der Shop-API, beispielsweise `v8`. In der neuen Version entfällt dieser Parameter, da ein passender Default-Wert hinterlegt ist.
`base_path`	Nur V8s. Basispfad für Schnittstellen, beispielsweise `/api/`. In der neuen Version entfällt dieser Parameter, da ein passender Default-Wert hinterlegt ist.
`auth_url`	Nur V8s. Endpunkt der Auth-API, beispielsweise `/authent/login/` beziehungsweise mit Common-ID. In der neuen Version entfällt dieser Parameter, da ein passender Default-Wert hinterlegt ist.
`shop_url`	Nur V8s. Öffentliche Shop-URL. In der neuen Version entspricht `host` in der Regel der Shop-URL beziehungsweise ist dafür ausreichend.

Mehrere Content-Quellen für die Suche

Mehrere Content-Quellen stehen ab den Plugin-Versionen elasticsearch_manager v1.15.0 und websale_search v1.18.0 zur Verfügung. Für die Darstellung einzelner Quellen im Frontend wird zusätzlich websale_search_webcomponents v1.7.0 benötigt.

Der im vorherigen Abschnitt beschriebene content-Block deckt eine einzelne Quelle ab, nämlich die statischen Inhaltsseiten des Shops. Reicht das nicht aus, lässt sich content stattdessen als Liste angeben. Jeder Eintrag der Liste ist eine eigene Content-Quelle mit eigenem Suchindex, beispielsweise die statischen Seiten, ein Blog und ein Magazin. Neben der Shop-API als Datenquelle kommt damit ein zweiter Weg hinzu. Über source: feed liest das Importmodul Inhalte aus einem externen Datenfeed ein, beispielsweise aus dem CSV-Export eines Blog-Systems.

Die bisherige Konfiguration mit einem einzelnen content-Block funktioniert unverändert weiter. Sie müssen nur dann auf die Listenform umstellen, wenn Sie mehr als eine Content-Quelle benötigen.

Beispielkonfiguration mit drei Quellen

index_configs:
  content:
    - name: static
      enabled: true
      source: api
      custom_fields: # analog zu product/category, im Default sind nur 'title' und 'content' enthalten
        - name: field_name
          type: field_type
      custom_config:
        host: demo.shop.websale.biz
        user: "example@websale.de"
        password: "<ihr-passwort>"
        endpoint: seo/urls/templates
        encoding: utf-8
        params:
          size: 300
          sort: resourceIdentifier:asc
        path_field: path
        source_field: resourceIdentifier
        content_id: "wsMainContent"
        included_content:
          - "content/aboutUs.htm"
          - "content/gtc.htm"
          - "content/imprint.htm"
    - name: blog
      enabled: true
      source: feed
      custom_fields: # optional, im Default sind nur 'title' und 'content' enthalten
        - name: field_name
          type: field_type
      custom_config:
        datafeed_url: https://blog.example.de/searchfeeds_csv/blog_DE.csv
        field_mapping:
          source: url
          title: title
          content: content_text
        format_config:
          format: csv
          field_separator: ","
    - name: magazin
      enabled: true
      source: feed
      custom_config:
        datafeed_url: https://magazin.example.de/searchfeeds_csv/magazin_DE.csv
        field_mapping:
          source: url
          title: h1
          content: texts
        format_config:
          format: csv
          field_separator: ","

Parameterbeschreibung Die folgende Tabelle beschreibt nur die Parameter, die in der Listenform zusätzlich gelten. Alle übrigen Keys entsprechen dem Content-Import über die Shop-API.

Parameter	Beschreibung
`name`	Pflichtfeld. Technischer Name der Quelle. Er wird als Suffix an den Index-Namen angehängt, aus `name: blog` wird der Index `content_blog`. Der Name muss eindeutig sein. Erlaubt sind Kleinbuchstaben, Ziffern, Unterstrich und Bindestrich. Großbuchstaben werden automatisch in Kleinbuchstaben umgewandelt, alle anderen Zeichen wie Umlaute, Leerzeichen oder Punkte werden durch einen Unterstrich ersetzt. Ein Eintrag ohne `name` wird beim Import übersprungen.
`source`	Herkunft der Inhalte. - `api` — die Inhalte werden über die Shop-API geladen, wie beim bisherigen Content-Import. - `feed` — die Inhalte werden aus einem externen Datenfeed gelesen.
`custom_fields`	Optionale Anpassung des Elasticsearch-Mappings, analog zu `product` und `category`. Wird pro Quelle einzeln angegeben. Im Default sind nur `title` und `content` enthalten.
`encoding`	Zeichencodierung, nur innerhalb von `custom_config` bei `source: api`, beispielsweise `utf-8`.
`datafeed_url`	Nur bei `source: feed`. URL des Datenfeeds, aus dem die Inhalte gelesen werden.
`format_config`	Nur bei `source: feed`. Format des Datenfeeds, analog zu `datafeed.format_config` des Produktfeeds.
`format`	Dateiformat des Feeds. Unterstützt werden `csv`, `tsv` und `json`.
`field_separator`	Trennzeichen zwischen den Spalten, beispielsweise `,` bei einer kommaseparierten CSV-Datei.
`field_mapping`	Nur bei `source: feed`. Zuordnung der Feldnamen des Datenfeeds auf die drei festen Index-Felder. Ohne Angabe sucht das Importmodul im Feed direkt nach Spalten mit den Namen `source`, `title` und `content`.
`source`	Feld im Feed, das die URL der Seite enthält. Default: `source`
`title`	Feld im Feed, das den Titel enthält. Default: `title`
`content`	Feld im Feed, das den Inhalt enthält. Default: `content`

Zusätzliche custom_fields lassen sich über field_mapping ebenfalls auf Feed-Spalten mappen. Namen der Indizes Aus jedem Listeneintrag entsteht ein eigener Index. Der Index-Typ heißt content_<name>, der eigentliche Index-Name setzt sich aus dem Basis-Namen des Content-Index, dem Namen der Quelle und der Subshop-ID zusammen. Bei Subshop deutsch und name: blog entsteht daraus der Index deutsch_content_blog. Diese Namen brauchen Sie an zwei Stellen wieder, nämlich in der Konfiguration des Suchmoduls und im source-Attribut der WebComponents.

Ist content weder ein einzelner Block noch eine Liste, wird die komplette Content-Suche deaktiviert. Es erscheint lediglich ein Log-Eintrag, aber keine Fehlermeldung im Shop. Prüfen Sie die Einrückung der Listeneinträge daher genau.

Konfiguration des Suchmoduls

Suchvorschläge (suggest_config)

Basiskonfiguration suggest_config

suggest_config:
  query:
    enabled: true
    fuzziness: 0
    size: 10
  product:
    enabled: true
    size: 8
  category:
    enabled: true
    size: 5
  content:
    enabled: true
    size: 5

Parameterbeschreibung

Parameter	Beschreibung
`query`	Konfiguration für textbasierte Suchvorschläge, also die Autovervollständigung der Sucheingabe.
`product`	Konfiguration für Produkt-Vorschläge. Grundlage bildet der Produkt-Index, siehe Import-Konfiguration.
`category`	Konfiguration für Kategorie-Vorschläge. Grundlage bildet der Kategorie-Index, siehe Import-Konfiguration.
`content`	Konfiguration für Inhaltsseiten-Vorschläge. Grundlage bildet der Content-Index, siehe Import-Konfiguration.
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) den jeweiligen Suggest-Typ. Deaktivierte Typen werden im Frontend nicht angezeigt, auch wenn die entsprechenden HTML-Komponenten vorhanden sind.
`size`	Anzahl der Suchvorschläge für den jeweiligen Suggest-Typ.
`fuzziness`	Steuert die fehlertolerante Suchmethode, nur für Typ `query`. Sie gleicht Tippfehler oder Abweichungen in der Schreibweise innerhalb der Suggest aus. Es kann die erlaubte Edit-Distanz innerhalb der Suggest (Ersetzen, Einfügen, Löschen) pro Wort konfiguriert werden: - `0` → keine Fehlertoleranz, es muss nach Analyse und Normalisierung exakt passen. - `1` → bis zu 1 Edit erlaubt. - `2` → bis zu 2 Edits erlaubt. - `AUTO` → passt die Distanz an die Wortlänge an. Wortlänge 1 bis 2 → 0, 3 bis 5 → 1, ab 6 → 2. - `AUTO:x,y` → eigene Schwellen. Bis x-1 Zeichen → 0, ab x bis y-1 → 1, ab y → 2. Beispiel `AUTO:4,8`: Längen bis 4 → 0, 5 bis 8 → 1, ab 9 → 2.

Grundlage der Suggest-Typen product, category und content bilden die jeweiligen Indizes. Diese müssen zunächst im Importmodul aktiviert und konfiguriert sein, damit die entsprechenden Vorschläge zur Laufzeit verfügbar sind. Siehe Kategorien, Inhaltsseiten sowie den Completion-Index.

Suchvorschläge bei mehreren Content-Quellen Nutzen Sie mehrere Content-Quellen, wird auch content im suggest_config zu einer Liste. Jede Quelle erhält einen eigenen Eintrag, dessen name mit dem Namen im Importmodul übereinstimmen muss.

suggest_config:
  query:
    enabled: true
    fuzziness: 0
    size: 10
  product:
    enabled: true
    size: 8
  category:
    enabled: true
    size: 5
  content:
    - name: static
      enabled: true
      size: 4
    - name: blog
      enabled: true
      size: 4
    - name: magazin
      enabled: true
      size: 4

Quellen, die Sie hier weglassen, liefern keine Suchvorschläge. Sie erscheinen aber weiterhin in den Suchergebnissen.

Filter (filter_config)

Basiskonfiguration filter_config

filter_config:
  filter_size: 100
  doc_count: 1
  default_min: 0
  default_max: 1000
  values_with_counts: true

Parameterbeschreibung

Parameter	Beschreibung
`filter_size`	Anzahl der Filteroptionen pro Filter.
`doc_count`	Mindestanzahl der Dokumente, in denen ein Wert vorkommen muss, um als Filteroption zur Auswahl zu stehen. Bei aktivem `values_with_counts` zählen die Varianten eines Produkts dabei einmal.
`default_min`	Fallback für Range-Filter, Minimalwert.
`default_max`	Fallback für Range-Filter, Maximalwert.
`values_with_counts`	Liefert im Such-Response zu jedem Filterwert die Anzahl der Produkte im Schlüssel `values_with_counts`. Varianten eines Produkts zählen einmal. Mit `false` enthält der Response nur die Werteliste `values`, und `<ws-filter>` kann keine Trefferanzahl anzeigen. Standardwert: `true`.

Subshopkonfiguration für das Suchmodul

Die Konfiguration des Suchmoduls ist pro Subshop definiert und wird jeweils unter der Subshop-ID als Schlüssel abgelegt. Übersichtsbeispiel

subshop_configs:
  {subshop_id}:          # beispielsweise 01-aa: oder 83-it: (lowercase)
    search_config:       # Basiskonfiguration der Sucharten (exakt, Präfix, Fuzzy)
      {...}
    fields_config:       # Felddefinitionen und Gewichtungen
      {...}
    index_configs:       # Indexeinstellungen
      {...}
    fuzzy_filter:        # Schwellenwerte für unscharfe Suche
      {...}
    stopwords_filter:    # Zu ignorierende Wörter
      {...}
    lemmatization:       # Wortgrundformreduktion
      {...}

Basiskonfiguration des Suchmoduls (search_config)

Die Basiskonfiguration definiert, welche Sucharten aktiv sind und wie Suchbegriffe ausgewertet werden. Über diese Einstellungen wird gesteuert, ob Suchbegriffe exakt, teilweise, unscharf oder als Wortbestandteile gefunden werden sollen. Jede Suchart kann separat aktiviert, gewichtet und kombiniert werden. Grundstruktur

search_config:
  mode: add
  log_search: false
  session_id_secret: "<geheimer-schluessel>"
  exact:
    {...}
  prefix:
    {...}
  wildcard:
    {...}
  ngram:
    {...}
  fuzzy:
    {...}

Parameterbeschreibung

Parameter	Beschreibung
`mode`	Legt fest, wie die Feldboosts der einzelnen Sucharten verrechnet werden, additiv oder multiplikativ.
`log_search`	Zeichnet die Suchanfragen für die Suchstatistik auf. Erfasst werden Suchbegriffe mit Treffern, Suchbegriffe ohne Treffer und Kategorieaufrufe ohne Suchbegriff. Suchbegriffe mit Treffern und Kategorieaufrufe werden mit Trefferzahl und angewendeten Filtern gespeichert, Suchbegriffe ohne Treffer ohne Filter. Kategorieaufrufe werden nur erfasst, wenn sie Treffer liefern. Zusätzlich werden Sprache und Gerät gespeichert. Die Sitzungskennung wird nur gespeichert, wenn `session_id_secret` gesetzt ist. Voraussetzung ist der Statistik-Index, den WEBSALE einrichtet. Fehlt er, zeichnet das Suchmodul nichts auf und schreibt eine Warnung ins Log. Ein Fehler beim Aufzeichnen bricht die Suche nicht ab. Default: `false`
`session_id_secret`	Geheimer Schlüssel, mit dem die Sitzungskennung vor dem Speichern anonymisiert (gehasht) wird. Ohne Angabe wird keine Sitzungskennung gespeichert und das Suchmodul schreibt eine Warnung ins Log. Nur relevant bei `log_search: true`.
`exact`	Konfiguration für exakte Übereinstimmungen von Suchbegriffen, siehe Abschnitt Exact Search.
`prefix`	Konfiguration für Präfix-Suchen, bei denen der Suchbegriff am Wortanfang steht, siehe Abschnitt Prefix Search.
`wildcard`	Konfiguration für Wildcard-Suchen, bei denen der Suchbegriff an beliebiger Stelle im Wort vorkommen kann, siehe Abschnitt Wildcard Search.
`ngram`	Konfiguration für N-Gram-Suchen, bei denen Teile des Suchbegriffs innerhalb eines Wortes übereinstimmen, siehe Abschnitt Ngram Search.
`fuzzy`	Konfiguration für fehlertolerante (unscharfe) Suchen, die auch leicht abweichende Schreibweisen berücksichtigen, siehe Abschnitt Fuzzy Search.

Jede Suchart kann zusätzlich der Fallback-Suche zugeordnet werden, siehe Fallback-Suche bei null Treffern.

Fallback-Suche bei null Treffern

Eine großzügige Suche findet zwar mehr Treffer, liefert aber auch mehr unpassende. Die Fallback-Suche löst diesen Zielkonflikt, indem im Normalfall nur mit den präzisen Sucharten gesucht wird. Erst wenn diese Hauptsuche in einem Index keinen einzigen Treffer bringt, wird für diesen Index automatisch eine zweite Suche mit toleranteren Sucharten gestartet. So bleiben die Ergebnisse bei korrekter Eingabe sauber und der Kunde landet bei einem Tippfehler trotzdem nicht auf einer leeren Ergebnisseite. Die Fallback-Suche greift dabei pro Index. Liefert die Produktsuche beispielsweise keine Treffer, die Kategoriesuche aber schon, wird für die Produkte trotzdem die Fallback-Suche ausgeführt. Welche Suchart zu welcher Suche gehört, legt der Parameter fallback der jeweiligen Suchart fest:

Hauptsuche: alle Sucharten mit enabled: true und fallback: false
Fallback-Suche: alle Sucharten mit fallback: true, unabhängig von enabled

Beispielkonfiguration

search_config:
  mode: add
  log_search: true
  exact:
    enabled: true
    fallback: false       # Hauptsuche
    boost: 2.0
    tie_breaker: 0.3
  prefix:
    enabled: true
    fallback: false       # Hauptsuche
    boost: 1.75
  wildcard:
    enabled: false
    fallback: true        # Fallback-Suche
    boost: 1.5
  ngram:
    enabled: false
    fallback: true        # Fallback-Suche
    boost: 1.25
    tie_breaker: 0.3
    minimum_should_match: 80%
  fuzzy:
    enabled: false
    fallback: true        # Fallback-Suche
    boost: 0.75
    tie_breaker: 0.3
    fuzziness: AUTO

Im Beispiel sucht der Shop zuerst exakt und nach Wortanfängen. Findet er nichts, sucht er erneut mit Wildcard-, N-Gram- und Fuzzy-Suche. Verhalten im Detail

Die Fallback-Suche startet nur bei einer Suche mit Suchbegriff. Eine Kategorieseite ohne Suchbegriff löst sie nicht aus.
Die Suchvorschläge nutzen die Fallback-Suche ebenfalls, wenn die Hauptsuche keine Produktvorschläge liefert.
Findet auch die Fallback-Suche nichts, bleibt es beim Ergebnis ohne Treffer.
Ist keine Suchart mit fallback: true konfiguriert, gibt es keine Fallback-Suche. Das Verhalten entspricht dann dem bisherigen.

Eine Suchart mit enabled: true und fallback: true wird nur in der Fallback-Suche, nicht in der Hauptsuche ausgeführt. Mindestens eine Suchart muss zur Hauptsuche gehören. Wenn alle aktivierten Sucharten auf fallback: true stehen, bricht die Suche mit einem Konfigurationsfehler ab.

Exakte Suche (exact)

Die exakte Suche liefert Treffer nur dann, wenn der Suchbegriff exakt mit dem gespeicherten Wort übereinstimmt. Sie bildet damit die präziseste Form der Suche und wird meist als Basis oder Ergänzung zu anderen Sucharten verwendet. Treffer aus der exakten Suche erhalten in der Regel eine höhere Relevanz, da sie eine vollständige Übereinstimmung darstellen. Diese Suchart sollte immer aktiviert bleiben, da sie sicherstellt, dass bei identischen Schreibweisen die relevantesten Ergebnisse zuerst erscheinen, beispielsweise bei exakten Produktnamen, Marken oder Artikelnummern. Über den Boost-Wert lässt sich die Gewichtung gegenüber anderen Sucharten feinjustieren. Standardkonfiguration

exact:
    enabled: true
    fallback: false
    boost: 2.0
    tie_breaker: 0.3

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) die exakte Suche. Sollte in der Regel aktiviert bleiben.
`fallback`	Ordnet die Suchart der Fallback-Suche zu (`true`), die nur startet, wenn die Hauptsuche keine Treffer liefert. Bei `true` läuft die Suchart unabhängig von `enabled` nur in der Fallback-Suche. Siehe Fallback-Suche bei null Treffern. Default: `false`
`boost`	Relevanzfaktor für exakte Treffer. Ein höherer Wert verstärkt die Gewichtung exakter Übereinstimmungen im Gesamtranking. Empfohlen: 2.0 bis 3.0.
`tie_breaker`	Bestimmt, wie stark sich Mehrfachtreffer desselben Suchbegriffs in mehreren Feldern auf den Score auswirken. Ein Wert von 0.1 bis 0.3 ist in der Regel sinnvoll, um die Relevanz leicht zu erhöhen, ohne sie zu dominieren.

Präfix-Suche (prefix)

Die Präfix-Suche liefert Treffer, wenn der Suchbegriff am Anfang eines Wortes steht. Sie wird typischerweise genutzt, um Treffer während der Eingabe zu ermöglichen oder um Wortanfänge zu erkennen. Die Eingabe „schn” liefert beispielsweise auch Ergebnisse wie Schneider, Schnürsenkel oder Schnalle. Diese Suchart ergänzt die exakte Suche sinnvoll, da sie flexibler auf Teilbegriffe reagiert, ohne die Präzision vollständig aufzugeben. Besonders nützlich ist sie in Kombination mit Autocomplete-Funktionen und Suggest-Komponenten. Standardkonfiguration

prefix:
    enabled: true
    fallback: false
    boost: 1.75

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) die Präfix-Suche.
`fallback`	Ordnet die Suchart der Fallback-Suche zu (`true`), die nur startet, wenn die Hauptsuche keine Treffer liefert. Bei `true` läuft die Suchart unabhängig von `enabled` nur in der Fallback-Suche. Siehe Fallback-Suche bei null Treffern. Default: `false`
`boost`	Relevanzfaktor für Präfix-Treffer. Empfohlener Bereich: 1.0 bis 2.0, um Wortanfänge leicht zu bevorzugen, ohne exakte Treffer zu verdrängen.

Wildcard-Suche (wildcard)

Die Wildcard-Suche findet Treffer, wenn der Suchbegriff an beliebiger Stelle innerhalb eines Wortes vorkommt. Sie ist deutlich flexibler als die Präfix-Suche, da sie auch Wortbestandteile erkennt. Die Eingabe „hose” liefert beispielsweise Treffer wie Jeanshose, Arbeitshose oder Strumpfhose. Diese Suchart eignet sich besonders für Fälle, in denen Nutzer nicht den exakten Wortanfang kennen, beispielsweise bei zusammengesetzten Begriffen, Varianten von Produktnamen oder technischen Bezeichnungen. Standardkonfiguration

wildcard:
    enabled: true
    fallback: false
    boost: 1.5

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) die Wildcard-Suche. Empfohlen, wenn Teilbegriffe oder Wortbestandteile relevant sind.
`fallback`	Ordnet die Suchart der Fallback-Suche zu (`true`), die nur startet, wenn die Hauptsuche keine Treffer liefert. Bei `true` läuft die Suchart unabhängig von `enabled` nur in der Fallback-Suche. Siehe Fallback-Suche bei null Treffern. Default: `false`
`boost`	Relevanzfaktor für Wildcard-Treffer. Empfohlener Bereich: 0.5 bis 1.5, um flexible Treffer zuzulassen, aber exakte Übereinstimmungen weiterhin zu priorisieren.

Teilwortsuche / N-Gram-Suche (ngram)

Die N-Gram-Suche liefert Treffer, wenn ein Teil des Suchbegriffs innerhalb eines Wortes vorkommt, unabhängig davon, ob der Begriff am Anfang, in der Mitte oder am Ende steht. Sie basiert auf der Aufteilung von Wörtern in kleine Einheiten, den sogenannten N-Grammen, die während des Indexaufbaus erzeugt werden. Diese Suchart eignet sich besonders für technische Begriffe, Modellnummern, Artikelcodes oder zusammengesetzte Wörter, von denen der Nutzer häufig nur Teile kennt. Die Eingabe „AB12” findet beispielsweise auch AB1234-X oder XX-AB12-Z. Standardkonfiguration

ngram:
    enabled: true
    fallback: false
    boost: 1.25
    tie_breaker: 0.3
    minimum_should_match: 80%

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) die N-Gram-Suche.
`fallback`	Ordnet die Suchart der Fallback-Suche zu (`true`), die nur startet, wenn die Hauptsuche keine Treffer liefert. Bei `true` läuft die Suchart unabhängig von `enabled` nur in der Fallback-Suche. Siehe Fallback-Suche bei null Treffern. Default: `false`
`boost`	Relevanzfaktor für Teilworttreffer. Empfohlener Bereich: 0.8 bis 1.5, um ergänzende Treffer zuzulassen, ohne exakte Ergebnisse zu verdrängen.
`tie_breaker`	Bestimmt, wie stark Mehrfachtreffer in verschiedenen Feldern den Gesamtscore beeinflussen. Werte zwischen 0.1 und 0.3 sind in der Regel sinnvoll.
`minimum_should_match`	Über den Parameter kann gesteuert werden, wie viel Prozent der N-Gramme übereinstimmen müssen, um als Treffer zu zählen. Das verbessert die Ergebnisqualität. Empfohlen: 60 bis 80 % für eine gute Balance zwischen Trefferquote und Präzision.

Fehlertolerante Suche & Levenshtein-Distanz (fuzzy)

Bei der Fuzzy-Suche handelt es sich um eine fehlertolerante Suchmethode, die Tippfehler oder Abweichungen in der Schreibweise ausgleicht. Grundlage ist die Levenshtein-Distanz, die ermittelt, wie viele Bearbeitungsschritte (Einfügen, Löschen, Ersetzen) erforderlich sind, um ein Wort in ein anderes zu überführen. Beispiele:

„Haus” → „Maus” = Distanz 1 (1 Buchstabe ersetzt)
„Haus” → „Huas” = Distanz 2 (Buchstaben vertauscht, also zweimal ersetzt)
„Haus” → „Hause” = Distanz 1 (ein Buchstabe eingefügt)

fuzzy steuert die globale fehlertolerante Suche auf Basis der Levenshtein-Distanz. Hier wird festgelegt, ob Fuzzy aktiv ist, welche Fehlertoleranz gilt, beispielsweise AUTO abhängig von der Wortlänge, und wie stark fuzzy Treffer im Scoring gewichtet werden (boost, tie_breaker). Die Konfiguration wirkt grundsätzlich auf alle Suchbegriffe und Felder, sofern sie nicht durch nachgelagerte Regeln eingeschränkt wird. Siehe Ausnahmen zur globalen Fuzzy-Logik (fuzzy_filter). Standardkonfiguration

...
fuzzy:
  enabled: true
  fallback: false
  boost: 0.75
  tie_breaker: 0.3
  fuzziness: AUTO
...

Fuzzy-Suche aktiviert: Fehlertolerante Matches auf Basis der Levenshtein-Distanz sind aktiv.
Gewichtung: Mit boost = 0.75 erhalten fuzzy-Treffer rund 75 % des Gewichts eines exakten Treffers. Höhere Werte priorisieren fuzzy stärker, 0 deaktiviert den Boost-Effekt.
Feldübergreifende Gewichtung: tie_breaker = 0.3 bewirkt, dass zusätzliche Treffer in weiteren Feldern den Score mit etwa 30 % beitragen. Kleinere Werte dämpfen diesen Mehrfeld-Effekt, größere verstärken ihn.
Fehlertoleranz: fuzziness = AUTO passt die erlaubte Edit-Distanz an die Wortlänge an. 1 bis 2 Zeichen → 0, 3 bis 5 → 1, ab 6 → 2.

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert oder deaktiviert die fehlertolerante Suche in der Hauptsuche. Bei `false` findet dort keine Fuzzy-Auswertung statt. Steht `fallback` auf `true`, läuft die Fuzzy-Suche trotzdem in der Fallback-Suche, mit den Einstellungen `fuzziness`, `boost` und `tie_breaker`.
`fallback`	Ordnet die Suchart der Fallback-Suche zu (`true`), die nur startet, wenn die Hauptsuche keine Treffer liefert. Bei `true` läuft die Suchart unabhängig von `enabled` nur in der Fallback-Suche. Siehe Fallback-Suche bei null Treffern. Default: `false`
`boost`	Gewichtet den Einfluss der Fuzzy-Treffer im Ranking. - `1.0` entspricht neutral, also weder Ab- noch Aufwertung. - Werte `< 1.0` schwächen Fuzzy gegenüber exakten Treffern ab, beispielsweise `0.75`. - Werte `> 1.0` stärken Fuzzy, beispielsweise `1.5`. - `0` bedeutet, dass Fuzzy-Treffer das Scoring nicht beeinflussen. Die Abfrage kann weiterhin matchen, liefert aber keinen Score-Beitrag.
`fuzziness`	Steuert die erlaubte Edit-Distanz (Ersetzen, Einfügen, Löschen) pro Wort. - `0` → keine Fehlertoleranz, es muss nach Analyse und Normalisierung exakt passen. - `1` → bis zu 1 Edit erlaubt. - `2` → bis zu 2 Edits erlaubt. - `AUTO` → passt die Distanz an die Wortlänge an. Wortlänge 1 bis 2 → 0, 3 bis 5 → 1, ab 6 → 2. - `AUTO:x,y` → eigene Schwellen. Bis x-1 Zeichen → 0, ab x bis y-1 → 1, ab y → 2. Beispiel `AUTO:4,8`: Längen bis 4 → 0, 5 bis 8 → 1, ab 9 → 2.
`tie_breaker`	Bei einer Suche wird meist in mehreren Feldern gleichzeitig gesucht, etwa im Titel, in der Marke und in der Beschreibung. Das System bewertet jedes Feld separat. Zuerst zählt immer das Feld mit der besten Übereinstimmung, beispielsweise der Titel. `tie_breaker` legt fest, wie stark zusätzliche Treffer in den anderen Feldern den Gesamtscore mittragen. - Mit `tie_breaker = 0.0` zählt nur das beste Feld. Treffer in weiteren Feldern bringen keinen Zusatzpunkt. - Mit einem moderaten Wert von etwa 0.2 bis 0.4 liefern die anderen Felder einen kleinen Bonus. Treffer in mehreren Feldern werden also sichtbar, ohne das Ranking zu dominieren. - Mit 1.0 würden alle Felder voll addiert. Das ist selten sinnvoll, weil schwächere Treffer aus langen Beschreibungen sonst zu viel Gewicht bekommen. Beispiel: Ein Begriff passt sehr gut im Titel (Score 10), mittel in Marke (6) und schwach in Beschreibung (3). - 0.0 → Gesamtscore etwa 10, nur der Titel zählt. - 0.3 → Gesamtscore etwa 10 + 0.3×(6+3) = 12.7. Der Titel bleibt führend, die anderen Felder helfen ein wenig.

Datenfelder

Mit fields_config wird festgelegt, welche Datenfelder in den Suchindex aufgenommen werden und wofür sie genutzt werden, also Suche, Anzeige, Filter, Sortierung, Teilwortsuche, Varianten und Kategorien. Änderungen an diesem Block werden nach Neustart des Suchmoduls aktiv. Grundstruktur

fields_config:
  search_fields:
    - {...}
    - {...}
  display_fields:
    - {...}
    - {...}
  filter_fields:
    {...}
  sort_fields:
    - {...}
    - {...}
  ngram_fields:
    - "..."
    - "..."
  variant_fields:
    - "..."
    - "..."
  category_field: ""

Parameterbeschreibung

Parameter	Beschreibung
`search_fields`	Definition der Felder, in denen gesucht werden soll, siehe Abschnitt Search Fields.
`display_fields`	Angabe der Felder, die im Suchergebnis an das Frontend übergeben werden, siehe Abschnitt Display Fields.
`filter_fields`	Definition der verfügbaren Filter und deren Typen im Such-Frontend, siehe Abschnitt Filter Fields.
`sort_fields`	Angabe der Felder, nach denen die Ergebnisse sortiert werden können, siehe Abschnitt Sort Fields.
`ngram_fields`	Festlegung der Felder, für die die Teilwortsuche (N-Gram-Suche) aktiv ist, siehe Abschnitt Ngram Fields.
`variant_fields`	Definition der Felder, die Produktvarianten kennzeichnen, siehe Abschnitt Variant Fields.
`category_field`	Angabe des Feldes, das die Kategorie-IDs enthält, siehe Abschnitt Category Field.

Datenfelder für die Suche (search_fields)

In diesem Abschnitt wird festgelegt, in welchen Feldern die Suche tatsächlich durchgeführt wird. Ohne definierte Suchfelder kann keine inhaltliche Suche stattfinden. Die Auswahl der Felder hängt vom jeweiligen Shop ab. Typischerweise werden Produktname, Beschreibung, Kategoriebezeichnungen, Marke oder Hersteller und Farbvarianten angegeben. Standardkonfiguration

fields_config:
  ...
  search_fields:
    - field: name
      boost: 3
    - field: descr
      boost: 2
    - field: brand
      boost: 1.5

Parameterbeschreibung

Parameter	Beschreibung
`field`	Name des Datenfeldes, das in den Suchindex aufgenommen und somit auch durchsucht werden soll. Es muss der technische Feldname des Datenfelds aus dem Datenfeed angegeben werden, das diese Information enthält, beispielsweise - Produktname (`name`) - Produktbeschreibung (`descr`) - Marke (`brand`)
`boost`	Optionaler Relevanzfaktor für das angegebene Datenfeld. Die Relevanzwerte reichen von 1 (niedrig) bis 5 (hoch). Höhere Werte bedeuten, dass das Feld bei der Berechnung des Suchergebnisses stärker gewichtet wird.

Datenfelder im Such-Response (display_fields)

In diesem Abschnitt wird festgelegt, welche Felder im Such-Response an das Shop-Frontend übergeben werden. Diese Felder können anschließend direkt in den WebComponents zur Anzeige verwendet werden. Standardmäßig wird nur die Produktnummer beziehungsweise der Produktindex zurückgegeben, da im Standard über diesen Index die Produktdaten aus der Shopdatenbank geladen und durch die WEBSALE Template-Engine im Frontend dargestellt werden. Wenn die Darstellung der Produkte nicht über das Laden der Shopdatenbank und somit nicht über die WEBSALE Template-Engine erfolgen soll, müssen in diesem Abschnitt alle Felder ergänzt werden, die für die Anzeige im Frontend benötigt werden, beispielsweise Preis, Marke oder Produktbild. Weitere Informationen siehe Integration in die Templates (Storefront). Standardkonfiguration

fields_config:
  ...
  display_fields:
    - field: baseprodindex
    - field: prodindexbase

Parameterbeschreibung

Parameter	Beschreibung
`field`	Es muss der technische Feldname des Produktdatenfelds aus dem Datenfeed angegeben werden.

Datenfelder für die Filter (filter_fields)

In diesem Abschnitt wird festgelegt, welche Filter im Such-Frontend verfügbar sind und nach welchen Feldwerten gefiltert werden kann. Das Filtersystem unterstützt verschiedene Typen von Filtern, die direkt über die Konfiguration definiert werden. Je nach Datentyp oder Anwendungsfall können so einfache Auswahlfilter, Preisbereiche oder benutzerdefinierte Filterlogiken erstellt werden. Unterstützte Filtertypen:

Terms-Filter (terms): exakte Werte, beispielsweise Marken, Farben oder Kategorien.
Range-Filter (range): numerische Wertebereiche, beispielsweise Preis oder Bewertung.
Custom-Filter (custom): benutzerdefinierte Bedingungen, beispielsweise „salesrank ≤ 1000”.
Default-Filter (default): automatisch aktive Filter, beispielsweise „nur verfügbare Produkte”.

Standardkonfiguration

fields_config:
  ...
  filter_fields:
    farbgrp:
      type: terms
      label: Farbe
    price:
      type: range
      label: Preis
    salesrank:
      type: custom
      label: Bestseller
      op_type: lte
      filter_value: 1000
    rating:
      type: custom
      label: Top bewertet
      op_type: gte
      filter_value: 4.0
    new_field:
      type: custom
      label: NEU
      op_type: eq
      filter_value: true
    inventory:
      # wird dauerhaft und nicht sichtbar angewendet, sorgt dafür,
      # dass die Suche wirklich nur verfügbare Produkte anzeigt
      - type: default
        op_type: gt
        filter_value: 0
      # damit der Kunde entscheiden kann, dass er auch nicht verfügbare
      # Produkte angezeigt bekommt
      - type: custom
        label: "Nicht verfügbare Artikel"
        op_type: rm

Terms-Filter farbgrp für Farben.
Range-Filter price für den Preis von und bis.
Custom-Filter salesrank, der Produkte mit einem Verkaufsrang kleiner oder gleich 1000 filtert.
Custom-Filter rating, der Produkte mit einer durchschnittlichen Kundenbewertung größer oder gleich 4 filtert.
Custom-Filter new_field, der Produkte filtert, die mit Neu gekennzeichnet sind.
Default-Filter inventory, der standardmäßig alle nicht verfügbaren Produkte ausfiltert, kombiniert mit einem Custom-Filter, der es ermöglicht, diesen Default-Filter zu entfernen und damit auch nicht verfügbare Produkte anzuzeigen.

Parameterbeschreibung

Parameter	Beschreibung
`<feldname_datenfeed>`	Technischer Feldname des Datenfelds aus dem Datenfeed, auf das sich der Filter bezieht, beispielsweise: - Farbe → `farbgrp` - Preis → `price` - Verkaufsrang → `salesrank` - Lagerbestand → `inventory` Werden mehrere Filter auf dasselbe Feld angewendet, muss eine Liste konfiguriert werden. Jeder Listeneintrag beginnt mit einem Bindestrich (`-`). Ein Beispiel dafür ist die Filterdefinition für `inventory` mit einem Default- und einem Custom-Filter, siehe oben im Codebeispiel für die Standardkonfiguration.
`type`	Typ des Filters: `terms`, `range`, `custom` oder `default`. Neben kundenspezifischen (dynamischen) Filtern stehen im Standard bereits vordefinierte `custom`- und `default`-Filter zur Verfügung, beispielsweise salesrank, rating, new_field oder inventory.
`label`	Optionaler Anzeigename des Filters, der im Frontend dargestellt wird.
`op_type`	Bedingungstyp für benutzerdefinierte Filter. Legt fest, wie der Vergleich des Feldwerts erfolgen soll. Verfügbare Operatoren: - `eq` — equal → gleich - `lt` — less than → kleiner als - `lte` — less than or equal → kleiner oder gleich - `gt` — greater than → größer als - `gte` — greater than or equal → größer oder gleich - `rm` — remove → entfernt einen zuvor gesetzten Filter, beispielsweise zur Aufhebung eines Default-Filters Nur für Filter des `type: custom` und `type: default` relevant.
`filter_value`	Vergleichswert, mit dem die Filterbedingung geprüft wird. Wird zusammen mit `op_type` verwendet, um festzulegen, welche Produkte ein- oder ausgeschlossen werden. Beispiele: - `0` bei `inventory` → zeigt nur Produkte mit einem Lagerbestand größer 0. - `true` bei `new_field` → zeigt nur Produkte, die als „neu” gekennzeichnet sind. Nur relevant für Filter des Typs `custom` und `default`. Über `filter_value` können auch Produkte ausgeschlossen werden.

Ausschluss bestimmter Produkte (filter_fields)

Standardmäßig erscheinen alle aktiven Produkte in der Suche. Der Ausschluss bestimmter Produkte erfolgt innerhalb von filter_fields. Über filter_fields können Produkte regelbasiert ausgeschlossen werden, ohne sie offline zu nehmen. Dieser Abschnitt beschreibt die Konfiguration im Suchmodul. Aktive Regeln filtern die betroffenen Artikel zur Laufzeit aus den Suchergebnissen. Beispielkonfiguration filter_fields

filter_fields:

  # Ausschluss: Produktnummer enthält "99", "88" ODER "77"
  produktnummer:
    type: default
    op_type: neq
    filter_value:
      - "99*"
      - "*88"
      - "*77*"

  # Ausschluss: Kategorie ist "Sonderposten" ODER "Testkategorie"
  category:
    type: default
    op_type: neq
    filter_value:
      - "Sonderposten"
      - "Testkategorie"

  # Ausschluss: Marke ist "adidas" und beispielsweise auch "adidas originals" ODER "Puma"
  brand:
    type: default
    op_type: neq
    filter_value:
      - "adidas*"
      - "Puma"

  # Ausschluss: Reduziert/SALE ist "true", das Produkt ist also im SALE beziehungsweise reduziert
  is_reduced:
    type: default
    op_type: eq
    filter_value: true

Parameterbeschreibung filter_fields Jeder Eintrag unter filter_fields ist eine Regel pro Datenfeld. Diese Regel wird bei jeder Suche geprüft und entscheidet, ob ein Produkt in die Ergebnisliste darf oder nicht.

Parameter	Beschreibung
`filter_value`	Vergleichswerte der Regel. Es wird definiert, wogegen verglichen wird. Mehrere Felder unter `filter_fields` werden UND verknüpft, alle Regeln müssen also erfüllt sein. Mögliche Eingaben und Werte beziehen sich auf den Datentyp des Datenfeldes im Suchindex: - Datentyp `Text`: Unterstützt Text und ``-Wildcards. `TEST` beginnt mit TEST, `TEST` endet mit TEST, `TEST*` enthält TEST. Mehrere Werte können als Array angegeben werden, innerhalb des Feldes gilt ODER-Logik. - Datentyp `Bool/Zahl`: ohne Wildcards, exakt angeben, beispielsweise `true`/`false` oder `0`/`1`.

Mehr Informationen zu den filter_fields sowie eine vollständige Übersicht der Parameter finden Sie im Abschnitt Datenfelder für die Filter (filter_fields).

Datenfelder für die Sortierung (sort_fields)

Dieser Block wird nur konfiguriert, wenn die UI-Komponente <ws-sort-box use-api="true"> verwendet wird. In diesem Fall liest die Komponente die Einträge aus sort_fields und generiert automatisch eine Select-Box mit allen konfigurierten Sortieroptionen. Änderungen an sort_fields sind dadurch sofort im Frontend sichtbar, ohne dass das Template angepasst werden muss. Wird use-api="false" genutzt, ist sort_fields nicht erforderlich. Die Sortier-UI wird dann manuell über das Template bereitgestellt. Mehr zur UI-Komponente ws-sort-box finden Sie hier. Standardkonfiguration

fields_config:
  ...
  sort_fields:
    - field: _score
      label:
        desc: Relevanz
    - field: name
      label:
        asc: Alphabetisch (A-Z)
        desc: Alphabetisch (Z-A)
    - field: price
      label:
        asc: Preis aufsteigend
        desc: Preis absteigend

Parameterbeschreibung

Parameter	Beschreibung
`field`	Es muss der technische Feldname des Datenfelds aus dem Datenfeed angegeben werden, das für die Sortierung verwendet werden soll.
`label`	Definition der im Frontend angezeigten Sortierbezeichnungen. Wenn kein Label angegeben ist, wird die Sortierung nicht erstellt.
`asc`	Anzeigename der aufsteigenden Sortierung, beispielsweise Preis aufsteigend.
`desc`	Anzeigename der absteigenden Sortierung, beispielsweise Preis absteigend.

Reihenfolge bei gleichen Feldwerten Bei jeder Sortierung nach einem Feld, beispielsweise nach Preis oder Name, verwendet das Suchmodul die Relevanz (_score) als zweites Sortierkriterium. Produkte mit demselben Feldwert erscheinen dadurch in der Reihenfolge ihrer Relevanz. Das gilt unabhängig davon, ob die Sortieroptionen über sort_fields oder manuell im Template bereitgestellt werden. Bei der Sortierung nach Relevanz selbst entfällt das zweite Kriterium. Wie sich das auf gewichtete Produkte auswirkt, beschreibt der Abschnitt Gewichtung nach Feldwerten.

Datenfelder für Teilwortsuche (ngram_fields)

In diesem Abschnitt wird definiert, für welche Felder die Teilwortsuche (auch N-Gram-Suche genannt) aktiviert wird. Die Teilwortsuche ermöglicht es, auch bei unvollständigen oder teilweise passenden Suchanfragen Treffer zu finden. Die Eingabe „jack” liefert beispielsweise auch Ergebnisse wie “Jacke”, “Jacket” oder “Jackett”. Beim Aufbau des Suchindex werden für die hier definierten Felder sogenannte N-Gram-Token erzeugt. Dadurch können Suchbegriffe bereits während der Eingabe oder bei ungenauer Schreibweise erkannt werden. Typische Felder sind Produktname, Beschreibung oder Artikelnummern. Standardkonfiguration

fields_config:
  ...
  ngram_fields:
    - name
    - descr
    - number

Parameterbeschreibung

Parameter	Beschreibung
`ngram_fields`	Liste der technischen Feldnamen des Datenfelds aus dem Datenfeed, für die die Teilwortsuche aktiviert werden soll.

Variantenfelder für Filter (variant_fields)

In diesem Abschnitt wird festgelegt, welche Variantenattribute bei der Ermittlung von Filterwerten berücksichtigt werden sollen. Da die Berechnung von Filteroptionen (Aggregation) über viele Variantenprodukte performancekritisch ist, müssen die relevanten Variantenfelder hier explizit angegeben werden. Nur die in diesem Abschnitt definierten Felder fließen bei der Filterermittlung ein und beziehen dabei die Varianten eines Produkts mit ein. Standardkonfiguration

fields_config:
  ...
  variant_fields:
    enabled: true
    fields:
      - size
      - color

In diesem Beispiel werden die Felder Farbe (color) und Größe (size) als Variantenfelder definiert.

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert die Berücksichtigung von Variantenattributen aus dem Datenfeed, um diese als Filterwerte bereitzustellen.
`fields`	Liste der technischen Feldnamen von Variantenattributen.

Kategoriefelder (category_field)

In diesem Abschnitt wird der Feldname eingetragen, der die Kategorie-IDs (Kategorieindizes) enthält. Der hier konfigurierte Feldname wird vom Suchmodul verwendet, um den Kontext korrekt zu bestimmen, also Suchergebnisseite oder Kategorieseite, und Produkte nach einer Suche, Filterung oder Sortierung in der richtigen Kategorie zu öffnen. Der Standardwert ist in der Regel bereits gesetzt und sollte nicht geändert werden. Standardkonfiguration

fields_config:
  ...
  category_field: catids

Parameterbeschreibung

Parameter	Beschreibung
`category_field`	Enthält immer den Feldnamen des Datenfelds aus dem Datenfeed, das die Kategorie-IDs enthält.

Ausnahmen zur globalen Fuzzy-Logik (fuzzy_filter)

fuzzy_filter definiert gezielte Ausnahmen zur globalen Fuzzy-Logik. Damit lassen sich einzelne Begriffe stets exakt suchen, also ohne Fuzzy, um Verwechslungen zu vermeiden. Ebenso lassen sich ganze Felder von Fuzzy ausschließen, beispielsweise Produkt-IDs. Dieser Abschnitt dient der Feinsteuerung, wenn das Standardverhalten zu unerwünschten Treffern führt oder bestimmte Datenfelder grundsätzlich exakt behandelt werden sollen. Standardkonfiguration

...
fuzzy_filter:
  enabled: true
  list: []
  excluded_fields:
    - productnumber
    - productid
...

Fuzzy-Suche aktiviert: Tippfehler werden gemäß der globalen Fuzzy-Toleranz in der search_config toleriert, beispielsweise abhängig von der Wortlänge.
Keine globalen Wort-Ausschlüsse: Die Liste list ist absichtlich leer, da kritische Begriffe je Shop variieren und individuell gepflegt werden sollten.
Felder ohne Fuzzy: In productnumber und productid wird kein Fuzzy-Match durchgeführt, dort gilt die exakte Suche auf IDs und SKUs.

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) den Fuzzy-Filter. Wenn `true`, wird der Fuzzy-Filter angewendet, bestimmte Felder oder Begriffe werden also laut `excluded_fields` beziehungsweise `list` von der Fuzzy-Suche ausgeschlossen. Wenn `false`, ist der Fuzzy-Filter inaktiv und die Fuzzy-Suche greift auf alle Felder ohne Einschränkung zu.
`list`	Liste von Begriffen, die ohne Fuzzy gesucht werden, also exakt. Diese Wörter werden exakt gesucht, auch wenn Tippfehler vorliegen. Nützlich für kritische Begriffe oder Begriffe mit hoher Verwechslungsgefahr. Beispiel: `list:` `- westen` `- western` Wenn hier `westen` und `western` eingetragen werden, gelten für diese beiden Wörter keine Tippfehler-Toleranzen. Dadurch werden Verwechslungen verhindert, beispielsweise zwischen der Kategorie Western und dem Kleidungsstück Westen.
`excluded_fields`	Felder, in denen Fuzzy grundsätzlich nicht angewendet werden soll, beispielsweise `productnumber` oder `productid` für die exakte ID-Suche.

Toleranz für das Ignorieren von Stopwörtern (stopwords_filter)

Die Konfiguration im Suchmodul legt ausschließlich fest, ob die beim Import definierte Stopwort-Liste während der Anfrageauswertung berücksichtigt wird. Mit stopwords_filter wird das Ignorieren von Stopwörtern zur Laufzeit ein- oder ausgeschaltet. Ist es aktiv, werden Begriffe aus der hinterlegten Liste vor dem Matching entfernt, während Wörter aus der Whitelist nicht entfernt und damit ganz normal gewertet werden. Die inhaltliche Zusammenstellung der Stopwort-Liste selbst erfolgt nicht im Suchmodul, sondern vollständig im Importmodul. Standardkonfiguration stopwords_filter

stopwords_filter:
  enabled: true

Parameterbeschreibung stopwords_filter

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) die Toleranz für das Ignorieren von Stopwörtern. Ist nur sinnvoll in Kombination mit einer gepflegten Stopwort-Liste aus dem Import.

Grammatikalische Flexion (lemmatization)

In diesem Abschnitt wird festgelegt, ob und in welcher Sprache Suchbegriffe während der Suche auf ihre grammatikalische Grundform reduziert werden. Dadurch erkennt das System, dass unterschiedliche Wortformen denselben Begriff meinen, etwa „rote Hemden”, „rotes Hemd” oder „Hemd in Rot”. Die Funktion verbessert die semantische Erkennung und sorgt für natürlichere Suchergebnisse. Für technische Felder wie Produktnummern oder Modellcodes kann die Lemmatization deaktiviert bleiben, um exakte Zeichenfolgen zu wahren.

Von der Verwendung der grammatikalischen Flexion (Lemmatisierung) zur Suchzeit wird abgeraten. Suchanfragen bestehen im E-Commerce typischerweise aus nur einem bis drei Wörtern und liefern damit nicht genügend Kontext für eine zuverlässige Lemmatisierung in deutscher Sprache. Dadurch kann die Nutzerabsicht verfälscht werden, beispielsweise wird aus „blau” fälschlich „blauen”, und die Suche liefert unvorhersehbare oder fehlende Ergebnisse. In der Praxis werden die relevanten Varianten bereits durch die vorhandenen Match-Strategien abgedeckt, unter anderem Exact, Prefix, N-gram, Fuzzy und Wildcard. Falls spezielle Fälle abgebildet werden müssen, ist ein Synonym-Mapping die bessere Alternative, da es kontrollierbar und nachvollziehbar ist. Die Lemmatisierung kann weiterhin zur Index-Zeit sinnvoll sein, beispielsweise bei längeren Produkttexten mit ausreichend Kontext. Sie sollte jedoch nicht bei der Verarbeitung der Suchanfrage aktiviert werden.

Standardkonfiguration

lemmatization:
  enabled: true
  language: de

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) die grammatikalische Reduktion von Suchbegriffen auf ihre Grundform. Grundlage sind die sprachspezifischen Wortstämme und Modelle der NLP-Bibliotheken spaCy und Simplemma. Bei deaktivierter Einstellung erfolgt eine wortgenaue Suche ohne sprachliche Vereinheitlichung.
`language`	Definiert die Sprache, für die der Lemmatizer angewendet wird. Aktuell verfügbar: - Deutsch (`de`) = Standard - Englisch (`en`) - Spanisch (`es`) - Französisch (`fr`) - Italienisch (`it`) - Niederländisch (`nl`) - Portugiesisch (`pt`) - Dänisch (`da`) - Tschechisch (`cs`) - Polnisch (`pl`) - Finnisch (`fi`) - Indonesisch (`id`) - Slowakisch (`sk`) - Türkisch (`tr`) - Schwedisch (`sv`) - Norwegisch Bokmål (`nb`) Je nach gewählter Sprache werden die entsprechenden Sprachmodelle von spaCy und Simplemma genutzt, um grammatikalische Varianten korrekt zu erkennen.

Hervorgehobene Produkte (promoted_products)

Mithilfe von promoted_products lassen sich bestimmte Produkte in den Suchergebnissen gezielt nach oben holen, unabhängig vom errechneten Ranking. Bei der Suche nach „Reithelm“ erscheint beispielsweise zuerst das Modell, das der Shop gerade bewerben möchte. Artikel einer Eigenmarke stehen ebenfalls vor allen anderen. Es gibt zwei Arten von Hervorhebungen:

Suchbegriffbasiert (query_based): gilt nur für bestimmte Suchbegriffe.
Global (global): gilt für alle Suchanfragen.

Bei beiden Arten lassen sich entweder einzelne Produkte (products) oder alle Produkte mit einem bestimmten Feldwert (promoted_fields) hervorheben. Ein Eintrag kann auch beides enthalten. Zusätzlich lassen sich beide Arten über Filterbedingungen und Zeiträumen einschränken. promoted_products folgt der oben beschriebenen Konfigurationshierarchie und kann global, je Sprache oder je Subshop gesetzt werden. Grundstruktur

promoted_products:
  query_based:
    - products: ["pid1", "pid2", "pid3"]
      queries: ["query1", "query2"]
      # optional
      show_on_filters:
        {field_name}: ["value1", "value2"]
      hide_on_filters:
        {field_name}: ["value1", "value2"]
      hide_on_filter: true
      hide_on_sort: true
      active_from: "YYYY-MM-DDTHH:MM:SS"
      active_until: "YYYY-MM-DDTHH:MM:SS"
    - promoted_fields:
        - field: field1
          value: "value1"
      queries: ["query3"]
      # optional wie oben
  global:
    - products: ["pid1"]
      # optional wie oben
    - promoted_fields:
        - field: field1
          value: "value1"
      # optional wie oben

Suchbegriffbasierte Hervorhebung (query_based)

Jeder Eintrag verknüpft eine Liste von Suchbegriffen entweder mit festen Produkten (products), mit Feldbedingungen (promoted_fields) oder mit beidem. Gibt der Kunde einen dieser Begriffe ein, werden die entsprechenden Produkte ganz oben in den Suchergebnissen angezeigt. Beispiel: feste Produkte

promoted_products:
  query_based:
    # Reithelme bei "reithelm" und "helm", auch mit Filtern und Sortierung
    - products: ["780347", "780348"]
      queries: ["reithelm", "helm"]
      hide_on_filter: false
      hide_on_sort: false
    # Decken bei "decken" oder "decke", nur im März
    - products: ["660879", "660878"]
      queries: ["decken", "decke"]
      hide_on_filter: true
      hide_on_sort: true
      active_from: "2026-03-01T00:00:00"
      active_until: "2026-03-31T23:59:59"

Beispiel: Produkte mit einem bestimmten Feldwert

promoted_products:
  query_based:
    # Bei "reithelm" und "helm" alle Produkte der Marke "Websale" nach oben holen
    - promoted_fields:
        - field: brand
          value: "Websale"
      queries: ["reithelm", "helm"]
    # Festes Produkt und Feldbedingung in einem Eintrag
    - products: ["780347"]
      promoted_fields:
        - field: brand
          value: "Websale"
      queries: ["sattel"]

Damit lassen sich bei bestimmten Suchbegriffen alle Produkte mit einem Feldwert hervorheben, beispielsweise einer Marke, ohne einzelne Produkt-IDs zu pflegen.

Der Suchbegriff muss vollständig mit einem Eintrag aus queries übereinstimmen. Verglichen wird dabei der vom Suchmodul bereits verarbeitete Suchbegriff, nicht die ursprüngliche Eingabe des Kunden. Groß- und Kleinschreibung sowie Leerzeichen am Anfang und Ende sind irrelevant. Die Suche nach „reithelm schwarz“ löst also nicht den Eintrag reithelm aus. Nehmen Sie deshalb häufige Kombinationen als eigene Einträge in queries auf.

Globale Hervorhebung (global)

Globale Einträge gelten für alle Suchanfragen. Wie bei query_based heben sie feste Produkte (products) hervor, d.h. alle Produkte, deren Feld einen bestimmten Wert enthält (promoted_fields), oder beide Kategorien. Beispiel: feste Produkte

promoted_products:
  global:
    # Produkt-Banner nur in den Kategorien 247439 und 408031
    - products: ["780347"]
      show_on_filters:
        catids: ["247439", "408031"]
    # Saisonartikel nur von April bis September
    - products: ["123456", "789012"]
      active_from: "2026-04-01T00:00:00"
      active_until: "2026-09-30T23:59:59"

Beispiel: Produkte mit einem bestimmten Feldwert

promoted_products:
  global:
    # Marke "Websale" immer bevorzugen
    - promoted_fields:
        - field: brand
          value: "Websale"
    # Winterartikel nur von November bis Februar
    - promoted_fields:
        - field: season
          value: "Winter"
      active_from: "2026-11-01T00:00:00"
      active_until: "2027-02-28T23:59:59"

Das Feld aus promoted_fields muss in den display_fields stehen. Andernfalls kann das Suchmodul den Feldwert nicht vergleichen, die Hervorhebung bleibt wirkungslos und es erscheint eine Warnung im Log.

Parameterbeschreibung

Parameter	Beschreibung
`query_based`	Liste der suchbegriffbasierten Hervorhebungen.
`global`	Liste der globalen Hervorhebungen.
`products`	Liste der Produkt-IDs, die hervorgehoben werden. Anzugeben ist immer die ID des Basisprodukts, nicht die einer Variante. Die ID entspricht dem Wert des Feldes, das im Importmodul als `product_id` konfiguriert ist, im Standard `number`.
`queries`	Nur bei `query_based`: Liste der Suchbegriffe, bei denen die Produkte hervorgehoben werden.
`promoted_fields`	Liste von Feldbedingungen. Jedes Produkt, bei dem mindestens eine Bedingung zutrifft, wird hervorgehoben. Kann in `query_based` und `global` verwendet und im selben Eintrag mit `products` kombiniert werden. - `field` - Feldname im Suchindex. Muss in `display_fields` stehen. - `value` - Wert, den das Feld haben muss. Bei Feldern mit mehreren Werten genügt ein passender Wert.
`show_on_filters`	Optional. Die Hervorhebung greift nur, wenn für eines der genannten Felder einer der genannten Werte als Filter gesetzt ist. Angabe als Feldname mit Werteliste.
`hide_on_filters`	Optional. Die Hervorhebung entfällt, sobald für eines der genannten Felder einer der genannten Werte als Filter gesetzt ist.
`hide_on_filter`	Optional. Bei `true` entfällt die Hervorhebung, sobald irgendein Filter gesetzt ist. Ist `show_on_filters` angegeben, zählen dabei nur Filter auf anderen Feldern. Default: `true`
`hide_on_sort`	Optional. Bei `true` entfällt die Hervorhebung, sobald der Kunde eine andere Sortierung wählt. Das erkennt das Suchmodul nicht durch einen Vergleich mit der Standardsortierung, sondern am Request-Parameter `sortOrderChanged`. Die WebComponents setzen diesen Parameter selbst. Wer die API direkt anspricht, muss `sortOrderChanged` mitschicken. Default: `true`
`active_from`	Optional. Zeitpunkt, ab dem die Hervorhebung gilt, im Format ISO 8601, beispielsweise `2026-03-01T00:00:00`. Ohne Angabe gilt sie sofort.
`active_until`	Optional. Zeitpunkt, bis zu dem die Hervorhebung gilt. Ohne Angabe gilt sie dauerhaft.

Weil hide_on_filter standardmäßig auf true gesetzt ist, greift eine globale Hervorhebung auf Kategorieseiten nicht. Dort ist immer der Kategoriefilter gesetzt. Wenn Sie ein Produkt in einer bestimmten Kategorie hervorheben möchten, geben Sie die Kategorie über show_on_filters an, wie im Beispiel mit catids.

Das Suchmodul vergleicht die Zeitangaben mit der Serverzeit. Die Zeitzone in der Angabe wird ignoriert. Ein ungültiges Datum schaltet die Hervorhebung ab und erzeugt eine Warnmeldung im Log.

Reihenfolge der Ergebnisse

Sind mehrere Hervorhebungen gleichzeitig aktiv, ordnet das Suchmodul die Treffer so:

Die Produkte aus products werden in der Reihenfolge der Konfiguration angezeigt. Suchbegriffbasierte Einträge stehen vor globalen. Doppelt genannte Produkte erscheinen nur einmal. Diese Produkte erscheinen auch dann, wenn sie den Suchbegriff selbst nicht enthalten. Sie erscheinen außerdem unabhängig von den gesetzten Filtern, weil das Suchmodul die Filter nur auf die regulären Treffer anwendet. Im Beispiel mit show_on_filters und catids erscheint das Produkt in den Kategorien 247439 und 408031 also auch dann, wenn es diesen Kategorien gar nicht zugeordnet ist. Das gilt ebenso, wenn bei hide_on_filter: false Filter gesetzt sind.
Produkte, die eine Bedingung aus promoted_fields erfüllen.
Alle übrigen Treffer in der gewählten Sortierung.

Hervorhebungen wirken nur auf der ersten Ergebnisseite. Produkte aus promoted_fields werden dabei nur innerhalb der Treffer der ersten Seite nach oben sortiert. Ein passendes Produkt, das erst auf Seite drei stünde, wird durch die Feldbedingung nicht nach vorne geholt.

Gewichtung nach Feldwerten (field_value_weights)

Hervorgehobene Produkte werden an festen Positionen ganz oben angezeigt. Oft genügt es jedoch, bestimmte Produkte im Ranking etwas zu stärken oder abzuschwächen, ohne ihre genaue Position festzulegen. Dafür gibt es field_value_weights. Damit können Sie für bestimmte Werte eines Feldes einen Gewichtungsfaktor festlegen. Das Suchmodul multipliziert anschließend die errechnete Relevanz jedes Treffers mit diesem Faktor. So rückt ein Produkt der Marke „Websale Premium“ in der Ergebnisliste nach oben, bleibt aber Teil des normalen Rankings. Die Gewichtung wirkt sich sowohl auf die Suche als auch auf die Suchvorschläge aus, weil Produkt-, Kategorie- und Inhaltsseiten-Vorschläge dieselbe Suchkonfiguration nutzen wie die jeweilige Suche. Sie lässt sich für jeden Index einzeln festlegen.

Produkte: direkt unter field_value_weights. Der Block folgt der oben beschriebenen Konfigurationshierarchie und kann global, je Sprache oder je Subshop gesetzt werden.
Kategorien und Inhaltsseiten: im jeweiligen Index unter index_configs.<index>.custom_config.field_value_weights, siehe Index-Konfiguration.

Beispielkonfiguration

subshop_configs:
  deutsch:
    field_value_weights:           # für den Product-Index
      - field: marke
        weights:
          - value: "Websale Premium"
            weight: 2.0            # Relevanz × 2.0, verdoppelt die Relevanz
          - value: "Websale Basic"
            weight: 0.5            # Relevanz × 0.5, halbiert die Relevanz
      - field: warengruppe
        weights:
          - value: "Hardware"
            weight: 2.0
          - value: "Zubehör"
            weight: 0.5
    index_configs:                 # für Category- und Content-Index
      category:
        enabled: true
        custom_config:
          field_value_weights:
            - field: cat_id
              weights:
                - value: ["407156", "407009", "411546"]                    # Kategorien „Neu“
                  weight: 0.5
                - value: ["254690", "256477", "247390", "254682", "254686"]  # Kategorien „Sale“
                  weight: 0.1

Die Beispielkonfiguration funktioniert wie folgt:

Produkte der Marke „Websale Premium“ sowie Produkte der Warengruppe „Hardware“ erhalten die doppelte Relevanz. Sie erscheinen in den Suchergebnissen und den Produktvorschlägen deutlich weiter oben.
Produkte der Marke „Websale Basic“ und Produkte der Warengruppe „Zubehör“ erhalten die halbe Relevanz und erscheinen somit weiter unten in den Suchergebnissen und Produktvorschlägen.
Die Kategorie „Neu“ erhält in der Kategoriesuche und den Kategorievorschlägen die halbe Relevanz und die Kategorie „Sale“ nur noch ein Zehntel. Sie erscheinen deshalb deutlich weiter unten.

Die Gewichtung im Category-Index betrifft die Suche nach Kategorien, also die Kategorietreffer und Kategorievorschläge. Auf die Reihenfolge der Produkte innerhalb einer Kategorieseite hat sie keinen Einfluss.

Verhalten im Detail

Der Wert muss exakt mit dem Feldinhalt übereinstimmen, einschließlich Groß- und Kleinschreibung. Teilwörter oder Wildcards werden nicht unterstützt.
Trifft auf ein Produkt mehr als eine Gewichtung zu, werden die Faktoren miteinander multipliziert. Ein Produkt der Marke „Websale Premium“ aus der Warengruppe „Hardware“ erhält im Beispiel also die vierfache Relevanz.
Die Gewichtung verändert die Relevanz. Bei der Sortierung nach Relevanz bestimmt sie die Reihenfolge direkt. Wählt der Kunde eine Sortierung nach einem Feld, beispielsweise nach Preis, entscheidet zuerst der Feldwert. Haben mehrere Produkte denselben Wert, ordnet das Suchmodul sie als zweites Kriterium nach Relevanz. Bei gleichem Preis stehen gewichtete Produkte also weiter vorne.
Hervorgehobene Produkte stehen weiterhin vor allen gewichteten Treffern.
Ungültige Einträge überspringt das Suchmodul und schreibt eine Warnung ins Log, beispielsweise einen Faktor, der keine Zahl ist oder nicht größer als 0.

Parameterbeschreibung

Parameter	Beschreibung
`field_value_weights`	Liste der Gewichtungsregeln. Jeder Eintrag gilt für ein Feld.
`field`	Technischer Feldname im Suchindex, immer in Kleinbuchstaben.
`weights`	Liste der Werte mit ihrem Gewichtungsfaktor.
`value`	Wert im Feld `field`, der gewichtet werden soll. Ein einzelner Wert als String oder mehrere Werte als Liste von Strings. Bei einer Liste gilt der Faktor für jeden der Werte.
`weight`	Gewichtungsfaktor, eine Zahl größer als `0`. Die errechnete Relevanz wird mit dem Faktor multipliziert. Werte über `1` stärken die Relevanz, Werte unter `1` schwächen sie ab.

Index-Konfiguration (index_configs)

Über index_configs wird pro Subshop gesteuert, welche Indizes bei der Suche zur Laufzeit aktiv sind und wie sie sich verhalten. Ein Index muss sowohl im Importmodul als auch hier im Suchmodul aktiviert sein, um wirksam zu werden. Grundstruktur

index_configs:
  product:        # Hauptindex für Produktsuche
    {...}
  completion:     # Index für Autovervollständigung
    {...}
  category:       # Index für Kategoriesuche
    {...}
  content:        # Index für statische Inhaltsseiten
    {...}

Produkte (Product-Index)

Der Product-Index ist der Hauptindex und bildet die Grundlage für jede Produktsuche. Er ist in der Regel immer aktiv. Die inhaltliche Konfiguration, also welche Felder durchsucht, gefiltert oder angezeigt werden, erfolgt über fields_config. Über index_configs.product wird primär gesteuert, ob der Index zur Laufzeit aktiv ist. Beispielkonfiguration

index_configs:
  product:
    enabled: true

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) den Produkt-Index im Suchmodul. Sollte in der Regel auf `true` gesetzt bleiben. Muss auch im Importmodul aktiviert sein (`index_configs.product.enabled`).

Autovervollständigung (Completion-Index)

Der Completion-Index dient der Autovervollständigung von Suchbegriffen. Wie beim Product-Index beschränkt sich die Konfiguration auf die reine Aktivierung des Index. Weitergehende Einstellungen, wie beispielsweise fuzziness, werden über suggest_config gesteuert. Die inhaltliche Grundlage wird beim Import festgelegt. Beispielkonfiguration

index_configs:
  completion:
    enabled: true

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert (`true`) oder deaktiviert (`false`) den Completion-Index im Suchmodul. Muss auch im Importmodul aktiviert sein (`index_configs.completion.enabled`).

Kategorien (Category-Index)

Wenn beim Import ein Kategorie-Index angelegt wurde, kann dieser im Suchmodul pro Subshop aktiviert werden. Dadurch werden neben Produkten und gegebenenfalls Inhaltsseiten auch Kategorien in die Suche einbezogen. Beispielkonfiguration

index_configs:
  category:
    enabled: true
    custom_config:
      search_fields:
        - field: cat_str
          boost: 2
        - field: cat_str_path
          boost: 1.5
      display_fields:
        - field: cat_id
        - field: cat_id_path
        - field: cat_str
        - field: cat_str_path
      search_config:
        exact:
          enabled: true
          boost: 2.0
          tie_breaker: 0.3

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert die Suche im Kategorie-Index für den jeweiligen Subshop.
`custom_config`	Konfigurationsblock für die Kategoriesuche. Legt fest, welche Felder durchsucht und welche in der Antwort zurückgegeben werden. Dieser Key wird für zukünftige zusätzliche Indizes analog übernommen.
`search_fields`	Liste der Felder, die bei einer Kategoriesuche durchsucht werden. Sollte immer mindestens `cat_str` und `cat_str_path` enthalten. Pro Feld kann ein `boost`-Wert angegeben werden. Alle untergeordneten Keys sind in diesem Abschnitt dokumentiert.
`display_fields`	Liste der Felder, die in der Suchantwort zurückgegeben werden. Benötigt wird mindestens `cat_id`. Alle untergeordneten Keys sind in diesem Abschnitt dokumentiert.
`search_config`	Optionaler Konfigurationsblock zur Steuerung der Sucharten für den Kategorie-Index. Analog zur Basiskonfiguration des Suchmoduls können die einzelnen Sucharten (`exact`, `prefix`, `wildcard`, `ngram`, `fuzzy`) gezielt aktiviert, deaktiviert und gewichtet werden.
`field_value_weights`	Optional. Gewichtung bestimmter Feldwerte in der Kategoriesuche, beispielsweise für einzelne Kategorie-IDs. Aufbau siehe Gewichtung nach Feldwerten.

Inhaltsseiten (Content-Index)

Wenn beim Import ein Content-Index angelegt wurde, kann dieser im Suchmodul pro Subshop aktiviert werden. Dadurch werden neben Produkten und gegebenenfalls Kategorien auch statische Inhaltsseiten wie „Über uns“, „AGB“ oder „Impressum“ in die Suche einbezogen. Beispielkonfiguration

index_configs:
  content:
    enabled: true
    custom_config:
      search_fields:
        - field: title
        - field: content
      display_fields:
        - field: source
        - field: title
      search_config:
        exact:
          enabled: true
          boost: 2.0
          tie_breaker: 0.3

Parameterbeschreibung

Parameter	Beschreibung
`enabled`	Aktiviert die Suche im Content-Index für den jeweiligen Subshop.
`custom_config`	Konfigurationsblock für die Inhaltsseiten-Suche.
`search_fields`	Liste der Felder, die für die Volltextsuche im Content-Index herangezogen werden. Beim Content-Index sind diese Felder fest vorgegeben, beispielsweise `title` und `content`.
`display_fields`	Liste der Felder, die in der Suchantwort enthalten sein müssen, beispielsweise `source` zum Nachladen des Inhalts und `title` als Label. Auch hier sind die Felder fest je Index-Art definiert.
`search_config`	Optionaler Konfigurationsblock zur Steuerung der Sucharten für den Content-Index. Analog zur Basiskonfiguration des Suchmoduls können die einzelnen Sucharten (`exact`, `prefix`, `wildcard`, `ngram`, `fuzzy`) gezielt aktiviert, deaktiviert und gewichtet werden.
`field_value_weights`	Optional. Gewichtung bestimmter Feldwerte in der Suche nach Inhaltsseiten. Aufbau siehe Gewichtung nach Feldwerten.

Mehrere Content-Quellen aktivieren Pro Content-Quelle aus dem Importmodul brauchen Sie hier einen eigenen Eintrag. Auch im Suchmodul wird content dazu zu einer Liste.

index_configs:
  content:
    - name: static
      enabled: true
      custom_config:
        search_fields:
          - field: title
          - field: content
        display_fields:
          - field: source
          - field: title
    - name: blog
      enabled: true
      custom_config:
        search_fields:
          - field: title
          - field: content
        display_fields:
          - field: source
          - field: title
    - name: magazin
      enabled: true
      custom_config:
        search_fields:
          - field: title
          - field: content
        display_fields:
          - field: source
          - field: title

Parameterbeschreibung

Parameter	Beschreibung
`name`	Name der Content-Quelle. Muss mit dem `name` im Importmodul übereinstimmen, sonst findet das Suchmodul den zugehörigen Index nicht.
`enabled`	Aktiviert die Suche in dieser Quelle.
`custom_config`	Optional. Ohne Angabe verwendet das Suchmodul die Standardkonfiguration des Content-Index. Sie können pro Quelle eine eigene `search_config` und eigene Gewichtungen setzen, beispielsweise um Blog-Treffer schwächer zu gewichten als die statischen Seiten.

Eine Quelle erscheint nur in den Suchergebnissen, wenn der zugehörige Index in Elasticsearch tatsächlich existiert. Wenn der Import einer Quelle fehlschlägt oder die Quelle im Importmodul nicht aktiviert ist, verschwindet sie ohne Fehlermeldung aus den Ergebnissen. Aktivieren Sie eine Quelle daher immer in beiden Modulen und prüfen Sie anschließend im Shop, ob Treffer geliefert werden.

Aufbau der Suchantwort Bei mehreren Content-Quellen werden die Treffer der Suche nicht mehr flach unter content angezeigt, sondern verschachtelt pro Quelle. Unterhalb von content steht je Quelle ein Block mit den Treffern (results) und der Trefferzahl (sub_total). Die Gesamttrefferzahl wird weiterhin über alle Indizes summiert. Die WebComponents erkennen dieses Format automatisch. Wenn Sie die Suchantwort dagegen selbst auswerten, müssen Sie die Verschachtelung berücksichtigen. Ein Beispiel finden Sie unter ws-search-result.

​Importkonfiguration & Konfiguration des Suchmoduls

​Importmodul der Suche

​Suchmodul

​Datenfeed im Dataflow Manager

​Konfigurationshierarchie (ab v1.12.x / v.1.11.x)

​Globale Konfiguration (global_configs)

​Sprachkonfiguration (language_configs)

​Subshop-Konfiguration (subshop_configs)

​Konfiguration des Importmoduls

​Datenfeed-Konfiguration

​Formatspezifische Parameter (format_config)

​Subshopkonfiguration im Importmodul

​Toleranz für das Ignorieren von Stoppwörtern (stopwords)

​Synonyme (synonyms)

​Grammatikalische Flexion (lemmatization)

​Sonderzeichen-Handhabung (punctuation_filter)

Verarbeitungsreihenfolge

Blacklist: bestimmte Zeichen entfernen

Whitelist: nur bestimmte Zeichen behalten

Parameterbeschreibung

​Kategorien

​Inhaltsseiten in den Suchindex aufnehmen

​Mehrere Content-Quellen für die Suche

​Konfiguration des Suchmoduls

​Suchvorschläge (suggest_config)

​Filter (filter_config)

​Subshopkonfiguration für das Suchmodul

​Basiskonfiguration des Suchmoduls (search_config)

​Fallback-Suche bei null Treffern

​Exakte Suche (exact)

​Präfix-Suche (prefix)

​Wildcard-Suche (wildcard)

​Teilwortsuche / N-Gram-Suche (ngram)

​Fehlertolerante Suche & Levenshtein-Distanz (fuzzy)

​Datenfelder

​Datenfelder für die Suche (search_fields)

​Datenfelder im Such-Response (display_fields)

​Datenfelder für die Filter (filter_fields)

​Ausschluss bestimmter Produkte (filter_fields)

​Datenfelder für die Sortierung (sort_fields)

​Datenfelder für Teilwortsuche (ngram_fields)

​Variantenfelder für Filter (variant_fields)

​Kategoriefelder (category_field)

​Ausnahmen zur globalen Fuzzy-Logik (fuzzy_filter)

​Toleranz für das Ignorieren von Stopwörtern (stopwords_filter)

​Grammatikalische Flexion (lemmatization)

​Hervorgehobene Produkte (promoted_products)

​Suchbegriffbasierte Hervorhebung (query_based)

​Globale Hervorhebung (global)

​Parameterbeschreibung

​Reihenfolge der Ergebnisse

​Gewichtung nach Feldwerten (field_value_weights)

​Index-Konfiguration (index_configs)

​Produkte (Product-Index)

​Autovervollständigung (Completion-Index)

​Kategorien (Category-Index)

​Inhaltsseiten (Content-Index)

Importkonfiguration & Konfiguration des Suchmoduls

Importmodul der Suche

Suchmodul

Datenfeed im Dataflow Manager

Konfigurationshierarchie (ab v1.12.x / v.1.11.x)

Globale Konfiguration (`global_configs`)

Sprachkonfiguration (`language_configs`)

Subshop-Konfiguration (`subshop_configs`)

Konfiguration des Importmoduls

Datenfeed-Konfiguration

Formatspezifische Parameter (format_config)

Subshopkonfiguration im Importmodul

Toleranz für das Ignorieren von Stoppwörtern (stopwords)

Synonyme (synonyms)

Grammatikalische Flexion (lemmatization)

Sonderzeichen-Handhabung (punctuation_filter)

Kategorien

Inhaltsseiten in den Suchindex aufnehmen

Mehrere Content-Quellen für die Suche

Konfiguration des Suchmoduls

Suchvorschläge (suggest_config)

Filter (filter_config)

Subshopkonfiguration für das Suchmodul

Basiskonfiguration des Suchmoduls (search_config)

Fallback-Suche bei null Treffern

Exakte Suche (exact)

Präfix-Suche (prefix)

Wildcard-Suche (wildcard)

Teilwortsuche / N-Gram-Suche (ngram)

Fehlertolerante Suche & Levenshtein-Distanz (fuzzy)

Datenfelder

Datenfelder für die Suche (search_fields)

Datenfelder im Such-Response (display_fields)

Datenfelder für die Filter (filter_fields)

Ausschluss bestimmter Produkte (filter_fields)

Datenfelder für die Sortierung (sort_fields)

Datenfelder für Teilwortsuche (ngram_fields)

Variantenfelder für Filter (variant_fields)

Kategoriefelder (category_field)

Ausnahmen zur globalen Fuzzy-Logik (fuzzy_filter)

Toleranz für das Ignorieren von Stopwörtern (stopwords_filter)

Grammatikalische Flexion (lemmatization)

Hervorgehobene Produkte (promoted_products)

Suchbegriffbasierte Hervorhebung (query_based)

Globale Hervorhebung (global)

Parameterbeschreibung

Reihenfolge der Ergebnisse

Gewichtung nach Feldwerten (field_value_weights)

Index-Konfiguration (index_configs)

Produkte (Product-Index)

Autovervollständigung (Completion-Index)

Kategorien (Category-Index)

Inhaltsseiten (Content-Index)