Everything you'd want to know before you install.
A detailed look at how Smart 404 Page PrestaShop 8 & 9 — Product Suggestions & 301 Redirects works, why we built it the way we did, and the thinking behind the features above.
A default 404 page is a lost sale
On a standard PrestaShop store, the 404 page shows an apology, an empty search box, and nothing else. The visitor arrives with a clear intent, often from Google or an old link, and hits a wall. They leave. Every unhandled 404 is burnt acquisition budget, a negative signal sent to search engines, and a customer who will shop elsewhere. This module turns that dead end into a crossroads: instead of telling the visitor the page does not exist, it shows them the products they were probably looking for.
How suggestions are computed
When a 404 occurs, the module splits the last two segments of the URL, discards stopwords in five languages, keeps only tokens of at least three characters and excludes numeric identifiers. Remaining tokens are matched against the catalog with weighted scoring: a match in link_rewrite scores four points, in the product name three points, in the reference two points. Products are ranked by descending score. If no match reaches the threshold, the module falls back to best sellers, then newest products: the visitor always sees something relevant.
The search field does half the work
The search form displayed on the 404 page is not empty: it is pre-filled with the humanized keywords extracted from the broken URL. A visitor landing on a deleted premium-leather-sneakers URL already sees premium leather sneakers in the field. The form points to the native theme search page, with the query string properly forwarded: no template override, no conflict with a third-party search module.
The 404 log: see what actually breaks
Every 404 is recorded with its URL, a hit counter incremented via upsert, the last referer, the last user agent and its date. Deduplication uses a hash of the URL, scoped per shop: one thousand visits on the same broken URL give one row with one thousand hits, not one thousand rows. Known crawlers can be filtered out, and a list of regex patterns keeps out the noise from vulnerability scanners (wp-admin, xmlrpc, phpmyadmin, .git, static assets) that would pollute your analysis. Old entries are pruned automatically according to the retention you set.
From 404 to 301 in one click
This is the core of the module. From the log, a broken URL whose match score is high enough can be redirected instantly to the best product through an AJAX button: one click, the 301 redirect is created, the entry switches to redirected status. When confidence is insufficient, a guided form opens with suggestions ranked by score and a custom URL field. In both cases, source and target are checked: no loop, no duplicate.
A discreet, safe redirect engine
Redirects created from the log are applied before the page is dispatched, upstream of the front controller. The default type (301 permanent or 302 temporary) is configurable and can be overridden rule by rule. Paths are normalized before comparison, and a collision guard rejects any rule where source and target would point to the same place. Every redirect counts its hits: you see exactly how many visits were rescued.
Complementary, not redundant
If you already run an advanced redirect manager (wildcards, regex, CSV import), the module remains useful: its redirect engine can be disabled with a single checkbox, and you keep the suggestion block on the 404 page as well as the log. Conversely, if you have nothing, the module is enough to cover the full cycle: detect, understand, redirect.
Two-minute install, clean uninstall
No external dependency, no Composer, no theme modification. Upload the ZIP through the Module Manager and install: two SQL tables are created, two tabs appear in the back office, and the block injects itself into your theme 404 page. On uninstall, tables and tabs are removed: nothing is left behind in the database.
There are no reviews yet.