Problemy z SSL w WordPress – HTTPS, mixed content, Let's Encrypt 2026

Czerwony komunikat "Not secure" w Chrome to nie kosmetyka – to bezpośredni cios w konwersję i pozycje. Google oficjalnie potwierdziło SSL jako ranking factor w sierpniu 2014, a od lipca 2018 Chrome oznacza wszystkie strony bez HTTPS jako niebezpieczne. W 2026 Chrome agresywnie blokuje formularze HTTP – użytkownik dostaje pełnoekranowe ostrzeżenie przed wpisaniem danych. Dla sklepu internetowego to wyrok.

Realne dane z moich audytów (2025–2026):

• Strony bez SSL mają średnio 38% wyższy bounce rate niż konkurencja z HTTPS
• Konwersja formularza kontaktowego na HTTP spada o 24–60% vs HTTPS (zależnie od branży)
• Sklepy bez SSL praktycznie nie istnieją w Google Shopping i Merchant Center
• Reklamy Google Ads na URL HTTP mają niższy Quality Score o 1–2 punkty

Sygnał "Not secure" pojawia się, gdy strona ładuje się przez HTTP, gdy certyfikat wygasł, gdy nazwa domeny w certyfikacie nie pasuje do URL, lub gdy strona miesza HTTPS z zasobami HTTP (mixed content). Każdy z tych przypadków wymaga innego podejścia – dlatego diagnozę robimy zawsze przed naprawą.

Jeśli po świeżej instalacji SSL nadal widzisz "Not secure", sprawdź problemy z hostingiem i problemy z domeną – to dwa najczęstsze źródła błędów konfiguracyjnych SSL na poziomie infrastruktury.

Diagnozę zaczynam zawsze od trzech narzędzi w tej kolejności: SSL Labs (najbardziej szczegółowo), Chrome DevTools (najszybciej), openssl (kiedy nic innego nie działa). To moja stała procedura przy każdym audycie sklepu lub migracji.

Krok 1 – SSL Labs (ssllabs.com/ssltest):

Wpisujesz domenę, czekasz 2 minuty, dostajesz pełen raport. Ocena A lub A+ to standard 2026, B akceptowalne, C lub niżej – natychmiastowa naprawa. SSL Labs sprawdza wersję protokołu (TLS 1.2 minimum, TLS 1.3 preferowane), siłę szyfrów, łańcuch certyfikatów, HSTS, certyfikat OCSP stapling.

Krok 2 – Chrome DevTools (F12 → Security):

Otwierasz stronę, naciskasz F12, klikasz zakładkę Security. Widzisz status certyfikatu, wystawcę, daty ważności, mixed content warnings. Czerwone wpisy w konsoli z prefiksem "Mixed Content" wskazują dokładnie, który zasób ładuje się przez HTTP.

Krok 3 – openssl z terminala (zaawansowane):

openssl s_client -connect twojadomena.pl:443 -servername twojadomena.pl

Pokaże pełen łańcuch certyfikatów, daty, wystawcę, klucz publiczny. Przydatne, gdy podejrzewasz problem z SNI, łańcuchem pośrednim lub klientem (np. starsze Java/Android nie czytają Let's Encrypt R3 bez cross-sign).

Sprawdź też te miejsca w samym WordPress:

1. `Ustawienia → Ogólne` – Adres WordPress (URL) i Adres witryny muszą zaczynać się od `https://`
2. wp-config.php – brak konfliktów z `WP_HOME` i `WP_SITEURL` zdefiniowanymi na sztywno
3. Baza danych – `wp_options` tabela, klucze `siteurl` i `home`
4. .htaccess – brak duplikujących się reguł rewrite na HTTPS
5. Cache (LiteSpeed, WP Rocket, W3TC) – wyczyść po każdej zmianie SSL

Mixed content to zmora migracji HTTP→HTTPS. Strona ładuje się przez HTTPS, ale obrazki, skrypty, fonty lub iframe odwołują się do `http://` – Chrome blokuje aktywne zasoby (skrypty, CSS) i ostrzega o pasywnych (obrazki, video). Efekt: kłódka znika, działa pół funkcjonalności, klient dzwoni.

Trzy poziomy naprawy (od najprostszego):

Poziom 1 – Really Simple SSL (5 minut):

Wtyczka darmowa, instalujesz, klikasz "Aktywuj SSL". Robi trzy rzeczy: zmienia URLe w bazie, dodaje redirect 301 HTTP→HTTPS w .htaccess, naprawia mixed content przez output buffering. Dla 80% stron to wystarcza. Wersja Pro (49 USD/rok) dodaje HSTS, security headers i mixed content fixer dla zewnętrznych zasobów.

Poziom 2 – manual search-replace przez WP-CLI:

Gdy chcesz zrobić to czysto, bez wtyczki:

wp search-replace 'http://twojadomena.pl' 'https://twojadomena.pl' --skip-columns=guid --dry-run
wp search-replace 'http://twojadomena.pl' 'https://twojadomena.pl' --skip-columns=guid

Flag `--dry-run` najpierw pokazuje, ile rekordów zostanie zmienionych. `--skip-columns=guid` chroni kolumnę GUID w wp_posts (zmiana GUID łamie feedy RSS).

Poziom 3 – Content Security Policy (zaawansowane):

Dodajesz do nginx/Apache header CSP z dyrektywą `upgrade-insecure-requests`:

Content-Security-Policy: upgrade-insecure-requests;

Przeglądarka automatycznie podmienia HTTP→HTTPS w runtime. Działa świetnie dla zewnętrznych zasobów (YouTube, Vimeo, Google Fonts), nie wymaga dotykania bazy.

Najczęstsze źródła mixed content w 2026:

• Stare wpisy z hardkodowanymi URLami obrazków (``)
• Iframes YouTube z protokołu HTTP (już rzadko, ale w starych szablonach)
• Google Fonts ładowane przez `http://fonts.googleapis.com`
• Widgety zewnętrzne (Trustpilot, Opineo, mapy Google) z HTTP embed code
• Pliki CSS/JS z wtyczek z hardkodowanym `http://` w enqueue

Po naprawie sprawdź wynik na whynopadlock.com – pokaże, czy zostały ostatnie HTTP zasoby.

Let's Encrypt wystawia certyfikaty na 90 dni. Powinny się odnawiać automatycznie co 60 dni przez cron, ale w realnym świecie czasem się zacinają – zwłaszcza po zmianie hostingu, aktualizacji panelu lub edycji DNS. Symptom: kłódka czerwona, Chrome wyświetla "NET::ERR_CERT_DATE_INVALID".

Procedura ratunkowa zależnie od panelu:

cPanel / DirectAdmin:

Idź do `SSL/TLS Status` lub `SSL Manager`, znajdź sekcję AutoSSL/Let's Encrypt, kliknij "Run AutoSSL". Większość paneli odnawia w 1–3 minuty. Jeśli nie pomaga – usuń stary certyfikat, dodaj nowy na nowo.

CloudPanel / Plesk / DirectAdmin (panel admina):

Sekcja "Site" → "SSL/TLS" → "Renew Let's Encrypt". Sprawdź, czy domena rozwiązuje się na ten serwer (czasem Cloudflare proxy blokuje walidację HTTP-01 – wtedy przełącz Cloudflare na grey cloud, odnow, włącz proxy z powrotem).

SSH / certbot manualnie:

sudo certbot renew --dry-run
sudo certbot renew

`--dry-run` pokaże błędy bez próby odnawiania. Najczęstsze błędy: domena nie wskazuje na serwer, port 80 zablokowany, plik `.well-known/acme-challenge/` zwraca 404 (sprawdź .htaccess).

Cron renewal – sprawdź czy działa:

sudo systemctl status certbot.timer
sudo certbot certificates

Druga komenda pokaże wszystkie certyfikaty i daty wygaśnięcia. Powyżej 30 dni do końca – spokojnie. Poniżej 14 dni – działaj natychmiast.

Pro tip: CyberFolks odnawia Let's Encrypt automatycznie w panelu i monitoruje wygasanie. Hosting w cenie 20–30 zł/mies, bez konfiguracji crona. To jeden z powodów, dla których polecam ich klientom zamiast tańszych "masowych" hostingów, gdzie SSL jest dorzucany bez monitoringu.

Błąd "NET::ERR_CERT_COMMON_NAME_INVALID" oznacza, że certyfikat został wystawiony dla innej nazwy niż ta, z której korzysta użytkownik. Klasyczny przypadek: certyfikat na `twojadomena.pl`, a użytkownik wchodzi na `www.twojadomena.pl`. Albo certyfikat na `sklep.twojadomena.pl`, a user na głównej domenie.

Trzy typy certyfikatów i kiedy ich używać:

Let's Encrypt wystawia wildcard tylko przez walidację DNS-01 (musisz dodać rekord TXT). Większość paneli (CloudPanel, Plesk, cPanel) wspiera to natywnie. Jeśli Twój hosting tego nie ma – to znak, że pora zmienić dostawcę.

Najczęstsze błędy konfiguracji:

• Certyfikat tylko na `domena.pl`, redirect z `www.domena.pl` ale zanim redirect zadziała, przeglądarka wymaga ważnego SSL na obu wariantach
• Subdomena dodana po wystawieniu certyfikatu – nie działa, dopóki nie wystawisz nowego SAN/wildcard
• Multisite WordPress z 10 subdomenami i certyfikatem na pojedynczych domenach (potrzebny wildcard)
• Sklep WooCommerce na `sklep.firma.pl` z kasą na `kasa.firma.pl` – obie subdomeny muszą być w certyfikacie

Procedura naprawcza:

1. W panelu hostingu znajdź SSL Manager
2. Usuń stary certyfikat
3. Wystaw nowy zaznaczając wszystkie warianty (domena, www, subdomeny)
4. Dla wildcard – wybierz walidację DNS-01
5. Po wystawieniu wyczyść cache przeglądarki (Ctrl+Shift+Del) i sprawdź na ssllabs.com

Powiązany problem: migracja WordPress z domeny na domenę często powoduje CN mismatch, jeśli zapomnisz wystawić nowy certyfikat na nową domenę przed przekierowaniem DNS.

Strona ładuje się w nieskończoność, Chrome pokazuje "ERR_TOO_MANY_REDIRECTS". Sprawdziłeś logi serwera, widzisz: HTTP→HTTPS→HTTPS→HTTPS w nieskończoność. To jeden z najbardziej irytujących problemów po włączeniu SSL.

Trzy źródła pętli (ponad 90% przypadków):

1. Cloudflare Flexible SSL z redirectem w WordPress:

Cloudflare w trybie Flexible łączy się z Twoim serwerem przez HTTP, ale prezentuje użytkownikowi HTTPS. Jeśli WordPress wymusza redirect HTTP→HTTPS, dostajesz pętlę: Cloudflare wysyła HTTP do serwera, serwer redirectuje na HTTPS, Cloudflare znowu HTTP, i tak w kółko.

Rozwiązanie: przełącz Cloudflare na Full lub Full (Strict). Wymaga ważnego SSL na origin serwerze. Jeśli nie masz – wystaw Origin CA Certificate w Cloudflare (15-letni, darmowy).

2. Konflikt .htaccess i wp-config.php:

Sprawdź .htaccess – nie powinno być dwóch reguł rewrite na HTTPS:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Tylko jedna taka reguła w pliku. Sprawdź też wp-config.php:

define('FORCE_SSL_ADMIN', true);
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
    $_SERVER['HTTPS']='on';

Ten drugi blok jest niezbędny, gdy serwer jest za Cloudflare lub innym proxy.

3. Konflikt wtyczek SSL:

Masz Really Simple SSL + manualne reguły w .htaccess + redirect w wp-config.php. Trzy źródła forsują redirect na siebie nawzajem. Rozwiązanie: dezaktywuj wszystkie wtyczki SSL, wyczyść .htaccess, zostaw jedną metodę wymuszania HTTPS.

Procedura debugowania:

1. Wyłącz wszystkie wtyczki przez FTP (zmień nazwę folderu `/wp-content/plugins/`)
2. Otwórz stronę – jeśli działa, włączaj wtyczki pojedynczo
3. Sprawdź .htaccess – usuń wszystkie reguły SSL, dodaj jedną
4. Sprawdź wp-config.php – usuń duplikaty FORCE_SSL_ADMIN
5. Wyczyść cache na poziomie hostingu (LiteSpeed, Varnish) i Cloudflare (Purge Everything)

Jeśli nadal nie działa – problem może leżeć w bazie danych (klucz `siteurl` z HTTP, klucz `home` z HTTPS – konflikt).

Cloudflare oferuje cztery tryby SSL i każdy z nich znaczy coś innego. Wybór złego trybu to najczęstsze źródło problemów SSL przy korzystaniu z Cloudflare. Tabela poniżej wyjaśnia różnice.

Dlaczego Full (Strict) to standard:

Tylko ten tryb chroni przed atakami man-in-the-middle między Cloudflare a Twoim serwerem. Wymaga ważnego certyfikatu (Let's Encrypt lub Cloudflare Origin CA) na origin. Cloudflare Origin CA jest darmowy, ważny 15 lat, generujesz w 30 sekund w panelu Cloudflare → SSL/TLS → Origin Server.

Konfiguracja Origin CA krok po kroku:

1. Cloudflare panel → SSL/TLS → Origin Server → Create Certificate
2. Wybierz RSA 2048, ważność 15 lat, wszystkie domeny (`*.twojadomena.pl, twojadomena.pl`)
3. Skopiuj klucz prywatny i certyfikat do plików na serwerze
4. W konfiguracji nginx/Apache wskaż te pliki
5. Restart serwera, przełącz Cloudflare na Full (Strict)

Najczęstsze błędy z Cloudflare SSL:

• Error 525 (SSL handshake failed) – origin nie ma SSL lub certyfikat wygasł. Sprawdź certbot, renew, włącz Always Use HTTPS
• Error 526 (Invalid SSL Certificate) – Full Strict, ale origin ma self-signed. Przełącz na Full lub wystaw zaufany cert
• Mixed content po włączeniu Cloudflare – włącz Automatic HTTPS Rewrites w panelu Cloudflare → SSL/TLS → Edge Certificates
• Strona wolna mimo Cloudflare – włącz Always Use HTTPS i HSTS, sprawdź czy Caching jest aktywny

Pełna procedura instalacji Cloudflare jest opisana w wpisie jak zainstalować Cloudflare w WordPress – tam znajdziesz kompletną konfigurację z page rules i firewall.

Pytanie wraca co miesiąc: "Czy darmowy Let's Encrypt jest gorszy od płatnego DV od Sectigo za 200 zł?". Krótka odpowiedź: nie. Długa odpowiedź wymaga zrozumienia trzech typów certyfikatów.

Trzy poziomy walidacji:

DV (Domain Validation):

Walidacja na poziomie własności domeny – udowadniasz, że masz dostęp do domeny (przez plik HTTP-01, rekord DNS-01 lub mail). Wystawienie 1–10 minut. Let's Encrypt to certyfikat DV. Wszystkie darmowe i większość tanich płatnych to DV. Dla 99% stron firmowych, blogów i sklepów to wystarcza.

OV (Organization Validation):

Walidacja organizacji – CA sprawdza, czy firma istnieje w KRS, dzwoni na numer z rejestru, weryfikuje adres. Wystawienie 1–5 dni. Cena 300–800 zł/rok. Praktyczna różnica dla użytkownika: zerowa. Przeglądarka nie pokazuje informacji o organizacji w pasku adresu.

EV (Extended Validation):

Najbardziej rygorystyczna walidacja, kiedyś wyświetlała zieloną nazwę firmy w pasku adresu. Chrome i Firefox usunęły ten wyróżnik w 2019 roku – EV w 2026 to praktycznie wyrzucone pieniądze. Wystawienie 5–14 dni, cena 800–3000 zł/rok.

Kiedy warto rozważyć płatny:

• Bank, instytucja finansowa (regulator wymaga konkretnego CA)
• Wymaganie kontraktowe (klient B2B żąda "komercyjnego" SSL)
• Potrzeba ubezpieczenia (płatne CA dają warranty 100k–1M USD na wypadek wycieku)
• Wsparcie techniczne CA (Let's Encrypt nie ma supportu telefonicznego)

Kiedy zdecydowanie Let's Encrypt:

1. Strona firmowa, blog, portfolio
2. Sklep internetowy do 1M PLN/rok obrotu
3. Strona lądowania, MVP
4. Środowisko deweloperskie i staging
5. Każdy projekt, gdzie hosting wspiera auto-renewal

Mit, który warto obalić: "Płatny SSL ma silniejsze szyfrowanie". Nie. Wszystkie DV/OV/EV używają tych samych algorytmów (RSA 2048 lub ECDSA P-256). Siła szyfrowania zależy od konfiguracji serwera, nie typu certyfikatu.

Pro tip: Większość polskich hostingów oferuje Let's Encrypt z auto-renewal w cenie pakietu. CyberFolks ma to standardowo, łącznie z monitoringiem wygasania i wildcard. Płacisz 20–30 zł/mies za hosting, SSL dostajesz w cenie. Dlaczego ktoś miałby płacić 200 zł/rok za DV od zewnętrznego CA? Tylko jeśli zmienia hosting i nie chce konfigurować od nowa.

HSTS (HTTP Strict Transport Security) to header HTTP, który mówi przeglądarce: "Pamiętaj, że ta domena ma działać tylko przez HTTPS. Nawet jeśli user wpisze HTTP, przekieruj automatycznie po stronie klienta". To dodatkowa warstwa ochrony przed downgrade attacks i SSL stripping.

Anatomia HSTS header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• `max-age=31536000` – 1 rok (w sekundach), przeglądarka pamięta przez ten czas
• `includeSubDomains` – obejmuje wszystkie subdomeny (sklep.domena.pl, blog.domena.pl)
• `preload` – zgłaszasz do Chrome HSTS preload list (twarda decyzja, raz wpisany URL trudno usunąć)

Implementacja w WordPress – trzy sposoby:

Sposób 1 – wtyczka Really Simple SSL Pro:

Zakładka Hardening → Enable HSTS. Wybierasz max-age, klikasz zapisz. Najprostsze.

Sposób 2 – nginx config:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Sposób 3 – Apache .htaccess:

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Ostrzeżenie przed preload:

Zgłoszenie do Chrome HSTS preload list to decyzja na lata. Po wpisaniu na listę:

1. Twoja domena będzie wymagała HTTPS we wszystkich przeglądarkach (Chrome, Firefox, Edge, Safari)
2. Wszystkie subdomeny też muszą mieć ważne SSL
3. Usunięcie z listy zajmuje miesiące i nie zawsze się udaje
4. Jeśli wygaśnie SSL na subdomenie – cała domena niedostępna

Najpierw przetestuj na max-age=300 (5 minut), potem 86400 (1 dzień), dopiero po miesiącu bez problemów ustawiaj 31536000 i rozważ preload. Sprawdź swój HSTS na hstspreload.org.

Dla kogo HSTS preload:

• Sklepy internetowe z płatnościami
• Strony bankowe i finansowe
• Aplikacje SaaS z loginem
• Strony rządowe i zdrowotne

Dla typowego bloga firmowego HSTS bez preload (max-age=31536000) wystarcza – daje 95% korzyści przy 0% ryzyka.

Przez lata widziałem migracje HTTP→HTTPS, które zniszczyły 60% ruchu organicznego na 3 miesiące. Powód: brak 301 redirectów, brak aktualizacji Search Console, brak nowej sitemapy. Poprawnie przeprowadzona migracja kosztuje 1–2 godziny i nie powinna powodować spadków powyżej 5%.

Lista kontrolna migracji w 11 krokach:

1. Backup pełny – pliki + baza danych, koniecznie przed jakąkolwiek zmianą
2. Wystaw certyfikat SSL na origin (Let's Encrypt przez panel hostingu)
3. Skonfiguruj Cloudflare (jeśli używasz) – tryb Full Strict, Always Use HTTPS
4. Zmień URLe w WordPress – Ustawienia → Ogólne → http:// na https://
5. Search-replace w bazie – `wp search-replace 'http://domena.pl' 'https://domena.pl' --skip-columns=guid`
6. Dodaj 301 redirect w .htaccess (server-side, nie JavaScript):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

7. Zaktualizuj canonical URLs – wtyczka SEO (Yoast, Rank Math) zwykle robi to automatycznie
8. Wygeneruj nową sitemap – z URLami HTTPS
9. Search Console – dodaj property HTTPS jako nową, nie edytuj starej. Stara HTTP zostaje do monitoringu redirectów
10. Submit nową sitemapę do nowej property HTTPS
11. Zaktualizuj linki w narzędziach zewnętrznych – Google Analytics (default URL), Google Ads (landing page URLs), Facebook Pixel (jeśli filtr URL), Mailchimp (linki w kampaniach), partnerów linkujących

Co się dzieje z rankingami:

Google traktuje HTTPS jako osobną stronę. 301 redirect przekazuje 99% PageRank z HTTP na HTTPS. Spadek o 5–10% przez 2–4 tygodnie to norma – Google indeksuje nowe URLe i konsoliduje sygnały. Po miesiącu rankingi wracają, często wyższe niż przed migracją (boost SSL).

Najczęstsze błędy migracji:

• 302 zamiast 301 (PageRank nie przechodzi)
• Brak aktualizacji canonical (Google widzi duplicate content)
• Robots.txt blokujący nowe URLe (sprawdź `Disallow: /` na HTTPS)
• Stary URL w Search Console jako primary (musisz dodać nowy property)
• Hardkodowane URLe w themes/plugins (``)

Monitoring po migracji:

Przez pierwsze 2 tygodnie sprawdzaj codziennie:

• Search Console → Crawl Errors – nie powinno być wzrostu 404
• Search Console → Index Coverage – HTTPS URLe powinny się indeksować
• Google Analytics → Acquisition → Organic – ruch może spaść 5–10%, normalne
• Backlink checker – sprawdź, czy najsilniejsze linki przechodzą przez 301

Jeśli Twoja migracja okazała się katastrofą i straciłeś 30%+ ruchu – zadzwoń pod +48 604 939 140 lub napisz przez formularz kontaktowy. Audyt SEO migracji to standardowa usługa, którą robimy w 1–2 dni i przywracamy większość strat w 3–4 tygodnie. Pomogliśmy z tym 30+ klientom w 2025.

Wiele z tych problemów można rozwiązać samodzielnie – ale gdy brakuje czasu, narzędzi lub utknąłeś na etapie diagnozy, warto zlecić pracę zespołowi który robi to codziennie. W KC Mobile zajmujemy się tym od lat.

Zobacz powiązane usługi i materiały:

• wdrożenie WordPress
• strona na WordPressie
• najlepszy hosting WordPress
• PHP memory limit WordPress
• biały ekran śmierci (WSOD)

Jeśli opis w tym wpisie nie dotyczy dokładnie Twojej sytuacji, napisz do nas – odpowiadamy w ciągu 24 godzin roboczych.