PrestaShop URLs, Canonicals and Redirects

What we would do

We would classify the job before choosing tools: a correction to the current URL policy, a new routing requirement or a move of the shop itself. The right route depends on your existing shop: its configured patterns, modules, theme, catalogue data, integrations, languages and markets, and who will maintain redirects afterwards. Include links generated by the theme and modules, imported slugs and integration endpoints in that assessment.

Make the agreed change on a protected staging copy with the same routing components and representative catalogue data. Isolate the copy from live customer emails, payments and stock or ERP exports. Rehearse the route map and purchase journeys, then plan the live switch with a named owner, saved configuration and a way to reverse the change. Keep the approved map and test results together so the live release uses the rules you actually tested.

If you want the evidence and priorities reviewed before implementation, the PrestaShop SEO Audit & Action Plan provides a read-only review and an ordered fix plan; implementation is separate.

Understand native URLs before changing them

Inspect the shop's actual routes before planning a restructure. On modern versions, use Shop Parameters > Traffic & SEO. In PrestaShop 1.6, use Preferences > SEO & URLs.

• Friendly URL: PS_REWRITING_SETTINGS enables readable routes. Apache needs working rewrite configuration; Nginx needs its own matching server rules.
• Accented URL: PS_ALLOW_ACCENTED_CHARS_URL controls accented slugs. Choose a consistent character policy and test encoding rather than assuming non-ASCII URLs are invalid.
• Canonical redirection: PS_CANONICAL_REDIRECT controls native redirection to preferred URLs for supported pages. Test the actual response, not only the setting.

Native product, category and CMS routes use identifiers. PrestaShop 1.7/8 product patterns can contain category information. PrestaShop 9's default product rule is {id}{-:id_product_attribute}-{rewrite}.html, without a category. Upgraded shops can retain configured patterns.

Assigning a product to two categories does not automatically make native links use every category. Alternate category-path requests may resolve, while normal link generation and canonical redirection consolidate them. Audit generated links, HTML canonical tags and HTTP responses before changing the structure.

Keeping an ID is a valid design choice. If you need an ID-free pattern such as /blue-wallet, you need routing that resolves it. Simply deleting {id} or redirecting to a prettified path does not implement that route.

Change a working structure to solve a defined problem, such as broken routing or persistent inconsistent links. Do not assume removing IDs, extensions or a category component improves rankings by itself.

Audit slugs, languages, shops and route collisions

The link_rewrite values live in language tables such as product_lang, category_lang and cms_lang. These can also be shop-scoped. A slug audit must preserve both language and shop context.

This read-only example checks repeated product slugs in shop 1 and language 1. Replace the table prefix and scope as needed.

SELECT id_shop, id_lang, link_rewrite,
       COUNT(DISTINCT id_product) AS distinct_products
FROM ps_product_lang
WHERE id_shop = 1 AND id_lang = 1
GROUP BY id_shop, id_lang, link_rewrite
HAVING COUNT(DISTINCT id_product) > 1
ORDER BY distinct_products DESC, link_rewrite;

A repeated slug is not necessarily a collision on native ID-based routes. With an ID-free resolver, check the complete generated path across products, categories, CMS, brands, suppliers and module routes. Two different entity types can claim the same path even when each table has no internal duplicates.

Test the chosen collision policy and any suffix it adds. A readable URL manager may append an ID, increment, reference or other discriminator. Never promise that every resulting URL will be number-free.

Keep a route inventory for each published language and shop. Review empty slugs, alternate encodings, case, suffix/trailing-slash choices, language prefixes and any installation subdirectory.

Align canonical URLs, domains and parameters

Choose one preferred host and HTTPS form. Once HTTPS works with a valid certificate, check PrestaShop's “Enable SSL” and “Enable SSL on all pages” settings, including requests through any CDN or proxy. Test bare-domain/www variants and HTTP/HTTPS variants together, including through the CDN. Use your trusted configured host as a redirect destination to avoid loops or untrusted Host-header behaviour.

Set native canonical redirection to a permanent move where appropriate, then test product and category requests. In PrestaShop 1.7.8 and 9, PS_CANONICAL_REDIRECT uses 0 for no redirect, 1 for temporary 302 and 2 for permanent 301. The core canonical redirect applies to GET requests, so check a real GET response. A canonical tag is a preference signal; it does not prevent visitors from opening another URL.

• Generate internal links in the preferred format.
• Use an appropriate canonical for equivalent tracking-parameter variants.
• Check pagination and filtered pages according to their actual content and indexing policy.
• Keep language alternates pointing at their own correct, indexable URLs.
• Do not canonicalise genuinely different pages merely because their addresses look similar.

Do not apply a site-wide slash-removal rule to files, directories and routes without checking their semantics. Functional parameters may choose a combination, filter, language or session action. They are different from disposable campaign tracking.

Check HTML source, response headers, internal links and sitemap entries for conflicting signals. See Google's canonical URL guidance.

If the source contains competing canonical tags, identify their emitters: the theme, an SEO module or custom code. Agree which component owns that output instead of adding another tag. If the output changes only after a cache purge, check application and CDN caching before judging the rule. Compare the affected language and shop as well as the default storefront; a correct default-language page does not prove the other contexts are correct.

Build the old-to-final URL map

Inventory the current catalogue and route configuration, crawl reachable pages, inspect sitemaps and server logs, and add Search Console performance/link data and known external links. Search Console's indexing report provides examples, not a complete list of every indexed URL; see its report documentation.

Record old URL, shop/language, status, current canonical, relevant traffic/backlinks, intended final URL and expected response. Keep unchanged URLs as unchanged. Include images, downloads and important module pages if they move.

Add the evidence source and the entity each row represents. A current crawl cannot discover a historical address that no current page links to, and logs only cover the period you retained. Mark unknown destinations for review rather than silently dropping them. Prioritise valuable landing pages and broken purchase links, but do not treat an empty traffic column as proof that an address is unused.

1. Configure and test destination routing first.
2. Map changed pages directly to their corresponding final destination.
3. Review important discontinued pages for a relevant replacement or equivalent consolidated page.
4. Use 404 or 410 when a page is gone and has no suitable equivalent.
5. Repoint earlier redirect chains to the final URL.

A parent category is not automatically an equivalent destination for a discontinued product. Blanket homepage or category redirects can mislead users and be treated as soft 404s. A 410 does not guarantee faster removal than a 404; see Google's deleted-page guidance.

Use 301 or 308 for permanent moves and the appropriate temporary status for temporary moves. A 302 does not categorically prevent signal consolidation; its indexing intent differs. Permanent redirects do not inherently lose PageRank at every hop. Shorten chains for latency, crawl efficiency and fewer failure points. See Google's redirect guidance.

Test destinations with worked examples

A product has old category paths

Suppose your audit finds historical /bags/42-blue-wallet.html and /sale/42-blue-wallet.html addresses for the same product, and you approve /42-blue-wallet.html as its final route. Confirm the product identity before mapping both aliases directly to that address. Removing the product from Sale later must not send the old Sale link to a generic sale listing.

Test a saved link that also selects a product combination. Follow it through to the product page, add the item to the cart and inspect the resulting size, price and stock choice. A redirect that ends at the correct product but silently drops the customer's selected combination fails this test. Check the same journey from a feed or campaign link, rather than testing only a link freshly generated by the shop.

A product and a content page want the same slug

Suppose an ID-free product and a CMS page both request /summer-sale. Checking product slugs alone will not expose this conflict. Decide which entity keeps the address and give the other a distinct route before publishing either change. Record that ownership in the map; changing redirect priority cannot make the same address serve both intended pages.

Implement exact Apache redirects

Place custom rules outside and before PrestaShop's generated rewrite block. Keep a configuration backup, validate the server and test on staging before reloading production. Use one deliberate redirect mechanism; mixing mod_alias and mod_rewrite can introduce ordering surprises.

These examples belong in a shop-root .htaccess for a root installation. They map exact old paths to tested native final routes on the illustrative domain.

RewriteEngine On
RewriteRule ^old-wallet\.html$ https://www.example.com/42-blue-wallet.html [R=301,L]
RewriteRule ^old-category/$ https://www.example.com/3-wallets [R=301,L]

The anchors make these path matches exact. RewriteRule in this context sees no leading slash and matches the path without query arguments. These rules preserve existing arguments by default. Use QSD only when you deliberately discard them and have confirmed they carry no required state.

For a shop under /shop/, adjust both rule context and target paths. An old index.php?id_product=42&controller=product request needs query-aware handling or tested native canonical behaviour; a path-only index.php rule would match many unrelated pages.

The plain Redirect directive uses path-prefix matching and appends unmatched path information. Use anchored RedirectMatch or a tested anchored rewrite for exact maps. See the Apache Redirect documentation.

Do not use a blanket “strip numeric prefix” or “remove .html” rule until every target route is known to work. Such rules can affect products, categories and unrelated endpoints and can create chains when run sequentially.

Implement a path map on Nginx

For a larger path-only map, define map in the http context and use it from the relevant server block. This example uses anchored, case-sensitive regular expressions and preserves query arguments deliberately.

# http context
map $uri $migration_target {
    default "";
    ~^/old-wallet[.]html$ /42-blue-wallet.html;
    ~^/old-category/$ /3-wallets;
}

# inside the intended server block
if ($migration_target != "") {
    return 301 https://www.example.com$migration_target$is_args$args;
}

$uri is the normalised current path without arguments; $request_uri includes the original query string. A map with path keys against $request_uri would miss /old-wallet.html?utm_source=email. Choose full-request matching only when the query itself is part of the intended key. See Nginx URI variables.

If a target intentionally replaces or drops arguments, change the return construction accordingly. Test escaped characters and repeated slashes against your normalisation policy. Place the logic so it sees the intended path before other internal rewriting changes $uri.

Run nginx -t, review the result, reload the intended instance and test representative requests. The example domains and paths describe a concrete sample map; generate your actual map from approved destinations rather than copying the sample into a different shop.

Move domains and preserve multilingual routes

A hosting move with the same public domain and paths can preserve URLs. Before changing DNS, test the new server with the intended public hostname and HTTPS certificate. Plan how requests still reaching the old server during DNS propagation will reach the active shop. A new domain or base directory also needs the shop's own URL configuration updated, certificates ready and old-to-new routing maintained.

1. Copy matching files and database to the new environment and protect the copy during testing.
2. Update the intended shop URL through the supported back-office settings. Verify shop_url.domain, domain_ssl, physical_uri and any multistore virtual URI.
3. Check relevant PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL values in the correct context.
4. If database access changes, update app/config/parameters.php on modern versions. The path is not config/parameters.php. Legacy 1.6 uses config/settings.inc.php.
5. Clear/rebuild caches and regenerate the applicable Apache rules or deploy the matching Nginx rules.
6. Install and test redirects from each old page to its final equivalent. Keep the old domain and its HTTPS certificate working.
7. Update payment callbacks, cron jobs, mail links, feeds, analytics and ad destinations.

For multilingual catalogues, map each language to its matching language, retain necessary language differentiation, and review canonical and reciprocal hreflang references. Do not redirect every language to English.

A catalogue with 5,000 products and four languages can have roughly 20,000 product-language URL pairs before aliases, categories and old history. Generate the inventory from actual published combinations instead of assuming every product has every translation.

For the platform/data side of the change, use the migration guide.

Use URL and SEO modules for routing and metadata

SEO Revolution provides redirect management, 404 review, permanent-chain handling, canonical/hreflang rules and sitemap workflows; its module help contains the setup and supported matching behaviour.

Smart SEO Friendly URL Manager provides entity URL patterns, collision policies and redirect history, including the condition that an old path must not be owned by a current route; use its module help for setup and interaction with SEO Revolution.

Product Canonical Manager provides per-product canonical controls; see its module help before changing preferred destinations.

Hreflang Tags Manager provides language-alternate management; its module help covers configuration.

Test module routes, exact/query matching, prefix rules, chain endings, language eligibility and current-route precedence on a copy. A redirect module still needs a checked destination map; it cannot choose semantic equivalents safely for every missing page.

Verify the launch and monitor the results

Update internal references to final URLs: navigation, CMS and product content, cross-sells, email templates, feeds and structured data. Redirects should catch old external references rather than add hops to every new internal link.

Generate sitemaps containing intended indexable canonical URLs that return successful responses. Check all shops and languages. Remove redirected, missing and noindex destinations. A sitemap is a discovery/canonical signal rather than an indexing guarantee; see Google's sitemap guidance.

Test the response and final content with both a normal browser and a command-line request. Some applications handle HEAD differently, so confirm with GET as well.

curl -sS -D - -o /dev/null 'https://www.example.com/old-wallet.html?utm_source=email'
curl -sS -L -o /dev/null -w '%{http_code} %{url_effective}\n' 'https://www.example.com/old-wallet.html'

• Changed URLs: expected permanent status, correct Location, no loop and a final 200 page with matching content.
• Unchanged URLs: direct 200, correct content and canonical.
• Removed pages: intended 404/410, without a misleading success page.
• Variants: host, scheme, suffix, case, encoding, arguments, language and installation subdirectory.
• Critical workflows: combinations, search/facets, checkout, account and payment callbacks.

Verify old and new Search Console properties, submit the current sitemap and use Change of Address for a supported domain move. Review crawl/indexing reports, logs, organic landing-page traffic and conversion. Retain permanent migration redirects for at least a year and longer while links or visitors use them.

Keep a pre-change baseline by landing page, language and shop, and compare the mapped destinations with their old equivalents. Whole-shop totals can conceal a broken language or a valuable missing category. Separate a request failure from a search-performance change: a loop, wrong product or blocked destination needs a technical correction, while a working URL with fewer visits needs examination of indexing, content and demand. Record the change time and any concurrent campaigns or catalogue changes so they do not become evidence against the wrong cause.

Processing times and search outcomes vary. Redirects cannot guarantee recovery or compensate for lost content, indexing restrictions or changed competition. See Google's site-move guidance.

What to ask your developer or agency

Ask for a handover you can use when the next import, rename or module update happens.

• Which component owns host redirects, page routing, historical redirects, canonicals and hreflang, and in what order do they run?
• Which map rows remain unresolved, who approves their destinations, and where are the request results and final-page checks?
• Can a catalogue import overwrite manual slugs or create new collisions, and who checks the result?
• Which theme links, feeds, callbacks and scheduled jobs were exercised against the intended live domain and languages?
• Who can restore the previous configuration, what triggers that decision, and how will new orders and stock changes be preserved?
• Who owns monitoring and incoming broken-link reports after the project is handed over?

Questions owners ask

Can we restore a database backup to undo the URL change?

Do not overwrite new orders, customer changes or stock movements with the pre-launch database. Plan recovery around the routing configuration, redirect map and specific data changes involved. Browsers and intermediaries can cache permanent redirects, so test recovery for visitors who still follow the published new destinations. Keep those destinations usable during recovery. If rollback needs data repair, your developer must reconcile the records written since launch rather than restore the entire shop blindly.

Can we reuse a retired product's address for a different product?

Check historical use before approving it. Old bookmarks, campaigns and backlinks would now open the new product, and a historical redirect may no longer run when a current route owns the path. Keep a distinct address when the products do not serve the same intent; reserve important aliases in the route inventory so an import cannot casually reuse them.

Must a domain move stop orders?

A redirect rehearsal does not decide that. If you are moving the database too, agree which environment accepts writes, how the final data synchronisation works and whether a checkout pause is needed. Orders, payment notifications and stock updates must not split between independent copies during the switch.

Who maintains the map after launch?

Give a named person ownership of approved destinations and the reason for each change. Keep redirect configuration with the release records and review it after catalogue imports or routing updates. Include missing-page reports from customer support: a broken purchase link can matter even when it has little search traffic.