Setting Up 301 Redirects in PrestaShop After a Migration

Understanding Redirects and Why 301 Is the Only Correct Choice

When you migrate a PrestaShop store, URLs change. Products that lived at one address now live at another. Categories that had one slug now have a different one. Without redirects, every old URL becomes a dead end, returning a 404 error to both visitors and search engines. The cumulative effect is devastating: lost traffic, lost rankings, and lost sales.

A redirect is an instruction from your server that tells browsers and search engine crawlers that a page has moved. When a visitor or Googlebot requests the old URL, the server responds with the new location, and the client automatically follows it. But not all redirects are equal, and using the wrong type can undermine your entire migration.

301 vs 302: A Critical Distinction

A 301 redirect signals a permanent move. It tells search engines to transfer the accumulated link equity (the SEO value built through backlinks, content quality, and user engagement) from the old URL to the new one. Over time, Google replaces the old URL in its index with the new one. This is what you want after a migration.

A 302 redirect signals a temporary move. It tells search engines that the old URL will return eventually, so they should keep the old URL in the index and not transfer link equity. Using 302 redirects after a permanent migration means Google keeps trying to index your old URLs, your new URLs struggle to gain authority, and you lose rankings unnecessarily.

There is also the 307 redirect, which is the HTTP/1.1 equivalent of 302, and the 308 redirect, which is the HTTP/1.1 equivalent of 301. For PrestaShop SEO purposes, 301 is the standard and universally supported choice.

The rule is simple: if the page has permanently moved, use 301. After a migration, the page has permanently moved. Always use 301.

Setting Up Redirects in .htaccess (Apache)

Most PrestaShop installations run on Apache, and the .htaccess file is where you configure redirects. This file sits in your PrestaShop root directory alongside index.php.

Placement Matters

PrestaShop's .htaccess file contains rewrite rules that handle friendly URLs, force HTTPS, and route requests to the correct controllers. Your redirect rules must be placed before the PrestaShop rewrite rules. If you place them after, the PrestaShop rules may intercept the request first and your redirects will never execute.

Look for the comment line that says # Dispatcher or the block starting with RewriteRule ^api. Your custom redirects go above this section but after RewriteEngine On.

Individual Page Redirects

The simplest form of redirect maps one specific old URL to one specific new URL:

Redirect 301 /old-category/old-product.html https://www.example.com/new-category/new-product

The Redirect directive is part of Apache's mod_alias module. The first argument is the HTTP status code (301), the second is the old path (relative to the document root), and the third is the full new URL.

Important details: the old path must start with a forward slash and must not include the domain name. The new URL must be a full URL including the protocol and domain. The old path is matched exactly, including trailing slashes and file extensions.

Pattern-Based Redirects with RewriteRule

When many URLs follow a predictable pattern change, individual redirects become impractical. Apache's mod_rewrite lets you write pattern-based rules using regular expressions:

RewriteEngine On
RewriteRule ^old-category/(.*)$ /new-category/$1 [R=301,L]

This rule captures everything after old-category/ and appends it to new-category/. The $1 is a backreference to the first captured group (the part in parentheses). The [R=301,L] flags specify a 301 redirect and that this is the last rule to process if matched.

Common pattern-based redirect scenarios for PrestaShop migrations:

Removing .html extensions:

RewriteRule ^(.+)\.html$ /$1 [R=301,L]

Changing from ID-based category URLs to name-based:

RewriteRule ^3-old-category-name(.*)$ /new-category-name$1 [R=301,L]

Redirecting an entire subdirectory:

RewriteRule ^shop/(.*)$ /$1 [R=301,L]

Conditional Redirects

Sometimes you need redirects that only apply under certain conditions. RewriteCond provides this capability:

RewriteCond %{HTTP_HOST} ^olddomain\.com$ [NC]
RewriteRule ^(.*)$ https://www.newdomain.com/$1 [R=301,L]

This redirects all requests from olddomain.com to newdomain.com, preserving the path. The [NC] flag makes the condition case-insensitive.

To redirect only if the requested file does not exist on the new server (useful during a gradual migration):

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^old-path/(.*)$ /new-path/$1 [R=301,L]

Setting Up Redirects in Nginx

If your PrestaShop runs on Nginx, redirects are configured in the server block configuration file, typically located at /etc/nginx/sites-available/yourdomain.conf or /etc/nginx/conf.d/yourdomain.conf.

Individual Redirects

location = /old-category/old-product.html {
  return 301 https://www.example.com/new-category/new-product;
}

The = modifier specifies an exact match. Without it, Nginx treats the location as a prefix match, which could redirect more URLs than intended.

Pattern-Based Redirects

location ~ ^/old-category/(.*)$ {
  return 301 /new-category/$1;
}

The ~ modifier enables regex matching. The captured group $1 works the same way as in Apache.

Map-Based Redirects for Large Lists

Nginx's map directive is ideal for managing hundreds or thousands of individual redirects without cluttering the server block:

map $request_uri $redirect_target {
  /old-product-1.html /new-product-1;
  /old-product-2.html /new-product-2;
  /old-product-3.html /new-product-3;
}

server {
  if ($redirect_target) {
    return 301 $redirect_target;
  }
}

The map block is evaluated only once per request and is highly efficient even with thousands of entries. You can even load the map from an external file using the include directive.

Remember to test your configuration with nginx -t and reload with systemctl reload nginx after any changes.

Bulk Redirects with CSV

For migrations involving thousands of products, manually writing redirect rules is not feasible. A CSV-based approach streamlines the process.

Creating the CSV

Export your old URLs from your pre-migration crawl data or database. Export your new URLs from the new installation. Match them in a spreadsheet with two columns: old URL path and new URL path. Save as CSV.

Your CSV might look like this:

/3-old-category,/new-category
/old-category/old-product-1.html,/new-category/new-product-1
/old-category/old-product-2.html,/new-category/new-product-2
/content/5-about-us,/content/about-us

Converting CSV to .htaccess Rules

A simple approach is to convert each CSV line into a Redirect directive. Using a text editor with find-and-replace or a simple command-line tool:

awk -F',' '{print "Redirect 301 " $1 " https://www.example.com" $2}' redirects.csv >> .htaccess

This reads the CSV file, splits each line by comma, and generates a Redirect directive for each line.

Using a Database Table

For very large redirect lists (10,000+ entries), consider storing redirects in a database table and handling them at the application level. Create a table with columns for old path and new path, and write a small PrestaShop module or override that intercepts 404 errors, checks the table, and returns a 301 redirect if a match is found. This approach is easier to manage through an admin interface but adds a small database query to each 404 response.

Module-Based Redirect Solutions

Several PrestaShop modules provide redirect management through the back office, eliminating the need to edit server configuration files directly.

Benefits of Module-Based Redirects

A redirect module offers a user-friendly interface for adding, editing, and deleting redirects. It typically includes import/export functionality for bulk operations, logging to track which redirects are being used, and the ability for non-technical team members to manage redirects without server access.

How Module-Based Redirects Work

Most redirect modules work by hooking into PrestaShop's request handling process. When a request comes in that would normally result in a 404 error, the module intercepts it, checks its redirect database for a matching old URL, and if found, sends a 301 redirect response to the new URL.

Some modules go further by automatically creating redirects when you change a product's friendly URL in the back office. This prevents the common problem of breaking old links when you optimize your URL slugs.

Performance Considerations

Module-based redirects add a small overhead to every 404 request because they must query the database. For most stores this is negligible, but if you have thousands of redirects and significant bot traffic hitting old URLs, the database queries can add up. Consider using a caching layer or moving the most-used redirects to .htaccess for optimal performance.

Regex Redirects: Power and Danger

Regular expression redirects are powerful tools that can handle complex URL transformations with a single rule. They are also the most common source of redirect errors and infinite loops.

When to Use Regex Redirects

Use regex redirects when the URL change follows a consistent, predictable pattern. Good candidates include: removing or adding file extensions across all URLs, changing a URL prefix for an entire section of the site, removing or adding language prefixes, and stripping query parameters.

Common Regex Patterns for PrestaShop

Removing the category ID prefix that PrestaShop 1.6 adds to category URLs:

RewriteRule ^([0-9]+)-(.+)$ /$2 [R=301,L]

This matches URLs like /3-shoes and redirects to /shoes.

Adding a language prefix:

RewriteCond %{REQUEST_URI} !^/(en|de|fr)/
RewriteRule ^(.+)$ /en/$1 [R=301,L]

Removing duplicate slashes:

RewriteRule ^(.*)//(.*)$ /$1/$2 [R=301,L]

Testing Regex Rules Safely

Before deploying regex redirects to production, test them thoroughly. Use an online regex tester (like regex101.com) to verify your pattern matches the URLs you intend and does not match URLs it should not.

Start with a 302 redirect during testing. This prevents search engines from caching incorrect redirects. Once you have verified the rule works correctly, change it to 301.

Test edge cases: URLs with query parameters, URLs with special characters, URLs with multiple matching patterns. Each of these can reveal problems that are not obvious with simple test URLs.

Testing Redirects

Deploying redirects without thorough testing is a recipe for disaster. Here are the methods you should use to verify your redirects before and after going live.

Command-Line Testing with curl

The curl command is the most reliable way to test redirects because it shows you exactly what the server returns:

curl -I https://www.example.com/old-product.html

The -I flag requests only the headers. In the response, look for:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-product

Verify that the status code is 301 (not 302) and that the Location header points to the correct new URL.

To follow the redirect chain and see every hop:

curl -IL https://www.example.com/old-product.html

The -L flag tells curl to follow redirects, showing you the headers at each step.

Bulk Testing

For large redirect lists, automate testing with a loop:

while IFS=, read -r old new; do
  status=$(curl -s -o /dev/null -w "%{http_code}" "https://www.example.com$old")
  echo "$old -> $status"
done < redirects.csv

This reads your CSV file, tests each old URL, and prints the HTTP status code. Any URL that does not return 301 needs attention.

Browser Testing

Open your browser's developer tools (F12), go to the Network tab, and navigate to an old URL. The Network tab shows the request chain, including all redirects. Verify the status code, the redirect target, and the final page that loads.

Google Search Console Inspection

After deployment, use the URL Inspection tool in Google Search Console to check how Google sees your redirected URLs. Enter an old URL and see if Google recognizes the redirect and has discovered the new URL.

Redirect Chains and How to Avoid Them

A redirect chain occurs when one redirect leads to another redirect, which may lead to yet another. For example: URL A redirects to URL B, which redirects to URL C, which finally serves the content. Each hop adds latency and dilutes link equity.

Why Redirect Chains Are Harmful

Google has stated that it will follow redirect chains, but with limits. After a certain number of hops (typically 5-10), Googlebot gives up and treats the URL as an error. Even for shorter chains, each hop delays page delivery and loses a small amount of link equity.

For visitors, each redirect adds 50-200 milliseconds of latency, depending on network conditions and server response time. A chain of 3 redirects can add half a second or more to the perceived load time.

Common Causes of Redirect Chains in PrestaShop

The most common chain occurs when a migration adds redirects on top of existing redirects. For example, you might have old redirects from a previous URL structure change, and the new migration adds another layer. URL A redirects to URL B (from the first migration), and URL B redirects to URL C (from the second migration).

Another common cause is the interaction between PrestaShop's built-in canonical redirect and your custom redirects. PrestaShop may redirect from a non-canonical URL to the canonical version, and if your custom redirect also matches, you get a chain.

HTTPS enforcement adds another potential hop. If your redirect points to an HTTP URL, and the server then redirects to HTTPS, that is a two-step chain.

Fixing Redirect Chains

Audit your redirects regularly using a crawling tool that detects chains. When you find a chain, update the first redirect to point directly to the final destination. URL A should redirect directly to URL C, bypassing URL B entirely.

When adding new redirects during a migration, always check if the target URL is itself a redirect. If it is, set the new redirect to point to the final destination instead.

Common Pitfalls and How to Avoid Them

Infinite Redirect Loops

An infinite loop occurs when URL A redirects to URL B, and URL B redirects back to URL A. The browser detects this and displays an ERR_TOO_MANY_REDIRECTS error. Common causes include conflicting rules in .htaccess (one rule redirects www to non-www while another redirects non-www to www), conflicting redirects between .htaccess and a redirect module, and regex rules that are too broad and match their own target URLs.

To fix a loop, start by disabling all custom redirects and re-enabling them one at a time until the loop reappears. This identifies the conflicting rule.

Forgetting Query Parameters

By default, Apache's Redirect directive passes query parameters through to the new URL. However, RewriteRule does not pass query parameters unless you add the [QSA] (Query String Append) flag. If your old URLs include important query parameters (like ?id_product=123), make sure they are handled correctly.

Case Sensitivity

On Linux servers, URLs are case-sensitive. /Product.html and /product.html are different URLs. If your old site had mixed-case URLs and your new site normalizes to lowercase, you need redirects that handle both cases. Use the [NC] flag in RewriteRule for case-insensitive matching.

Not Redirecting All URL Variations

A single product page might be accessible via multiple URLs: with and without trailing slash, with and without .html extension, with and without the category path prefix, with and without www. Each variation that was indexed needs its own redirect to the new canonical URL.

Leaving Redirects in Place Forever

While redirects should remain in place for at least 12 months after a migration (Google recommends at least one year), they should not remain indefinitely. After a year or more, the old URLs should no longer appear in search results or receive significant traffic. Audit your redirect logs, remove rules that are no longer being triggered, and keep your configuration clean.

Summary

Setting up 301 redirects correctly is the single most important technical task in a PrestaShop migration. Every old URL that had traffic, backlinks, or search engine visibility must redirect to its new counterpart with a 301 status code. The implementation method depends on your server (Apache .htaccess or Nginx configuration), the number of URLs (individual rules, regex patterns, or database-backed modules), and your team's technical capabilities. Test every redirect before going live using curl or browser developer tools. Watch for redirect chains, infinite loops, and case sensitivity issues. Monitor Google Search Console after deployment to verify that Google is processing your redirects correctly. And remember that a 302 where a 301 should be is never harmless. It is always the wrong choice for a permanent migration.

For more details, read our guides: What Are Friendly URLs and Why Every PrestaShop Store Needs Them and PrestaShop .htaccess: Security and Performance Rules You Need.