Setting Up 1C-Bitrix Search Autocomplete
We often encounter a situation where a client asks to "make autocomplete," but actually needs product suggestions, and vice versa. The difference is critical: autocomplete completes a phrase, suggestions show specific entities. In this article, we'll explain how we differentiate these scenarios and what we implement for each business case.
Projects often outgrow the standard capabilities of the bitrix:search.suggest component. For example, an e-commerce store with a catalog of 500,000 items requires autocomplete that accounts for query popularity and categories. Or a corporate portal with a thousand employees — suggestions for documents and contacts are needed. We develop custom solutions, integrating autocomplete with the search index and query history. We will evaluate your project for free and select the best turnkey option.
How does standard Bitrix autocomplete work?
The bitrix:search.suggest component offers options from the search index. If autocomplete based on popular user queries is needed — customization is required. We include search history and write our own endpoint.
Scenario 1: Autocomplete from search index User types "red", the system suggests: "red dresses", "red sneakers", "red sofa". Source — titles from b_search_content.
Scenario 2: Autocomplete from search history The system suggests popular queries of other users that match the entered characters. Source — search history from b_search_user_trans (if history tracking is enabled).
The standard bitrix:search.suggest component implements scenario 1. Scenario 2 requires custom development.
What does autocomplete from search history provide?
In practice, a combined UX (history + index) yields 30% more clicks than index alone. Users find popular products faster, and rare queries are not lost. For an electronics store with a catalog of 200,000 items, we implemented such a hybrid — search speed dropped from 4 clicks to 1, and conversion increased by 25%. Additional revenue grew by 15% due to fewer abandoned carts.
Enabling search history
Settings → Search → Module settings → Save search history — enable.
History is stored in b_search_user_trans. Fields: SITE_ID, WORD (search query), DATE_CHANGE, POPULARITY (repeat count).
Implementing autocomplete from popular queries
AJAX endpoint for autocomplete from history:
// /local/ajax/search_autocomplete.php require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'; $query = trim($_GET['q']); if (strlen($query) < 2) { die(json_encode([])); } $result = \Bitrix\Main\Application::getConnection()->query( "SELECT WORD, POPULARITY FROM b_search_user_trans WHERE SITE_ID = '" . SITE_ID . "' AND WORD LIKE '" . \Bitrix\Main\DB\MssqlConnection::ForSql($query) . "%' ORDER BY POPULARITY DESC LIMIT 10" ); $suggestions = []; while ($row = $result->fetch()) { $suggestions[] = $row['WORD']; } echo json_encode($suggestions); On the frontend — standard input with input event handler and debounce 200-300 ms.
Why does a combined UI give the best UX?
In practice, the most convenient UX is a combined dropdown:
- Top part: 3-5 popular queries (autocomplete)
- Bottom part: 5-7 specific products (suggestions with images)
This is implemented via two parallel AJAX requests or a single endpoint returning both data types. A combined interface gives 30-40% more clicks on search results.
| Parameter | Autocomplete (search index) | Autocomplete (search history) |
|---|---|---|
| Source | b_search_content | b_search_user_trans |
| Requires setup | No, out of the box | Yes, enable search history |
| Accuracy | High for products | High for popular phrases |
| Performance | Fast, index ready | Slower, requires selection |
Comparison by implementation time
| Solution type | Setup time | Database load |
|---|---|---|
| Standard search.suggest | 1-2 hours | Low |
| Custom from history | from 4 hours | Medium (with cache) |
| Combined UI | from 2 days | Medium |
Caching
Autocomplete queries run on every keystroke — it's important to cache responses. Options:
- Bitrix cache (
\Bitrix\Main\Data\Cache) with TTL 30-60 minutes - Redis/Memcached to store popular queries
- Static files for top-100 popular queries (updated by agent once an hour)
What is included in the work
- Analysis of current search architecture and autocomplete requirements
- Implementation of AJAX endpoint for autocomplete/suggestions
- Caching setup (tagged cache, Redis/Memcached)
- Front-end integration (debounce, UI component)
- Load testing and query optimization
- Documentation of modifications and maintenance recommendations
Work process
- Analytics — study of business requirements, current search and load
- Design — selection of autocomplete scenario, endpoint and cache architecture
- Development — coding, component setup, UI layout
- Testing — validation on real data, load testing
- Deployment — rollout to production, performance monitoring
Implementation time
From 1 day for basic autocomplete to 5 days for a complex combined solution with custom UI. Cost is calculated individually after project analysis. Contact us — we will evaluate your project and offer the best turnkey solution.
Case study
For an electronics e-commerce store with a catalog of 200,000 items, we implemented autocomplete with category awareness and search history. Result: product search speed reduced from 4 clicks to 1, search conversion increased by 25%. We used Redis tagged cache and 300 ms debounce.
Learn more about autocomplete on Wikipedia. Our team has over 5 years of Bitrix development experience, certified specialists. We have completed more than 30 search customization projects. We guarantee stable operation under load up to 10,000 simultaneous users.
Get a consultation on your project — we will select the optimal solution for your budget and timeline. Write to us.