PrestaShop 1.6 to 8: migrating without losing your SEO

The main risk is not the one you expect

On a PrestaShop 1.6 migration, the instinctive worry is the data: are we going to lose orders, customers, products? In practice, that data comes across reasonably well. What does get lost, and does not come back on its own, is organic traffic.

URL structure changes between 1.6 and the modern versions. Without a redirect plan, every indexed URL becomes a 404. Google deindexes, hard-won rankings vanish, and it then takes months to climb back. That is why a migration that succeeds technically can still be a commercial failure.

The upgrade path is not optional

First rule: there is no direct jump from 1.6 to 8. The migration scripts run incrementally, and skipping steps leaves the database in an inconsistent state.

The path is: 1.6.1.x to 1.7.8.x to 8.x (then 9.x where appropriate).

Each step has to be checked before you move to the next: the back office loads, an order goes through, products display. A database migrated too fast produces errors that only surface weeks later, on peripheral features.

The six classic losses

1. The theme. A 1.6 theme does not work on 1.7 and beyond. The template engine moved to a new version, and the product file structure was rebuilt from scratch. There is no automatic conversion: the theme is rebuilt, or replaced.

2. Every override. The override/ directory has to start again from nothing. Overridden classes have changed signature, and a 1.6 override left in place causes a fatal error. It is also an opportunity: half of those overrides answer requirements everyone abandoned long ago.

3. The 1.6 modules. Hooks were renamed (hookHeader became hookDisplayHeader, for instance) and module architecture has moved on. Each module has to be replaced with its modern version, or rewritten.

4. Product reviews. The productcomments module changes schema. Customer reviews are not carried over automatically: they have to be migrated by script, table by table. That content has real SEO value, so do not leave it behind.

5. Product images. Regenerating thumbnails from Design > Image Settings exceeds the permitted execution time once you go past a few thousand images. The result: products with no visual on the front office. You need to go through the command line, or work in batches.

6. CMS blocks and static content. CMS pages, reassurance blocks, home page content: depending on the modules used in 1.6, this content lives in tables that no longer exist. Export it beforehand and re-enter it afterwards.

The SEO plan, step by step

This is the part that deserves the most attention.

Before the migration

1. Export every indexed URL. Cross-reference three sources: a full crawl of the site, the Search Console page export over 16 months, and your current sitemap. Search Console is essential: it surfaces URLs the crawl no longer finds but which still bring in traffic.
2. Record your rankings. A snapshot of ranking keywords before the switch is your only objective point of comparison afterwards.
3. Build the mapping table. Every old URL has to point to its new equivalent. Deleted products go to their category, never to the home page: a bulk redirect to the home page is treated as a soft error by Google.

During the migration

4. Implement the 301 redirects at server level rather than through a module for large volumes. A PHP redirect across 40,000 URLs weighs on performance.
5. Check the canonical tags and the robots.txt file. A staging site set to noindex and pushed live with the directive still in place is a classic disaster, and an entirely avoidable one.

After the migration

6. Submit the new sitemap and watch the coverage report daily for a month.
7. Track the real 404s in the server logs, not only in Search Console, which reports with a delay. Every recurring 404 on a URL that used to receive traffic is a redirect you forgot.

How long to allow

A 1.6 to 8 migration with a theme rebuild and module rework is measured in weeks, not days. The heaviest item is almost always the theme, followed by porting the bespoke development.

The best investment remains the upfront audit: an inventory of modules, overrides, overridden templates and indexed URLs. It turns a rough quote into a workload plan, and often reveals that the job is lighter than advertised.

If you are already on version 8 and unsure what comes next, read our article on the end of support for PrestaShop 8.

Have your store migrated

We take on the full migration, redirect plan included, and monitor organic traffic after the switch. See our PrestaShop migration page.