SSL und HTTPS in PrestaShop einrichten

Zuletzt aktualisiert: Juni 2026.

Hier ist der Teil einer SSL-Migration, der PrestaShop-Betreiber oft kalt erwischt: Das Zertifikat zu kaufen, sind die einfachen 10 %. Das Zertifikat ist in wenigen Minuten auf dem Server. Die anderen 90 %, also der Teil, der Shops tatsächlich beschädigt, passieren innerhalb von PrestaShop, wo SSL mit der Datenbank, dem URL-Rewriting, dem Cookie-Geltungsbereich und einem abgestuften Schalter SSL auf allen Seiten aktivieren verknüpft ist, der Sie aus Ihrem eigenen Admin-Bereich aussperren kann, wenn Sie ihn in der falschen Reihenfolge umlegen. In dieser Anleitung geht es um genau diese 90 %: HTTPS speziell in PrestaShop korrekt zu konfigurieren, mit den echten Backoffice-Pfaden, den exakten Konfigurationsschlüsseln und dem Rettungsweg, falls etwas schiefgeht.

Wenn Sie das größere Bild zur Absicherung eines Shops sehen möchten, Admin-Sicherheit, Server-Regeln, virtuelles Patching, ist das hier nur ein Punkt auf einer längeren Liste; beginnen Sie mit der PrestaShop-Checkliste zur Sicherheits-Härtung. Dieser Beitrag bleibt bewusst eng bei SSL und HTTPS.

Warum das für einen PrestaShop-Shop unverzichtbar ist

Sie wissen wahrscheinlich bereits, dass HTTPS die Verbindung verschlüsselt. In klaren geschäftlichen Worten ist es für einen Shop aus diesen Gründen Pflicht:

• Browser schrecken Ihre Kunden aktiv von HTTP ab. Chrome und Firefox kennzeichnen reine HTTP-Seiten in der Adressleiste als „Nicht sicher“, genau auf den Seiten, auf denen ein Kunde gleich seine Kartennummer eingeben soll. Das ist ein Conversion-Problem, nicht nur ein Sicherheitsproblem.
• Zahlungsintegrationen setzen es voraus. Stripe-, PayPal-, Mollie- und Adyen-Webhooks sowie Weiterleitungsabläufe gehen von HTTPS-Endpunkten aus. Ein halb konfiguriertes Zertifikat ist einer der stillen Gründe, warum ein Zahlungs-Callback ohne sichtbaren Fehler scheitert.
• Es ist ein Ranking-Signal und die Eintrittskarte zu HTTP/2. Google behandelt HTTPS seit 2014 als leichtgewichtigen Ranking-Faktor, und HTTP/2, das Seitenladezeiten durch Multiplexing tatsächlich beschleunigt, ist nur über HTTPS verfügbar. Der Schritt, der Ihren Shop sicherer macht, macht ihn also auch schneller.

Das „Und was heißt das konkret?“: Wenn Sie es richtig machen, verschwindet eine Browser-Warnung aus Ihrer Kasse, Ihre Zahlungs-Callbacks bleiben funktionsfähig und Sie schalten eine kostenlose Performance-Stufe frei. Wenn Sie es nur halb richtig machen, Zertifikat vorhanden, aber PrestaShop falsch konfiguriert, bekommen Sie Mixed-Content-Warnungen und defekte Layouts, die schlechter wirken als reines HTTP je wirkte.

Welches Zertifikat Sie wirklich kaufen sollten (Spoiler: wahrscheinlich keines)

SSL-Zertifikate gibt es in drei Validierungsstufen. Die Verschlüsselung ist bei allen drei identisch, der Preisunterschied bezahlt Prüfunterlagen, nicht stärkere Sicherheit.

Ein kostenloses Let's-Encrypt-DV-Zertifikat zeigt dem Browser eines Kunden dasselbe Schloss und bietet dieselbe Verschlüsselung wie ein EV-Zertifikat für 500 EUR. Sofern Sie kein regulierter B2B-Anbieter sind, dessen Käufer Zertifikatsdetails gezielt prüfen, nehmen Sie das kostenlose DV-Zertifikat und investieren Sie das Geld in Ihren Shop.

Schritt 1: Das Zertifikat auf Ihren Server bringen

Das passiert auf Hosting-Ebene, bevor PrestaShop überhaupt ins Spiel kommt. Wählen Sie den Weg, der zu Ihrer Umgebung passt.

• cPanel: Öffnen Sie SSL/TLS-Status und klicken Sie auf AutoSSL ausführen. Dadurch werden Let's-Encrypt-Zertifikate für jede Domain ausgestellt und installiert und alle 60–90 Tage automatisch verlängert.
• Plesk: Websites & Domains → SSL/TLS-Zertifikate → Installieren unter Let's Encrypt, und automatische Verlängerung aktivieren.
• VPS / dedizierter Server (Root-Zugriff): Installieren Sie Certbot. certbot --apache oder certbot --nginx holt das Zertifikat, passt Ihren vHost an und richtet einen Renewal-Cronjob bzw. Timer ein. Das ist der sauberste Weg, wenn Sie den Server kontrollieren.
• Cloudflare: Der kostenlose Tarif terminiert SSL am Cloudflare-Edge. Wichtiger Punkt unten, stellen Sie auf Full (Strict), niemals auf Flexible.

Eine Cloudflare-Falle ist eine eigene Erwähnung wert, weil sie PrestaShop-Shops besonders häufig trifft: Im Modus Flexible ist die Strecke Besucher zu Cloudflare verschlüsselt, die Strecke Cloudflare zu Ihrem Server aber reines HTTP. Das Schloss sieht gut aus, doch PrestaShop sieht eine HTTP-Anfrage, und genau diese Abweichung ist die häufigste Ursache für die Weiterleitungsschleife im Abschnitt zur Fehlerbehebung weiter unten. Verwenden Sie Full (Strict); dafür braucht Ihr Origin ein Zertifikat (auch ein kostenloses von Let's Encrypt reicht) und beide Strecken werden verschlüsselt.

Schritt 2: SSL in PrestaShop aktivieren, in der richtigen Reihenfolge

Wenn das Zertifikat auf dem Server aktiv ist, muss PrestaShop trotzdem noch angewiesen werden, es zu nutzen. Das ist der Schritt, bei dem sich viele aussperren, also gehen Sie bewusst vor.

Gehen Sie im Backoffice zu Shop-Parameter → Allgemein (PrestaShop 1.7, 8 und 9.x). Es gibt zwei Schalter, und die Reihenfolge ist wichtig:

• Setzen Sie SSL aktivieren auf Ja und speichern Sie. Dadurch liefert PrestaShop sensible Seiten (Login, Kasse, Kundenkonto) über HTTPS aus, während der Rest unverändert bleibt. Prüfen Sie, ob Backoffice und Kasse weiterhin laden.
• Erst danach setzen Sie SSL auf allen Seiten aktivieren auf Ja. Dadurch werden alle Frontoffice-URLs auf HTTPS gezwungen.

Warum dieser zweistufige Ablauf wichtig ist: Wenn Ihr Zertifikat oder Ihre Proxy-Konfiguration im Detail falsch ist und Sie beide Schalter gleichzeitig umlegen, kann PrestaShop den Admin-Bereich auf einen kaputten HTTPS-Endpunkt weiterleiten und Sie verlieren den Zugriff auf genau die Maske, in der Sie es rückgängig machen müssten. Wenn Sie die Schalter nacheinander aktivieren, zeigt der erste Schalter das Problem, während Sie das Backoffice noch erreichen können.

Wenn Sie sich trotzdem ausgesperrt haben

Diesen Rettungsweg sollte man kennen. Die beiden Schalter entsprechen zwei Zeilen in ps_configuration: PS_SSL_ENABLED und PS_SSL_ENABLED_EVERYWHERE. Öffnen Sie phpMyAdmin (oder Ihren bevorzugten DB-Client) und setzen Sie beide auf 0:

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

(Ersetzen Sie ps_ durch Ihr tatsächliches Tabellenpräfix.) Das deaktiviert die erzwungene SSL-Nutzung, stellt den Admin-Zugriff wieder her und lässt Sie das eigentliche Problem beheben, meist das weiter unten beschriebene Proxy-Header-Problem, bevor Sie es erneut versuchen. Leeren Sie anschließend den Cache (Inhalte von var/cache/ löschen), damit die Änderung greift.

Shop-URLs korrekt setzen

Gehen Sie zu Shop-Parameter → Traffic & SEO → SEO & URLs und verwenden Sie unten auf der Seite den Bereich Shop-URL festlegen (bei Multishop ist es die eigene Maske für Shop-URLs). Die Felder Shop-Domain und SSL-Domain sollten identisch sein, reine Hostnamen wie yourstore.com, und ohne http://- oder https://-Präfix und ohne abschließenden Schrägstrich. PrestaShop ergänzt das Protokoll selbst anhand der SSL-Schalter. Eine vollständige URL in diese Felder einzufügen, ist eine klassische Ursache für verdoppelte Adressen wie https://https//yourstore.com.

Schritt 3: Allen HTTP-Traffic auf HTTPS weiterleiten

Nachdem SSL in PrestaShop aktiviert ist, erzwingen Sie die Weiterleitung, bevor die Anwendung überhaupt Arbeit erledigt. Setzen Sie die Regel nahe an den Anfang der öffentlichen .htaccess, nachdem Sie sie in einer Staging-Umgebung getestet haben.

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

SSL „auf allen Seiten“ zu aktivieren, sorgt dafür, dass PrestaShop HTTPS-Links erzeugt, aber alte Lesezeichen, Backlinks und manuell eingegebene Adressen kommen weiterhin über HTTP an. Eine einzige kanonische HTTPS-Adresse, durch eine 301-Weiterleitung erzwungen, hält Kunden auf der verschlüsselten Version und verhindert, dass Suchmaschinen HTTP und HTTPS als doppelte Websites behandeln.

Der PrestaShop-spezifische Haken: PrestaShop besitzt seine .htaccess. Sobald jemand unter Shop-Parameter → Traffic & SEO → SEO & URLs auf .htaccess-Datei generieren klickt, wird die gesamte Datei neu geschrieben und alle manuell ergänzten Weiterleitungsregeln verschwinden. Die Weiterleitung selbst und der sichere Weg, Regeln so einzufügen, dass sie eine Neugenerierung überstehen, gehören zur Konfiguration auf Dateiebene, ausführlich behandelt in PrestaShop .htaccess: Sicherheits- und Performance-Regeln. Die saubereren Optionen, die das Regenerierungsproblem komplett umgehen:

• Cloudflare: Aktivieren Sie Always Use HTTPS unter SSL/TLS → Edge Certificates. Die Weiterleitung passiert am Edge, bevor die Anfrage Ihren Server überhaupt erreicht, schneller und immun gegen eine Neugenerierung der .htaccess.
• Nginx: ein Port-80-server-Block mit return 301 https://$host$request_uri;, Konfiguration, die PrestaShop nie anfasst.

Schritt 4: Mixed Content aufspüren (der Teil, der Layouts zerstört)

Mixed Content ist das Problem, mit dem Sie tatsächlich Zeit verbringen werden. Eine HTTPS-Seite, die ein Bild, Skript oder Stylesheet über http:// lädt, löst Browser-Warnungen aus, und moderne Browser blockieren gemischte Skripte komplett. Deshalb kann ein Shop direkt nach der Migration völlig unformatiert aussehen oder ein totes Zahlungsformular haben.

So finden Sie es: Öffnen Sie den Shop in Chrome, drücken Sie F12 und prüfen Sie den Tab Console auf Zeilen wie „Mixed Content: the page at https://… requested an insecure resource http://…“. Jede Zeile nennt die verursachende URL.

In PrestaShop konzentriert sich Mixed Content auf einige vorhersehbare Stellen:

• Fest codiertes http:// in der Datenbank. Produktbeschreibungen, Kategoriebeschreibungen und CMS-Seiten, in die jemand eine absolute http://-Bild-URL eingefügt hat. Das ist die häufigste Quelle.
• Modul-Assets. Ältere oder schlecht geschriebene Module, die CSS/JS mit einer expliziten http://-URL registrieren, statt PrestaShops $this->context->link / protokollbewusste Helfer zu verwenden. Aktualisieren Sie das Modul oder melden Sie es dem Entwickler.
• E-Mail-Templates. Bilder, die in Transaktions-E-Mails über HTTP referenziert werden, bearbeitet unter Design → E-Mail-Theme.
• Theme-Dateien. CSS-background-image- oder Font-URLs, die in den Stylesheets eines individuellen Themes fest auf http:// gesetzt sind.
• Drittanbieter-Einbettungen. Schriften, Analytics, Video- oder Social-Widgets, die über HTTP geladen werden.

Suchen und Ersetzen in der Datenbank

Für die Datenbanktreffer führen Sie nach einem Backup gezielte Updates aus. Die wichtigsten Felder liegen in ps_product_lang (description, description_short), ps_category_lang (description) und ps_cms_lang (content):

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

Wiederholen Sie das pro Feld und Tabelle. Die robuste langfristige Lösung sind künftig protokollrelative oder HTTPS-URLs im Inhalt; am saubersten ist es, absolute Domain-URLs in Beschreibungen gar nicht mehr einzufügen. Erstellen Sie vor jedem Massen-UPDATE immer ein Datenbank-Backup. Es gibt kein Rückgängig.

Schritt 5: Externe Dienste umstellen, die Sie noch für HTTP halten

Google behandelt http:// und https:// als getrennte Properties. Wenn Sie diesen Schritt bei der Migration überspringen, verschwinden Sie still aus Ihren eigenen Berichten. Arbeiten Sie diese Punkte ab:

• Google Search Console: Fügen Sie https://yourstore.com als neue Property hinzu, sie übernimmt die Historie der HTTP-Property nicht.
• Google Analytics / Merchant Center: Aktualisieren Sie die Property-/Website-URL auf https://; eine veraltete HTTP-Feed-URL im Merchant Center kann dazu führen, dass Produkte abgelehnt werden.
• Sitemap: Generieren Sie sie neu, damit jeder Eintrag HTTPS verwendet. Wenn Sie ein Sitemap-Modul nutzen, regenerieren Sie die Sitemap über das Modul statt über das Core-Tool. Unser eigenes mypresta.rocks-Sitemap-Modul übernimmt das Protokoll automatisch aus Ihren SSL-Einstellungen. Nach dem Aktivieren von SSL erzeugt eine Neugenerierung daher saubere HTTPS-URLs ohne manuelle Bearbeitung. Eine Sache weniger, an die Sie denken müssen.
• Zahlungs-Webhooks: Aktualisieren Sie die Benachrichtigungs-URLs in den Dashboards Ihrer Anbieter, PayPal IPN, Stripe-Webhook-Endpunkt, Mollie-Webhook, auf https://. Ein übrig gebliebener HTTP-Webhook ist ein stiller Fehler beim Bestellstatus.

Schritt 6: Prüfen, nicht vermuten

Gehen Sie diese Checkliste durch, bevor Sie die Aufgabe als erledigt betrachten:

• Startseite über HTTPS zeigt ein sauberes Schloss ohne Warnungen.
• Produkt-, Kategorie- und CMS-Seiten, Console frei von Mixed Content.
• Ein vollständiger Testkauf läuft über HTTPS durch, inklusive Zahlungs-Callback.
• Jede Backoffice-Seite lädt über HTTPS.
• Die Eingabe von http://yourstore.com leitet per 301 auf https:// weiter.
• Ein kanonischer Host, www oder non-www, nicht beide auflösbar.
• Führen Sie den kostenlosen SSL Labs Server Test aus (ssllabs.com/ssltest); Ziel ist A oder A+.

Die drei Fehler, die für die meisten „HTTPS hat meinen Shop kaputtgemacht“-Tickets verantwortlich sind

Endlose Weiterleitungsschleife

Der Klassiker. Ihr Hoster oder Cloudflare terminiert SSL vorgelagert und leitet die Anfrage als reines HTTP an PrestaShop weiter. PrestaShop sieht HTTP, leitet auf HTTPS um, der Proxy gibt die Anfrage wieder als HTTP zurück, endlos. Die Lösung ist, PrestaShop den X-Forwarded-Proto-Header des Proxys vertrauen zu lassen, damit es erkennt, dass die ursprüngliche Anfrage HTTPS war. Speziell bei Cloudflare löst der Wechsel von Flexible zu Full (Strict) das Problem direkt. Bei anderen Reverse Proxies müssen Sie den Forwarded-Proto-Header eventuell auf Webserver- oder .htaccess-Ebene berücksichtigen.

Shop lädt ohne Styling / Zahlungsformular ist tot

Fast immer blockierter Mixed Content, ein Stylesheet oder Skript, das der Browser auf einer HTTPS-Seite nicht über HTTP laden wollte. Zurück zu Schritt 4: Console lesen, die http://-Ressource finden, Quelle korrigieren.

Bilder sind nach der Migration verschwunden

Produkt- oder CMS-Bilder mit fest codierten http://-URLs oder ein Bild-CDN, das kein HTTPS ausliefert. Suchen und Ersetzen in der Datenbank aus Schritt 4 behebt Ersteres; für Letzteres prüfen Sie, ob Ihr CDN bzw. Bildhost HTTPS unterstützt.

Ein Hinweis zum nächsten Schritt

Wenn HTTPS sauber läuft und geprüft ist, ist der natürliche nächste Schritt HSTS (HTTP Strict Transport Security). Damit weisen Sie Browser an, HTTP für Ihre Domain vollständig abzulehnen. Das ist wirksam und ein wenig riskant, ein zu langer max-age-Wert auf einer falsch konfigurierten Website kann die Domain unerreichbar machen, deshalb gehört HSTS zur übrigen Härtung der Security-Header und nicht hier hineingequetscht. Wir behandeln HSTS, Security-Header und weitere Regeln auf Server-Ebene im .htaccess-Leitfaden zu Sicherheit und Performance, und SSL ist Teil des größeren Programms in der vollständigen Härtungs-Checkliste. Wenn Sie das Ganze zuerst ohne Fachjargon erklärt haben möchten, ist die einfach verständliche Anleitung zur Absicherung Ihres Shops der sanftere Einstieg.

SSL in PrestaShop ist nicht schwer, verzeiht aber weder eine falsche Reihenfolge noch die Eigenheiten der Plattform: Aktivieren Sie die Schalter nacheinander, kennen Sie den ps_configuration-Rettungsweg, bevor Sie ihn brauchen, rechnen Sie damit, dass die Datenbank noch ein paar letzte http://-URLs versteckt, und prüfen Sie mit der Console statt nur mit dem Auge. Dann ist der Nutzen sofort sichtbar, kein „Nicht sicher“ mehr in Ihrer Kasse, Zahlungs-Callbacks, die ausgelöst werden, und HTTP/2-Geschwindigkeit ohne Aufpreis. Machen Sie es zum Projekt dieser Woche; es ist einer der wertvollsten Nachmittage, die Sie in Ihren Shop investieren können.

Häufig gestellte Fragen

Ich habe SSL aktiviert und jetzt leitet das Backoffice endlos weiter, wie komme ich wieder hinein?

Das ist die Weiterleitungsschleife, und fast immer steckt ein Proxy dahinter, der PrestaShop eine reine HTTP-Anfrage liefert, während die Strecke Browser zu Edge HTTPS ist. Die schnelle Rettung ist, die erzwungene Nutzung in der Datenbank zu deaktivieren: UPDATE ps_configuration SET value = 0 WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE'); (ersetzen Sie das Tabellenpräfix), danach leeren Sie den Cache, indem Sie var/cache/ leeren. Das stellt den Admin-Zugriff wieder her. Bevor Sie SSL erneut aktivieren, beheben Sie die eigentliche Ursache, bei Cloudflare von Flexible auf Full (Strict) wechseln; bei einem anderen Reverse Proxy muss PrestaShop den X-Forwarded-Proto-Header berücksichtigen, damit es erkennt, dass die ursprüngliche Anfrage HTTPS war.

Ist ein kostenloses Let's-Encrypt-Zertifikat wirklich so sicher wie ein bezahltes?

Für die Verschlüsselung: ja, identisch. Ein DV-Zertifikat von Let's Encrypt gibt dem Browser des Besuchers dasselbe Schloss und dieselbe TLS-Verschlüsselung wie ein EV-Zertifikat für 500 EUR. Der Preis von OV und EV bezahlt Validierungsunterlagen (die rechtliche Identität Ihres Unternehmens wird geprüft), keine stärkere Kryptografie, und Browser haben die grüne Leiste mit dem Unternehmensnamen entfernt, die der einzige sichtbare Vorteil von EV war. Sofern Sie kein regulierter B2B-Anbieter sind, dessen Käufer Zertifikatsdetails gezielt prüfen, nehmen Sie das kostenlose DV-Zertifikat.

Mein Shop lädt nach der Umstellung auf HTTPS ohne Styling oder das Zahlungsformular ist tot, warum?

Fast immer blockierter Mixed Content: Eine HTTPS-Seite lädt ein Stylesheet oder Skript über http://, und moderne Browser verweigern unsichere Skripte auf einer sicheren Seite. Öffnen Sie den Shop in Chrome, drücken Sie F12 und lesen Sie den Tab Console, jede „Mixed Content“-Zeile nennt die betroffene http://-URL. Die üblichen Verursacher sind absolute http://-Links, die in Produkt- oder CMS-Inhalte eingefügt wurden (nach einem Backup per Suchen und Ersetzen in der Datenbank beheben), ältere Module, die Assets mit fest codiertem Protokoll registrieren, und Stylesheets individueller Themes. Beheben Sie die Quelle, nicht das Symptom.

Warum muss ich die beiden SSL-Schalter nacheinander aktivieren?

Weil die Reihenfolge Ihr Sicherheitsnetz ist. SSL aktivieren (PS_SSL_ENABLED) erzwingt HTTPS nur auf sensiblen Seiten, Login, Kasse, Kundenkonto, sodass ein fehlerhaftes Zertifikat oder ein falsch konfigurierter Proxy auffällt, während Sie das Backoffice noch erreichen können. Erst wenn Sie bestätigt haben, dass Admin-Bereich und Kasse weiterhin laden, setzen Sie SSL auf allen Seiten aktivieren (PS_SSL_ENABLED_EVERYWHERE). Legen Sie beide Schalter bei kaputter Konfiguration gleichzeitig um, kann PrestaShop den Admin-Bereich auf einen toten HTTPS-Endpunkt weiterleiten, und Sie aus genau der Maske aussperren, in der Sie es rückgängig machen müssten.

Muss ich nach der Umstellung auf HTTPS etwas in der Google Search Console tun?

Ja. Google behandelt http:// und https:// als getrennte Properties. Fügen Sie daher https://yourstore.com als neue Property hinzu, sie übernimmt die Historie der HTTP-Version nicht. Aktualisieren Sie auch Ihre Analytics- und Merchant-Center-URLs auf HTTPS (eine veraltete HTTP-Feed-URL im Merchant Center kann dazu führen, dass Produkte abgelehnt werden), generieren Sie Ihre Sitemap neu, damit jeder Eintrag HTTPS nutzt, und stellen Sie Zahlungs-Webhooks (PayPal IPN, Stripe, Mollie) auf den HTTPS-Endpunkt um. Ein übrig gebliebener HTTP-Webhook ist ein stiller Fehler beim Bestellstatus.

Sollte ich HSTS sofort aktivieren?

Nicht als ersten Schritt. HSTS weist Browser an, HTTP für Ihre Domain vollständig abzulehnen, was gut ist, aber ein zu langer max-age-Wert auf einer Website, die noch nicht vollständig sauber ist, kann die Domain unerreichbar machen. Außerdem lässt sich die Direktive schwer zurücknehmen, weil Browser sie zwischenspeichern. Prüfen Sie HTTPS zuerst Ende zu Ende (saubere Console, funktionierende Kasse, 301 von HTTP, A/A+ im SSL-Labs-Test), und ergänzen Sie HSTS dann zusammen mit der übrigen Härtung Ihrer Security-Header statt während der Migration selbst.