Jak skonfigurować SSL i HTTPS w PrestaShop

Ostatnia aktualizacja: czerwiec 2026.

Oto etap migracji SSL, który zaskakuje właścicieli sklepów PrestaShop: zakup certyfikatu to proste 10% pracy. Certyfikat trafia na serwer w kilka minut. Pozostałe 90% — część, która naprawdę potrafi zepsuć sklep — dzieje się wewnątrz PrestaShop, gdzie SSL jest powiązany z bazą danych, mechanizmem przepisywania adresów URL, zakresem plików cookie oraz dwuetapowym przełącznikiem Włącz SSL na wszystkich stronach, który przy użyciu w złej kolejności może odciąć Cię od własnego panelu administracyjnego. Ten poradnik dotyczy właśnie tych 90%: poprawnej konfiguracji HTTPS konkretnie w PrestaShop, z realnymi ścieżkami w panelu administracyjnym, dokładnymi kluczami konfiguracji i sposobem odzyskania dostępu, gdy coś pójdzie nie tak.

Jeśli chcesz spojrzeć szerzej na zabezpieczenie sklepu — bezpieczeństwo panelu administracyjnego, reguły serwera, wirtualne łatanie luk — to jest tylko jeden punkt na dłuższej liście; zacznij od listy kontrolnej wzmacniania bezpieczeństwa PrestaShop. Ten artykuł skupia się wyłącznie na SSL i HTTPS.

Dlaczego w sklepie PrestaShop nie da się tego pominąć

Prawdopodobnie już wiesz, że HTTPS szyfruje połączenie. Powody, dla których jest obowiązkowy w sklepie, w prostych kategoriach biznesowych:

• Przeglądarki aktywnie zniechęcają klientów do HTTP. Chrome i Firefox oznaczają zwykłe strony HTTP jako "Niezabezpieczone" w pasku adresu — dokładnie na tych stronach, na których klient ma wpisać numer karty. To problem konwersji, nie tylko bezpieczeństwa.
• Integracje płatności tego wymagają. Webhooki i przepływy przekierowań Stripe, PayPal, Mollie i Adyen zakładają punkty końcowe HTTPS. Częściowo skonfigurowany certyfikat to jeden z cichych powodów, dla których wywołanie zwrotne płatności kończy się bez widocznego błędu.
• To sygnał rankingowy i warunek wejścia w HTTP/2. Google traktuje HTTPS jako lekki czynnik rankingowy od 2014 roku, a HTTP/2 — które realnie przyspiesza ładowanie stron dzięki multipleksowaniu — jest dostępne tylko przez HTTPS. Ten sam krok, który zwiększa bezpieczeństwo, poprawia też szybkość.

Co z tego wynika? Poprawna konfiguracja usuwa ostrzeżenie przeglądarki z finalizacji zakupu, utrzymuje przy życiu wywołania zwrotne płatności i odblokowuje darmową warstwę wydajności. Konfiguracja zrobiona połowicznie — certyfikat jest, ale PrestaShop jest ustawiony źle — daje ostrzeżenia o mieszanej zawartości i zepsute układy stron, które wyglądają gorzej niż zwykłe HTTP.

Jaki certyfikat naprawdę kupić (spoiler: prawdopodobnie żadnego)

Certyfikaty SSL występują w trzech poziomach walidacji. Szyfrowanie jest identyczne we wszystkich trzech — różnica w cenie kupuje formalności weryfikacyjne, a nie mocniejsze bezpieczeństwo.

Bezpłatny certyfikat DV od Let's Encrypt daje przeglądarce klienta dokładnie tę samą kłódkę i dokładnie takie samo szyfrowanie jak certyfikat EV za 500 EUR. Jeśli nie prowadzisz regulowanej działalności B2B, w której kupujący konkretnie sprawdzają szczegóły certyfikatu, wybierz darmowy DV, a pieniądze przeznacz na sklep.

Krok 1: Zainstaluj certyfikat na serwerze

To dzieje się na poziomie hostingu, zanim PrestaShop w ogóle wejdzie do gry. Wybierz ścieżkę pasującą do Twojej konfiguracji.

• cPanel: otwórz SSL/TLS Status i kliknij Run AutoSSL. Narzędzie wystawi i zainstaluje certyfikaty Let's Encrypt dla każdej domeny oraz będzie je automatycznie odnawiać w cyklu 60–90 dni.
• Plesk: Websites & Domains → SSL/TLS Certificates → Install w sekcji Let's Encrypt, a następnie zaznacz automatyczne odnawianie.
• VPS / serwer dedykowany (dostęp root): zainstaluj Certbota. certbot --apache albo certbot --nginx pobierze certyfikat, zmodyfikuje vhost i doda zadanie cron/timer do odnawiania. To najczystsza droga, jeśli kontrolujesz maszynę.
• Cloudflare: darmowy plan kończy SSL na brzegu sieci Cloudflare. Kluczowy szczegół poniżej — ustaw tryb Full (Strict), nigdy Flexible.

Warto jasno nazwać jedną pułapkę Cloudflare, bo szczególnie często uderza w sklepy PrestaShop: w trybie Flexible odcinek od odwiedzającego do Cloudflare jest szyfrowany, ale odcinek od Cloudflare do Twojego serwera idzie zwykłym HTTP. Kłódka wygląda poprawnie, ale PrestaShop widzi żądanie HTTP, a ta niespójność jest najczęstszą przyczyną pętli przekierowań opisanej niżej w sekcji rozwiązywania problemów. Użyj Full (Strict), który wymaga certyfikatu na serwerze źródłowym (może być darmowy Let's Encrypt) i szyfruje oba odcinki.

Krok 2: Włącz SSL w PrestaShop — we właściwej kolejności

Gdy certyfikat działa już na serwerze, PrestaShop nadal musi dostać informację, żeby go używać. To właśnie ten krok potrafi odciąć dostęp do panelu, więc wykonaj go świadomie.

Przejdź do Parametry sklepu → Ogólne w panelu administracyjnym (PrestaShop 1.7, 8 i 9.x). Są tam dwa przełączniki, a kolejność ma znaczenie:

• Ustaw Włącz SSL na Tak i zapisz. Dzięki temu PrestaShop zacznie serwować wrażliwe strony (logowanie, finalizację zakupu, konto klienta) przez HTTPS, zostawiając resztę bez zmian. Sprawdź, czy panel administracyjny i finalizacja zakupu nadal się ładują.
• Dopiero potem ustaw Włącz SSL na wszystkich stronach na Tak. To wymusi HTTPS dla każdego adresu URL w sklepie.

Skąd ta dwuetapowa ostrożność: jeśli certyfikat albo konfiguracja proxy są subtelnie błędne i włączysz oba ustawienia naraz, PrestaShop może zacząć przekierowywać panel administracyjny na niedziałający punkt końcowy HTTPS, a Ty stracisz dostęp do ekranu potrzebnego do cofnięcia zmiany. Włączanie ich po kolei sprawia, że pierwszy przełącznik ujawnia problem wtedy, gdy nadal możesz wejść do panelu.

Jeśli mimo wszystko odciąłeś sobie dostęp

To procedura awaryjna, którą warto zapamiętać. Dwa przełączniki odpowiadają dwóm wierszom w ps_configuration: PS_SSL_ENABLED i PS_SSL_ENABLED_EVERYWHERE. Otwórz phpMyAdmin (albo wybranego klienta bazy danych) i ustaw oba na 0:

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

(Zamień ps_ na swój rzeczywisty prefiks tabel.) To wyłącza wymuszanie SSL, przywraca dostęp do panelu administracyjnego i pozwala naprawić prawdziwy problem — zwykle nagłówek proxy omówiony niżej — zanim spróbujesz ponownie. Następnie wyczyść pamięć podręczną (usuń zawartość var/cache/), aby zmiana zaczęła działać.

Poprawnie ustaw adresy URL sklepu

Przejdź do Parametry sklepu → Ruch & SEO → SEO & adresy URL i użyj panelu Ustaw adres URL sklepu na dole tej strony (w multistore służy do tego osobny ekran adresów URL sklepu). Pola Domena sklepu i Domena SSL powinny być identyczne — same nazwy hostów, np. yourstore.com, bez prefiksu http:// lub https:// i bez końcowego ukośnika. PrestaShop sam dodaje protokół na podstawie przełączników SSL. Wklejenie pełnego adresu URL do tych pól to klasyczna przyczyna podwojonych adresów, takich jak https://https//yourstore.com.

Krok 3: Przekieruj cały ruch HTTP na HTTPS

Po włączeniu SSL w PrestaShop wymuś przekierowanie, zanim aplikacja wykona jakąkolwiek pracę. Umieść regułę blisko początku publicznego pliku .htaccess, po wcześniejszym przetestowaniu jej na środowisku testowym.

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

Włączenie SSL "na wszystkich stronach" sprawia, że PrestaShop generuje linki HTTPS, ale stare zakładki, linki zewnętrzne i adresy wpisywane ręcznie nadal trafiają przez HTTP. Jeden kanoniczny adres HTTPS — wymuszony przekierowaniem 301 — utrzymuje klientów na szyfrowanej wersji i nie pozwala wyszukiwarkom traktować HTTP i HTTPS jako duplikatów sklepu.

Pułapka specyficzna dla PrestaShop: PrestaShop zarządza swoim plikiem .htaccess. Wystarczy, że ktoś kliknie Wygeneruj plik .htaccess w Parametry sklepu → Ruch & SEO → SEO & adresy URL, a cały plik zostanie przepisany i ręcznie dodane reguły przekierowań znikną. Samo przekierowanie oraz bezpieczny sposób dodawania reguł odpornych na regenerację należą do konfiguracji na poziomie pliku — szczegółowo omawiamy to w artykule PrestaShop .htaccess: reguły bezpieczeństwa i wydajności. Czystsze opcje, które całkowicie omijają problem regeneracji:

• Cloudflare: włącz Always Use HTTPS w SSL/TLS → Edge Certificates. Przekierowanie odbywa się na brzegu sieci, zanim żądanie w ogóle dotrze do Twojego serwera — szybciej i bez ryzyka, że regeneracja .htaccess je usunie.
• Nginx: blok server na porcie 80 wykonujący return 301 https://$host$request_uri; — konfiguracja, której PrestaShop nigdy nie dotyka.

Krok 4: Znajdź mieszaną zawartość (część, która psuje układy stron)

Mieszana zawartość to problem, na którym naprawdę spędzisz czas. Strona HTTPS, która pobiera obraz, skrypt albo arkusz stylów przez http://, wywołuje ostrzeżenia przeglądarki — a nowoczesne przeglądarki wprost blokują mieszane skrypty, dlatego sklep tuż po migracji może wyglądać jak pozbawiony stylów albo mieć martwy formularz płatności.

Jak to znaleźć: otwórz sklep w Chrome, naciśnij F12 i sprawdź kartę Konsola pod kątem wierszy w rodzaju "Mixed Content: the page at https://… requested an insecure resource http://…". Każdy taki komunikat wskazuje problematyczny adres URL.

W PrestaShop mieszana zawartość zwykle skupia się w kilku przewidywalnych miejscach:

• Zakodowane na sztywno http:// w bazie danych. Opisy produktów, opisy kategorii i strony CMS, w których ktoś wkleił bezwzględny adres obrazu z http://. To najczęstsze źródło.
• Zasoby modułów. Starsze albo słabo napisane moduły, które rejestrują CSS/JS z jawnym adresem http://, zamiast używać $this->context->link PrestaShop lub helperów świadomych protokołu. Zaktualizuj moduł albo zgłoś problem jego deweloperowi.
• Szablony wiadomości e-mail. Obrazy odwołujące się do HTTP w wiadomościach transakcyjnych, edytowanych w Wygląd → Motyw wiadomości e-mail.
• Pliki motywu. Adresy CSS background-image albo adresy fontów wpisane na sztywno jako http:// w arkuszach stylów własnego motywu.
• Osadzenia zewnętrzne. Fonty, analityka, wideo albo widgety społecznościowe pobierane przez HTTP.

Wyszukiwanie i zamiana w bazie danych

Dla wpisów z bazy danych wykonaj ukierunkowane aktualizacje po zrobieniu kopii zapasowej. Najważniejsze pola znajdują się w ps_product_lang (description, description_short), ps_category_lang (description) oraz ps_cms_lang (content):

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

Powtórz to dla każdego pola i tabeli. Solidnym rozwiązaniem długoterminowym są adresy względne względem protokołu albo adresy HTTPS w treści od teraz; najczyściej jest po prostu przestać wklejać do opisów bezwzględne adresy z domeną. Zawsze wykonaj kopię zapasową bazy danych przed jakimkolwiek masowym UPDATE — nie ma tu przycisku cofania.

Krok 5: Przestaw usługi zewnętrzne, które nadal myślą, że jesteś na HTTP

Google traktuje http:// i https:// jako osobne usługi, więc migracja pomijająca ten krok po cichu wyrzuca Cię z własnych raportów. Przejdź przez:

• Google Search Console: dodaj https://yourstore.com jako nową usługę — nie dziedziczy historii z wersji HTTP.
• Google Analytics / Merchant Center: zaktualizuj adres URL usługi/strony do https://; nieaktualny adres pliku produktowego HTTP w Merchant Center może spowodować odrzucenie produktów.
• Mapa strony: wygeneruj ją ponownie, aby każdy wpis był w HTTPS. Jeśli używasz modułu mapy strony, generuj ją przez moduł, a nie przez narzędzie rdzenia. Nasz własny moduł mapy strony mypresta.rocks automatycznie pobiera protokół z Twoich ustawień SSL, więc ponowne wygenerowanie po włączeniu SSL tworzy czyste adresy HTTPS bez ręcznej edycji — jedna rzecz mniej do pamiętania.
• Webhooki płatności: zaktualizuj adresy powiadomień w panelach dostawców — PayPal IPN, punkt końcowy webhooka Stripe, webhook Mollie — na https://. Pozostawiony webhook HTTP to cicha awaria statusu zamówienia.

Krok 6: Zweryfikuj, nie zakładaj

Przejdź tę listę kontrolną, zanim uznasz temat za zakończony:

• Strona główna przez HTTPS pokazuje czystą kłódkę, bez ostrzeżeń.
• Strony produktów, kategorii i CMS — Konsola bez ostrzeżeń o mieszanej zawartości.
• Pełne testowe przejście finalizacji zakupu kończy się przez HTTPS, łącznie z wywołaniem zwrotnym płatności.
• Każda strona panelu administracyjnego ładuje się przez HTTPS.
• Wpisanie http://yourstore.com przekierowuje 301 na https://.
• Jeden host kanoniczny — www albo bez www, ale nie oba działające równolegle.
• Uruchom bezpłatny test serwera SSL Labs (ssllabs.com/ssltest); celuj w ocenę A lub A+.

Trzy awarie odpowiadające za większość zgłoszeń typu "HTTPS zepsuł mój sklep"

Nieskończona pętla przekierowań

Klasyka. Hosting albo Cloudflare kończy SSL wyżej w ścieżce i przekazuje żądanie do PrestaShop jako zwykłe HTTP. PrestaShop widzi HTTP, przekierowuje na HTTPS, proxy oddaje mu żądanie z powrotem jako HTTP — i tak bez końca. Naprawa polega na tym, żeby PrestaShop ufał nagłówkowi proxy X-Forwarded-Proto i rozpoznawał, że pierwotne żądanie było HTTPS. W samym Cloudflare przełączenie z Flexible na Full (Strict) rozwiązuje to od razu. Na innych reverse proxy może być konieczne obsłużenie nagłówka forwarded-proto na poziomie serwera WWW albo .htaccess.

Sklep ładuje się bez stylów / formularz płatności nie działa

Prawie zawsze chodzi o zablokowaną mieszaną zawartość — arkusz stylów albo skrypt, którego przeglądarka odmówiła wczytania przez HTTP na stronie HTTPS. Wróć do kroku 4: odczytaj Konsolę, znajdź zasób http:// i napraw jego źródło.

Obrazy zniknęły po migracji

Obrazy produktów albo CMS z wpisanymi na sztywno adresami http://, ewentualnie CDN obrazów, który nie obsługuje HTTPS. Wyszukiwanie i zamiana w bazie danych z kroku 4 rozwiązuje pierwszy przypadek; dla drugiego potwierdź, że Twój CDN/host obrazów obsługuje HTTPS.

Uwaga o dalszych krokach

Gdy HTTPS jest czysty i zweryfikowany, naturalnym następnym krokiem jest HSTS (HTTP Strict Transport Security), który mówi przeglądarkom, żeby całkowicie odmawiały HTTP dla Twojej domeny. To mechanizm mocny i trochę niebezpieczny — zbyt długi max-age na źle skonfigurowanej stronie może sprawić, że domena stanie się nieosiągalna — dlatego powinien być wdrażany razem z pozostałym utwardzaniem nagłówków bezpieczeństwa, a nie wciskany tutaj. HSTS, nagłówki bezpieczeństwa i inne reguły serwerowe omawiamy w poradniku bezpieczeństwa i wydajności .htaccess, a SSL jest częścią szerszego programu w kompletnej liście kontrolnej utwardzania. Jeśli wolisz najpierw wyjaśnienie całego tematu bez żargonu, łagodniejszym wejściem będzie prosty poradnik zabezpieczania sklepu.

SSL w PrestaShop nie jest trudny, ale nie wybacza złej kolejności ani ignorowania specyfiki platformy: włączaj przełączniki po jednym, poznaj procedurę awaryjną z ps_configuration, zanim będzie potrzebna, zakładaj, że baza danych ukryje ostatnie kilka adresów http://, i weryfikuj Konsolę, a nie tylko wygląd strony. Zrób to, a korzyść będzie natychmiastowa — brak "Niezabezpieczone" przy finalizacji zakupu, działające wywołania zwrotne płatności i darmowa szybkość HTTP/2. Zrób z tego projekt na ten tydzień; to jedno z najbardziej wartościowych popołudni, jakie możesz poświęcić sklepowi.

Najczęściej zadawane pytania

Włączyłem SSL i teraz panel administracyjny przekierowuje w nieskończoność — jak odzyskać dostęp?

To pętla przekierowań i prawie zawsze oznacza proxy, które podaje PrestaShop zwykłe żądanie HTTP, podczas gdy odcinek od przeglądarki do brzegu sieci jest HTTPS. Szybka procedura awaryjna to wyłączenie wymuszania w bazie danych: UPDATE ps_configuration SET value = 0 WHERE name IN ('PS_SSL_ENABLED', 'PS_SSL_ENABLED_EVERYWHERE'); (podmień prefiks tabeli), a potem wyczyszczenie pamięci podręcznej przez opróżnienie var/cache/. To przywraca dostęp do panelu administracyjnego. Przed ponownym włączeniem napraw prawdziwą przyczynę — w Cloudflare przełącz Flexible na Full (Strict); przy innym reverse proxy spraw, aby PrestaShop uwzględniał nagłówek X-Forwarded-Proto i rozpoznawał, że pierwotne żądanie było HTTPS.

Czy darmowy certyfikat Let's Encrypt naprawdę jest tak samo bezpieczny jak płatny?

Pod względem szyfrowania tak — identyczny. Certyfikat DV od Let's Encrypt daje przeglądarce odwiedzającego tę samą kłódkę i takie samo szyfrowanie TLS jak certyfikat EV za 500 EUR. Cena OV i EV kupuje formalności weryfikacyjne (sprawdzenie prawnej tożsamości firmy), a nie mocniejszą kryptografię, a przeglądarki usunęły zielony pasek z nazwą firmy, który był jedyną widoczną zaletą EV. Jeśli nie prowadzisz regulowanej działalności B2B, w której kupujący konkretnie sprawdzają szczegóły certyfikatu, wybierz darmowy DV.

Po przełączeniu na HTTPS sklep ładuje się bez stylów albo formularz płatności nie działa — dlaczego?

Prawie zawsze przyczyną jest zablokowana mieszana zawartość: strona HTTPS pobiera arkusz stylów albo skrypt przez http://, a nowoczesne przeglądarki odmawiają ładowania niezabezpieczonych skryptów na zabezpieczonej stronie. Otwórz sklep w Chrome, naciśnij F12 i sprawdź kartę Konsola — każdy wiersz "Mixed Content" wskazuje problematyczny adres URL http://. Typowe źródła to bezwzględne linki http:// wklejone do treści produktów lub CMS (naprawiane wyszukiwaniem i zamianą w bazie po kopii zapasowej), starsze moduły rejestrujące zasoby z protokołem wpisanym na sztywno oraz arkusze stylów własnego motywu. Napraw źródło, nie objaw.

Dlaczego muszę włączać dwa przełączniki SSL po jednym?

Bo kolejność jest Twoją siatką bezpieczeństwa. Włącz SSL (PS_SSL_ENABLED) wymusza HTTPS tylko na wrażliwych stronach — logowaniu, finalizacji zakupu, koncie klienta — więc jeśli certyfikat albo proxy są subtelnie błędne, problem wyjdzie na jaw, gdy nadal możesz dostać się do panelu administracyjnego. Dopiero po potwierdzeniu, że panel i finalizacja zakupu nadal się ładują, ustaw Włącz SSL na wszystkich stronach (PS_SSL_ENABLED_EVERYWHERE). Włączenie obu naraz przy zepsutej konfiguracji może sprawić, że PrestaShop zacznie przekierowywać panel administracyjny na martwy punkt końcowy HTTPS — odcinając Cię od dokładnie tego ekranu, na którym można to cofnąć.

Czy po przełączeniu na HTTPS muszę coś zrobić w Google Search Console?

Tak. Google traktuje http:// i https:// jako osobne usługi, więc dodaj https://yourstore.com jako nową usługę — nie odziedziczy historii wersji HTTP. Zaktualizuj też adresy URL w Analytics i Merchant Center do HTTPS (nieaktualny adres pliku produktowego HTTP w Merchant Center może spowodować odrzucenie produktów), wygeneruj ponownie mapę strony, aby każdy wpis był HTTPS, i przestaw webhooki płatności (PayPal IPN, Stripe, Mollie) na punkt końcowy HTTPS. Pozostawiony webhook HTTP to cicha awaria statusu zamówienia.

Czy od razu włączyć HSTS?

Nie jako pierwszy krok. HSTS mówi przeglądarkom, żeby całkowicie odmawiały HTTP dla Twojej domeny, co jest dobre — ale zbyt długi max-age ustawiony na stronie, która nie jest jeszcze w pełni czysta, może uczynić domenę nieosiągalną, a dyrektywę trudno wycofać, bo przeglądarki ją buforują. Najpierw zweryfikuj HTTPS od początku do końca (czysta Konsola, działająca finalizacja zakupu, 301 z HTTP, ocena A/A+ w teście SSL Labs), a dopiero potem dodaj HSTS razem z pozostałym utwardzaniem nagłówków bezpieczeństwa, nie w trakcie samej migracji.