301 redirects and 404s after a migration: what to check

What a shop loses when addresses change

Search engines, external links, bookmarks and campaigns point to precise addresses. If, after a migration or a URL change, those addresses answer 404, Google does not index them: according to its documentation, URLs that return a 4xx code are not indexed and those already indexed are removed from the index. A permanent redirect instead says that the page exists and has been moved: Google uses it as a signal that the destination is the canonical URL and states that 301s and other permanent redirects do not cause a loss of PageRank. How much traffic is actually lost depends on the site, which is why it is measured with Search Console rather than trusting generic figures.

The HTTP codes that matter

The same RFC specifies that 410 is preferable to 404 when the server knows that the condition is probably permanent.

What PrestaShop 9.1 does by itself

What follows was verified in the PrestaShop 9.1.5 code, with the files cited in the sources.

Redirect to the canonical URL

In Shop Parameters, Traffic & SEO, Set up URLs, the “Redirect to the canonical URL” option (PS_CANONICAL_REDIRECT) is 0 (no redirect), 1 (302) or 2 (301). In the FrontController, for GET requests, if the requested URL does not match the canonical one PrestaShop answers with a 301 when the option is 2, with a 302 otherwise, and does nothing with 0. The official documentation recommends 301 once the changes are finished and warns that without redirects you can end up with duplicate URLs. In development mode, a debug page appears instead of the redirect: keep this in mind when testing.

The slug of a product or a category changes

The default rules put the id in the URL ({id}{-:id_product_attribute}-{rewrite}.html for products, {id}-{rewrite} for categories). The old URL, with the previous slug, therefore still finds the object, and the controller compares it with the current one: with the option on 301 it redirects, with 0 both addresses answer and the duplicates remain.

The URL scheme changes

The Dispatcher starts from the pagenotfound controller and replaces it only if the URI matches one of the current routes, the default ones or the custom ones (PS_ROUTE_*). The code does not keep the previous schemes: old addresses that no longer match any route end up on a page that answers with a real 404 status. Redirects from the old schemes must be created separately.

Product disabled or no longer available

The “Redirection when offline” field of the product page (redirect_type) has ten values: default, 404 and 410 (error page), 200-displayed, 404-displayed and 410-displayed (product shown as out of catalogue with that code), 301-category and 302-category (redirect to a category), 301-product and 302-product (redirect to another product). With default the “Default behavior for disabled products” setting (PS_PRODUCT_REDIRECTION_DEFAULT) applies. A deleted product no longer exists and the page answers 404.

Category disabled or deleted

A disabled category follows the “Redirection when not displayed” field: 301 by default, to the nearest active parent category if you do not choose another one, or 302, 410, 404. A deleted category answers 404, and Category::deleteRedirections() resets to the default behaviour the products and categories that redirected to it.

Migration from another platform

When you change platform almost all URLs change shape: products, categories, pages, images and files. PrestaShop cannot guess the old addresses; they must be collected and mapped.

1. Collect the old URLs. Google suggests starting from the sitemaps, the server logs or analytics for the most visited URLs, the “Links” report of Search Console and the CMS list. The “Performance” report has the “Pages” dimension and an export button. Include images, videos, JavaScript and CSS.
2. Map every URL. Google writes that it is important to map the URLs of the old site to those of the new one and to decide where each should point: the most relevant page, one to one.
3. Handle what has no equivalent. Google asks that deleted content answer 404 or 410. Avoid sending many old URLs to a single irrelevant destination, such as the home page: according to Google it can confuse users and can be treated as a soft 404. If several pages have merged into one, that is a legitimate destination.
4. Avoid common mistakes: redirect chains (Googlebot follows up to 10, but Google recommends pointing to the final destination and, if that is not possible, ideally staying within 3 hops and in any case below 5); loops; 302 instead of 301; internal links, canonicals, hreflang and sitemaps left on the old URLs; redirects to URLs that do not exist; noindex or robots.txt blocks from the development phase left active; redirects removed too early.

What to check in Search Console

• “Page indexing” report: “Not found (404)”, “Soft 404”, “Page with redirect” and “Redirect error” (chain too long, loop, URL too long or not valid). The report itself says that a 404 is not necessarily a problem if the page was removed without a replacement, and to use a 301 if it was moved.
• “URL Inspection”: the live URL test follows redirects but does not say that it has followed one and does not show the final URL. To see codes and chain you need a command-line tool or a script.
• Sitemaps: submit the one with the new URLs. The one with the old URLs may show redirect warnings, which is normal.
• “Change of Address”: only needed when moving from one domain or subdomain to another, not for HTTP to HTTPS, www or non-www, or for paths within the same domain.
• Timing: for a small or medium-sized site Google indicates a few weeks for most pages, with temporary fluctuations in visibility.

Checklist

1. List of the old URLs with visits and links, from sitemaps, logs and Search Console.
2. One-to-one mapping; 404 or 410 for what has no equivalent.
3. Server-side 301 for moved content, 302 only if temporary.
4. No chains: every old URL points to the final destination, verified with a script on the whole list.
5. Internal links, canonicals, hreflang and sitemaps on the new URLs.
6. “Redirect to the canonical URL” set to 301 when the shop is online.
7. Monitoring of 404s and “Page indexing” in the weeks after the migration; redirects kept for as long as possible, generally at least one year.

How the SEO Redirects - 301/302/404 manager module does it

• 301, 302 and 410 rules with simple path, wildcard (* and ?) or validated regex, and query string options (ignore it, compare the full URL or require a parameter). The 410 answers with a real 410 status and X-Robots-Tag: noindex, before the theme is loaded.
• The redirect fires in the actionDispatcher hook, before the page is built: simple rules are found with an indexed lookup on the path hash, wildcards and regexes are evaluated in order.
• The 404 monitor records missing URLs with number of requests, last access, referer and user agent (up to 5,000 distinct URLs, adjustable); “Create 301” pre-fills the rule.
• Creates a 301 when the slug of a product, a category or a CMS page changes, for every language, if no rule already covers that URL.
• Imports and exports CSV (columns source, target, type, is_regex, keep_querystring, qs_mode, qs_param, qs_value, active), with the count of imported and skipped rows: handy for loading the mapping of a migration.
• Rejects external destinations that are not on the shop or in a list of authorised hosts (open redirect protection).

See the module page or read the installation and setup guide.

Sources

• RFC 9110, HTTP Semantics: sections 15.4.2, 15.4.3, 15.4.9, 15.5.5 and 15.5.11
• Google Search Central: Redirects and Google Search, site move with URL changes, HTTP status codes
• Search Console Help: Page indexing, URL Inspection, Change of Address, Performance
• PrestaShop 9.1.5 code on GitHub: FrontController, ProductController, CategoryController, Dispatcher
• PrestaShop documentation: SEO and URLs, managing products

Frequently asked questions

301 or 302 for a migration?

301 (or 308) for content moved permanently: Google uses it as a strong signal, while a 302 is a weak signal. Its documentation recommends permanent redirects when you are sure they will not be reversed.

Is it a good idea to redirect all old URLs to the home page?

No. Google advises against sending many old URLs to a single irrelevant destination: it can confuse users and can be treated as a soft 404. It is better to use the most relevant page, or a 404 or 410 if there is no equivalent.

How long should redirects be kept?

Google says to keep them for as long as possible, generally at least one year, so that signals pass to the new URLs and external links are reassigned.

Does PrestaShop redirect the old URL by itself when the slug changes?

Yes, if the id is in the URL and “Redirect to the canonical URL” is set to 301 (with 302 the redirect is temporary, with 0 there is no redirect). It does not happen if the URL scheme changes: old addresses that no longer match any route return 404.

404 or 410 for deleted pages?

The standard prefers 410 when the removal is probably permanent. For Google the two codes are treated in the same way, like all 4xx codes except 429.

Is the module enough on its own?

No. The module manages rules, 404 monitoring, CSV and automatic 301s, but the mapping must be prepared by you. It does not check chains and loops between rules and does not fix internal links, canonicals, hreflang and sitemaps: these remain to be verified with a script and with Search Console.