No Search Results — Rescue Page & Alerts — Documentation

Overview

The No Search Results module (dfzerosearch) intercepts your store’s searches that return no result and replaces them with a rescue page: a “did you mean…” spelling correction, near-match products, best sellers of the guessed category, global best sellers and a “notify me” form.

In the back office, a lost-queries dashboard aggregates every zero-result search and lets you map it, in one click, to a product, a category or a URL — as a suggestion shown on the page or as an automatic redirect.

Installation

1. In your back office, open Modules > Module Manager and click Upload a module.
2. Select the dfzerosearch.zip archive and confirm.
3. On install, the module creates its three SQL tables, its admin tab (and its three sub-tabs) and its default configuration.
4. The module is active immediately. No external dependency is required (no Composer, no framework).

Configuration (back office)

Open the module configuration page (Modules > Module Manager > dfzerosearch > Configure). The available settings are:

• Enable the module — enables or suspends detection and the rescue page display.
• Spelling correction — enables the “did you mean…” block.
• Category block — enables the best sellers of the guessed category.
• Best-sellers block — enables the global best sellers, shown only as a last resort.
• “Notify me” form — enables email capture on the rescue page.
• Products per block — number of products shown in each block (8 by default, 1 to 24).
• Minimum query length — below this number of characters, the search is not logged (2 by default).
• Retention (days) — how long lost queries are kept, with a manual purge button (180 days by default).

Values are stored in the configuration variables DFZS_ENABLED, DFZS_FUZZY, DFZS_CATEGORY_BLOCK, DFZS_BESTSELLERS_BLOCK, DFZS_NOTIFY_FORM, DFZS_NB_PRODUCTS, DFZS_MIN_LENGTH and DFZS_RETENTION_DAYS. A quick-links panel points to the three admin screens.

The rescue page (visitor side)

On the results page, a script detects that the product grid is empty, then loads the rescue page via AJAX through the rescue front controller. The blocks appear in this order:

1. Suggested target — if an active “suggestion”-mode mapping exists for the query, its target (product, category or URL) is highlighted.
2. “Did you mean…” — the corrected query and its products, with a link to the real corrected search page.
3. Best sellers of the guessed category — from the query words.
4. Global best sellers — only if none of the previous blocks produced a result.
5. “Notify me” form — to capture the visitor’s email for that query.

Spelling correction & category guessing

The spelling correction rewrites the query word by word against PrestaShop’s native search index (the ps_search_word table), using a Levenshtein distance scaled to word length. Only words actually present in the index are suggested; the real PrestaShop search is then re-run with the corrected query.

The category guessing matches the query words against the store’s active category names (substring match, then Levenshtein). The best-scored category provides its best sellers.

Lost-queries dashboard & mapping

The DF Zero Search tab brings together three screens:

• Lost queries — every zero-result search, aggregated, counted and sorted by volume, with four key indicators (total lost searches, distinct queries, active mappings, pending alerts). A “Map” action pre-fills the mapping form.
• Mappings — the list of query → target associations. A target can be a product, a category or a URL, in suggestion mode (shown on the rescue page) or redirect mode (the visitor is redirected automatically).
• “Notify me” subscriptions — the list of captured emails, with their status (pending / notified).

“Notify me” form & alerts

On the rescue page, an opt-in form unchecked by default, protected by an anti-bot honeypot, lets the visitor drop their email for the current query. From the back office, when you create an active mapping for that query, the “Notify” action sends the dfzerosearch_alert email to every waiting subscriber, each in their own language, then marks them as notified.

GDPR compliance

• Explicit opt-in: email capture relies on a checkbox unchecked by default, with clear consent wording.
• Honeypot: a hidden field filters automated submissions without bothering the visitor.
• Controlled retention: lost queries are purged automatically beyond the configured number of days, with a manual purge available at any time.
• Self-hosting: no data is sent to any third party.

Compatibility & technical conventions

• PrestaShop 8.0 to 9.x, multistore, 5 languages.
• Hooks used: actionSearch and actionFrontControllerSetMedia.
• SQL tables: dfzerosearch_query, dfzerosearch_mapping, dfzerosearch_alert.
• Admin tab AdminDfZeroSearch and its three sub-tabs, under the Improve menu.
• Front controller rescue secured by token, JSON responses.
• No dependency: manual PSR-4 autoloader, vanilla JS without jQuery, no external service.

Troubleshooting

• The rescue page doesn’t appear — check that the module is enabled, that the search really returns zero results, and clear the PrestaShop cache.
• No correction is offered — the correction only suggests words present in the native index; re-index the PrestaShop search if your catalogue has changed a lot.
• No query shows in the dashboard — make sure the query length exceeds the configured minimum threshold and that the module is enabled.
• Alert emails are not sent — check PrestaShop’s email configuration and that the “Notify” action was actually run on an active mapping with waiting subscribers.