How to Migrate PrestaShop Without Losing Google Rankings

Why Migrations Are Dangerous for SEO

Migrating a PrestaShop store is one of the highest-risk operations you can perform from an SEO perspective. Whether you are moving to a new server, changing domains, upgrading from PrestaShop 1.6 to 1.7 or 8.x, or restructuring your URL patterns, every migration carries the potential to destroy months or years of accumulated search engine rankings.

The reason is straightforward. Google and other search engines have indexed your current URLs, assigned authority to them, and built a map of how your site is structured. When you change anything about those URLs, their structure, or their accessibility, search engines must re-evaluate everything. If the transition is handled poorly, Google interprets the change as your old content disappearing and new, unproven content appearing. The result is a rankings drop that can take months to recover from, if full recovery happens at all.

The good news is that migrations can be done safely. With proper planning, correct redirect implementation, and careful monitoring, you can preserve the vast majority of your rankings through a migration. This guide walks through every step of the process, from the initial SEO audit through post-migration monitoring.

Pre-Migration SEO Audit

Before you touch a single configuration file, you need a complete picture of your current SEO state. This audit serves two purposes: it gives you a baseline to compare against after the migration, and it identifies the most valuable pages that must be handled with absolute care.

Crawl Your Current Site

Use a crawling tool like Screaming Frog, Sitebulb, or the free version of Screaming Frog (limited to 500 URLs) to crawl your entire site. Export the full list of URLs, their HTTP status codes, page titles, meta descriptions, canonical tags, and internal linking structure. Save this data. You will need it after migration to verify that nothing was lost.

Export Google Search Console Data

Google Search Console is your most reliable source of truth for which pages actually receive organic traffic. Go to Performance > Search Results and export data for the last 16 months (the maximum available). Pay special attention to:

Pages with the most clicks and impressions. These are your money pages. A redirect failure on any of these pages will have an immediate and visible impact on traffic.

Queries that drive the most traffic. After migration, you will monitor these queries to verify rankings are stable.

Pages with high impressions but low clicks. These pages are on the verge of ranking well and are especially sensitive to disruption.

Document Your URL Structure

PrestaShop generates URLs based on your friendly URL settings, category structure, and product configurations. Document the patterns. For example, are your product URLs structured as /category/product-name.html or just /product-name.html? Do your category URLs include IDs like /3-category-name? Are CMS pages at /content/5-page-name?

Understanding these patterns is essential because your new installation may generate different URL structures by default, and every changed URL needs a redirect.

Check Existing Backlinks

Use a backlink checking tool like Ahrefs, Moz, or Google Search Console's Links report to identify which external sites link to your store and which specific pages they link to. These backlinked pages carry the most authority, and losing them means losing the SEO value of every backlink pointing to them.

Building Your URL Mapping

The URL mapping is the most critical document in your entire migration. It is a spreadsheet that maps every old URL to its corresponding new URL. Every single URL that has ever received traffic, has backlinks, or appears in your sitemap must have a mapping.

Generating the URL List

Combine URLs from your site crawl, Google Search Console export, backlink report, and XML sitemap. Remove duplicates and sort by importance (traffic and backlink value). Your final list should include:

All product URLs. In PrestaShop, these are generated from the product name and your friendly URL configuration. If you are changing your URL structure (for example, removing .html extensions or changing the category path format), every product URL changes.

All category URLs. PrestaShop category URLs often include the category ID, and this ID may be different in the new installation if you reimport categories.

All CMS page URLs. These include your about page, terms and conditions, privacy policy, and any other content pages.

All manufacturer and supplier URLs, if you use these features.

Paginated URLs for categories with many products.

Creating the Mapping

For each old URL, determine what the corresponding new URL will be. If the URL structure is not changing (same domain, same friendly URL settings, same IDs), many URLs may map to themselves and no redirect is needed. But verify this. Even small changes like a different category tree depth or a trailing slash difference create new URLs that need redirects.

If you are changing URL patterns systematically (for example, removing all .html extensions), you can use regex-based redirects instead of mapping every URL individually. But always verify the regex against your actual URL list before going live.

Implementing 301 Redirects

A 301 redirect tells search engines that a page has permanently moved to a new location. It transfers the vast majority of the SEO value (link equity) from the old URL to the new one. This is the mechanism that preserves your rankings through a migration.

Where to Place Redirects

For PrestaShop on Apache, redirects go in the .htaccess file in your document root. Place your redirect rules before the PrestaShop rewrite rules (before the section that starts with # Dispatcher).

For PrestaShop on Nginx, redirects go in your server block configuration. You may need to reload Nginx after changes: sudo nginx -t && sudo systemctl reload nginx.

Redirect Rule Syntax

For Apache .htaccess, individual redirects use this format:

Redirect 301 /old-path/old-product.html https://www.newdomain.com/new-path/new-product

For pattern-based redirects using mod_rewrite:

RewriteEngine On
RewriteRule ^old-category/(.*)$ /new-category/$1 [R=301,L]

For Nginx, individual redirects:

location = /old-path/old-product.html {
  return 301 https://www.newdomain.com/new-path/new-product;
}

Handling Large Numbers of Redirects

PrestaShop stores with thousands of products need a more scalable approach than writing individual redirect rules. Options include using a RewriteMap in Apache (which reads from a text file or database), using a PrestaShop module designed for managing redirects, or implementing redirects at the application level through a custom module that intercepts 404 errors and checks a redirect table.

The application-level approach has the advantage of being manageable through the back office but adds a small performance overhead to every 404 request. The .htaccess approach is faster but harder to manage at scale.

XML Sitemap Updates

Your XML sitemap tells search engines which URLs exist on your site and should be crawled. After a migration, the sitemap must reflect the new URL structure immediately.

Generating a New Sitemap

PrestaShop includes built-in sitemap generation, but many store owners use a module like Google Sitemap or a third-party SEO module for more control. After migration, generate a fresh sitemap that includes all new URLs. Verify that the sitemap does not contain any old URLs that now redirect.

Submitting the Updated Sitemap

Go to Google Search Console, navigate to Sitemaps, and submit your new sitemap URL (typically https://www.yourdomain.com/1_index_sitemap.xml for PrestaShop). If the sitemap URL itself has changed, remove the old sitemap entry and add the new one.

A fresh sitemap submission signals to Google that your site structure has changed and encourages faster crawling of the new URLs. Combined with proper 301 redirects from the old URLs, this gives Google a clear picture of what happened.

Google Search Console Migration Steps

Same Domain Migration (Server Move or Upgrade)

If your domain is not changing, there is no special Search Console action needed beyond submitting the updated sitemap and monitoring. Google will discover the changes through normal crawling.

Domain Change Migration

If you are changing domains, use the Change of Address tool in Google Search Console. This requires that both the old and new domains are verified in Search Console. The steps are:

First, set up and verify the new domain in Google Search Console. Second, ensure all 301 redirects are in place from the old domain to the new domain. Third, go to the old domain's property in Search Console and use Settings > Change of Address. Fourth, follow the prompts to specify the new domain.

This tells Google explicitly that your site has moved, which speeds up the transition significantly. Without this step, Google eventually figures it out through the 301 redirects, but it takes longer.

DNS Propagation Considerations

If your migration involves changing DNS records (pointing your domain to a new server), be aware that DNS propagation is not instant. Different DNS resolvers around the world update at different times, and full propagation can take 24 to 72 hours.

Minimizing Downtime

Before the migration, reduce your DNS TTL (Time To Live) to a low value like 300 seconds (5 minutes). Do this at least 48 hours before the actual migration so the old, high TTL expires everywhere. When you change the DNS records, resolvers will check for updates every 5 minutes instead of every few hours.

After the migration is complete and verified, increase the TTL back to a normal value like 3600 (1 hour) or higher to reduce DNS query load.

Running Both Servers in Parallel

During the propagation window, some visitors will reach the old server and some will reach the new one. Keep the old server running with a copy of the site (or at least with the redirect rules in place) until propagation is complete. Shutting down the old server immediately causes downtime for visitors whose DNS has not updated yet.

Monitoring Rankings Post-Migration

The work does not end when the migration goes live. Post-migration monitoring is essential to catch problems before they cause lasting damage.

Immediate Checks (Day 1)

Verify that all critical pages load correctly on the new site. Test every redirect from your URL mapping to confirm it works. Check Google Search Console for any new crawl errors. Run a fresh site crawl and compare it against your pre-migration crawl data.

First Week Monitoring

Check Google Search Console daily for crawl errors, indexing issues, and any traffic drops. Look at the Coverage report for pages that are no longer indexed or that returned errors. Monitor your core keyword rankings using a rank tracking tool. Some fluctuation is normal in the first week, but large drops on important keywords indicate a redirect problem.

First Month Monitoring

Compare organic traffic in Google Analytics or your analytics platform against the same period before migration. Check that all important pages are being re-indexed by searching site:yourdomain.com/specific-page in Google. Verify that the old URLs are being removed from the index (they should redirect to the new URLs, and Google should eventually replace them in its index).

Three Month Assessment

By three months post-migration, your organic traffic should have stabilized at or near pre-migration levels. If it has not, investigate which specific pages or queries have lost rankings and check their redirect chains, content quality, and technical health.

Common Migration Mistakes

Using 302 Instead of 301 Redirects

A 302 redirect tells search engines that the move is temporary. Search engines do not transfer full link equity through 302 redirects. Always use 301 for permanent migrations. This is the single most common and most damaging mistake.

Forgetting to Redirect Non-www to www (or Vice Versa)

If your old site used www.example.com and your new site uses example.com (or the reverse), you need redirects for both the URL structure change and the www/non-www change. Forgetting one of these creates a situation where some old URLs return 404 errors.

Not Updating Internal Links

After migration, your internal links should point directly to the new URLs, not to the old URLs that redirect. While redirects preserve SEO value for external links, internal links that redirect create unnecessary redirect chains and slow down crawling.

Losing HTTPS

If your old site used HTTPS and your new site does not (or vice versa), Google treats these as different URLs. Make sure your SSL certificate is properly configured on the new server before going live, and that all redirects use the correct protocol.

Changing Multiple Things at Once

If you change your domain, your URL structure, your content, and your site design all at the same time, it becomes impossible to diagnose what caused any ranking drops. Change as few things as possible during the migration itself. Content and design updates can happen after rankings have stabilized.

Migration Timeline

A well-planned PrestaShop migration follows this timeline:

4 weeks before: Complete SEO audit, export all data, begin URL mapping. Lower DNS TTL if changing servers.

2 weeks before: Finalize URL mapping, write all redirect rules, set up the new site on a staging environment, and test thoroughly.

1 week before: Test all redirects on staging. Verify the new XML sitemap is correct. Run a full crawl of the staging site and compare against the old site's crawl data.

Migration day: Deploy the new site, activate redirects, update DNS if needed, submit the new sitemap to Search Console, use Change of Address if changing domains.

Week 1: Monitor Search Console daily, fix any crawl errors immediately, verify redirect functionality.

Month 1: Weekly Search Console reviews, compare traffic against baseline, check indexing progress.

Month 3: Full assessment against pre-migration baseline. Address any remaining issues.

Summary

A successful PrestaShop migration that preserves Google rankings requires three things: thorough preparation, correct redirect implementation, and diligent post-migration monitoring. The pre-migration audit gives you a baseline and identifies your most valuable pages. The URL mapping and 301 redirects ensure that every page's SEO value transfers to the new location. The sitemap update and Search Console configuration help Google discover and process the changes quickly. And post-migration monitoring catches problems before they become permanent. Skip any of these steps and you risk losing rankings that took months or years to build. Follow them all and your migration becomes a controlled transition rather than an SEO disaster.

Further reading: Moving from Shopify to PrestaShop: When and Why It Makes Sense and Moving from WooCommerce to PrestaShop: A Practical Migration Guide.