How to set up SSL and HTTPS on PrestaShop

Last updated: June 2026.

Here is the part of an SSL migration that catches PrestaShop owners off guard: buying the certificate is the easy 10%. The certificate goes on your server in minutes. The other 90%, the part that actually breaks stores, happens inside PrestaShop, where SSL is wired into the database, the URL rewriter, the cookie scope, and a stepped Enable SSL on all pages toggle that can lock you out of your own admin if you flip it in the wrong order. This guide is about that 90%: getting HTTPS configured correctly on PrestaShop specifically, with the real back-office paths, the exact configuration keys, and the recovery move for when something goes wrong.

If you want the wider picture of locking a store down, admin security, server rules, virtual patching, this is one item on a longer list; start with the PrestaShop security hardening checklist. This post stays narrowly on SSL and HTTPS.

Why this is non-negotiable for a PrestaShop store

You probably already know HTTPS encrypts the connection. The reasons it is mandatory for a shop, in plain business terms:

• Browsers actively scare your customers off HTTP. Chrome and Firefox label plain-HTTP pages "Not Secure" in the address bar. On the exact pages where a customer is about to type a card number. That is a conversion problem, not just a security one.
• Payment integrations require it. Stripe, PayPal, Mollie and Adyen webhooks and redirect flows assume HTTPS endpoints. A half-configured certificate is one of the quiet reasons a payment callback silently fails.
• It is a ranking signal and an HTTP/2 gate. Google has treated HTTPS as a lightweight ranking factor since 2014, and HTTP/2, which genuinely speeds up page loads through multiplexing, is only available over HTTPS. So the move that makes you secure also makes you faster.

The "So what?": getting this right removes a browser warning from your checkout, keeps your payment callbacks alive, and unlocks a free performance tier. Getting it half-right, certificate present but PrestaShop misconfigured, gives you mixed-content warnings and broken layouts that look worse than plain HTTP ever did.

Which certificate to actually buy (spoiler: probably none)

SSL certificates come in three validation tiers. The encryption is identical across all three, the price difference buys validation paperwork, not stronger security.

A free Let's Encrypt DV certificate gives a customer's browser the exact same padlock and the exact same encryption as a 500 EUR EV certificate. Unless you are a regulated B2B operation whose buyers specifically vet certificate details, take the free DV and put the money into your store.

Step 1: Get the certificate onto your server

This happens at the hosting layer, before PrestaShop is involved at all. Pick the path that matches your setup.

• cPanel: open SSL/TLS Status and click Run AutoSSL. It issues and installs Let's Encrypt certificates for every domain and auto-renews them on a 60–90 day cycle.
• Plesk: Websites & Domains → SSL/TLS Certificates → Install under Let's Encrypt, and tick automatic renewal.
• VPS / dedicated (root access): install Certbot. certbot --apache or certbot --nginx obtains the certificate, edits your vhost, and drops a renewal cron/timer in place. This is the cleanest route if you control the box.
• Cloudflare: the free plan terminates SSL at Cloudflare's edge. Critical detail below. Set it to Full (Strict), never Flexible.

One Cloudflare trap worth calling out, because it bites PrestaShop stores specifically: in Flexible mode the visitor-to-Cloudflare hop is encrypted but the Cloudflare-to-your-server hop is plain HTTP. The padlock looks fine, but PrestaShop sees an HTTP request, and that mismatch is the number-one cause of the redirect loop in the troubleshooting section below. Use Full (Strict), which requires a certificate on your origin (even a free Let's Encrypt one) and encrypts both hops.

Step 2: Turn SSL on inside PrestaShop, in the right order

With the certificate live on the server, PrestaShop still needs to be told to use it. This is the step that locks people out, so do it deliberately.

Go to Shop Parameters → General in the back office (PrestaShop 1.7, 8 and 9.x). There are two switches, and the order matters:

• Set Enable SSL to Yes and save. This makes PrestaShop serve sensitive pages (login, checkout, account) over HTTPS while leaving the rest alone. Confirm the back office and a checkout still load.
• Only then set Enable SSL on all pages to Yes. This forces every front-office URL onto HTTPS.

Why the two-step dance: if your certificate or proxy config is subtly wrong and you flip both at once, PrestaShop can start redirecting the admin to a broken HTTPS endpoint and you lose access to the very screen you need to undo it. Enabling them one at a time means the first switch reveals the problem while you can still reach the back office.

If you locked yourself out anyway

This is the recovery move worth memorising. The two toggles map to two rows in ps_configuration: PS_SSL_ENABLED and PS_SSL_ENABLED_EVERYWHERE. Open phpMyAdmin (or your DB client of choice) and set both to 0:

UPDATE ps_configuration SET value = 0 WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE');

(Swap ps_ for your actual table prefix.) That disables SSL enforcement, restores admin access, and lets you fix the real problem, usually the proxy header issue covered below, before trying again. Clear the cache afterwards (delete var/cache/ contents) so the change takes effect.

Set the shop URLs correctly

Go to Shop Parameters → Traffic & SEO → SEO & URLs and use the Set shop URL panel at the bottom of that page (in multistore it is the dedicated Shop URLs screen). The Shop domain and SSL domain fields should be identical, bare hostnames such as yourstore.com, with no http:// or https:// prefix and no trailing slash. PrestaShop adds the protocol itself based on the SSL toggles. Pasting a full URL into these fields is a classic cause of doubled-up addresses like https://https//yourstore.com.

Step 3: Redirect all HTTP traffic to HTTPS

After SSL is enabled inside PrestaShop, force the redirect before the application does any work. Put the rule near the top of the public .htaccess, after testing it on staging.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Enabling SSL "on all pages" makes PrestaShop generate HTTPS links, but old bookmarks, backlinks and typed addresses still arrive over HTTP. A single canonical HTTPS address, enforced with a 301 redirect, keeps customers on the encrypted version and stops search engines treating HTTP and HTTPS as duplicate sites.

The PrestaShop-specific gotcha: PrestaShop owns its .htaccess. The moment anyone clicks Generate .htaccess file under Shop Parameters → Traffic & SEO → SEO & URLs, the entire file is rewritten and any hand-added redirect rules vanish. The redirect itself, and the safe way to add rules that survive regeneration, belong to the file-level config, covered in depth in PrestaShop .htaccess: security and performance rules. The cleaner options that sidestep the regeneration problem entirely:

• Cloudflare: turn on Always Use HTTPS in SSL/TLS → Edge Certificates. The redirect happens at the edge before the request ever reaches your server, faster, and immune to .htaccess regeneration.
• Nginx: a port-80 server block that does return 301 https://$host$request_uri;, config PrestaShop never touches.

Step 4: Hunt down mixed content (the part that breaks layouts)

Mixed content is the issue you will actually spend time on. An HTTPS page that pulls an image, script or stylesheet over http:// triggers browser warnings, and modern browsers block mixed scripts outright, which is why a store can look completely unstyled or have a dead payment form right after migration.

To find it: open the store in Chrome, press F12, and read the Console tab for lines like "Mixed Content: the page at https://… requested an insecure resource http://…". Each one names the offending URL.

On PrestaShop, mixed content concentrates in a handful of predictable places:

• Hardcoded http:// in the database. Product descriptions, category descriptions and CMS pages where someone pasted an absolute http:// image URL. This is the most common source.
• Module assets. Older or poorly written modules that register CSS/JS with an explicit http:// URL instead of using PrestaShop's $this->context->link / protocol-aware helpers. Update the module or report it to its developer.
• Email templates. Images referenced over HTTP in transactional emails, edited under Design → Email Theme.
• Theme files. CSS background-image or font URLs hardcoded to http:// in a custom theme's stylesheets.
• Third-party embeds. Fonts, analytics, video or social widgets pulled over HTTP.

The database search-and-replace

For the database offenders, run targeted updates after backing up. The fields that matter most are in ps_product_lang (description, description_short), ps_category_lang (description) and ps_cms_lang (content):

UPDATE ps_product_lang SET description = REPLACE(description, 'http://yourstore.com', 'https://yourstore.com');

Repeat per field and table. The robust long-term fix is protocol-relative or HTTPS URLs in content going forward; the cleanest of all is to stop pasting absolute domain URLs into descriptions entirely. Always take a database backup before any bulk UPDATE. There is no undo.

Step 5: Re-point the external services that still think you're HTTP

Google treats http:// and https:// as separate properties, so a migration that skips this step quietly drops you out of your own reporting. Work through:

• Google Search Console: add https://yourstore.com as a new property. It does not inherit history from the HTTP one.
• Google Analytics / Merchant Center: update the property/website URL to https://; a stale HTTP feed URL in Merchant Center can disapprove products.
• Sitemap: regenerate it so every entry is HTTPS. If you run a sitemap module, regenerate through the module rather than the core tool. Our own mypresta.rocks sitemap module picks up the protocol from your SSL settings automatically, so a regenerate after switching SSL on emits clean HTTPS URLs without manual editing, one less thing to remember.
• Payment webhooks: update notification URLs in your provider dashboards, PayPal IPN, Stripe webhook endpoint, Mollie webhook, to https://. A leftover HTTP webhook is a silent order-status failure.

Step 6: Verify, don't assume

Run this checklist before you call it done:

• Homepage over HTTPS shows a clean padlock, no warnings.
• Product, category and CMS pages, Console clear of mixed content.
• A full test checkout completes over HTTPS, payment callback included.
• Every back-office page loads over HTTPS.
• Typing http://yourstore.com 301-redirects to https://.
• One canonical host, www or non-www, not both resolving.
• Run the free SSL Labs server test (ssllabs.com/ssltest); aim for an A or A+.

The three failures that account for most "HTTPS broke my store" tickets

Infinite redirect loop

The classic. Your host or Cloudflare terminates SSL upstream and forwards the request to PrestaShop as plain HTTP. PrestaShop sees HTTP, redirects to HTTPS, the proxy hands it back as HTTP, forever. The fix is to make PrestaShop trust the proxy's X-Forwarded-Proto header so it recognises the original request was HTTPS. On Cloudflare specifically, switching from Flexible to Full (Strict) resolves this outright. On other reverse proxies you may need to honour the forwarded-proto header at the web-server or .htaccess level.

Store loads unstyled / payment form dead

Almost always blocked mixed content, a stylesheet or script the browser refused to load over HTTP on an HTTPS page. Back to Step 4: read the Console, find the http:// resource, fix its source.

Images vanished after migration

Product or CMS images with hardcoded http:// URLs, or an image CDN that does not serve HTTPS. The database search-and-replace in Step 4 handles the former; confirm your CDN/image host supports HTTPS for the latter.

A note on going further

Once HTTPS is clean and verified, the natural next step is HSTS (HTTP Strict Transport Security), which tells browsers to refuse HTTP for your domain entirely. It is powerful and slightly dangerous, a too-long max-age on a misconfigured site can make the domain unreachable, so it belongs with the rest of the security-header hardening rather than crammed in here. We cover HSTS, security headers and the other server-level rules in the .htaccess security and performance guide, and SSL sits inside the broader programme in the complete hardening checklist. If you'd rather have the whole thing explained without the jargon first, the plain-English guide to securing your store is the gentler on-ramp.

SSL on PrestaShop is not hard, but it is unforgiving of order and of the platform's quirks: enable the toggles one at a time, know the ps_configuration recovery before you need it, expect the database to hide your last few http:// URLs, and verify with the Console rather than your eyes. Do that and the payoff is immediate, no "Not Secure" on your checkout, payment callbacks that fire, and HTTP/2 speed for free. Make it this week's project; it is one of the highest-value afternoons you can spend on the store.

Frequently asked questions

I enabled SSL and now the back office redirects forever. How do I get back in?

This is the redirect loop, and it's almost always a proxy serving PrestaShop a plain-HTTP request while the browser-to-edge hop is HTTPS. The fast recovery is to disable enforcement in the database: UPDATE ps_configuration SET value = 0 WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE'); (swap in your table prefix), then clear the cache by emptying var/cache/. That restores admin access. Before re-enabling, fix the real cause, on Cloudflare switch from Flexible to Full (Strict); on another reverse proxy, make PrestaShop honour the X-Forwarded-Proto header so it recognises the original request was HTTPS.

Is a free Let's Encrypt certificate really as secure as a paid one?

For encryption, yes, identical. A DV certificate from Let's Encrypt gives the visitor's browser the same padlock and the same TLS encryption as a 500 EUR EV certificate. The price of OV and EV buys validation paperwork (your company's legal identity is checked), not stronger cryptography, and browsers removed the green company-name bar that was EV's only visible payoff. Unless you're a regulated B2B operation whose buyers specifically vet certificate details, take the free DV.

My store loads unstyled or the payment form is dead after switching to HTTPS, why?

Almost always blocked mixed content: an HTTPS page is pulling a stylesheet or script over http://, and modern browsers refuse to load insecure scripts on a secure page. Open the store in Chrome, press F12, and read the Console tab, each "Mixed Content" line names the offending http:// URL. The usual culprits are absolute http:// links pasted into product or CMS content (fix with a database search-and-replace after backing up), older modules registering assets with a hardcoded protocol, and custom theme stylesheets. Fix the source, not the symptom.

Why must I enable the two SSL toggles one at a time?

Because the order is your safety net. Enable SSL (PS_SSL_ENABLED) only forces HTTPS on sensitive pages, login, checkout, account, so if your certificate or proxy is subtly wrong, the problem surfaces while you can still reach the back office. Only once you've confirmed the admin and a checkout still load do you set Enable SSL on all pages (PS_SSL_ENABLED_EVERYWHERE). Flip both at once on a broken config and PrestaShop can start redirecting the admin to a dead HTTPS endpoint. Locking you out of the exact screen you need to undo it.

Do I need to do anything in Google Search Console after switching to HTTPS?

Yes. Google treats http:// and https:// as separate properties, so add https://yourstore.com as a new property, it doesn't inherit the HTTP version's history. Update your Analytics and Merchant Center URLs to HTTPS as well (a stale HTTP feed URL in Merchant Center can disapprove products), regenerate your sitemap so every entry is HTTPS, and re-point payment webhooks (PayPal IPN, Stripe, Mollie) to the HTTPS endpoint. A leftover HTTP webhook is a silent order-status failure.

Should I turn on HSTS straight away?

Not as your first move. HSTS tells browsers to refuse HTTP for your domain entirely, which is good, but a too-long max-age set on a site that isn't fully clean can make the domain unreachable, and the directive is hard to walk back because browsers cache it. Get HTTPS verified end to end first (clean Console, working checkout, 301 from HTTP, an A/A+ on the SSL Labs test), then add HSTS with the rest of your security-header hardening rather than during the migration itself.