PS PrestaShop Beginner

DF Smart 404 — Documentation

Install, configure and operate the smart 404 page: product suggestions, pre-filled search, 404 log and one-click 301 redirects.

Updated Module version 1.0.0

Overview

DF Smart 404 turns your store’s “page not found” screen into a conversion crossroads. When a visitor lands on a broken URL, the module analyses that URL, extracts its keywords, and displays the catalog products that match best, alongside a search form that is already pre-filled.

In parallel, every 404 is recorded in a back-office log. You see exactly which URLs break, how many visitors hit them, and where they come from. From that log, a 301 redirect to the right product is one click away.

What the module does

  • Injects a product suggestion block into your theme’s 404 page, with no template override.
  • Pre-fills the search form with humanized keywords extracted from the broken URL.
  • Logs every 404 with deduplication, hit counter, referer and user agent.
  • Creates 301 or 302 redirects in one click, with loop protection.
  • Applies those redirects before the page is dispatched.

Requirements

  • PrestaShop 8.0 to 9.x
  • PHP 7.4 or above
  • No external dependency, no Composer

Installation

  1. Go to Modules > Module Manager.
  2. Click Upload a module and drop the df404smart-1.0.0.zip file.
  3. Click Install.

On install, the module creates two SQL tables (404 log and redirects), registers three hooks and adds a DF Smart 404 menu in the back office with two sub-tabs.

The block is live on the 404 page immediately, with working default settings. You can test it by visiting a non-existent URL on your shop.

Configuration

Open the module’s Configure page. It shows four tracking KPIs first, then the settings form.

Dashboard

  • Broken URLs to fix — number of entries with the “new” status in the log.
  • 404 hits on those URLs — total visits on URLs not yet handled.
  • Active redirects — number of redirect rules currently in service.
  • Visits rescued by redirects — total hits intercepted by your redirects.

Available settings

  • Enrich the 404 page — enables or disables the suggestion block injection.
  • Show the search form — displays the pre-filled search field inside the block.
  • Enable the redirect engine — applies the redirects created from the log. Uncheck this if you already run a third-party redirect module.
  • Number of suggestions — between 0 and 12 products displayed. A value of 0 disables suggestions while keeping the search form.
  • Default redirect type — 301 permanent (recommended for SEO) or 302 temporary.
  • Log bot traffic — when disabled, hits from known crawlers are not written to the log.
  • Log retention (days) — older entries are pruned automatically. Redirect rules are never pruned.
  • Exclusion patterns — one case-insensitive regular expression per line. Matching URLs are never logged.

Default exclusion patterns

The module ships with a list of patterns that filter out the noise generated by vulnerability scanners and automated requests: attempts on wp-admin, wp-login, xmlrpc, phpmyadmin, .git folders, as well as static assets (images, stylesheets, scripts). Add your own patterns, one per line. An invalid pattern is reported on save, along with the line number involved.

The front-office suggestion block

How products are selected

When a 404 occurs, the module splits the last two segments of the URL into keywords. Stopwords are discarded in five languages (French, English, Spanish, German, Italian), only tokens of at least three characters are kept, and purely numeric identifiers are excluded.

Each remaining token is then matched against the catalog with weighted scoring:

  • match in the product link_rewrite: 4 points
  • match in the product name: 3 points
  • match in the reference: 2 points

Products are ranked by descending score, and only those scoring above zero are kept.

The fallback

If no product comes out of the analysis — a common case on very short or obscure URLs — the module automatically falls back to best sellers. If those are unavailable too (new catalog, statistics not computed), it displays the newest products. The visitor therefore always sees products, never an empty block.

The search form

The search field is pre-filled with the humanized version of the URL keywords. A visitor landing on /premium-leather-sneakers-edition already sees “premium leather sneakers edition” in the field.

The form points to your theme’s native search page, with the query string parameters correctly forwarded as hidden fields. No conflict with a third-party instant search module: this module overrides nothing, it uses PrestaShop’s standard entry point.

Where the block appears

The module detects the content section of your theme’s 404 page and inserts the block there, right below the native message. If the theme structure is unusual, several successive fallbacks guarantee the block stays above the footer. No theme file is modified.

The 404 log

Menu DF Smart 404 > 404 log.

Columns

  • Broken URL — the requested path, normalized.
  • Hits — number of visits on this URL. The list is sorted by descending hits by default: the most expensive URLs appear first.
  • Last referer — where the last visitor came from (Google, a third-party site, an internal page).
  • Status — New, Redirected or Ignored.
  • Last hit — date of the most recent visit.

Deduplication

Deduplication is based on a hash of the URL, scoped per shop. One thousand visits on the same broken URL produce a single row with one thousand hits, never one thousand rows. Writing is done in a single upsert query.

Row actions

  • Auto redirect (lightning icon) — instantly creates a redirect to the most relevant product, over AJAX, without leaving the page. This action is only offered when the match score exceeds the confidence threshold; otherwise, a message invites you to use the guided form.
  • Create redirect — opens the guided form (see below).
  • Ignore — switches the entry to “ignored” status. It disappears from the KPIs but remains browsable.
  • Delete — removes the entry from the log.

A bulk delete action and a CSV export are also available from the toolbar.

Creating a redirect

Auto redirect

The lightning button computes the best product matching the broken URL. If the score exceeds the internal confidence threshold, the redirect is created immediately with the configured default type, and the log entry switches to “redirected” status. A confirmation message names the target product.

The confidence threshold prevents risky redirects. A URL such as /summer-sale-2024 will probably have no reliable match: the module will refuse the auto redirect and send you to the guided form.

The guided form

It shows the broken URL, its hit count, then the list of suggested products ranked by score. Each suggestion is a radio button, the first one preselected. A custom URL field lets you enter any target: a category, a CMS page, an external URL.

You then pick the redirect type (301 or 302) and submit. The module checks that the target is not empty, that it does not point to the source URL itself (loop protection), and that no redirect already exists for that source.

Managing redirects

Menu DF Smart 404 > 404 redirects.

This screen offers a full CRUD on your redirect rules:

  • Source URL — the broken path (e.g. /old-category/old-product).
  • Target URL — path or full URL to redirect to.
  • Type — 301 (permanent) or 302 (temporary).
  • Hits — number of visits intercepted by this rule. This is your direct measure of rescued visits.
  • Active — toggle to disable a rule without deleting it.

The same validations as in the guided form apply: non-empty source, no loop, no duplicate source (the current ID is excluded from the check when editing).

How the engine works

Redirects are evaluated before the page is dispatched, upstream of the front controller. The requested path is normalized, then an indexed lookup on its hash searches for an active rule on the current shop. If a rule matches, the hit counter is incremented and the redirect is issued with the configured HTTP code.

Performance

  • The log only writes on an actual 404, in a single upsert query.
  • The redirect engine performs an indexed hash lookup: negligible cost, even with hundreds of rules.
  • Pruning of old entries is triggered randomly on roughly 1% of hits, so it never blocks a visitor request.
  • Hits from bots can be excluded from writing, which further reduces load on heavily crawled shops.

Multistore

All module data is scoped by shop ID: the log, the redirects and the suggestions. Each shop has its own log, its own rules and its own configuration. A broken URL on shop A does not appear in the log of shop B.

GDPR

The log records the broken URL, the referer and the user agent. No IP address is stored, no personal data is collected. Retention is configurable and pruning is automatic. The module sends no data to any external service.

Uninstall

Uninstalling drops the two module tables (404 log and redirects), the back-office tabs and the configuration. The redirects you created will be lost. A confirmation is requested before the operation.

If you plan to reinstall the module or migrate, export your redirects to CSV first from the management screen.

Troubleshooting

The block does not appear on the 404 page

  • Check that the Enrich the 404 page setting is enabled.
  • Clear the PrestaShop cache (Advanced Parameters > Performance > Clear cache).
  • Make sure your theme uses the standard pagenotfound controller.

This case is handled since version 1.0.0: the module targets the content section rather than the closing tag of the main container. If you still see this behaviour, clear the Smarty cache and report your theme structure to support.

No product is suggested

  • Check that Number of suggestions is not set to 0.
  • On a brand-new catalog with no sales history, the best sellers fallback is empty: the module then switches to newest products. Make sure you have at least one active, visible product.

Auto redirect refuses to create

This is the expected behaviour when the match score is too low. Use the guided form, which displays suggestions even below the threshold and lets you enter a custom target.

A redirect does not apply

  • Check that the Enable the redirect engine setting is ticked.
  • Check that the rule is active in the management screen.
  • Check that the rule belongs to the right shop in a multistore context.
  • If another redirect module is installed, it may intercept the request upstream.

Support

12 months of updates and 12 months of email support are included with your licence. The full PHP source code is provided, unobfuscated.

Was this page helpful?

Still stuck? Contact support