PrestaShop combination reference search: why the default combination opens

A shopper enters the exact reference of a non-default product combination. PrestaShop may return the correct base product, yet its result link opens the default size and color. That is different from a reference producing no result at all, and the two symptoms need different diagnostics.

Disclosure: Neuroplugin publishes this guide and maintains the commercial NP Search module. The native results below were captured with that module disabled. The catalogue is synthetic; this is maintainer-run QA, not an independent merchant case study.

First separate the three outcomes

This guide addresses the second outcome.

What the PrestaShop 9.1.4 search path retains

PrestaShop's current product-search index documentation lists both a product reference and a combination reference ( pa_reference) under the same PS_SEARCH_WEIGHT_REF setting, with a default weight of 10. So a combination reference can contribute words that make its base product searchable.

The exact PrestaShop 9.1.4 core source also shows the important boundary. Search words are saved against an id_product; the lookup selects distinct product IDs. The listing query then joins the product attribute whose default_on value is 1. The index does not carry the matched id_product_attribute through that path.

In this exact core path, a combination reference can therefore identify the right product while the product card is built with the default combination. PrestaShop's combination resource documentation confirms that reference and default_on are separate combination fields. A theme or search module can use a different provider, so verify the behavior on your actual stack rather than generalizing it to every PrestaShop 9 storefront.

Why rebuilding the index is not the same diagnosis

Reindexing is relevant when the exact reference returns no product. PrestaShop documents product updates, full rebuilds and the Back Office search-index action as ways to refresh the keyword index.

If the exact reference already returns the expected base product, the index has supplied a product match. Rebuilding that same product-level index does not by itself demonstrate that the result URL will retain the matched combination. Check the URL and the selected options after the click; do not treat the presence of the right product card as a complete pass.

A current, reproducible native result

We ran a controlled fixture on PrestaShop 9.1.4, PHP 8.2.29, MariaDB 10.11 and Hummingbird. The third-party search provider was disabled, the production cache was cleared and every product and reference was synthetic.

Searching NPBENCH-TEE-L returned product 24, so the combination reference was present in the native index. The result linked attribute 40, Small / Blue. The expected combination for that reference was attribute 43, Large / Red. The exact environment, URLs and steps are retained in the disclosed PrestaShop issue reproduction.

A separate public fixture we published for PrestaShop 8.2.7 native search observed the same correct-product, wrong-combination boundary. That wider native-only evaluation remains explicitly inconclusive because no candidate search stack or rollback was tested in that run.

This behavior also has a longer public history. PrestaShop issue #18368 was closed as unable to reproduce before the current-version fixture was added, while #40275 tracks combination-reference discovery. Older official-forum threads describe both the no-result symptom and the default-combination symptom; they are related, but not identical.

How to test your own storefront

1. Use staging and record the PrestaShop, PHP, theme and search-provider versions.
2. Create or identify a non-default combination with a unique reference.
3. Search that exact reference. If there is no result, verify visibility, reference weight and index state before rebuilding.
4. Copy the result URL and open it in a clean browser session.
5. Record which combination ID or selected options the page actually opens.
6. If you evaluate another search provider, repeat the same fixture, include desktop and mobile, and retain a rollback check.

What this evidence does — and does not — establish

It establishes a reproducible result for the tested native PrestaShop 9.1.4 path and our separate PrestaShop 8.2.7 fixture. It does not establish that every PrestaShop version, theme or search provider behaves the same way. It also establishes no conversion, revenue, ranking or performance outcome.

Treat exact-reference search as a product-and-combination test, not just a product-card test. Keep the reference, selected combination and destination URL together in your QA evidence so a correct base product cannot hide an incorrect variant handoff.