How the catalogue is indexed
The engines per store, language and currency, what goes into each document, and the three routes that keep the index up to date.
Search does not run over the store database. It runs over an index of ours, which is a copy of the catalogue prepared to answer in milliseconds. This guide is about how that copy is made and how it stays faithful.
One engine per store, language and currency
During the handshake, the module tells us which shops it has, in which languages and with which currencies. A search engine is born for each combination, and that is what you see under Search → Search engines: the store it belongs to, what it indexes, the language and the currency, how many documents it has and when the last indexing was.
The separation is not a tidiness detail. A product name in French and in Portuguese are different texts, and a search for "chaussures" should not find results through the Portuguese text. Prices follow the same logic: each engine holds the ones in its currency.
A multi-language store therefore has more than one engine, and almost everything configured per engine (weights, synonyms, filters) is configured once for each of them.
What goes into a document
Of each product we keep what serves to find it and to show it: reference, EAN and MPN, name, brand, categories, features and attributes, descriptions, price, image, stock status and the URL in the store.
Three module options change what gets there:
- Prices with tax: decides whether the indexed price is with or without tax. It has to match what the store shows, or the results say one number and the product page says another.
- Image size: which of the PrestaShop images travels to the index. The one for the search cards, not the detail one.
- Products out of stock: index them anyway, push them down in the results, or hide them.
And three optional signals, which the store shares if it wants to, and which are not there for searching but for sorting and measuring: sales volume (feeds the "best sellers" sort order and the detection of invisible best sellers), cost price (gives margins in analytics) and orders (tie search to revenue).
Warning Turning the sharing of sales or cost on or off calls for a full reindex for the index to reflect the change. The module warns you when that happens.
The three routes that keep it up to date
After the first complete indexing, the day to day takes care of itself:
- Real time. Saving, deleting or changing the stock of a product pushes the change straight away. This is where the overwhelming majority of updates go through, and it is what makes the price and the stock in search the same as in the store.
- Periodic sync. On a regular cycle, the platform asks the store to go over the catalogue again, and this is what catches what real time did not see (a CSV import, a change made directly in the database). For it to work, the address
https://your-store/module/buskara/synchas to be reachable from outside. - Manual. The Reindex everything button in the module, or the command line. See reindexing the catalogue.
When to suspect route 2 Firewalls, basic authentication on pre-production environments and "my IP only" rules block the periodic sync without giving a visible error in the back office. The symptom is the index sitting still for days while real time carries on working.
What indexing costs
Nothing to the plan. Indexing counts symbolically (10 requests for every 10,000 indexed items) and is never charged: it does not push against the limit and it does not generate overage. Keeping the catalogue up to date should not be a budget decision.
What shows up on the usage chart is that symbolic count, and it is there for transparency, so you can see what the index has been doing. See what counts as a request.
A second engine, for the content
The blog and the store pages can be indexed separately, in an engine of their own, and show up in the results without stealing space from the products. It is optional and it is switched on in the module; it is explained in articles and store content.