PrestaShop 301/302 Redirects After Migration: Safe URL Mapping
Changing a PrestaShop URL is easy. Preserving the value of the old URL is the part that needs planning.
A platform upgrade, category restructure, product rename, domain move or catalog cleanup can leave search engines, customers, bookmarks and external links pointing at paths that no longer exist. If those requests simply become 404 responses, users lose the expected destination and search engines must rediscover the new structure without a clear mapping.
The safest migration workflow is to create an explicit map from each important old path to the most relevant new destination, choose the redirect type deliberately, test the response before and after launch, and keep watching for missed URLs.
1. Build the redirect map before changing URLs
Do not start with the redirect rule. Start with the inventory.
Export or record the important current URLs before the migration. Include:
- product URLs;
- category URLs;
- CMS pages;
- high-traffic blog or landing pages;
- campaign URLs that still receive external traffic;
- URLs with valuable backlinks;
- paths that are changing because of a new naming or routing convention.
Then assign a destination to every URL that will disappear.
The destination should normally be the closest equivalent page. A discontinued product might map to a direct replacement or a tightly related category. Sending every missing product to the homepage creates a technically valid redirect but a poor user journey and often loses the original intent.
2. Use 301 when the move is intended to be permanent
A 301 redirect communicates that the old location has permanently moved to the new target. That is normally the right choice when a migration, rename or permanent catalog restructure replaces the old URL.
A 302 redirect communicates a temporary move. Use it when the original URL is expected to become the primary location again or when the routing change is intentionally temporary.
Do not choose 302 simply because you are nervous about the migration. The status code should describe the intended relationship between the old and new locations.
3. Normalize the source path consistently
A redirect manager needs a predictable way to identify the incoming request. In URL Redirect Migration Helper Lite, Lite rules use exact source paths.
For example, a source can represent the old storefront path:
/old-category/blue-notebookThe important part is consistency. Do not create several differently formatted versions of the same source unless they represent genuinely different requests.
Decide separately how query strings should behave. A request such as:
/old-page?utm_source=newslettermay need the incoming query string preserved on the new destination, while tracking or obsolete application parameters may be better dropped. Treat that as an explicit migration decision rather than an accidental side effect.
4. Prefer exact mappings for high-value URLs
Exact rules are easy to review because one known source has one known target. They are particularly useful for:
- top landing pages;
- products with external backlinks;
- renamed categories;
- old CMS pages;
- URLs that previously ranked or converted.
Broad wildcard rules can be useful in larger migrations, but they are also easier to over-apply. URL Redirect Migration Helper Lite intentionally focuses on exact 301/302 rules; wildcard rules are a Pro capability.
Even when a broad pattern exists, keep the most important exceptions explicit so they are easy to audit.
5. Preview CSV imports before writing rules
Large migrations are usually easier to prepare in a spreadsheet than by adding hundreds of rules manually. The risky part is importing a bad mapping at scale.
A safe CSV workflow has two phases:
- parse and validate the file;
- show what would be inserted or changed before committing anything.
Review at least:
- invalid rows;
- duplicate source paths;
- empty targets;
- conflicts with existing rules;
- the intended 301/302 type;
- whether an existing rule should be skipped or updated.
URL Redirect Migration Helper Lite includes a preview-before-import workflow plus conflict handling, and it can export the current shop's redirect rules back to CSV for backup or review.
6. Avoid redirect chains
A migration can accidentally create chains such as:
/old-a → /old-b → /new-cThe cleaner result is usually:
/old-a → /new-c
/old-b → /new-cEvery extra hop adds another request and another opportunity for a configuration mistake.
Before launch, resolve old targets to their final intended destination where practical. Pro tooling can automate chain and loop analysis, but Lite users can still prevent most problems by reviewing the map before import and testing the final response.
7. Never create a redirect loop
A loop can be direct:
/a → /b
/b → /aor indirect through several rules. Browsers eventually stop following the sequence, but the user never reaches useful content.
When changing an existing mapping, test both the old source and the new target. The final target should return content, not another route that eventually points back to the source.
8. Test the HTTP response, not only the browser screen
A browser can make a broken setup look successful because it automatically follows redirects. During migration QA, inspect the actual response.
For each important rule verify:
- the old URL returns the intended 301 or 302;
- the
Locationpoints to the expected destination; - the destination returns the expected final response;
- there is no unnecessary chain;
- query-string behavior matches the plan;
- the redirect is active in the correct shop.
Use a private browser session or an HTTP inspection tool so cached redirects do not hide changes while you test.
9. Update internal links as well as redirects
A redirect is a compatibility layer for old references. It should not become the normal way your own store navigates.
After the migration, update:
- menus;
- category descriptions;
- product descriptions;
- CMS links;
- blog internal links;
- XML sitemap output;
- email templates and recurring campaigns where relevant.
Internal links should point directly to the final URL so customers and crawlers do not take an avoidable redirect hop on every visit.
For a broader SEO checklist, see our PrestaShop 9 SEO guide.
10. Treat 404s after launch as migration feedback
No migration inventory is perfect. Old links can exist in search indexes, forgotten emails, partner sites, browser bookmarks and external content you do not control.
After launch, review 404 traffic and ask:
- Is the missing path a real legacy URL?
- Does it still receive meaningful traffic?
- Is there a clear equivalent destination?
- Should a redirect be added, or is a genuine 404 the correct result?
Do not redirect every 404 automatically. Typo URLs, bot-generated paths and requests for content that never existed often should remain 404 responses.
11. Use hit data to remove guesswork
Redirect hit counts and last-hit timestamps help distinguish rules that still receive real requests from rules that were prepared but never used.
URL Redirect Migration Helper Lite records hit counts and last-hit information for rules. That makes the redirect table more useful as an operational migration record instead of a static list that nobody revisits.
12. Keep redirects shop-scoped in multistore
In a multistore environment, the same path can have different meaning depending on the active shop or domain. Keep the migration map associated with the shop that owns the URL structure and test each storefront separately.
A successful redirect in one shop does not prove that another shop has the same rule or target.
Safe PrestaShop migration redirect checklist
- Export the important old URLs before the migration.
- Map each disappearing URL to the closest useful destination.
- Use 301 for permanent moves and 302 for genuinely temporary moves.
- Decide how query strings should be handled.
- Preview bulk/CSV imports before writing rules.
- Resolve unnecessary chains to the final destination.
- Test status code and Location header.
- Update internal links to the final URLs.
- Monitor 404s after launch.
- Review redirect hits and add missed high-value mappings.
Use URL Redirect Migration Helper Lite for exact migration rules
URL Redirect Migration Helper Lite is the free PrestaSuite workflow for exact PrestaShop 8/9 redirects. It provides exact 301/302 rules, enable/disable controls, query-string handling, hit counts, CSV preview/import/export and runtime diagnostics.
Lite is intentionally focused on exact redirects. The Pro edition adds wildcard rules, scheduling, bulk actions, dry-run testing, chain/loop tooling and 404 tracking for larger migrations.
Frequently asked questions
Should every removed product redirect to its category?
No. Use the closest relevant destination. A direct replacement may be better than the parent category, while a product with no meaningful replacement may legitimately remain unavailable.
Should I redirect every 404 to the homepage?
No. That hides the difference between a moved page and a URL that never had a valid replacement. Redirect only when you can identify a useful destination.
Can I use 302 during a permanent migration and change it later?
You can, but if the move is already known to be permanent, a 301 better describes the intended relationship from the start.
Should query parameters always be preserved?
No. Preserve them when they remain meaningful on the new destination. Old application parameters that no longer apply can create confusing or duplicate requests.