Zeyvro SEO Redirect 301 for PrestaShop: documentation

Version 1.8.6 · Updated on 2026-10-12 · Tested on PrestaShop 8.0.5, 8.1.7, 8.2.6, 9.0.0, 9.1.3 and 9.2.0 · PHP 8.1 or later

Documentation for Zeyvro SEO Redirect 301: every redirect in your shop managed from the back office, both the ones you create and the ones the module detects on its own when a product or category URL changes. Without touching the .htaccess, without redirect chains and without leaving a 404 behind every catalogue change.

What the module does

It manages every redirect in your shop from the back office, without touching the .htaccess and without losing them when PrestaShop regenerates that file.

1. Manual redirects. Permanent 301, temporary 302 and 303, with listing, filters and editing.
2. Slug autodetection. If a product’s or a category’s link_rewrite changes, the 301 is created on its own.
3. Chains resolved. With A→B and B→C, when C becomes D the module updates A→D. No chained hops.
4. Slug suggestions. When you rename a product or a category it proposes the new URL and applies it with the 301 in one click, one at a time or several at once. If you switch it on in Settings, it is applied on its own when you save.
5. Product removals. Lists withdrawn products whose URL is still live and redirects them, one by one or in bulk, to a destination you search by name without having to know its ID.
6. History and CSV. A record of the automatic changes, plus bulk import and export.
7. Trailing slash. Strict by default: /page and /page/ are different rules. In Either mode, a single rule serves both forms.

Installation

1. Back office → Modules → Module Manager → Upload a module.
2. Pick zeyvroseoredirect-1.8.6.zip and wait for it to finish.
3. Go to the Zeyvro → SEO Redirects menu, which the module adds when it installs.

There is no key to enter. The module ships without DRM: it works as soon as it is installed, it does not ask for an activation key and it does not contact any validation server.

Redirects screen

Zeyvro → SEO Redirects menu. One row per rule, with filters and sorting on every column.

Column	What it holds
ID	Internal identifier of the rule.
Old URL (path)	Source path. Always starts with /. E.g.: /old-shaving-soap.html
New URL	Full destination, with http:// or https://.
Type	301 permanent · 302 temporary · 303.
Source	manual if you created it, auto if the module generated it on a slug change.
Date	Creation date.

Create a redirect

1. Click New redirect.
2. Old URL: the old path, starting with /.
3. New URL: the full destination URL, with protocol.
4. Pick the type (301 by default) and save. Confirmation: Redirect saved successfully.

The Back button at the top of the add and edit form takes you back to the list without saving.

Deleting

Tick several rows and use Delete selected, or delete one from its own row. Delete all removes every redirect of the active shop: it asks you to tick a confirmation box and it cannot be undone, so export the CSV first.

CSV import and export

Import

Import CSV button: pick the file and the separator, ; (recommended) or ,. When it finishes it reports how many went in and how many were skipped as duplicated or malformed. The Back button closes the import box without importing anything.

Format, one redirect per line:

old_url;new_url;type
/old-page.html;https://yourshop.com/new-page.html;301

The recommendation is to write the full destination, with protocol, exactly as in the form. The import also accepts a destination starting with /; the back office form does not, and always requires http:// or https://.

Export

Export CSV button: downloads every redirect of the active shop. The number next to the button is the total row count.

Slug suggestions

Suggestions tab, with the number of pending ones in brackets. They show up when you change the name of a product or a category but its URL still carries the old text, one per language. The Type column tells you whether it is a Product or a Category.

• Apply: changes the slug of the product or category and creates the 301 from the old URL to the new one, in a single step.
• Dismiss: discards the suggestion and leaves the product or category as it is.
• In bulk: tick the rows (the header checkbox ticks them all) and click Apply to selected or Dismiss selected. The message tells you how many were applied or dismissed and how many failed, with the reason for each failure.
• Back takes you to the redirect list.

If you would rather skip this list, suggestions can be applied on their own when you save: see Settings.

Product removals

Product removals tab: products that are disabled or that deny orders whose URL is still live and without a redirect. It keeps you from leaving a 404 behind when you withdraw a reference.

• Filters by status (all · disabled · denies orders) and by manufacturer.
• Per row: you pick the destination type —category, manufacturer or product—, search for it in the box and click Create. The row arrives with the product’s default category and its manufacturer already filled in when it has them and, if there is one, with a link to pick its parent category in one click.
• In bulk: tick several rows, pick destination (with the same box) and type (301 or 302) and click Apply to selected.
• The destination box autocompletes as you type: a product is searched by name, reference, EAN13 or ID and shown as “#ID · reference · name”; a category or a manufacturer, by name or ID. At most 20 results are shown, and only active destinations. With the keyboard: arrows to move, Enter to pick and Esc to close. If you type a number (or “#123”) without picking from the list, it is taken as the ID.
• A product leaves the list as soon as a redirect exists for its current URL.
• Back takes you to the redirect list.

Settings

Settings tab, with two sections: Trailing slash and Slug suggestions (automatic apply of slug suggestions). Changes are saved with Save; Back takes you to the redirect list.

Trailing slash

Option	Behaviour	When to use it
Strict (default)	The request only matches the rule saved with the exact URL: /page and /page/ are different rules.	A shop with consistent URLs; maximum control.
Either	A single rule serves the URL both with and without the trailing slash.	Migrations from another platform with both forms linked.

Apply slug suggestions automatically

Two switches, one for products and one for categories: Apply slug suggestions automatically — products and — categories. Both are set to No by default, both on install and when upgrading from an earlier version.

Option	Behaviour
No (default)	The change waits in Suggestions until you apply or dismiss it.
Yes	When a product or a category is saved with a new name and a URL that still carries the old text, the module sets the suggested URL and creates the 301 from the old one, in every language, without going through the list.

• If you changed the slug by hand in that same save, the module does not replace it: the 301 for your change is created as usual and, if your slug does not match the suggested one, the suggestion stays in the list.
• If the 301 cannot be saved, the slug is left as it was and the change stays in the suggestions list.

How it works under the hood

Hook	Role
actionDispatcher	Serves the redirect on every front-office request.
moduleRoutes	The module’s own routes.
displayBackOfficeHeader	Back office styles and scripts.
actionObjectProductUpdateBefore / …After	Captures the product slug before saving, compares it afterwards and creates the 301.
actionObjectCategoryUpdateBefore / …After	The same for categories.

The data lives in three tables of the module’s own: redirects, change history and detected suggestions.

How the URL is matched

• Matching is exact: _ and % in the URL do not act as wildcards.
• URLs with parameters: if /old-page.html?utm_source=x has no rule of its own, it follows the rule of /old-page.html and the destination keeps the query string (…/new-page.html?utm_source=x, with & if the destination already had one). The full URL, query string included, is looked up first, so a rule that includes it always wins.
• Shops in a subfolder (e.g. https://domain.com/shop/): automatic redirects are saved and matched relative to the shop base.
• Automatic apply writes the slug straight to the database, so it does not fire the save hooks again.

Updating and support

• To update, upload the new ZIP from Modules → Upload a module: PrestaShop runs the upgrade and keeps your redirects.
• Do not uninstall the module to update it: upload the new ZIP on top. Uninstalling does not delete your redirects —the tables are kept on purpose— but the module stops serving them until you install it again. The only thing you lose is the settings: when you reinstall, Trailing slash goes back to Strict and the automatic apply of suggestions to No.
• Since 1.7.1 the module invalidates its own files in OPcache when it upgrades, and warns you if the hosting does not allow it.
• Technical support for 6 months from purchase: hola@zeyvro.com.

Download the PDF manual

Troubleshooting

PrestaShop 9.1 says the update failed after uploading the ZIP

The warning is false: the upgrade was applied, both in the database and in the code. It happened because the module’s auto-upgrade ran the upgrade/ scripts inside the same request in which PrestaShop 9.1 runs them again, and the core flagged them as duplicates. Fixed in 1.7.2. When uploading 1.7.2 itself from an older version the warning may still appear, because during that upload the server is still running the code of the version you had; from 1.7.2 on it no longer shows up.

UndefinedMethodError: trailingSlashMode in the Settings view

This happens on servers with OPcache revalidation disabled (opcache.validate_timestamps=0): the cache kept serving the previous version’s main class while the controller was already the new one. Since 1.7.1 the module invalidates only its own files in OPcache when it upgrades —it never flushes the whole shop’s cache— so it should not happen again.

The back office warns that the server is caching the previous code

If the hosting does not allow invalidating the cache (disabled function, restrict_api…), the upgrade still completes and the module shows the notice “Your server is still caching the previous version of the code. If you see errors, ask your hosting provider to restart PHP”. It goes away by itself as soon as the server serves the new code.

The URL is rejected when I save a redirect

These are two separate rules, each with its own message. Old URL must start with /: the source is always a relative path starting with /, not a full URL. New URL must start with http:// or https://: the destination is always an absolute URL with protocol. If the type you send is not 301, 302 or 303, it is saved as 301.

Rows are skipped when I import the CSV

The skipped counter adds up lines with fewer than two columns, lines whose source is empty or does not start with /, and lines whose destination is empty or starts with neither http nor /. Each line is read up to 2000 bytes: a longer line arrives truncated and is skipped too. Check the separator you picked if the whole file gets skipped.

The back office reports a database error

Since 1.8.0, every write checks whether the database saved it: saving a rule, deleting, applying or dismissing suggestions, importing the CSV and saving the settings. If it was not saved, the back office shows an error (“Database error: the change was not saved.”, or “The redirect could not be saved: database error.” in the form) instead of a confirmation. On import, rows the database does not save are counted separately: “%d row(s) could not be imported: database error.”.

PrestaShop 9.1.3 / 9.2.0: the category or brand page is cut off

This is a bug in PrestaShop itself, not in the module. It also happens without the module installed, only in Spanish-language shops using the PrestaShop 9 default theme (Hummingbird); it does not happen in English or with the Classic theme. The module’s redirects keep working. It comes from an official Spanish translation with one extra “%”. One-minute fix: back office → International → Translations → Modify translations: Front office Translations · theme hummingbird · Español. In the Shop › Theme › Catalog domain, find “Subcategories for %s” (currently translated as “Subcategorías de %s%”), set it to exactly “Subcategorías de %s”, save and clear the cache in Advanced Parameters → Performance. If you update the language pack, check the fix is still there.

Version history

• 1.8.6 · 2026-10-12 — Compatible with and tested up to PrestaShop 9.2.0. On update, the module clears its own code cache (OPcache) so the server does not keep running the previous version. No new features or database changes. Includes 1.8.1 to 1.8.5, which were never released.
• 1.8.0 · 2026-09-25 — Slug suggestions for categories too, with optional automatic apply (Settings, default No); bulk actions in Suggestions; Back button in Suggestions, Product removals, Settings, the redirect form and the CSV import; Product removals destination with autocomplete. Includes 1.7.4 and 1.7.5, which were never released: shops in a subfolder, exact URL matching, URLs with parameters, database errors shown in the back office and removal of the licence engine, which was switched off.
• 1.7.3 · 2026-09-21 — Declared compatibility becomes PrestaShop 8.0.0 – 9.1.3, the versions it has been tested on. No functional or database changes.
• 1.7.2 · 2026-09-12 — Fixes the false “cannot be updated” warning on PrestaShop 9.1 when uploading the ZIP from the back office.
• 1.7.1 · 2026-09-11 — On upgrade, the module invalidates only its own files in OPcache; if the server does not allow it, it warns in the back office.
• 1.7.0 · 2026-09-11 — New Settings view with the Trailing slash option (Strict by default, or Either).
• 1.6.2 · 2026-09-10 — Compatibility fix reported by the official PrestaShop validator.
• 1.6.1 · 2026-09-10 — Compatibility fixes reported by the official PrestaShop validator.
• 1.6.0 · 2026-09-06 — New Product removals section: disabled products or products denying orders, with a destination per row or in bulk.

Frequently asked questions