What Should You Check Before Moving Your PrestaShop Store to a New Domain?

Migrating your PrestaShop store to a new domain can feel like a high-wire act where one missed step threatens years of hard-earned SEO rankings and customer trust. Whether you are rebranding or upgrading your infrastructure, rushing the process or skipping database checks is a fast track to broken checkouts, redirect loops, and lost revenue.

A successful domain move relies on precise execution, strict order of operations, and thorough pre-flight testing. This comprehensive guide walks you through the exact gate-by-gate checklist, from updating hidden database tables and configuring 301 redirects to managing post-launch monitoring, so you can transition your store seamlessly without missing a beat.

What Should You Actually Confirm Before Flipping The Domain?

Moving a PrestaShop store to a new domain is a one-way trip if you rush the prep. Work through this pre-flight list on a working day when you can monitor it, not on a Friday night:

• Take a full backup of the store files and the database, and download both. A backup you have not downloaded is a backup you have not proved.
• Clone the store to a staging environment and rehearse the migration there first.
• Lower the TTL on the domain's DNS records 24-48 hours before the switch, so stale records expire quickly.
• Confirm you hold the DNS login for both the old and new domains.
• Provision an SSL certificate for the new domain before it goes live, so no customer hits an insecure page.
• Run a full crawl of the live store with a tool such as Screaming Frog and export the indexable URLs from Google Search Console.
• Inventory every place the old domain is hard-coded: transactional emails, invoices, CMS pages, module configuration and theme templates.

A migration is only as safe as the backup and URL snapshot you take before touching a single setting. Keep that crawl export open in another tab for the rest of the process.

The Database Layer: Shop_url, Parameters.php and Multistore Traps

PrestaShop records the domain in more than one place, and the SEO settings panel is only the visible layer. The shop_url table holds the domain per shop and per URL pattern, and it does not always update when you change the Shop URL field in the back office.

Run a SQL query against that table before you touch DNS. If a row still points to the old domain, every link PrestaShop generates after the switch will send customers and crawlers to a dead host. A database cleanup module can help you inspect rows, but verify the values manually.

Next, open app/config/parameters.php. Some installs write the domain into the database connection string and other environment values. If the domain is hard-coded there, edit it and confirm the file stays valid PHP.

• For multistore setups, check the shop_url rows for each shop, not only the default one. One missed shop keeps serving the old domain.
• Confirm each shop has the correct virtual URL and that no shop shares the main domain by accident.
• Delete the contents of var/cache (or the configured cache directory) so compiled templates and routing no longer reference the old host.
• Clear the Smarty cache and any CDN or full-page cache in the same window.

This is where migrations fail quietly. A stale row or a cached route throws no error; the store simply keeps pointing at the old address.

How Does Changing Your PrestaShop Domain Affect SEO?

Expect rankings to wobble for a few days after the switch. That short dip is normal and usually settles once Google recrawls the new URLs. The losses that last come from missing redirects, stale canonicals, conflicting hreflang and crawl errors nobody checked. Work through these in order, because each step depends on the one before it.

1. Publish one 301 redirect from every old URL to its exact new counterpart, before you announce the domain anywhere.
2. Update the canonical URL on every page so it points to the new host. A canonical still naming the old domain tells Google to ignore the new one.
3. Fix hreflang tags so every language alternate uses the new domain. Mixed hreflang is one of the fastest ways to confuse international targeting.
4. Submit a fresh XML sitemap in Google Search Console, generated from the new base URL.
5. File a Change of Address in Search Console for the old property, pointing at the new verified one.
6. Check that robots.txt on the new domain does not block crawling, and that no Disallow line survived from a staging setup.

The 301 and the canonical must agree before you request indexing, or you are asking Google to choose between two conflicting signals.

Backlinks are the slow part. External sites still point at the old domain, and only your redirects carry that authority forward, so verify a sample of key inbound URLs redirect cleanly rather than assuming the pattern works everywhere.

Redirect Map and 301 Rules in .htaccess, The Step That Decides Your Traffic

Once the database points at the new domain, the old URLs still need a home. Every indexed product, category and CMS page must answer with a single 301 to its exact new equivalent. Miss one and Google treats it as a soft 404, dropping the ranking signal you spent years building.

Build the map before you touch .htaccess. Export every URL from the PrestaShop SEO & URLs tab (or crawl the live site) and pair each one with its new address in a spreadsheet. Two columns, no blanks.

• Product Pages: map each /product-name.html to the same link_rewrite on the new domain. If you renamed any, redirect the old slug, not just the ID.
• Category Pages: keep the category tree identical so /category/subcategory stays intact. Rewriting a flat category to the homepage loses the hierarchy signal.
• CMS and Blog Pages: PrestaShop's /content/ and /module/ paths need explicit rules too, especially after a module update.

A wildcard redirect to the homepage is the single fastest way to erase category rankings you cannot get back.

Write the rules directly in.htaccess, before the PrestaShop block, and test each one with curl -I. Confirm a clean 301, not a 302, and that www and non-www, http and https, and language prefixes all land on the canonical version. After deploy, run one final crawl against the old domain.

Moving the PrestaShop Domain vs Launching A New Store: Which Are You Doing?

Before you touch a single setting, be clear which of these two jobs you are doing. A domain move takes an existing store, its order history, customer accounts and years of indexed URLs to a new address. A new store starts with a fresh database and no legacy to protect. They look identical on the surface and behave completely differently underneath.

The distinction changes almost every item on the checklist. On a domain move, your shop_url and Shop URLs entries under Shop Parameters > Traffic & SEO must point at the new address while the old one keeps serving 301 redirects. On a new store you simply set the new domain once and move on.

• Marketing pixels (Google Analytics, Meta Pixel, Google Ads conversion tags) need re-verifying either way, but on a domain move they also need the property or data stream reconfigured so history is not split.
• Transactional email templates must be checked for hard-coded links to the old domain.
• Payment gateway callbacks and return URLs (for example, Stripe webhooks or PayPal IPN) must be updated with each provider, or orders will confirm, but the customer lands on a broken page.
• On a new store, do not 301 the old domain wholesale. Point it at the new site only if you want the traffic, and never blanket-redirect an unrelated domain you still intend to use.

If you are moving a domain, you are protecting history. If you are launching a store, you are building it from zero, so do not import old redirects that will confuse search engines.

Go-live Day: Ordered Switchover Sequence To Sign Off

By switchover day, every pre-flight check should already be signed off. What remains is a timed sequence where each step depends on the one before it. Run these in order and treat each item as a gate.

1. Put the Store Into Maintenance Mode. Enable it from the Back Office so live orders cannot land mid-migration.
2. Deploy the File Set and Import the Database. Upload your prepared files and the updated SQL dump to the new hosting environment.
3. Update shop_url and the Shop URL Settings. Correct the database value first, then confirm the matching entry under Shop Parameters.
4. Flush the Cache. Clear PrestaShop's cache and any server-side opcode or CDN cache so old URLs stop being served.
5. Activate the Redirects. Confirm your .htaccess 301 rules are live before any traffic sees the new domain.
6. Test Checkout and Payments End to End. Place a real transaction through each payment module and confirm the order appears correctly.
7. Remove Maintenance Mode. Only now should the store accept public traffic.

Set a rollback trigger before you start: if checkout fails on the new domain and cannot be fixed within a defined window, restore the old files and database rather than debugging live in front of customers.

The First 30 Days After The Move: What To Monitor

Go-live is a gate you pass, not a finish line. The month after the switch is where you catch the small leaks (a missed redirect, a sitemap still pointing at the old host) before they turn into a ranking slide. Work through these checks a few days apart.

• Open Search Console and confirm the change of address has been accepted for the new property; check the old property's coverage report for URLs still resolving to it.
• Watch the Pages report for a sudden spike in 404s, then trace each one back to your redirect map.
• Read the crawl stats weekly: a jump in crawl errors or a drop in pages crawled signals a misconfigured .htaccess or base URL.
• Compare rankings for your top product and category terms against the pre-move baseline, not against zero.
• In Google Analytics, segment referrals by hostname to spot traffic still arriving on the old domain.
• Check your backlink profile in Bing Webmaster Tools and any link-monitoring account for links that broke after the switch.
• Keep old DNS records live and leave TTLs at their short migration values for the full post-migration window, then restore them.

Log each check with a date and result. A written trail turns a vague "traffic feels down" into a specific fix you can act on that week.

The 5 Mistakes That Quietly Break A PrestaShop Domain Move

Most PrestaShop domain migration disasters do not come from a single dramatic error. They come from ordinary steps taken out of order, or skipped because they looked too small to matter.

• Forgetting The Shop_url table. Editing the domain in the back office is not enough. PrestaShop reads shop_url on every request, and if it is missed the store bounces between domains or loops on redirects. Fix it with a direct SQL update before you touch DNS.
• Wildcard Redirects. A blanket RedirectMatch or catch-all rule in .htaccess sends every old URL to the homepage. Search engines read that as a soft 404 and drop the page. Map each product, category and CMS page to its exact new URL instead.
• Redeploying the Sitemap Before Redirects Are Live. Submitting a fresh sitemap while the 301s are still missing tells crawlers to index dead ends. Publish redirects first, then regenerate and resubmit.
• Forgetting Module Hard-coded URLs. Payment, shipping and marketing modules often store the old domain in their own tables or configuration. Test checkout and every third-party module after the switch, not just the storefront.
• Switching DNS Before SSL is Live. If the certificate for the new domain is not issued and confirmed, visitors hit a security warning. DNS is the last switch you flip, never the first.

Why The Order of A PrestaShop Domain Migration Matters

A PrestaShop domain migration is a sequence, not a list of tasks you can tick off in any order, because some steps lock in decisions the rest of the move depends on. Change the DNS before the database is updated, for example, and your storefront starts serving pages that point customers back to the old domain. That is when rankings start to slip.

Most PrestaShop migration guides cover the SEO basics and stop there. This one also includes the database-level steps many guides skip, because the PrestaShop platform keeps shop URLs both in configuration and in the database, so a careless search-and-replace can corrupt serialised data. 

The PrestaShop Domain Migration Checklist

Treat each stage as a gate: do not open the next one until the current one passes.

1. Freeze and Back Up Everything. Take a full backup of your files and your database, and put the store into maintenance mode so no orders or registrations land mid-migration. Keep the backup off the server. If a later gate fails, you restore to this point rather than trying to undo changes by hand.
2. Record Your Current Settings. Note your current Shop domain name and Shop domain name for SSL in Shop Parameters, plus your base URL configuration from config/settings.inc.php (or the .env file in more recent versions). Having the "before" values written down makes rollback trivial.
3. Audit for Hard-coded References. Search your theme files, custom modules, transactional email templates and third-party integrations for the old domain. Hard-coded links in a theme's header.tpl or a module's configuration will keep pointing at the old address long after you switch.
4. Update the Database At the Right Moment. The ps_shop_url table stores your domain and physical URL, and the ps_configuration table holds values such as PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL. Update these directly, or through PrestaShop's own Shop URLs screen, but do it before DNS changes go live, not after.
5. Set the New Shop URLs in the Back Office. In Shop Parameters, open the Traffic & SEO tab and set the new Shop domain name and Shop domain name for SSL. Confirm the base URL matches the new domain exactly (http versus https, and with or without a trailing slash).
6. Clear the Cache. Use Advanced Parameters, then Performance, to clear the cache, and delete the contents of the var/cache folder on the server. Stale cache will serve old-domain URLs even after the settings are correct.
7. Set up 301 Redirects From Old To New. Add server-level redirects (in .htaccess for Apache, or your server config for Nginx) mapping the old domain to the new one. Keep them in place until the old URLs have fully handed over their signals.
8. Update Your Google Search Console and Analytics Properties. Add and verify the new domain in Search Console, submit the new sitemap, and update your analytics property so tracking does not fall off a cliff at go-live. Keep the old property verified so you can watch how much traffic still hits the old URLs.
9. Repoint DNS and Switch Off Maintenance Mode. Update the DNS records to point to the new domain, wait for propagation, then take the store out of maintenance mode. Verify a product page, a category page, and the checkout flow all load over the new domain and SSL.
10. Verify, Then Monitor. Run a crawl of the new domain to catch broken links and stray old-domain references, test the redirects return 301s, and confirm orders and emails work. Keep watching Search Console for crawl errors and ranking shifts for several weeks after go-live.

Sign-Off Notes for the Riskier Gates

A few stages carry more risk than the rest, and they deserve a deliberate sign-off rather than a quick "looks fine".

Get The Database Step Right

The single biggest cause of a broken PrestaShop migration is a careless database edit. Do not run a blind find-and-replace across the whole database with a raw SQL tool. PrestaShop stores some configuration as serialised strings, and replacing text inside them without adjusting lengths corrupts the record.

Use PrestaShop's own interface or a serialisation-aware tool for the URL change. If you edit ps_shop_url and ps_configuration by hand, change only the specific rows that hold the domain, and re-check the storefront and back office load correctly before moving on.

Redirect Before You Switch DNS

Redirects should be live on the old domain's server before the new domain resolves, so there is no window where old links dead-end. A crawler hitting the old URLs during propagation should already be getting a clean 301. Test a handful of deep URLs (a product, a CMS page, a blog post) to confirm the rules catch them, not just the homepage.

A gap in redirect coverage can undo months of SEO work; a redirect set up in advance costs you nothing.

Watch the SSL and base URL Details

Mismatches between http and https, or a stray trailing slash, are enough to cause redirect loops or mixed-content warnings. Copy the values directly from the new domain's configuration and check them twice.

Conclusion

Nobody remembers a domain migration that ran quietly on a Tuesday afternoon. They remember the one where the cart broke, or where six months of category rankings vanished because a wildcard rule sent everything to the homepage. The difference is almost never talent; it is whether the checklist was worked in order, and signed off gate by gate.

If you take one thing from this guide, take the sequencing. Database first, then settings, then cache, then redirects, then DNS, then verification. Each stage removes a way for the next one to fail silently.

For a store running on PrestaShop, the practical next step is straightforward: open your back office, go to Shop Parameters > Traffic & SEO, and write down the current Shop domain name and SSL value before anything else happens. That single screenshot is your rollback point, and it takes less than a minute.

Frequently Asked Questions