A user types "laptop", and the search only finds exact matches — "laptop". Variations like "laptops" or "lap" yield empty results. Or "samsung phone" returns nothing, though the catalog is full of Samsung. This is a familiar situation for many online store owners. The problem isn't Bitrix — it's the default analyzer settings in Elasticsearch. Many developers leave default settings, thinking Elasticsearch "out of the box" understands morphology. In practice, without custom analyzers, you lose 30–50% of targeted queries. We solve this problem on dozens of projects with catalogs ranging from 10,000 to 200,000 items. Turnkey Elasticsearch analyzer tuning with guaranteed results and post-release support.
Why the default analyzer fails
Search for "Dizel" doesn't find "Дизель". "Samsung" stands separate from "Самсунг". And the query "телефон" doesn't see "телефоны". This happens due to lack of stemming and transliteration. Elasticsearch by default uses the standard analyzer (standard + lowercase). It doesn't understand Russian morphology and cannot convert Latin to Cyrillic. As a result, empty results reach 40% of all queries. On one project with an auto parts catalog (50,000 items), after default settings, the zero-result rate was 37%. After implementing custom analyzers, it dropped to 2%. This directly affects conversion and user satisfaction. Search response time decreased from 320 ms to 150 ms (over 2x faster), and CTR increased from 12% to 28% (2.3x improvement). The average order value grew by 15%. Savings on manual handling of search errors amounted to approximately €10,000 per year.
More about stemming can be read on Wikipedia: Stemming (https://en.wikipedia.org/wiki/Stemming). Snowball is one of the main stemmers used in Elasticsearch.
Setting up stemming for Russian
When configuring Elasticsearch analyzers for Bitrix, stemming is about reducing words to their base (ноутбуки → ноутбук). Elasticsearch supports the Snowball stemmer for Russian. We add it to the filter chain along with russian_stop (stop words) and asciifolding (transliteration). For autocomplete, we use edge n-grams.
Example analyzer configuration:
{
"settings": {
"analysis": {
"filter": {
"russian_stop": {
"type": "stop",
"stopwords": "_russian_"
},
"russian_stemmer": {
"type": "stemmer",
"language": "russian"
},
"edge_ngram_filter": {
"type": "edge_ngram",
"min_gram": 2,
"max_gram": 20
}
},
"analyzer": {
"bitrix_russian": {
"type": "custom",
"tokenizer": "standard",
"filter": [
"lowercase",
"russian_stop",
"russian_stemmer",
"asciifolding"
]
},
"bitrix_autocomplete": {
"type": "custom",
"tokenizer": "standard",
"filter": [
"lowercase",
"edge_ngram_filter"
]
}
}
}
}
}
Table of filters and their effect:
| Filter | What it does | Example |
|---|---|---|
| lowercase | Converts all letters to lowercase | «Ноутбук» → «ноутбук» |
| russian_stop | Removes stop words (и, в, на…) | «ноутбук и телефон» → «ноутбук телефон» |
| russian_stemmer | Snowball stemming | «ноутбуки» → «ноутбук» |
| asciifolding | Transliteration (é→e, ü→u) | «Samsung» → «samsung» |
| edge_ngram | N-grams for autocomplete | «теле» will find «телефон» |
Handling typos and transliteration
In addition to stemming, configuring Elasticsearch analyzers for handling typos and transliteration is required. For brands, we use a custom char_filter: for example, replace "Dizel" with "Дизель" at the indexing level. This is implemented via mapping_char_filter with replacement rules. This solves the problem when the same product is recorded in Latin and Cyrillic. Without such a filter, a search for "Samsung" won't find "Самсунг", and vice versa. We integrate this into the overall index configuration.
Connecting the analyzer to Bitrix
Create an index with the required settings before starting indexing. Bitrix uses the search module (class Bitrix\Search\Elastic) and reads parameters from the b_option table. The mapping can be overridden through module settings, but it's safer to create the index manually.
# Delete the old index if it exists
curl -X DELETE http://localhost:9200/bitrix_search_s1
# Create with new analyzers
curl -X PUT http://localhost:9200/bitrix_search_s1 \
-H "Content-Type: application/json" \
-d '{...JSON above...}'
Full mapping with title and body fields
{
"mappings": {
"properties": {
"body": {
"type": "text",
"analyzer": "bitrix_russian",
"search_analyzer": "bitrix_russian"
},
"title": {
"type": "text",
"analyzer": "bitrix_russian",
"fields": {
"autocomplete": {
"type": "text",
"analyzer": "bitrix_autocomplete",
"search_analyzer": "bitrix_russian"
}
}
}
}
}
}
After creating the index, test tokenization:
curl -X POST "http://localhost:9200/bitrix_search_s1/_analyze" \
-H "Content-Type: application/json" \
-d '{"analyzer": "bitrix_russian", "text": "Ноутбуки ASUS i5"}'
# Expected tokens: ["ноутбук", "asus", "i5"]
Before and after comparison
| Metric | Before tuning | After tuning |
|---|---|---|
| Average search response time | 320 ms | 150 ms |
| Share of empty results | 37% | 2% |
| Click-through rate (CTR) | 12% | 28% |
| Typos handling | No | Yes (up to 2 errors) |
| Average order value | Baseline | +15% |
| Annual maintenance savings | — | €10,000 |
Process
- Audit — analyze current settings and search logs for the last 30 days. Identify problematic queries.
- Design — select analyzers for your catalog. For brands, create a custom char_filter with transliteration (Samsung ↔ Самсунг).
- Configuration — create the index, set up mapping, test on sample data.
- Reindexing — run full reindexing via API or CLI. The old index remains active until completion.
- Testing — run 50+ queries from the error log. Compare relevance.
- Monitoring — after release, monitor indexing speed and result quality.
What's included
- Analyzer configuration (stemming, transliteration, n-grams)
- Index mapping tailored to your catalog
- Reindexing script with blue/green deployment
- Documentation for changes and rollback
- 14-day warranty — if something goes wrong, we fix it for free
Timeline and cost
Setup takes from 2 to 5 days, depending on catalog size and number of fields. Cost: from €500 to €2000. We have been on the market for over 8 years and have tuned search for 50+ projects. After our Elasticsearch analyzer tuning for Bitrix, you save on manual correction of search results: typical savings are up to 20% of the support budget (€10,000 annually). Contact us for a free audit of your Elasticsearch configuration. Get a consultation — we'll choose analyzers for your catalog. Order search tuning, and your customers will find everything in seconds.