Set up HTTPS in PrestaShop and recover from redirect loops

What we would do

We would first map the existing shop: its host, CDN or reverse proxy, PrestaShop version, multistore domains, theme, modules, payment integrations and stored content URLs. Agree who controls each layer and who can recover access. A certificate change, a proxy correction and a content repair need different owners.

For a planned switch, rehearse on a staging copy with the same theme and integrations, isolated from customer emails, live payments and fulfilment exports. Keep a recoverable backup and record the current server, proxy and shop settings. Then repeat the proven changes in an agreed live window, with someone checking orders and callbacks. Restore the affected configuration if needed; replacing the live database with an older copy could discard orders taken since that backup.

Choose the starting point

If ownership of the request path is unclear, the PrestaShop Hosting & Infrastructure Audit provides an assessment and written report; certificate installation and server configuration changes are separate work.

Install and verify the certificate

HTTPS encrypts the connection and authenticates the server hostname through its certificate. Domain Validation checks control of a domain; Organization Validation and Extended Validation add identity checks. Those labels do not by themselves select stronger TLS encryption.

A free domain-validated certificate can meet a shop's needs. Choose coverage, issuer and renewal arrangements that fit your host and any contractual requirements.

• cPanel: use SSL/TLS Status and its AutoSSL action where your host enables it. Check the configured provider, domain-validation results and renewal status. See cPanel's AutoSSL documentation.
• Plesk: use the domain's certificate management and the enabled Let's Encrypt or certificate extension. Confirm hostname coverage and renewal in the installed panel; see Plesk's certificate-extension guidance.
• Your own server: follow the Certbot instructions for your server and operating system. The Apache and Nginx plugins can obtain and install certificates; test automatic renewal.
• Cloudflare: configure a valid origin certificate and use Full (strict) for encrypted, certificate-validated origin connections. Flexible sends HTTP to the origin and can conflict with HTTPS redirects.

Before changing PrestaShop, open the storefront and back office directly over HTTPS. Check certificate expiry, hostname coverage and chain validity. Include any alternate hostname reached over HTTPS before redirecting to the preferred name: the certificate is checked before that redirect can run. Keep server and database access available for recovery.

Browsers normally negotiate HTTP/2 over TLS, but the server or CDN must support it. HTTPS alone does not enable HTTP/2 or guarantee a speed improvement.

Enable the controls for your PrestaShop version

Open Shop Parameters > General. Check the controls present in your installed version.

PrestaShop 9.1

The SSL preference uses one control, Enable SSL, backed by PS_SSL_ENABLED. When enabled, storefront controllers use SSL throughout the storefront.

Older releases with two controls

PrestaShop 1.7.8 has Enable SSL and Enable SSL on all pages, backed by PS_SSL_ENABLED and PS_SSL_ENABLED_EVERYWHERE. After testing HTTPS access, enable SSL, verify the affected pages, then enable it on all pages and test again. Check the actual interface on other releases.

The first control can already affect administration. Enabling controls in stages does not guarantee that HTTP access to the back office remains available.

In Shop Parameters > Traffic & SEO > SEO & URLs, check the shop URL settings. Domain fields contain bare hostnames, such as example.com, without a scheme or path. Configure the base path separately. In multistore, inspect the relevant shop URL records and shop context.

Make proxy scheme detection consistent

If TLS terminates at a reverse proxy, the browser-facing scheme and origin connection can differ. A redirect loop can result when the application sees HTTP and redirects a visitor who is already using HTTPS. For example, a load balancer accepts HTTPS and forwards HTTP to Apache. The direct-TLS Apache rule below sees an insecure origin request and redirects to the same public HTTPS URL on every visit. Put that redirect at the edge or adapt scheme detection to the trusted proxy, then test both storefront and administration.

Legacy Tools::usingSecureMode() checks server variables and also reads X-Forwarded-Proto. Earlier server-variable checks can affect its result. Symfony administration uses its request object's secure-scheme detection and trusted-proxy configuration.

On PrestaShop 9 administration, set PS_TRUSTED_PROXIES to the actual proxy addresses as required by your deployment. Make the proxy overwrite forwarded headers, prevent untrusted clients from spoofing them and expose a consistent scheme to PHP. Do not trust arbitrary proxy addresses.

With Cloudflare, check encryption mode and origin redirects together. Full (strict) validates the origin connection, but conflicting host or scheme rules can still loop. Use Cloudflare's redirect-loop checks to inspect both layers.

Add canonical redirects in the correct layer

After HTTPS works, redirect old HTTP URLs to the chosen HTTPS hostname. Preserve paths and query strings. Check that the final canonical tags, internal links and sitemap agree.

Prefer a virtual-host or edge rule when that is where HTTPS is terminated. On Apache, custom rules belong outside PrestaShop's # ~~start~~ and # ~~end~~ generated block. Core regeneration preserves content outside those markers and can replace rules inside them.

The following example is for Apache terminating TLS directly, with example.com as the chosen host. It does not cover a proxy that connects to Apache over HTTP:

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

Test with temporary redirects before committing a permanent rule. Behind a proxy, redirect at the edge or configure the server to use the original scheme reported by your trusted proxy. A bare HTTPS !=on condition can loop there.

On Cloudflare, Always Use HTTPS redirects HTTP requests at the edge; configure Full (strict) separately for the origin connection. Nginx uses server-block configuration rather than .htaccess. For further file-level rules, use the PrestaShop .htaccess guide.

Find and fix mixed content

Open the browser Console and Network panels on HTTPS pages. Mixed content means a secure page requests an insecure resource. Browsers block some resource types and may upgrade others. Check the URL and failure rather than guessing from a broken layout.

• Product and category descriptions and CMS content can contain absolute HTTP image URLs.
• Modules can register insecure CSS or JavaScript URLs. Use the Network panel's request initiator to trace the source, then update the module or ask its maintainer to correct URL generation.
• Theme CSS can contain HTTP fonts or background images.
• External video, analytics and social embeds need HTTPS support.
• Email images also need valid HTTPS URLs for the email client, although email rendering is separate from storefront mixed content.

Use supported editors or a targeted migration after a backup. Check product_lang.description, product_lang.description_short, category_lang.description and cms_lang.content where relevant. Limit changes to the intended host, shop and fields; do not run a blind database-wide replacement.

For storefront resources, use HTTPS or suitable root-relative URLs going forward. Use absolute HTTPS URLs for email images. Confirm third-party hosts actually serve the replacement URL. Security headers cannot repair a missing file or a certificate failure.

Update external services and generated URLs

Regenerate sitemaps through the installed sitemap tool, then inspect the URLs it emits. Update product landing pages, feeds, advertising destinations and configured website URLs to match the canonical HTTPS site.

In Search Console, an existing Domain property covers both HTTP and HTTPS. If you use URL-prefix properties, add or verify the HTTPS prefix as needed. See Google's property-type guidance.

Check payment callback handling with the installed provider and module version. Update dashboard-configured webhook or notification addresses where that integration uses them. Other integrations submit the callback URL while creating a payment, so check a newly created test transaction as well as the provider dashboard.

Complete a payment and confirm the callback changes the order status. A working browser return page alone is insufficient.

Recover access without changing every shop

1. Record the failing URL, the affected shop and whether the storefront, administration or both fail. Keep hosting, file and database access available outside the broken back office.
2. Inspect the redirect chain with a fresh client and record which host or layer emits each redirect. Compare the requested URL with each response's Location value to spot repeated addresses or alternating hostnames.
3. Check certificate errors, CDN mode, server rules and forwarded headers. Change the layer causing the failure, then retest before changing another.
4. If application SSL enforcement prevents access, back up and inspect the relevant configuration rows before changing them. Record the active shop context, shop and group identifiers, and any inherited configuration so you can identify the effective value.

SELECT id_configuration, name, value, id_shop_group, id_shop
FROM ps_configuration
WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE');

Use your actual prefix. Change only the intended configuration row or rows for the affected scope, and only keys used by that release. Avoid an unrestricted update across all shops. Keep the original values and a record of each change. Restore the secure configuration after fixing the cause, then test the affected shop and, in multistore, another shop sharing the installation.

An application-level change cannot remove web-server or CDN redirects, repair proxy headers, or clear browser HSTS state. Keep customer traffic out of an insecure recovery session. Clear cache through Advanced Parameters > Performance or the supported console command with the correct environment and application user. Reopen administration, place a test order and confirm its payment callback before admitting normal traffic. Reconcile any payments received during the incident before asking customers to retry.

Verify the result before adding HSTS

1. Check connection security and certificate status in the browser. The icon varies by browser and version.
2. Test home, product, category, CMS, login and checkout pages with a clear Console. Use the actual theme and enabled payment methods on desktop and mobile, covering the languages, currencies and shops you serve.
3. Check the full back office over HTTPS.
4. Test HTTP and HTTPS for every configured hostname of the affected shop, including www and non-www where applicable. Confirm alternate addresses redirect to that shop's chosen HTTPS hostname while preserving paths and query strings. The Apache example above redirects HTTP only; if an HTTPS alternate hostname remains accessible, configure its host redirect at the appropriate layer.
5. Complete a test payment, including its callback. Match the provider reference to the resulting order and expected status; retain the outcome for the person monitoring the switch.
6. Test certificate renewal, name the person responsible for renewal failures and inspect the deployment with a TLS checker such as SSL Labs.

curl -I https://example.com/
curl -I http://example.com/

HSTS instructs browsers to use HTTPS for a remembered period. Enable it after the site is stable, with a cautious lifetime. Add includeSubDomains or preload only after checking every affected hostname. HSTS makes an HTTP rollback ineffective in browsers that have remembered the policy.

For supported security-header controls in Security Revolution, use the module help page and confirm which controls your installed release provides.

What to ask your developer or agency

• Where does TLS terminate, which layer owns canonical redirects, and which proxy addresses does the application trust?
• Which shop-specific settings and integrations changed, and where are the staging and live test results?
• What restores access if administration fails, and what limits apply because of cached redirects or HSTS?
• Who monitors renewal, callback failures and new orders after the switch, and where are the recovery instructions?

Questions owners ask

Can HTTPS make a compromised shop safe?

HTTPS protects the connection to the hostname. It does not remove malicious code from your theme or modules; a compromised page can still send customers to a fraudulent payment form over HTTPS.

Why does a payment provider reject a callback when my browser opens the page?

The provider is a separate client. Check its delivery error, public certificate chain, endpoint authentication and response. A browser session may already be authenticated, while the provider receives a login page or challenge; a redirected notification may also behave differently from the original request.

Should I replace every HTTP link in my content?

Identify whether it is a loaded resource or an ordinary link to another site. Repair resources and your shop's canonical URLs as needed; do not rewrite unrelated external links blindly when their destination may not support HTTPS.

Can I keep the staging hostname after a successful rehearsal?

Use staging to prove the method, then apply the agreed settings for the live hostname. Check for staging addresses in content, module settings, feeds and callback URLs before reopening the live shop.