Migrate PrestaShop 1.6 or 1.7 to 9 without losing SEO: the 301 checklist

The new shop is live on PrestaShop 9, orders are coming in, and a week later Search Console starts listing hundreds of "Not found (404)" pages: the old product addresses Google still had in its results. To migrate PrestaShop without losing SEO, every address that ranks or gets visits has to do one of two things on switchover day: stay exactly the same, or redirect with a 301 to its new page.

This is the checklist we follow in our migrations from 1.6 and 1.7 to 9: what changes in your URLs, what to list beforehand, how to build the redirect map, and what to check on the day and in the weeks after.

The migration starts with the server: PrestaShop 9 needs PHP 8.1 or later, and which PHP version PrestaShop needs has the table for every version and how long each PHP gets security patches.

What changes in your URLs between 1.6, 1.7 and 9?

Less than people fear, but it's not nothing. These are PrestaShop's default address formats, taken from the code of each version:

• Products. In 1.6 the address carries the category and, if the product has one, the EAN barcode: /shoes/12-blue-trainer.html. 1.7 and 8 keep that format and add the combination number when there is one. PrestaShop 9 drops the category and the EAN by default: /12-blue-trainer.html.
• Brands and suppliers. In 1.6 they look like /3_brand-name and /2__supplier-name; since 1.7.5, /brand/3-brand-name and /supplier/2-supplier-name.
• Categories and content pages keep the same format in every version: /3-shoes and /content/4-about-us.
• Filtered categories. In 1.6 the filter module could put the filters into the path (/3-shoes/colour-blue). Since 1.7 they go after a question mark, in the q parameter.
• Languages. Up to version 8, a shop with several languages puts the language code in every address, the default language included (/en/). PrestaShop 9 adds a switch to remove it from the default language: it has to match what your old shop did.

Two details decide almost everything. The first: the number in the address is the product or category ID, so the migration has to keep the same IDs. A tool that renumbers your catalogue changes every single URL. The second: if you upgrade with PrestaShop's own 1-Click Upgrade module, its upgrade scripts save the old product, brand and supplier formats as custom routes so they keep working. If the new version is installed from scratch and your data is moved over, the new formats apply unless you set them yourself.

That's the cheapest redirect of all: in Shop Parameters → Traffic & SEO → SEO & URLs, the "Route to products" field and its neighbours let you keep your old format. An address that doesn't change needs no redirect.

Before migrating: which URLs do I need to list?

All the ones that bring something, not only the ones in your sitemap. Gather them in a spreadsheet with three columns: old address, new address and status.

1. The old shop's sitemap. Save a copy before switching: it's the full list of what you told Google exists.
2. Search Console → Performance → Pages. The pages that get clicks and impressions, from the last 16 months. Those are the ones you can't afford to lose.
3. Search Console → Links. Your most-linked pages. A link from another site to an address that returns a 404 stops adding to your shop.
4. Server logs or Analytics. Landing pages people reach from emails, ads or bookmarks, which Google doesn't see.
5. Images. If Google Images brings you visits, include the image addresses too (more on this below).

How do I build the 301 map?

Go row by row through the spreadsheet and give each address one destination:

• Same format, same ID: nothing to do. That's why keeping the routes is worth it.
• Format that changes (brands, suppliers, old filters, products if you don't keep the route): a redirect to the new address of that same page.
• Products or categories you're not taking across: to the product that replaces them or to their category. Never all to the home page: Google says mass redirects to an unrelated page can be treated as a soft 404, and the customer doesn't find what they were looking for either.
• One hop, not two. If an old address already redirected to another one, point it straight at the final page.

If you have questions about when to use 301, 302 or 410, or where to send each page, we covered that in 404 errors in PrestaShop and how to fix them with 301s.

What else has to survive the move?

The address is the main thing, but not the only one. Check these on the test copy, before switching:

• Meta titles and descriptions. They're stored per product, category and page, in each language, and they travel with your data. Open a few and compare. Meta keywords disappear in PrestaShop 9: nothing lost, Google hasn't used them for years.
• Canonical and hreflang. Current themes add both tags in each page's header. Check that they point to your real domain, not to the address of the test copy.
• Images. A product image address looks like /123-large_default/blue-trainer.jpg, and the middle part is an image size defined by the theme. The 1.6 theme had sizes, such as thickbox_default, that current themes don't have. If those images get visits, create the old sizes in Design → Image Settings and regenerate the thumbnails: the old addresses will work again.
• robots.txt and maintenance mode. The test copy is usually blocked from search engines. On switchover day, regenerate robots.txt, turn off maintenance mode and check that no page carries noindex.

On switchover day: how do I check it worked?

1. Test 20 or 30 addresses from your list, the ones with the most clicks first. Each one should answer with a single 301 and land on a page that loads. If one redirects twice or ends in a 404, fix it before moving on.
2. Crawl the new shop with a crawler such as Screaming Frog (its free version crawls up to 500 addresses) looking for 404s and internal links that still point to old addresses.
3. Submit the new sitemap in Search Console and remove the old one, as Google recommends.
4. Inspect your ten most important pages with the URL Inspection tool to confirm Google can access them.
5. Check every language: the redirect that works in English may be missing in French.

What should I watch in the weeks after?

The first few weeks set the tone. Google itself says it can take a few weeks or more for a medium-sized site to settle after a change of addresses, and that some ups and downs are normal. What isn't normal is a 404 that keeps getting visits.

• Every week, "Not found (404)" in Search Console's Pages report, and your shop's own 404 log, which also catches visits from emails and other sites.
• Clicks in Performance, comparing the 28 days after with the same period before. If a page loses visits, check its redirect first.
• Keep the redirects for at least a year, which is what Google recommends, and update the links you control: newsletters, social profiles and marketplaces.

How do we set up the redirects in our migrations?

With our 301 redirects module for PrestaShop, which works from 1.7.5 to 9 and whose free edition has no limit on rules. You install it on the new shop from day one: it records every 404 the shop receives, with bots counted apart, and from each one you create the redirect to a product, category, page, brand or any address. The rule points to the page itself, so it keeps working even if you change that page's URL later.

For a migration with hundreds of addresses, the PRO edition saves you the typing: it imports your whole map from a CSV with a preview of every row before saving, catches whole groups of old addresses with a single rule ("starts with", wildcard or regular expression) and suggests the best destination for each 404. And if you're still weighing whether to make the move, we explained what upgrading PrestaShop 1.6 or 1.7 to 9 involves and what it costs.