Zainstalowali Państwo certyfikat SSL, skonfigurowali HTTPS, a przeglądarka wciąż pokazuje ostrzeżenie „połączenie nie jest bezpieczne". Brzmi znajomo?

Tak wygląda błąd mieszanej treści. Strona niby działa, odwiedzający nie narzekają, ale Google widzi problem i obniża pozycje w wynikach wyszukiwania. Od 2018 roku Chrome oznacza strony z mieszaną treścią jako niebezpieczne, a z każdą aktualizacją polityka staje się bardziej restrykcyjna.

Naprawia się to w dwóch krokach. Bez programisty, bez ręcznej edycji każdego linku i bez ryzyka uszkodzenia układu strony.

💡 Szybki przegląd:

• znajdujemy źródło mieszanej treści przez Chrome DevTools lub narzędzia online
• instalujemy wtyczkę (sposób automatyczny) lub edytujemy.htaccess i bazę danych (sposób ręczny)
• sprawdzamy wynik i utrwalamy przekierowanie HTTPS na przyszłość

Czym jest mieszana treść i dlaczego jest niebezpieczna

Mieszana treść (Mixed Content) to sytuacja, gdy strona jest ładowana przez HTTPS, ale poszczególne jej elementy, obrazy, skrypty, style, czcionki, są pobierane niezabezpieczonym protokołem HTTP.

Przeglądarka widzi to jako lukę w zabezpieczeniach. Osoba atakująca może przechwycić żądanie HTTP, podmienić skrypt lub obraz i uzyskać dostęp do danych użytkownika. Dlatego Chrome, Firefox i Safari całkowicie blokują „aktywną" mieszaną treść (skrypty, iframe), a „pasywną" (obrazy, media) wyświetlają z ostrzeżeniem w pasku adresu.

Typową przyczyną powstania problemu jest migracja z HTTP na HTTPS. Stare linki w treści, ustawieniach motywu, plikach CSS i widżetach pozostają z prefiksem http://. WordPress nie zmienia ich automatycznie, stąd konflikt.

Od 2020 roku Google mówi wprost: HTTPS jest sygnałem rankingowym. Strona z mieszaną treścią traci „zieloną kłódkę", a wraz z nią zaufanie odwiedzających i pozycje w SERP. Należy to naprawić natychmiast po zainstalowaniu SSL, nie odkładając na później.

Krok 1: Diagnostyka, znajdujemy źródło problemu

Zanim zaczniemy naprawiać, trzeba zrozumieć, które dokładnie zasoby są ładowane przez HTTP. Uniwersalnym sposobem jest Chrome DevTools.

Proszę otworzyć stronę w Chrome, nacisnąć F12 (lub Ctrl+Shift+I), przejść do zakładki Console i odświeżyć stronę. Każdy wiersz z ostrzeżeniem „Mixed Content" pokazuje dokładny adres URL problematycznego pliku.

Obok, w zakładce Security, znajduje się podsumowanie: status certyfikatu, lista niebezpiecznych żądań i zalecenia dotyczące naprawy. Do szybkiej oceny sytuacji to wystarczy.

Jeśli błędów jest dużo i potrzebują Państwo pełnej listy w jednym raporcie, z pomocą przychodzą narzędzia online.

Jitbit SSL Checker, bezpłatny skaner online. Wpisują Państwo URL i otrzymują listę wszystkich zasobów HTTP na stronie: obrazy, skrypty, CSS, wywołania zewnętrzne. Darmowa wersja sprawdza do 200 stron.

Why No Padlock, kolejna bezpłatna usługa ze szczegółową analizą: które elementy nie są zabezpieczone, skąd są ładowane i do jakiego typu treści należą. Obsługuje sprawdzanie stron z autoryzacją.

HTTPS Checker, aplikacja desktopowa dla macOS, która skanuje witrynę lokalnie i pokazuje błędy po każdej zmianie. Działa z limitem 100 stron, jest wygodna podczas debugowania krok po kroku.

Gdy lista problematycznych adresów URL jest już przed oczami, przechodzimy do naprawy.

Krok 2: Naprawa, trzy skuteczne metody

Wybór metody zależy od liczby błędów i Państwa gotowości do pracy z kodem. Wtyczki rozwiązują zadanie w kilka kliknięć, sposób ręczny daje pełną kontrolę.

Metoda 1: Really Simple Security, rozwiązanie automatyczne

Really Simple Security (dawniej Really Simple SSL), najpopularniejsza wtyczka SSL do WordPressa z 3 milionami aktywnych instalacji i oceną 4,9/5 na WordPress.org.

Proszę zainstalować wtyczkę przez „Wtyczki → Dodaj nową", aktywować ją i uruchomić kreator konfiguracji. Wtyczka automatycznie:

• ustawia HTTPS w ustawieniach WordPress (adres witryny i adres domowy),
• konfiguruje przekierowanie 301 z HTTP na HTTPS,
• podmienia linki HTTP w treści „w locie" przez bufor wyjściowy,
• sprawdza certyfikat i ostrzega o zbliżającym się terminie wygaśnięcia.

Po instalacji proszę otworzyć witrynę w trybie incognito i upewnić się, że kłódka w pasku adresu jest zielona, a w DevTools → Console nie ma żadnego ostrzeżenia Mixed Content Warning. Dla zdecydowanej większości witryn to wystarczy.

Metoda 2: SSL Insecure Content Fixer, elastyczne ustawienie poziomów

Jeśli Really Simple Security nie poradził sobie (na przykład część treści ładuje się przez zewnętrzne API), proszę zainstalować SSL Insecure Content Fixer. Wtyczka ma 100 000 aktywnych instalacji, ocenę 4,8/5 i oferuje pięć poziomów filtracji:

• Simple, podstawowy poziom dla początkujących, naprawia linki w treści i ustawieniach;
• Content, dodatkowo sprawdza widżety tekstowe i shortkody;
• Widgets, koncentruje się na zawartości widżetów, w tym na niestandardowym HTML;
• Capture, przechwytuje całą stronę przed renderowaniem i zastępuje każdy http:// na https://. Wolniejszy, ale skuteczniejszy;
• Capture All, maksymalny zasięg: skrypty, style inline, wywołania zewnętrzne. Tryb najbardziej zasobożerny.

Proszę zacząć od Simple. Jeśli błędy pozostaną, proszę przełączyć poziom wyżej i ponownie sprawdzić witrynę. Nie należy od razu przechodzić na Capture All bez potrzeby: obciąża on serwer i może powodować konflikty z wtyczkami buforującymi.

Metoda 3: Ręczna naprawa,.htaccess i baza danych

Jeśli jest Pan/Pani zasadniczo przeciwna dodatkowym wtyczkom lub błąd jest pojedynczy, oto bezpośrednia ścieżka.

Krok A. Wymuszone przekierowanie HTTPS w.htaccess. Proszę dodać na początku pliku (przed # BEGIN WordPress):

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

Proszę zapisać, sprawdzić: strona główna i wszystkie wewnętrzne adresy URL powinny przekierowywać na HTTPS. Przed edycją proszę pobrać kopię zapasową.htaccess: jeden błąd literowy psuje witrynę.

Krok B. Zamiana linków HTTP w bazie danych. Stare adresy URL wewnątrz postów, pól meta i ustawień pozostały z http://. Zmienianie ich bezpośrednim zapytaniem SQL jest ryzykowne, dane serializowane PHP ulegają uszkodzeniu. Proszę użyć:

• WP-CLI: wp search-replace 'http://example.com' 'https://example.com' --dry-run (najpierw bez --dry-run, aby zobaczyć liczbę zamian);
• wtyczki Better Search Replace, robi to samo przez panel administracyjny z podglądem.

Po zamianie proszę wyczyścić pamięć podręczną przeglądarki (Ctrl+Shift+Del), pamięć podręczną wtyczki (WP Rocket, LiteSpeed) i sprawdzić witrynę w trybie incognito.

Przydatne wideo na ten temat

Autor kanału GoTechWizard pokazuje proces naprawy mieszanej treści od diagnostyki do czystego HTTPS bez ani jednej linii kodu:

⁉️🤔 Często zadawane pytania

Dlaczego po zainstalowaniu SSL witryna nadal pokazuje „niezabezpieczona"?

Certyfikat SSL jest aktywny na serwerze, ale część treści ładuje się przez HTTP. Certyfikat obejmuje połączenie między przeglądarką a serwerem, natomiast linki HTTP wewnątrz strony omijają je. Przeglądarka widzi mieszankę protokołów i ostrzega użytkownika. Główne przyczyny są trzy: stare linki do obrazów w postach (wstawione przed instalacją SSL), zahardkodowane adresy URL HTTP w motywie lub wtyczkach, zasoby zewnętrzne (czcionki Google, skrypty CDN), które są pobierane przez http:// zamiast https://. Proszę zdiagnozować problem przez DevTools → Console i postępować zgodnie z krokami z artykułu.

Czy trzeba kupować certyfikat SSL, czy wystarczy darmowy?

Dla zdecydowanej większości witryn darmowy SSL od Lets Encrypt jest wystarczający. Jest uznawany przez wszystkie przeglądarki i wyszukiwarki. Płatne certyfikaty (OV, EV) mają sens w przypadku sklepów internetowych, banków i witryn z formularzami płatności: wymagają weryfikacji firmy i wyświetlają nazwę organizacji w pasku adresu. Dla bloga, portfolio czy strony firmowej Lets Encrypt to standard. Większość hostingów (Timeweb, Beget, Hostinger) wydaje go automatycznie podczas tworzenia witryny.

Czy można naprawić mieszaną treść bez wtyczek i poprawek w kodzie?

Na niektórych hostingach tak. Cloudflare włącza opcję Automatic HTTPS Rewrites w darmowym planie: poprawia ona w locie linki HTTP na HTTPS dla całego ruchu przechodzącego przez CDN. Jest to jednak półśrodek: problem pozostaje na poziomie serwera, a po wyłączeniu Cloudflare błędy wracają. Lepiej usunąć przyczynę: zastąpić linki HTTP w bazie danych i skonfigurować przekierowanie.htaccess. Wtedy witryna będzie czysta przy każdym sposobie dostarczania ruchu.

SSL Insecure Content Fixer czy Really Simple Security, co wybrać?

Zależy od zadania. Really Simple Security to rozwiązanie „włącz i zapomnij": pasuje do typowej witryny na WordPressie bez skomplikowanych integracji. SSL Insecure Content Fixer to narzędzie ze stopniowaniem poziomów do precyzyjnej konfiguracji. Jeśli po aktywacji Really Simple Security błędy pozostały (zdarza się to przy niestandardowej strukturze motywu, niestandardowych endpointach lub wtyczkach z bezpośrednimi wywołaniami HTTP), proszę przejść na SSL Insecure Content Fixer i zwiększać poziom filtracji. Praktyka pokazuje: większość przypadków zamyka pierwsza wtyczka, pozostałe druga.

Czy bezpiecznie jest używać trybu Capture All w SSL Insecure Content Fixer?

Capture All przechwytuje i przepisuje każdy bajt strony przed wysłaniem do przeglądarki. Jest to niezawodne, ale zwiększa obciążenie procesora. Na słabym hostingu lub mocno obciążonej witrynie możliwe jest opóźnienie odpowiedzi o 100-300 ms. Wtyczki buforujące (WP Rocket) niwelują ten efekt: strona jest generowana raz i serwowana z pamięci podręcznej. Przed włączeniem Capture All proszę upewnić się, że łagodniejsze poziomy nie rozwiązały problemu, i zrobić kopię zapasową.

Naprawili Państwo mieszaną treść, co dalej

Błąd mieszanej treści to nie wyrok. Po dwóch krokach z tego artykułu zostaje całkowicie zamknięty i z reguły więcej nie wraca. Najważniejsze to nie zagłuszać ostrzeżenia przeglądarki, lecz usunąć przyczynę: przełączyć każdy zasób na HTTPS.

Proszę utrwalić wynik: skonfigurować automatyczne sprawdzanie SSL (UptimeRobot lub monitoring hostingu wysyła powiadomienie na 30 dni przed wygaśnięciem certyfikatu) i przyjąć zasadę wstawiania nowych linków od razu z https://. Kilka minut profilaktyki teraz oszczędza godziny debugowania później.