# 301 redirects after a PrestaShop redesign: the battle plan

> A visually successful redesign can lose half the organic traffic in three weeks. The four sources to cross-reference for the inventory, the mapping rules, the order of operations on switchover day and the fortnight of checks that follows.

- Page: <https://www.datafirefly.com/en/2026/09/10/301-redirects-after-prestashop-redesign/>
- Language: en
- Published: 2026-09-10
- Last updated: 2026-09-10
- Other languages: [fr](https://www.datafirefly.com/2026/09/10/redirections-301-refonte-prestashop/index.md), [es](https://www.datafirefly.com/es/2026/09/10/redirecciones-301-rediseno-prestashop/index.md), [de](https://www.datafirefly.com/de/2026/09/10/301-weiterleitungen-prestashop-relaunch/index.md), [it](https://www.datafirefly.com/it/2026/09/10/redirect-301-restyling-prestashop/index.md), [pl](https://www.datafirefly.com/pl/2026/09/10/przekierowania-301-przebudowa-prestashop/index.md), [nl](https://www.datafirefly.com/nl/2026/09/10/301-redirects-herbouw-prestashop/index.md), [pt](https://www.datafirefly.com/pt/2026/09/10/redirecionamentos-301-remodelacao-prestashop/index.md)
- Index: <https://www.datafirefly.com/en/2026/llms.txt>

A redesign that succeeds visually can lose half the organic traffic in three weeks. The cause is almost always the same: the addresses changed and nothing links the old ones to the new ones.

The redirect plan is not an end-of-project task. It is prepared before go-live and monitored for a month afterwards.

## Before: the exhaustive inventory

You cannot redirect what you do not know about. Four complementary sources, to be cross-referenced.

**A crawl of the current site**, which gives every page reachable through navigation. That is the base, and it is incomplete.

**The sitemap**, which sometimes contains pages not linked in the navigation.

**Search Console**, over twelve months, which reveals the pages receiving organic traffic, including those the crawl did not find. This is the most valuable source: it tells you what has value.

**The server logs** over three months, which show the addresses actually requested, including through old external links you had forgotten about.

The union of those four sources gives you your scope. On a mid-sized catalogue, expect several thousand URLs, a share of which deserve no treatment at all.

## Prioritise rather than treat everything

Redirecting ten thousand pages one by one is neither possible nor useful. Three levels of treatment.

**General rules.** If the URL structure changes systematically, one rule covers thousands of pages. That is the case when you drop a prefix, change the identifier format, or move from one structure to another.

**Individual redirects.** For pages that follow no rule: renamed CMS pages, merged categories, consolidated products. Focus them on pages with traffic or inbound links.

**410 treatment.** For what disappears with no equivalent. That code signals a deliberate removal and speeds up removal from the index, which a 404 does more slowly.

A useful marker: on most redesigns, 90% of organic traffic concentrates on less than 20% of the pages. Those are the ones that need individual verification.

## The mapping rules

Four principles, the first of which is the most often broken.

**A redirect points to the closest equivalent, never to the home page.** A mass redirect to the home page is treated as a soft error: the engine sees that the destination has nothing to do with the request, and the benefit is nil. For a discontinued product, redirect to a replacement product or, failing that, to its category.

**A redirect is permanent.** The 301 code passes the value of the old page. A temporary redirect does not, and it leaves both addresses coexisting in the index.

**A redirect is direct.** No chains: if address A was redirected to B last year and B becomes C today, update the A rule to point to C rather than stacking.

**The destination has to answer with a 200.** Redirecting to a page that is itself in error is a frequent case when the mapping is built before the new site is finished. Check afterwards, not before.

## Switchover day

Order of operations, each one conditioning the next.

1. **The redirects are in place before opening**, tested on the staging environment with the real addresses.
2. **The sitemap is regenerated** with the new addresses only, and submitted.
3. **Internal links point to the new addresses**, not to the old ones that redirect. A site where every internal link goes through a redirect slows its own crawling and dilutes value.
4. **The robots file is checked**, particularly if the staging environment was blocking indexing. A forgotten blocking directive in production is the most expensive accident of a redesign.
5. **The canonical tags** point to the new addresses.

## The following fortnight

This is the period where everything is decided, and where most projects let their attention slip.

**The 404 errors in Search Console**, to be checked every two days. Every new 404 signals an address missed in the mapping.

**The server logs**, filtered on 404 and 500 codes. They surface faster than Search Console and include the crawlers' requests.

**Organic traffic**, compared with the same period last year rather than with last month. A drop of 10 to 20% for two to four weeks is normal, the time engines need to process the redirects. A drop of 50% signals a problem.

**The positions on your twenty main queries**, recorded before the redesign and tracked after.

## How long to keep the redirects

A frequent question. Engines pass the value fairly quickly, but external links and visitors' bookmarks never update themselves.

The prudent rule: keep the redirects indefinitely as long as they raise no performance issue. A file of a few thousand well indexed rules costs nothing. What costs is the chains accumulated over several successive redesigns, which have to be flattened periodically.

## The classic mistakes

Redirecting every old page to the home page, mentioned above, and by far the most destructive. Forgetting the versions with and without a trailing slash, which are two distinct addresses. Ignoring images, whose addresses also change and which can receive traffic. And leaving the URL parameters of the old filters untreated, which produces a significant volume of errors.

The  handles this chain on PrestaShop 8 and 9: bulk import of the mapping, pattern rules alongside individual redirects, detection of chains and loops, and tracking of the 404s encountered so the plan can be completed day by day.