301 redirects and 404 errors for PrestaShop: setup guide

Add a redirect

From the Redirects tab, click Add a redirect to open the rule form.

• Source path or pattern: the incoming path, e.g. /old-page. With Pattern matching on you can use * and ? wildcards or a delimited regex.
• Target: an internal path (starting with /) or a URL on your shop or a whitelisted host. External, non-whitelisted targets are rejected (open-redirect protection).
• Redirect type: 301 Permanent or 302 Temporary.
• Shop scope multistore, on a multistore installation the form shows a Shop scope selector: restrict the redirect to one shop, or apply it to All shops.
• Pattern matching and Append the original query string to the target: optional per-rule switches.

Add a redirect: source, target, type and per-shop scope

Settings master switch

The Settings tab groups the engine switch, matching behaviour, the open-redirect security and data handling.

• Enable the redirect engine: master switch. When off, no redirects are served and nothing is logged.
• Log 404 errors: record URLs that end on the 404 page so you can turn them into redirects.
• Auto-create 301 on slug change: when a product, category or CMS page slug changes, automatically create a 301 from the old URL to the new one.
• Ignore the query string when matching: match the path regardless of ?a=b parameters (you can still append the original query string per rule).
• Case-insensitive matching and Normalize trailing slashes: treat /Page, /page and /page/ as the same source.
• Allowed external hosts: comma-separated hostnames a redirect may point to besides your own shop domains. Leave empty to allow internal redirects only, this is the open-redirect protection; any other external target is rejected.
• 404 log size cap: the maximum number of distinct 404 URLs kept.
• Drop data on uninstall: when enabled, uninstalling deletes all rules and the 404 log. Keep it off to preserve redirects across a reinstall.

Settings: engine, matching, open-redirect security and data

The choice in short

• The content moved and still exists: a 301, to the single most relevant replacement, not to the homepage as a catch-all.
• The content is temporarily unavailable but will come back at the same address: a 302, not a 301, so the search engine keeps the original indexed and checks back later.
• The content is gone with no direct replacement: a 404, or a 410 if you know for certain it will never come back (search engines tend to drop those URLs from the index faster).
• The content never existed at that address: a plain 404, nothing further needed.

The soft 404 to avoid

A soft 404 is a page whose text tells a visitor “product not found” while the server still answers 200 OK. Search engines notice the mismatch and treat the URL as an error anyway, except it wastes a normal indexing slot instead of being handled as the error it is. PrestaShop core answers 404 correctly when a product does not exist: a soft 404 usually appears when a theme or module intercepts the page and shows a “not found” message with a 200 code. If a page's text says something is missing, its status code should say so too.

Crawl budget is real traffic, with our own store's numbers

Search engines, and increasingly AI crawlers, allocate a rough daily request budget to each domain: every request spent on a redirect chain or a stale 404 is a request not spent on a page that matters. This is not abstract. On our own store, before a routine cleanup, the visit-tracking filter turned out to be using a bot signature list from 2010: it logged 43,478 "visits" a day from bots, against roughly 300 real people, and the tracking data had grown to 1.4 GB before cleanup brought it down to 24 MB. Separately, a single crawler (Meta's) was making 38,000 requests a day, around 80% of all traffic the server received, until a targeted rule was added.

410: when it is the right call, and when it backfires

A 410 always has to be declared on purpose: it communicates "there will never be anything here again", not just "there is nothing here now". Using it without that certainty is the costliest mistake among the four codes. Two typical cases: a product out of stock but coming back (a 410 here discourages the engine from rechecking the URL right when you want it to: a 404, or a 302 to a heads-up page, is the right tool), and a rule that is too broad on a wildcard pattern or a query-string condition, which can permanently shut the door on legitimate traffic that only shares part of the pattern.

What a properly built 410 looks like

In the module, picking the 410 type makes the target field unnecessary, it is ignored. The response fires as early as possible in the request lifecycle, before the application builds the theme or fetches the product from the database, and includes three elements often forgotten when a 410 is hand-rolled: a real 410 Gone HTTP status (not a 200 with "unavailable" text), an X-Robots-Tag: noindex header, and a minimal page body translated into the visitor's language.

A real case: a crawler looping on a poisoned parameter

On our own store, a crawler (Meta's) was looping on /login?back=... URLs that still carried the store's old domain inside the parameter value: over 36,000 requests in a single night, more than 90% of all traffic, each served with a 200 response and a full page render, the same CPU cost as a genuine request. A single 410 rule with a query-string condition solved it without touching legitimate traffic: the rule only fires when the back parameter contains the old domain, not on every request to /login. Verified on three different PrestaShop versions: /login?back=http://old-domain.example/x and /login?back=https://old-domain.example/login return 410, while /login?back=/my-account (legitimate traffic) still returns 200, unchanged.

Redirect chains: the quiet tax

A single 301 costs almost nothing. A chain of three or four hops forces every crawler and every visitor to make as many requests to reach one page, and search engines follow only a limited number of hops before giving up. Every time a URL changes again, redirect the original straight to the current final destination instead of adding another hop on top of the last one: flattening chains as soon as you find them is one of the most useful cleanups on a redirect map built up over time.