Migrating from PrestaShop to Shopify without losing search rankings

A PrestaShop-to-Shopify migration gets pitched, correctly, as an upgrade: less server maintenance,
a checkout that does not need a security patch every quarter, a theme ecosystem that does not
require a developer for every small change. What the pitch usually skips is that the two platforms
structure URLs, categories and product data differently enough that a lift-and-shift migration,
done without mapping the difference deliberately, drops search rankings for weeks or permanently.

The URL structure does not translate on its own

PrestaShop, out of the box or with a common SEO module enabled, tends to produce URLs like
/17-category-name/42-product-name.html, with numeric identifiers baked in and an .html
extension. Shopify generates /collections/category-handle and /products/product-handle, no
extension, no numeric prefix. There is no automatic way to preserve the old pattern; the platform
dictates the shape.

That means every single indexed PrestaShop URL needs an explicit redirect to its Shopify
equivalent, not a pattern-based rewrite rule. A generic rule stripping .html and renumbering
would work for some URLs and silently mismatch others, particularly where French accented
characters in a product name got encoded differently by each platform's slug generator.

Categories and collections are not the same structure

PrestaShop categories can nest arbitrarily deep, and a product can live in exactly one category by
default. Shopify collections are flatter, and a product can belong to several collections
simultaneously through tags or manual assignment, with no native parent-child nesting shown in the
URL. A PrestaShop store with Home > Kitchen > Cookware > Cast Iron as a category path has no
direct Shopify equivalent; the migration has to decide whether that becomes one collection, a
collection with a tag filter, or gets flattened into Cookware with Cast Iron demoted to a
product tag. This decision changes which URL should receive the redirect, so it has to happen
before the redirect map gets built, not after.

Exporting the map, and importing it Shopify's way

Old PrestaShop URL,New Shopify URL
/17-cookware/42-cast-iron-pan.html,/products/cast-iron-pan
/12-kitchen.html,/collections/kitchen

Shopify's admin accepts bulk redirects as a CSV import under URL Redirects, which is the
mechanism to use rather than reproducing an Apache or nginx rewrite layer that Shopify does not
give direct access to. The two-column format above is the whole contract; the discipline is making
sure every row maps to a URL that actually resolves, not to a category that got merged or a product
that got discontinued along the way, in which case that row should point to the closest surviving
collection instead of guessing at a homepage fallback.

Structured data written by a different hand

PrestaShop's product schema, whether from the core or a module, and Shopify's theme-generated
Product schema rarely produce identical output. Price formatting, currency codes, and whether
availability reflects real-time stock or a static value at theme install time can all differ. A
rich result that showed price and stock before the migration can vanish for a week simply because
the new theme's schema block uses a different field name or omits priceCurrency entirely,
something worth checking directly on a handful of product pages before calling the migration done,
rather than assuming the theme handled it correctly by default.

Language and multistore setups need their own mapping

PrestaShop's multistore and multilingual features often produce URL patterns with a language or
store prefix that Shopify's own multi-market or multi-language setup structures differently.
Treating this as a detail to sort out after launch is how a bilingual store loses its French
rankings while someone is still debugging why the English ones redirect correctly.

A store selling into both France and Morocco through separate PrestaShop language trees needs each
tree mapped to its own Shopify market or language variant before launch, with its own redirect rows.
Merging them into a single default market to save setup time is how one language ends up redirecting
correctly while the other quietly loses its indexed pages for weeks, because nobody checked the
smaller of the two traffic sources until the monthly report flagged the drop.

What actually gets checked after cutover

Watching organic traffic in the days after launch answers little on its own, because traffic always
dips during a platform change. What matters is the index coverage report: are old URLs showing as
properly redirected, or as errors. The approach this kind of migration follows at Nooralto treats the
redirect map, not the new theme, as the actual deliverable of the project, because a beautiful new
storefront sitting behind broken redirects is invisible to the search traffic it was supposed to
keep.

A platform migration is rarely undone by the new platform being worse. It is undone by treating the
gap between two URL structures as an afterthought instead of the center of the project.

Nooralto builds websites and runs search optimisation for businesses, from Agadir and Paris.