> For the complete documentation index, see [llms.txt](https://docs.abtasty.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.abtasty.com/commerce/search/search-configuration.md).

# Search configuration

**Search** delivers intelligent, catalog-aware search experiences that help visitors find exactly what they need. It runs on the same product catalog as Recommendations and Merchandising, and is configured from the **Search** → **Configuration** page in the Commerce left navigation.

This page covers how to configure search relevance and display, how visitor-facing suggestions are built, the query rules that let you fine-tune results, how to launch the front-end **Search widget**, and how to query search directly through the REST APIs.

{% hint style="info" %}
**What changed:** Search is part of AB Tasty Commerce and shares the catalog connected for Recommendations & Merchandising. The back-office configuration described here lives under **Search** → **Configuration**; the runtime search and autocomplete endpoints are served from a dedicated `{identifier}.search.abtasty.com` host.
{% endhint %}

## Configuration

Open **Search** → **Configuration** from the left navigation. A banner at the top reflects catalog freshness:

> **Your search catalog is up to date / Last refresh: about 14 hours ago**

The search index is rebuilt from your catalog on the same synchronization schedule as the rest of Commerce, see Monitoring Commerce deployment health to track refreshes and synchronizations.

<figure><img src="/files/MFmInCZZuGnve0IZSovR" alt=""><figcaption></figcaption></figure>

#### Display: Displayable attributes

The **Display** section controls **Displayable attributes**, *"Define which attributes can be displayed in your search results."* Each attribute is shown as a removable chip; remove a chip to stop returning that field in search results.

The catalog fields available as displayable attributes include:

| Displayable attributes                        |
| --------------------------------------------- |
| `title`, `link`, `price`, `img_link`, `id`    |
| `Brand`, `Category_id`, `Collection`, `Color` |
| `Description`, `Material`, `Sku`, `Vendor`    |

{% hint style="info" %}
Displayable attributes determine which fields are **returned** with each hit (and therefore available to render in the widget or consume via the API). They are independent from which fields are **searched**, that is controlled by the searchable attributes below.
{% endhint %}

#### Ranking parameters: Searchable attributes for ranking

The **Ranking parameters** section controls **Searchable attributes for ranking**, *"Define which attributes will be used for text search as well as their level of priority."*

This is an ordered, draggable priority list. Fields higher in the list carry more weight when matching a query. Each row has drag, up/down, and delete controls, and you add fields with **Add other searchable attributes**.

| Priority | Searchable attribute |
| -------- | -------------------- |
| 1        | `Title`              |
| 2        | `Description`        |
| 3        | `Category_id`        |
| 4        | `Sku`                |
| 5        | `Collection`         |
| …        | …                    |

{% hint style="info" %}
AB Tasty recommends keeping `Title` at the top of the list and only reordering or adding attributes when you have a specific business reason. Changes take effect on the next catalog refresh.
{% endhint %}

#### Synonyms

The **Synonyms** section lets you group related terms so a query for one returns matches for the others (for example, *sneakers* and *trainers*). Use:

* **Add synonym**: define a synonym group manually.
* **Import synonyms**: bulk-import synonym groups.

{% hint style="info" %}
Synonyms are largely unnecessary when **Semantic search** is active (it is on by default), because semantic matching already understands related concepts. Use synonyms for domain-specific terms or brand names that semantic search may not infer.
{% endhint %}

#### Result quality threshold

The **Result quality threshold** sets the minimum match quality a product must reach to appear in results. Raising it returns fewer, more precise hits; lowering it returns more, broader hits. This corresponds to the `rankingScoreThreshold` parameter exposed in the Search API.

#### Semantic search

**Semantic search** is enabled by default. It matches products by meaning rather than exact keywords, so a query like *"warm winter jacket"* can surface relevant coats even when those exact words are not in the product fields. The balance between semantic and keyword matching maps to the `semanticRatio` parameter in the Search API.

### Sortable attributes and default Relevance

Beyond text ranking, you can offer visitors explicit sort options through **Sortable attributes**. The default sort is **Relevance** (the engine's own ranking for the query). You can add further options such as price ascending/descending, release date, ratings, or popularity, depending on which numeric catalog fields you expose.

At runtime, sort options map to the API `sort` directive, for example `price:asc` (see Search API).

### Autocomplete and suggestions

Autocomplete gives visitors *"a fast, intuitive search experience by surfacing relevant search suggestions as they type."* It is powered by a dedicated **Suggestions index** (the autocomplete index), which is rebuilt daily and served by the `/autocomplete` endpoint.

The suggestions index blends two data sources:

| Source                      | What it contributes                                                                                   |
| --------------------------- | ----------------------------------------------------------------------------------------------------- |
| **Past search queries**     | Real queries typed by your visitors over roughly the last **8 weeks**.                                |
| **Catalog-based whitelist** | A verified list of allowed terms extracted from your active product catalog and custom configuration. |

The daily pipeline runs in three stages:

1. **Data collection**: gathers recent searches (8-week window) plus current catalog data.
2. **Whitelist building**: tokenizes catalog attributes, integrates synonyms configured on the catalog index, and normalizes accents, punctuation, and spacing.
3. **Cleaning & merging**: validates queries against the whitelist, standardizes display formatting, and merges grammatical variations such as plurals and singulars.

Suggestions are then ranked by:

* **Popularity**: queries typed by a larger number of unique visitors rank higher.
* **Relevance**: broader terms that match more catalog items are preferred.

{% hint style="info" %}
**Fallback suggestions:** even a brand-new site with no search history gets catalog-derived suggestions, so high-value products and categories remain suggestible from your very first visitor.
{% endhint %}

### Query rules to optimize results

Query rules let you intervene on specific searches to steer relevance and merchandising. Three mechanisms are available:

* **Redirections**: for specific search terms, send visitors straight to a target page (for example, redirect *"gift card"* to your gift-card landing page). You define the search term and a destination URL.
* **Custom strategies**: query-specific ranking modifications built in the **Strategy Builder**: define the query conditions, then set the filtering and ranking parameters that apply when the query matches.
* **Boost & Bury**: product-level rules that promote (Boost) or demote (Bury) products across searches, at Major / Moderate / Minor strength. These are the same rules used elsewhere in Commerce, see Creating rules: boost and bury.

{% hint style="info" %}
Boost & Bury affects product visibility across all searches; Custom strategies are scoped to the queries they match; Redirections bypass the results page entirely for the matched term.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.abtasty.com/commerce/search/search-configuration.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.