PrestaShop URL Structure: Clean URLs, Canonicals and Avoiding Duplicate Content

Changing your PrestaShop store's URL structure is one of the most impactful — and most dangerous — SEO tasks you can undertake. Done correctly, it cleans up years of accumulated technical debt, eliminates duplicate content, and gives you a URL architecture that scales with your catalog. Done wrong, it can erase months or years of organic traffic overnight.

I have managed URL migrations for PrestaShop stores ranging from small boutiques to catalogs with 30,000+ products. This guide is not about what makes a "good URL" in theory — there are plenty of articles covering that. This is the practical, step-by-step guide for store owners who are actually changing their URLs: how to plan the migration, implement 301 redirects correctly, monitor the transition in Google Search Console, and recover if something goes wrong.

When Should You Change Your URL Structure?

URL changes carry real risk, so make sure you actually need to do it. Here are legitimate reasons to restructure URLs in PrestaShop:

• Category paths in product URLs causing duplicates: PrestaShop's default configuration includes the category path in product URLs (/bags/leather/blue-wallet). When a product belongs to multiple categories, it becomes accessible at multiple URLs — a classic duplicate content problem.
• Unnecessary IDs in URLs: URLs like /42-wallets or /123-blue-leather-wallet.html add no SEO or user value. Removing IDs creates cleaner, more shareable URLs.
• Language prefixes on single-language stores: A store serving only English-speaking customers does not need /en/ in every URL.
• Legacy .html extensions: Some PrestaShop configurations append .html to every URL. While harmless, removing them creates shorter, cleaner URLs.
• Platform migration: Moving from another CMS to PrestaShop — or from PrestaShop 1.6 to 1.7/8.x — often changes URL patterns automatically.
• Category restructuring: Reorganizing your catalog hierarchy changes category URLs and any product URLs that include category paths.

When NOT to Change URLs

If your URLs are functional, indexed, and ranking — leave them alone. A URL with an ID number that ranks on page one of Google is infinitely more valuable than a "cleaner" URL that starts from scratch. Cosmetic URL changes are almost never worth the migration risk.

The Real Cost of Changing URLs Without a Plan

I need to be direct about what happens when URL changes go wrong, because I have seen it happen too many times:

• Immediate traffic drop of 20-60% — Google has to re-crawl and re-evaluate every changed URL. During this period, pages may temporarily drop from the index.
• Lost backlinks: Every external site linking to your old URLs will hit a 404 unless you redirect. Those backlinks — often built over years — transfer zero value without a 301 redirect.
• Broken internal links: Menus, footers, product cross-sells, CMS page links, email templates — all contain hardcoded URLs that will break.
• Recovery time of 4-16 weeks — Even with perfect redirects, Google takes time to process changes. Semrush data suggests most properly executed migrations recover 90-95% of traffic within 8-12 weeks (source: Semrush).

That said, when a migration is necessary — especially fixing duplicate content from category paths — the long-term SEO benefit outweighs the short-term cost. The key is executing it correctly.

Step 1: Audit Your Current URL Landscape

Before changing anything, you need a complete picture of your current URLs. This means:

Crawl Your Entire Site

Use Screaming Frog, Sitebulb, or any crawler to extract every URL on your site. Export the full list. For a PrestaShop store, pay particular attention to:

• Product URLs with category paths: The same product appearing at /category-a/product and /category-b/product
• URLs with ID numbers: /42-category-name vs. /category-name
• Parameter-based URLs: ?id_product=123&controller=product — these are non-friendly URL versions that may still be crawlable
• Paginated URLs: /category?page=2 through /category?page=50

Export Google Search Console Data

Go to Search Console → Performance → Pages. Export all URLs that received impressions or clicks in the last 16 months. These are your "valuable" URLs — the ones Google is actively ranking. Any migration plan must account for every single one of these.

Export Backlink Data

Use Ahrefs, Semrush, or Google Search Console's Links report to identify which of your URLs have external backlinks. These are your highest-priority redirect targets — losing backlink equity from high-authority referring domains can take years to rebuild.

Document the Current State

Create a spreadsheet with columns for: current URL, HTTP status, canonical tag value, number of backlinks, monthly organic clicks, and target new URL. This becomes your migration map — the single most important document in the entire process.

Step 2: Design Your New URL Structure

For PrestaShop stores, I recommend these URL structure principles:

Remove Category Paths from Product URLs

This is the single most common — and most important — URL change for PrestaShop stores. Instead of:

/bags/leather-bags/blue-leather-wallet

Use:

/blue-leather-wallet

Why? Because when a product belongs to multiple categories, the category-path approach creates multiple URLs for the same product. PrestaShop attempts to handle this with canonical tags, but in practice, I have seen Google index both versions anyway, diluting ranking signals across duplicates.

A flat product URL structure — where products sit at the root level — eliminates this problem entirely. Each product has exactly one URL regardless of how many categories it belongs to. Tools like the Smart SEO Friendly URL Manager make this change straightforward in PrestaShop.

Keep Category URLs with Hierarchy (But Shallow)

Categories benefit from hierarchy in URLs because it communicates structure to both users and search engines:

/bags/leather-bags    ✓ Good — clear parent/child relationship
/bags/leather-bags/casual/everyday    ✗ Too deep — limit to 2 levels

Remove IDs, Extensions, and Unnecessary Prefixes

/42-wallets            → /wallets
/blue-wallet.html      → /blue-wallet
/en/wallets            → /wallets  (single-language stores)
/home/1-home.html      → /         (homepage)

Use Hyphens, Always Lowercase

Google treats hyphens as word separators (blue-wallet = "blue" + "wallet") but underscores as joiners (blue_wallet = "bluewallet"). Always use hyphens. Always use lowercase — URLs are case-sensitive, and /Blue-Wallet is a different URL than /blue-wallet.

Step 3: Build Your Redirect Map

This is the most labor-intensive step, and the one where mistakes are most costly. Every old URL that has ever been indexed, linked to, or received traffic must be mapped to its new equivalent.

One-to-One Mapping

The golden rule: every old URL redirects to its direct equivalent. Not to the homepage. Not to a category page. To the exact same content at its new URL.

/42-wallets                      → /wallets
/bags/leather-bags/blue-wallet   → /blue-wallet
/123-blue-wallet.html            → /blue-wallet
/en/bags/wallets                 → /bags/wallets

Handle Deleted Pages Correctly

For products that no longer exist, you have three options — in order of preference:

1. Redirect to the closest equivalent product — if you discontinued "Blue Wallet v1" and replaced it with "Blue Wallet v2," redirect to the new product.
2. Redirect to the parent category — if no direct equivalent exists, send users to the category page where they can find alternatives.
3. Return a 410 Gone — if the product has no equivalent and the category is also gone, a 410 tells Google to remove the URL from its index faster than a 404.

Never redirect everything to the homepage. Google calls this a "soft 404" and it provides zero SEO value — the ranking signals from the old URL are simply lost.

Avoid Redirect Chains

A redirect chain occurs when URL A redirects to URL B, which redirects to URL C. Each hop adds latency (typically 50-200ms per redirect), and while Google says they will follow up to 5 hops, link equity can diminish through chains. More importantly, chains are a maintenance nightmare that compound over successive migrations.

Always redirect directly from the original URL to the final destination:

✗ Bad:  /old-url → /intermediate-url → /final-url
✓ Good: /old-url → /final-url

If you have existing redirects from a previous migration, update them to point directly to the new URLs rather than chaining through the intermediate step.

Step 4: Implement 301 Redirects in PrestaShop

There are several ways to implement redirects in PrestaShop, each with different trade-offs:

Method 1: .htaccess Rules (Apache)

The fastest and most server-efficient method. Redirects happen at the web server level before PrestaShop even loads:

# Individual product redirects
RewriteRule ^42-wallets$ /wallets [R=301,L]
RewriteRule ^bags/leather-bags/blue-wallet$ /blue-wallet [R=301,L]

# Pattern-based redirects (remove .html extension)
RewriteRule ^(.+)\.html$ /$1 [R=301,L]

# Pattern-based redirects (remove ID prefix)
RewriteRule ^[0-9]+-(.+)$ /$1 [R=301,L]

# Remove language prefix for single-language stores
RewriteRule ^en/(.*)$ /$1 [R=301,L]

Place redirect rules before PrestaShop's own rewrite rules in .htaccess. The [R=301,L] flags mean: return a 301 status (permanent redirect) and stop processing further rules.

Pros: Fastest execution, no PHP overhead, works even if PrestaShop is down.
Cons: Requires manual maintenance, regex mistakes can break the entire site, Apache-only.

Method 2: PrestaShop Module

A redirect management module provides a database-driven interface for creating and managing redirects. This is the approach I recommend for most stores because:

• Non-technical staff can manage redirects through the admin panel
• Bulk import from CSV — critical for large migrations with thousands of redirects
• Automatic 404 detection with redirect suggestions
• No risk of breaking .htaccess syntax

Method 3: Nginx Configuration

For stores running on Nginx (including many Docker-based deployments), redirects go in the server configuration:

location = /42-wallets {
    return 301 /wallets;
}

# Pattern-based redirect
location ~ ^/(\d+)-(.+)$ {
    return 301 /$2;
}

Nginx requires a reload after configuration changes (nginx -s reload), but redirects execute faster than Apache's .htaccess approach because the configuration is loaded into memory rather than read from disk per-request.

Step 5: Update Everything That References Old URLs

Redirects are a safety net, not a solution. Every internal reference to old URLs should be updated to point directly to new URLs. Relying on redirects for internal navigation wastes crawl budget and adds unnecessary latency.

Internal Links to Update

• Navigation menus — top menu, footer links, sidebar navigation
• CMS page content — any hardcoded links in "About Us," "Shipping Policy," etc.
• Product descriptions — cross-references to other products or categories
• Email templates — order confirmation, shipping notification, abandoned cart emails
• XML sitemap — regenerate immediately with new URLs only (see our sitemap guide)
• Social media profiles — any links in your bio, pinned posts, or ads
• Google Merchant Center feed — product URLs in your shopping feed must match the new structure
• Structured data — JSON-LD markup on product pages includes URLs that must be updated

Database-Level URL Cleanup

PrestaShop stores URLs in several database tables. After changing your URL schema, verify that these tables reflect the new structure:

• ps_product_lang — the link_rewrite column
• ps_category_lang — the link_rewrite column
• ps_cms_lang — the link_rewrite column

If you changed your friendly URL settings (removed category path, removed IDs), PrestaShop regenerates URLs from these link_rewrite values. Ensure they are clean — no special characters, no uppercase, no underscores.

Step 6: The Canonical Tag Strategy

Even with clean URLs and proper redirects, canonical tags remain essential. They are your explicit declaration to search engines: "This is the official version of this page."

Self-Referencing Canonicals

Every page on your store should have a canonical tag pointing to itself. This protects against accidental duplicate content from tracking parameters, session IDs, or other URL variations:

<link rel="canonical" href="https://yourstore.com/blue-leather-wallet" />

In PrestaShop, canonical tags are generated automatically for product and category pages, but verify they are using the new URL structure — not the old one. The Product Canonical Manager module gives you fine-grained control over canonical tag generation.

Canonicals for Paginated Content

Category pages with pagination deserve special attention. Google removed support for rel="prev"/rel="next" years ago, so the current best practice is:

• Each paginated page (/wallets?page=1, /wallets?page=2) gets a self-referencing canonical
• If you prefer, canonicalize all paginated pages to page 1 — but this means products on page 2+ are only discoverable through internal links, not through the sitemap
• Alternatively, use "view all" pages if your catalog size permits — a single page with all products in the category

Cross-Domain Canonicals

If you run a multi-store PrestaShop setup with products shared across domains, cross-domain canonical tags prevent duplicate content across stores. The canonical on store-b.com/blue-wallet can point to store-a.com/blue-wallet to consolidate ranking signals.

Step 7: Crawl Budget and Why It Matters

Crawl budget is the number of pages Googlebot will crawl on your site within a given timeframe. For small stores (under 1,000 pages), crawl budget is rarely a concern. For larger catalogs, it directly impacts how quickly new pages are discovered and how frequently existing pages are re-crawled.

URL migrations impact crawl budget in several ways:

• Redirect processing consumes crawl budget: Every 301 redirect Googlebot encounters counts as a crawled URL. If you have 10,000 redirects and Google visits them all, that is 10,000 crawls spent on redirects instead of actual content pages.
• Duplicate URLs double crawl requirements: If old URLs remain accessible (returning 200 instead of 301), Google may crawl both old and new versions — doubling crawl demand while providing zero additional value.
• Redirect chains multiply the cost: A chain of A → B → C counts as three crawled URLs for one piece of content.

The fix: implement redirects correctly (direct, no chains), update internal links to point to new URLs (reducing redirect hits), and regenerate your XML sitemap with only new URLs.

Step 8: Monitor the Migration in Google Search Console

After deploying your URL changes and redirects, monitoring is critical. Here is a week-by-week guide:

Day 1-3: Verify Redirects Are Working

• Test 50-100 old URLs manually (or with a crawler). Every one should return a 301 status with the correct destination.
• Check your server logs for 404 errors — any spike indicates missed redirects.
• Resubmit your updated sitemap in Google Search Console.

Week 1-2: Initial Impact Assessment

• Expect a traffic dip of 10-30%. This is normal and not cause for alarm.
• Monitor the "Pages" report in Search Console for new crawl errors.
• Watch for "Redirect" entries — these confirm Google is discovering and following your 301s.
• Check that old URLs are gradually being replaced by new URLs in the "Performance" report.

Week 3-6: Recovery Phase

• Traffic should begin recovering as Google reprocesses redirects and recalculates rankings.
• Monitor for pages that dropped out of the index — check whether their redirect is working correctly.
• Look for "Crawled - currently not indexed" status on new URLs. This may indicate thin content or quality issues unrelated to the migration.

Week 8-12: Stabilization

• By week 8-12, traffic should be at 90-100% of pre-migration levels.
• If traffic is still down 20%+ at week 12, investigate specific pages — the issue is likely with individual redirects, not the migration as a whole.
• Start auditing redirect chains — over time, third-party sites will update their links, reducing the need for some redirects.

Ongoing: When to Remove Redirects

Google recommends keeping redirects in place for at least one year. After that, high-value redirects (pages with backlinks) should remain permanently. Low-value redirects (pages with no backlinks and no search traffic) can be removed after 12-18 months and allowed to return 404/410.

Handling Multi-Language Stores

PrestaShop multi-language stores face additional URL complexity. Each product exists at /en/blue-wallet, /de/blaue-brieftasche, /fr/portefeuille-bleu, etc. When restructuring URLs, you must:

• Maintain language prefixes for multi-language stores (they serve a real purpose — telling Google which language version to serve)
• Ensure hreflang tags point to the new URLs across all language versions
• Create redirects for every language variant — if you change the English URL, you need corresponding redirects for German, French, and every other language
• Update the link_rewrite values in the database for all languages, not just the default

The redirect count multiplies by the number of languages. A store with 5,000 products in 4 languages may need 20,000 redirects for a full URL restructure.

The Duplicate Content Problem in PrestaShop: Root Causes

Before wrapping up, let me address the specific duplicate content issues I see most often in PrestaShop — because understanding these helps you design a URL structure that prevents problems rather than just fixing them:

Products in Multiple Categories

A product assigned to both "Sale" and "Wallets" categories creates two URLs. PrestaShop adds canonical tags, but the safest fix is removing category paths from product URLs entirely.

www vs. non-www

If both www.yourstore.com and yourstore.com resolve to your store without a redirect, every page is duplicated. Fix with a 301 redirect in .htaccess or server config — pick one version and redirect the other.

HTTP vs. HTTPS

Same issue as www/non-www. If http://yourstore.com still resolves, redirect it to https:// with a 301.

Trailing Slashes

/wallets and /wallets/ are technically different URLs. Pick one convention and redirect the other. PrestaShop's default is no trailing slash — stick with it unless you have a specific reason not to.

Session IDs and Tracking Parameters

/blue-wallet?utm_source=newsletter&utm_medium=email — if your canonical tags are correct, this is handled. But verify that PrestaShop is not generating canonical tags that include tracking parameters.

Conclusion: Migration Is a Project, Not a Quick Fix

A PrestaShop URL migration is not something you do on a Friday afternoon. It is a project that requires an audit, a plan, a redirect map, implementation, internal link updates, sitemap regeneration, and weeks of monitoring. But when you have duplicate content bleeding ranking signals across multiple URLs, or a URL structure that wastes crawl budget on parameter variations — the migration is worth it.

Plan meticulously, redirect everything, update all internal references, monitor weekly in Search Console, and give Google 8-12 weeks to process the changes. I have never seen a well-executed migration fail to recover. I have seen many poorly planned ones cause lasting damage.

Take the time to do it right.