PrestaShop Search Index: Why Reindexing Products Fixes Search

How PrestaShop Search Works Internally

PrestaShop includes a built-in product search engine that operates on a full-text index stored directly in the MySQL database. Unlike external search services, this index lives alongside your product data in the same database, which means it is fast to query but requires explicit maintenance to stay current. Understanding how this search system works is the first step to diagnosing and fixing search problems.

When a customer types a query into the search bar on your store, PrestaShop does not scan through every product name and description in real time. Instead, it looks up the query terms in a pre-built index that maps individual words to products. This index is constructed by breaking down product text fields into individual words (tokenization), normalizing them (lowercasing, removing accents), and storing the relationship between each word and the products it appears in, along with a relevance weight.

This approach is fundamentally the same as how search engines like Google work, just on a much smaller scale. The tradeoff is that the index must be rebuilt whenever product data changes in ways that the automatic indexing does not catch, which is the root cause of most search problems in PrestaShop.

The Search Database Tables

PrestaShop's search index is spread across several database tables, each serving a specific purpose in the search pipeline.

ps_search_word

This table stores every unique word that has been extracted from your product data, along with the language it belongs to. Each word gets an id_word that serves as a reference key. The table is language-aware, meaning the word "shoe" in your English catalog and "Schuh" in your German catalog are separate entries, each linked to their respective language ID.

When you look at this table, you will see thousands or tens of thousands of rows depending on the size of your catalog and the number of languages. Every distinct word from every indexed product field is represented here.

ps_search_index

This is the core mapping table. Each row links a product (id_product) to a word (id_word) with a weight value. The weight determines how relevant that word is to that product. A word appearing in the product name carries more weight than the same word appearing in the description, and the weight values are configurable in the back office.

When a customer searches for "blue leather wallet", PrestaShop looks up each word in ps_search_word, finds the corresponding id_word values, then queries ps_search_index for products that match those word IDs. Products are ranked by the sum of their weights for the matching words, with higher total weights appearing first in the results.

ps_search_engine

This table stores referrer search engine patterns used for tracking which search engines send traffic to your store. It is not directly related to the internal search functionality but is often confused with it due to the similar naming.

ps_alias

The alias table stores search term aliases, which are alternative spellings or synonyms that should map to a canonical search term. For example, you might configure "sneakers" as an alias for "trainers" so that customers searching for either term get the same results. Aliases are configured in the back office under Shop Parameters > Search > Search > Aliases.

When and Why Reindexing Is Needed

PrestaShop has an automatic indexing feature that updates the search index whenever a product is saved through the back office. When you edit a product and click Save, PrestaShop re-indexes that specific product, updating its entries in ps_search_word and ps_search_index. This works well for day-to-day product management.

However, automatic indexing does not cover every scenario. There are several common situations where a full reindex is necessary.

Bulk Product Imports

When you import products via CSV, the import process may not trigger the search indexing hooks for every product. This is especially common with large imports where performance optimizations skip non-essential processing steps. After a bulk import, new products may exist in the catalog but be completely invisible to site search.

Direct Database Modifications

If you or a module modifies product data directly in the database (bypassing the PrestaShop object model), the search index will not be updated. This includes SQL updates to product names, descriptions, or other indexed fields. Any database migration, data cleanup, or external synchronization tool that writes directly to ps_product_lang will leave the search index stale.

Language Changes

Adding a new language to your store requires a full reindex because the search index is language-specific. Existing products need their content in the new language to be tokenized and added to the index. Similarly, if you edit product content in a specific language (especially through bulk operations), a reindex ensures the changes are reflected in search.

Search Weight Configuration Changes

When you change the weight values assigned to different product fields (more on this below), the existing index entries retain their old weights. A reindex recalculates all weights using the new configuration.

Module Installations or Updates

Some modules modify product data structures or add searchable fields. After installing or updating such modules, a reindex ensures that any new or modified data is included in the search index.

Corrupted Index

Database crashes, failed migrations, or interrupted indexing operations can leave the search index in an inconsistent state. Symptoms include products that should appear in search results but do not, products appearing for completely wrong search terms, or search returning no results at all. A full reindex rebuilds the index from scratch, resolving these inconsistencies.

How to Reindex Products

Back Office Method

Navigate to Shop Parameters > Search in your PrestaShop back office. At the top of the page, you will find an "Indexing" section with options to rebuild the search index. There are typically two options: add products to the index that have not yet been indexed (incremental), or rebuild the entire index from scratch (full reindex).

For most troubleshooting scenarios, choose the full rebuild. The incremental option only adds missing products and does not update existing entries that may have stale data.

The back office method works well for small to medium catalogs (up to a few thousand products). For larger catalogs, it may time out due to PHP execution time limits, which is where the CLI method becomes necessary.

CLI Reindex Command

For large catalogs or automated workflows, use the command line to trigger a reindex. In PrestaShop 1.7 and later, the command is:

php bin/console prestashop:search-index:rebuild

For PrestaShop 1.6, you would call the search indexing script directly. The exact path depends on your installation, but the indexing logic lives in the Search class.

The CLI method does not have the same timeout constraints as the web interface. For very large catalogs (tens of thousands of products across multiple languages), the reindex can take several minutes. You can monitor progress through the output.

If you are running PrestaShop in Docker, execute the command inside the container context where PHP and the PrestaShop codebase are available. Make sure to run it as the web server user to avoid file permission issues with any cache files that get generated during the process.

Automating Reindexing

If your store relies on automated product imports or external data synchronization, schedule periodic reindexing as a cron job. A nightly reindex ensures that any products added or modified through automated processes are searchable the next day. The cron entry would call the same CLI command on a schedule.

Be aware that reindexing locks the search tables briefly during the rebuild. On a busy store, schedule the reindex during low-traffic hours to avoid impacting search availability for active customers.

Weight Configuration: Controlling Search Relevance

PrestaShop allows you to configure how much weight different product fields carry in search results. This is one of the most powerful and most underused features of the built-in search system.

Available Weight Fields

The weight configuration is found in Shop Parameters > Search. You can assign a weight (typically 1 to 10, though higher values work) to each of these product fields:

Product name: This should typically have the highest weight. When a customer searches for a product by name, the product with that exact name should appear first.

Reference: Product reference codes are often used by B2B customers who know the exact SKU they need. A moderate weight ensures reference-based searches work well without overpowering name-based searches.

Short description: The short description often contains key selling points and product characteristics. A moderate weight is appropriate.

Description: The full description contains the most text and therefore the most potential keyword matches. However, because it contains so much text, a high weight can cause irrelevant matches where a search term appears incidentally in a long description. A lower weight relative to the product name is recommended.

Category: Including category names in search allows customers to find products by category terms even when those terms do not appear in the product's own text.

Brand (manufacturer): Customers often search by brand name. A moderate to high weight ensures brand searches return relevant results.

Tags: Tags are explicitly assigned search terms for products. A high weight for tags gives you direct control over which products appear for specific search queries.

Attributes: Product attribute values (size, color, material) can be included in the search index. This allows searches like "red XL" to return products with those attribute combinations.

Features: Product feature values (weight, dimensions, material type) can also be indexed.

Weight Strategy

A reasonable starting configuration might be: product name at 6, reference at 4, short description at 3, description at 1, category at 2, manufacturer at 3, tags at 4, attributes at 2, features at 2. But the optimal weights depend entirely on your catalog and your customers' search behavior.

If your customers frequently search by SKU or reference number, increase the reference weight. If brand searches are important, increase the manufacturer weight. If you find that long descriptions are causing irrelevant results to rank highly, reduce the description weight or set it to zero to exclude descriptions from the index entirely.

After changing weights, always perform a full reindex for the new values to take effect across all products.

Common Search Problems and Solutions

Products Not Appearing in Search Results

This is the most common search complaint. A product exists in the catalog but searching for it by name returns no results. Causes include: the product was added through an import that did not trigger indexing, the product is disabled or out of stock and the search is configured to exclude such products, or the search index is corrupted.

Solution: First, verify the product is active and visible. Then run a full reindex. If the product still does not appear, check whether the product name contains special characters that might be stripped during tokenization, and check whether the minimum word length setting (in Search configuration) is excluding short words from the product name.

Wrong Products Ranking First

When a search for "blue widget" returns a product called "widget holder" before the actual "blue widget" product, it is usually a weight configuration issue. The product that ranks higher has accumulated more total weight across all indexed fields. Perhaps "widget" appears many times in the description of the holder product, and with a high description weight, those occurrences outweigh a single match in the product name.

Solution: Adjust field weights to prioritize the product name. Set the product name weight significantly higher than the description weight. Reindex after making changes.

Search Returns Too Many Irrelevant Results

This happens when the description weight is too high or when common words appear in many product descriptions. A search for "premium" returns every product whose description contains the word "premium" even when it is not a defining characteristic of those products.

Solution: Reduce the description weight or use the blacklisted words feature to exclude common non-discriminating words from the index. The blacklist is configured in Shop Parameters > Search and allows you to specify words that should be ignored during indexing.

Search Does Not Find Partial Matches

PrestaShop's built-in search does not support true fuzzy matching. If a customer searches for "shoe" they will not find products that only contain the word "shoes" unless the stemming or alias features handle the variation. This is a fundamental limitation of the word-based index approach.

Solution: Use the alias feature to map common variations ("shoe" to "shoes", "TV" to "television"). For more comprehensive partial matching, consider an external search solution like Elasticsearch.

Accented Characters Causing Misses

PrestaShop normalizes accented characters during indexing (for example, converting "cafe" and "café" to the same base form). If this normalization is not working correctly, searches with or without accents may produce different results.

Solution: Verify that the search configuration has accent-stripping enabled. Reindex after verifying. If the problem persists, check the database character set and collation, as mismatched encodings can interfere with text normalization.

Search Performance Optimization

For stores with large catalogs (10,000+ products), search performance can become an issue. The built-in search performs database queries against the index tables on every search request, and with a large index, these queries can become slow.

Database Indexing

Ensure that the ps_search_word and ps_search_index tables have proper database indexes. PrestaShop creates these by default, but if the tables have been altered or rebuilt, indexes may be missing. The key indexes are on id_word and id_lang in ps_search_word, and on id_product and id_word in ps_search_index.

Minimum Word Length

The minimum word length setting controls the shortest word that gets indexed. The default is usually 3 characters, meaning one and two-character words are excluded. Increasing this to 4 reduces the index size and can improve search speed, but it means searches for short terms like "XL" or "TV" will not work. Balance index size against your search requirements.

Blacklisted Words

Adding common words ("the", "and", "for", "with") to the blacklist reduces the index size significantly because these words appear in almost every product description. Smaller index tables mean faster queries.

Table Optimization

After a full reindex, run OPTIMIZE TABLE ps_search_word, ps_search_index in MySQL. The reindex process deletes and reinserts large numbers of rows, which can leave the tables fragmented. Optimization reclaims that space and improves query performance.

Elasticsearch as an Alternative

For stores that have outgrown PrestaShop's built-in search, Elasticsearch provides a significant upgrade in both search quality and performance. Elasticsearch is a dedicated search engine that runs as a separate service and offers features that the built-in MySQL-based search cannot match.

What Elasticsearch Adds

Fuzzy matching allows Elasticsearch to find results even when the search term is misspelled. A search for "leahter" will still find "leather" products. Stemming reduces words to their root form, so "running", "runs", and "ran" all match products containing any of these variations. Synonym support lets you define relationships between words ("sofa" and "couch") at the search engine level rather than through manual aliases.

Faceted search (filtering results by attributes like price range, color, brand) is dramatically faster with Elasticsearch because it is designed for exactly this type of aggregation query. Auto-complete suggestions and "did you mean" features are also native Elasticsearch capabilities.

Performance-wise, Elasticsearch handles large catalogs (100,000+ products) with sub-second response times because it uses inverted indexes optimized for full-text search, unlike MySQL which is primarily designed for relational data.

Integration with PrestaShop

Several PrestaShop modules provide Elasticsearch integration. These modules typically replace the default search controller with one that queries Elasticsearch instead of the MySQL search tables. Product data is synchronized from PrestaShop to Elasticsearch either in real-time (on product save) or via periodic batch synchronization.

Running Elasticsearch requires a dedicated server or container with adequate RAM (minimum 2GB for small catalogs, more for larger ones). It adds operational complexity since you now have another service to monitor and maintain. For many small to medium stores, the built-in search with proper weight configuration and regular reindexing is sufficient.

When to Consider Elasticsearch

Consider Elasticsearch when your catalog exceeds 10,000 products and search performance is degrading, when customers frequently misspell search terms and expect fuzzy matching, when you need advanced features like auto-complete or faceted filtering, or when search quality is a competitive differentiator for your business (B2B stores with complex product catalogs, for example).

The Reindexing Checklist

When search is not working correctly in your PrestaShop store, follow this diagnostic and resolution process. First, verify that the problem products are active, visible, and in stock (if your search excludes out-of-stock products). Second, check the search weight configuration and ensure it matches your priorities. Third, run a full search index rebuild from the back office or CLI. Fourth, clear the PrestaShop cache after reindexing. Fifth, test the search with specific terms to verify the fix. Sixth, if problems persist, check the ps_search_word and ps_search_index tables directly to verify that the problem products have entries. Seventh, if the index appears correct but search still fails, investigate the search controller logic and any modules that override it.

Regular reindexing, combined with thoughtful weight configuration and a well-maintained alias list, keeps PrestaShop's built-in search working reliably for the majority of stores. For those that need more, Elasticsearch provides an upgrade path without requiring a platform change.

For more details, read our guides: Smart Search for PrestaShop: When Default Search Is Not Good Enough and PrestaShop SEO: The Complete Guide to Ranking Higher.