How the catalogue is indexed

The engines per store, language and currency, what goes into each document, and the routes that keep the index up to date, on PrestaShop and on Shopify.

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, whether the store runs on PrestaShop or on Shopify.

One engine per store, language and currency

During the handshake, the PrestaShop module tells us which shops it has, in which languages and with which currencies; on a Shopify store, the app reads the published languages and the main currency at the moment it is installed. 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. On Shopify, each published language receives whatever product translations exist in the store, and the original where they do not: a product without a translation never disappears from that language's engine.

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. Combinations and variants go in too, each with its own reference and barcode: the EAN read off the box of one size finds the product, and search can add the right size or colour to the cart.

On PrestaShop, 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. A product the store still allows to be ordered while out of stock counts as being in stock in all three options: it is neither hidden nor pushed down, and it shows in the results the delivery time written on its sheet.

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). On Shopify, orders arrive through the platform itself, and only the ones that search or the assistant touched come in.

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 routes that keep it up to date

After the first complete indexing, the day to day takes care of itself, and the exact shape depends on the platform.

On a PrestaShop store

1. Real time. Saving, deleting or changing the stock of a product pushes the change straight away, through the module's hooks. 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.
2. 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/sync has to be reachable from outside.
3. Manual. The Reindex everything button, in the panel or 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.

On a Shopify store

1. Real time, through webhooks. Shopify itself tells Buskara whenever a product is created, changed or deleted, or the stock moves, and the change reaches the index seconds later. There is nothing to configure: the subscriptions are made when the app is installed.
2. Periodic safety net. On a regular cycle, Buskara checks with Shopify what changed since the last pass, so nothing is left behind if a webhook gets lost along the way. It does not depend on any store address being reachable.
3. Manual. The Reindex everything button on the store's page, in the panel. See reindexing the catalogue.

Installation and the day to day are described step by step in connecting a Shopify store.

The content, every hour

The blog and the store pages have no real-time hook, and it makes no sense to reindex the whole catalogue because of one article. On a PrestaShop store with content switched on, Buskara makes a pass of its own every hour, over the articles and pages only, rebuilding the content engine in full; it is the only way to also catch what was unpublished. This pass is always free, whoever asks for it.

A published article therefore shows up in search within the hour, without anyone clicking anything.

What indexing costs

Routine costs nothing: real time, the periodic sync, the first sync of a Shopify store and the hourly content pass are never charged. They do not push against the plan limit and they do not generate overage. Keeping the catalogue up to date should not be a budget decision.

What has a price is forcing: clicking Reindex everything costs 1 bToken per 1,000 documents sent, and the warning with the count shows before you confirm. It is explained in reindexing the catalogue; what is spent shows on the usage chart, on the reindex line. 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.