PrestaShop internal search: why is a listed product missing from the results?

A customer searches for a product you sell, gets an empty list and
tries another store. Support finds the item in the back office and
concludes that everything is registered correctly. Both observations can
be true: an existing catalog record does not prove that a product is
available to storefront search.

Separate three questions: is the product eligible in this context,
are its terms represented in the index, and does the query actually
match them? Only then should you investigate ranking. This guide offers
a reproducible investigation with fictional examples, based on
PrestaShop 9 documentation checked on September 14, 2026. For other
versions or search modules, confirm the available capabilities before
applying commands.

1. Reproduce
the customer’s query, not a similar one

Choose a product and record its ID, name, main reference, combination
references, language and shop. Copy the exact search term, including
hyphens, spaces, accents and codes. Record whether the customer used
suggestions while typing or opened the full results page.

Test as a visitor and, where relevant, with the same customer group.
Do not compare an English search with a catalog record inspected only in
another language. In multistore installations, use the correct domain
and context.

Keep a simple piece of evidence: query, expected result, observed
result, URL and time. “Search is broken” is difficult to investigate.
“LX-204 does not find product 42 in shop 2 in English, but lamp does”
already narrows the problem considerably.

2. Identify what actually
handles search

The search box may look like part of the theme while results come
from the native engine, a module or an external service. Autocomplete
and the full results page may also follow different paths.

Open the browser’s network panel and run the query. Identify the
request returning results, its parameters and the component responsible.
An HTTP 200 response containing an empty list is different from a
JavaScript error that prevents a list from appearing.

If an external engine is involved, inspect its synchronized catalog
and processing records. Rebuilding the native index does not prove that
the other engine has been updated. Document this architecture before
changing settings; otherwise, you may fix a component the customer is
not using.

3. Check
eligibility before rebuilding the index

Confirm that the product is active, assigned to the correct shop and
configured with visibility that allows it to appear in search.
PrestaShop distinguishes product visibility options; access through a
direct URL does not prove that an item should appear everywhere in the
storefront. Check the installed version’s options against the product
documentation.

Also investigate restrictions introduced by modules, access rules and
availability filters. Do not treat zero stock as a universal
explanation: the business may allow out-of-stock products, and a
customization may filter them differently.

If the issue affects one language only, compare the localized fields
actually saved. If it affects one shop only, inspect its associations
and settings. Rebuilding everything before these checks may consume time
and reproduce exactly the same result.

4. Treat
the index as separate from the catalog record

Native search relates words and products through index tables. The
documentation identifies ps_search_word, including shop and
language context, and ps_search_index, holding word,
product and weight relationships. Your database may use a prefix other
than ps_. Official
index structure.

This supports a staged investigation: does the normalized term exist
in the correct context? Is it linked to the expected product? Does the
product pass the query’s filters? Does the result reach the browser? You
do not need to begin by editing database records directly.

An import routine can write fields without following the update path
used by the back office. If the defect returns after every import, the
lasting correction belongs in the update process and its observability.
A manual rebuild that works for a few hours is evidence, not the end of
the investigation.

5.
Worked example: the name matches, the reference does not

Consider a fictional product called Adjustable desk
lamp, ID 42, reference LX-204. The team wants
customers to find it through both descriptive language and the code
printed on the packaging.

Run the first query. If it finds the item, the product is not missing
from every search. Next, inspect the stored code: is it the product
reference, a combination reference or merely text inside an image? Do
not assume that search reads a photograph of the packaging.

Compare the code variants and record their results. Do not remove
every hyphen from the catalog because of one test. That could change
identifiers used by other processes. First determine whether the
discrepancy comes from the record, normalization or engine
configuration.

After the selected correction, repeat every query in the table.
Fixing LX-204 while breaking name searches is not an acceptable outcome.
Add similar products to check whether the engine has begun returning
irrelevant matches.

6. Short terms, ignored
words and aliases

Search settings include minimum word length, ignored words, aliases
and approximate matching features. Field weights influence relevance.
These controls serve different purposes and should be evaluated
separately. Official
search parameters.

In a technical catalog, two letters may identify an important product
line. Elsewhere they may generate mostly unhelpful results. List
relevant short queries before lowering limits globally. Compare result
quality and processing cost in a copy of the store.

An alias may suit a recurring, clearly identified typo, such as
transposed letters in “lamp”. Do not use a massive dictionary as a
substitute for incomplete product information. Each mapping needs a
clear purpose and a test demonstrating that it helps shoppers.

Fuzzy search is not the same as semantic understanding. With
technical references, a visually small difference can point to an
incompatible product. Keep exact-reference tests alongside tests for
typo tolerance.

7.
Missing products and poorly ranked products are different defects

If an item appears on page five, it matches, but the ordering may not
serve the query’s intent. If it appears nowhere, increasing the name
weight may not address the cause.

Build a query set with expected outcomes: an exact code, a specific
name, a broad category and a term appearing only in a description. For
each, specify whether you expect one particular product or a coherent
group. No single ordering is perfect for every intent.

Change one weight at a time and rerun the set. Check whether the
installed implementation requires index rebuilding for the stored
weights to reflect the change. Do not assume that saving a setting has
reprocessed all existing data.

Avoid repeating keywords in descriptions to force a ranking. Besides
making the text worse for readers, this ties the catalog to a particular
engine behavior. Adjust relevance in the appropriate layer and keep
product copy useful to shoppers.

8. Reindex
with a defined scope and verify completion

In the back office, distinguish adding missing items from rebuilding
the entire index. An already indexed product with old terms may need a
different operation from adding new products. Schedule broader
operations outside peak hours and avoid simultaneous rebuilds.

On installations providing the command documented for PrestaShop 9,
inspect local help first:

php bin/console prestashop:search:index --help

To investigate the example in a controlled copy, replace the IDs with
real ones:

php bin/console prestashop:search:index --shop-id=2 --product-id=42

Do not add --full without defining the scope: that
option removes and rebuilds index data. Confirm command availability and
options in the installed version. Official
indexing command.

Record duration, output and exit status. Then verify the storefront
result. With scheduled execution, monitor actual runs rather than merely
checking that a job exists. Protect maintenance URLs containing tokens
and keep them out of public screenshots.

9.
When to investigate the database, modules and presentation

If the index contains the expected terms, inspect the query path. In
a diagnostic environment, correlate search times with logs and requests.
Examine context, parameters, filters, sorting and pagination.

If the server returns the product but the interface does not display
it, investigate the theme, JavaScript and rendering. If autocomplete and
the full page disagree, compare both endpoints. Treat caching as a
concrete hypothesis: identify which layer stored which response before
clearing everything indiscriminately.

When execution is slow, profiling can help locate the cost, but it
does not by itself explain why a product was excluded. Separate
execution time from functional correctness. Preserve a reproducible case
before replacing modules or editing code.

10. Define when the
support issue is resolved

Consider the problem resolved when approved queries return the
expected results in the correct context, the update process preserves
that behavior and the team can repeat the verification.

Record the cause, change, tests and configuration rollback procedure.
Rerun a representative import or edit and confirm that the failure does
not return. To monitor quality, a business can measure searches without
results, query reformulations and clicks after search if that tracking
is implemented; do not assume all those metrics are already
available.

Reliable search depends on catalog records, indexing, query handling
and presentation behaving consistently. AGTI can help locate the failing
stage and correct the process feeding it. Contact the team with a real query
and the product that should be found.