Po wdrożeniu certyfikatu SSL miało być bezpiecznie, nowocześnie i bez komunikatów ostrzegawczych. Zamiast tego przeglądarka pokazuje kłódkę przekreśloną lub komunikat, że strona „nie jest w pełni bezpieczna”. W WordPressie to bardzo często nie jest problem z samym SSL, tylko z mixed content, czyli mieszaną zawartością ładowaną po HTTP na stronie działającej już po HTTPS.
To jeden z najczęstszych i najbardziej frustrujących problemów po migracji na SSL. Strona może działać, formularze mogą działać, a jednak użytkownik nadal widzi ostrzeżenie. Dla właściciela biznesu oznacza to spadek zaufania, gorszy CTR w wynikach wyszukiwania, niższą konwersję i poczucie, że „coś jest zepsute”, mimo że hosting i certyfikat wyglądają poprawnie.
W tym artykule wyjaśniam, czym naprawdę jest mixed content, jak go szybko zdiagnozować, skąd bierze się w WordPressie i jak go naprawić bez przypadkowego psucia bazy danych, motywu lub wtyczek. Jeśli prowadzisz stronę firmową, sklep lub blog i właśnie po włączeniu SSL nadal widzisz ostrzeżenia, ten poradnik jest dla Ciebie.
Szybka odpowiedź
Mixed content w WordPressie oznacza, że strona ładuje się po HTTPS, ale część zasobów nadal ma adres HTTP. Przeglądarka traktuje to jako niepełne zabezpieczenie i może wyświetlać ostrzeżenie.
Najczęściej trzeba zrobić cztery rzeczy:
- ustawić WordPress na adres HTTPS w ustawieniach ogólnych,
- zamienić stare adresy HTTP na HTTPS w bazie danych,
- naprawić odwołania w motywie, builderze lub wtyczkach,
- wymusić ładowanie wszystkich zasobów po HTTPS i sprawdzić efekt w konsoli przeglądarki.
Jeśli mixed content dotyczy tylko pojedynczych obrazków, logo lub skryptów, zwykle da się to naprawić samodzielnie. Jeśli problem wraca po każdej zmianie, strona korzysta z niestandardowego motywu, multisite, cache na kilku poziomach albo po migracji doszło do uszkodzenia danych, lepiej działać ostrożnie i wykonać pełną kopię zapasową przed zmianami.
Diagnoza problemu
Najpierw trzeba ustalić, czy rzeczywiście chodzi o mixed content, a nie o inny błąd SSL. Objawy są zwykle podobne, ale przyczyna bywa różna.
Najczęstsze symptomy mixed content w WordPressie:
- kłódka w przeglądarce nie jest pełna lub widnieje informacja o niebezpiecznej zawartości,
- strona otwiera się po HTTPS, ale część obrazów się nie ładuje,
- CSS lub JavaScript znikają, przez co strona wygląda „rozsypana”,
- formularze, mapy, slidery lub iframe nie działają poprawnie,
- w narzędziach deweloperskich pojawiają się ostrzeżenia typu „Mixed Content: The page at … was loaded over HTTPS, but requested an insecure resource over HTTP”.
W praktyce problem polega na tym, że przeglądarka widzi stronę jako bezpieczną, ale część elementów jest pobierana niebezpiecznym kanałem. Czasem dotyczy to tylko zasobów widocznych dla użytkownika, a czasem skryptów, które wpływają na całe działanie witryny.
W WordPressie mixed content najczęściej widać w takich miejscach:
- adres strony zapisany w ustawieniach WordPressa nadal zawiera http://,
- stare wpisy i strony zawierają absolutne odwołania do obrazków z http://,
- motyw ma wpisane zasoby na sztywno,
- wtyczka ładuje pliki z zewnętrznego źródła po HTTP,
- builder strony zapisuje pełne adresy URL w treści lub w danych meta,
- cache lub CDN podaje starą wersję plików.
Jeśli chcesz zdiagnozować problem szybko, otwórz stronę w przeglądarce, włącz narzędzia deweloperskie i sprawdź zakładkę z błędami konsoli. Szukaj informacji o zasobach ładowanych przez HTTP. Drugim krokiem jest przejrzenie źródła strony i wyszukanie http:// w adresach plików, obrazków, arkuszy stylów, fontów i skryptów.
Ważne: nie zakładaj od razu, że winny jest certyfikat SSL. W większości przypadków certyfikat jest poprawny, a problem leży w starszych ścieżkach zapisanych w WordPressie, motywie lub bazie danych.
Możliwe przyczyny
Mixed content nie pojawia się bez powodu. Zwykle jest skutkiem migracji, niedokończonej konfiguracji albo zapisanych wcześniej danych, które nadal wskazują na HTTP.
Najczęstsze przyczyny:
1. Adres WordPressa i adres witryny nadal mają HTTP
To podstawowy błąd po włączeniu SSL. Jeśli w ustawieniach ogólnych WordPressa pole „Adres WordPressa (URL)” lub „Adres witryny (URL)” nadal zawiera http://, system może generować część linków w starej wersji.
2. Stare adresy zapisane w treści i meta danych
WordPress przechowuje wiele informacji w bazie danych. Obrazki w treści wpisów, przyciski, linki w sekcjach ustawień, dane w polach niestandardowych, konfiguracje buildera – to wszystko mogło zostać zapisane jeszcze przed wdrożeniem SSL. W efekcie strona po HTTPS nadal odwołuje się do zasobów po HTTP.
3. Motyw lub child theme z „na sztywno” wpisanymi zasobami
Niektóre motywy zawierają odwołania do plików przez pełne adresy. Dotyczy to zwłaszcza logo, ikon, skryptów, fontów i plików CSS. Jeśli autor motywu nie przewidział pełnej zgodności z HTTPS, problem wróci mimo poprawnej konfiguracji WordPressa.
4. Wtyczki ładowane zewnętrznie po HTTP
Wtyczki do sliderów, map, czatów, analityki, marketing automation czy embedów social media potrafią pobierać elementy z innych domen. Jeśli zewnętrzny dostawca nie udostępnia HTTPS lub konfiguracja jest błędna, mixed content pozostanie aktywny.
5. CDN, cache lub proxy serwujące starą wersję
Jeżeli korzystasz z cache, reverse proxy albo CDN, możliwe, że w obiegu nadal jest wersja strony z linkami HTTP. Czasem po samej poprawce strona lokalnie wygląda dobrze, ale użytkownik nadal widzi stary kod z cache.
6. Błędy po imporcie treści lub migracji
Po przenoszeniu strony na nowy serwer, zmianie domeny lub imporcie z innego środowiska łatwo zostawić część adresów w starej formie. Problem bywa szczególnie częsty przy ręcznym przenoszeniu baz danych, bez wykonania pełnego search and replace.
7. Mieszanie protokołów przez zewnętrzne zasoby
Jeśli na stronie osadzono zewnętrzny film, mapę, font, plik PDF, ikonę lub skrypt, a źródło wymusza HTTP, przeglądarka może blokować taki element lub oznaczyć stronę jako częściowo niezabezpieczoną.
Rozwiązanie krok po kroku
Najbezpieczniej naprawiać mixed content etapami. Nie zaczynaj od losowego grzebania w bazie danych. Najpierw ustal źródło problemu, potem wprowadź poprawki i sprawdzaj efekt po każdym kroku.
Krok 1. Wykonaj pełną kopię zapasową
To absolutna podstawa. Zapisz kopię plików i bazy danych. Jeśli coś pójdzie nie tak, będziesz mógł wrócić do poprzedniego stanu. Przy stronie firmowej lub sklepie to nie jest formalność, tylko realna ochrona przed utratą danych.
Ostrzeżenie bezpieczeństwa: nie wykonuj masowych zmian w bazie bez backupu. Jedna błędna operacja może usunąć linki, uszkodzić serializowane dane lub zepsuć ustawienia buildera.
Krok 2. Sprawdź ustawienia WordPressa
Wejdź do ustawień ogólnych i upewnij się, że oba adresy witryny zaczynają się od https://. Jeśli używasz panelu hostingu lub pliku konfiguracyjnego, sprawdź też, czy nie ma tam wymuszenia starego adresu HTTP.
Jeżeli po zmianie strona logowania lub front zaczynają zachowywać się niestabilnie, może oznaczać to konflikt z cache lub nieprawidłową konfigurację przekierowań. W takim przypadku nie kontynuuj na ślepo – najpierw sprawdź logikę przekierowań i działanie certyfikatu.
Krok 3. Wymuś przekierowanie z HTTP na HTTPS
Jeśli strona działa równolegle w dwóch wersjach, trzeba ustawić jednoznaczne przekierowanie na HTTPS. Dzięki temu użytkownik i roboty wyszukiwarki zawsze trafiają na bezpieczną wersję strony. Pamiętaj jednak, że samo przekierowanie nie usuwa mixed content z zasobów już zapisanych w treści lub bazie danych.
Krok 4. Wyszukaj stare adresy HTTP w treści i bazie danych
Najczęściej właśnie tutaj leży przyczyna. Trzeba znaleźć wszystkie wystąpienia http://twojadomena.pl lub http://www.twojadomena.pl i zamienić je na wersję HTTPS.
Dotyczy to zwłaszcza:
- wpisów i stron,
- opisów produktów,
- pól niestandardowych,
- ustawień motywu,
- treści zapisanych przez builder,
- widgetów i stopki,
- pól SEO i social media,
- danych wtyczek galerii, sliderów i formularzy.
Ważne: nie każda zmiana w bazie danych jest bezpieczna „na ślepo”. Jeśli wpisy są przechowywane w formacie serializowanym, zwykłe masowe zastąpienie tekstu może uszkodzić dane. Dlatego najlepiej używać narzędzia, które poprawnie obsługuje serializację, albo wykonać zmianę z poziomu wtyczki lub bezpiecznego narzędzia migracyjnego.
Krok 5. Sprawdź motyw i child theme
Jeśli część zasobów nadal ładuje się po HTTP, zajrzyj do plików motywu. Szukaj pełnych adresów do obrazków, ikon, fontów i skryptów. Zamiast wpisywać adres na sztywno, lepiej korzystać z funkcji generujących poprawny adres względem środowiska.
Jeśli używasz child theme, sprawdź zarówno pliki rodzica, jak i dziecka. Problem może siedzieć w szablonie nagłówka, stopki, sekcji hero lub niestandardowym komponencie przygotowanym przez programistę.
Krok 6. Zweryfikuj wtyczki
Wyłącz na próbę podejrzane wtyczki, zwłaszcza te, które ładują zewnętrzne skrypty, mapy, czcionki, galerie, pop-upy, integracje marketingowe i elementy osadzane z innych serwisów. Jeśli po wyłączeniu konkretnej wtyczki problem znika, masz winowajcę.
Nie instaluj kolejnych wtyczek „naprawiających SSL” bez zrozumienia, co robią. Część z nich tylko maskuje objawy, a nie usuwa przyczynę. W efekcie problem wraca po aktualizacji albo zmienia się w gorszy błąd.
Krok 7. Oczyść cache i CDN
Po każdej zmianie wyczyść cache WordPressa, cache hostingu, cache przeglądarki i – jeśli używasz – CDN. Mixed content często wydaje się „nienaprawiony”, bo przeglądarka lub pośrednia warstwa serwuje starą wersję strony.
Jeśli masz cache na wielu poziomach, testuj w trybie incognito i po twardym odświeżeniu. Dzięki temu nie pomylisz starego kodu z nowym.
Krok 8. Sprawdź, które zasoby dalej lecą po HTTP
Po naprawie odśwież stronę i ponownie sprawdź konsolę przeglądarki. Zwróć uwagę na konkretne pliki: obrazki, arkusze CSS, fonty, skrypty JS, iframe, API zewnętrzne. To pokaże, czy problem zniknął całkowicie, czy tylko częściowo.
Jeżeli ostrzeżenie dotyczy pojedynczego elementu, najlepiej poprawić go bezpośrednio w źródle. Jeśli ostrzeżeń jest wiele, trzeba wrócić do bazy danych i motywu.
Krok 9. Włącz automatyczne wymuszanie HTTPS dla mediów tylko wtedy, gdy rozumiesz skutki
Niektóre rozwiązania potrafią automatycznie podmieniać adresy lub próbować „naprawiać” zasoby na poziomie wyświetlania. To wygodne, ale nie zawsze wystarczające. Jeśli problem jest strukturalny, lepiej poprawić zapis danych, a nie tylko maskować wynik po stronie frontu.
Krok 10. Przetestuj najważniejsze podstrony
Nie ograniczaj się do strony głównej. Sprawdź:
- strony z formularzem kontaktowym,
- kategorie i archiwa,
- strony produktów,
- checkout, jeśli masz sklep,
- strony z osadzonym wideo,
- blog z obrazkami i galeriami,
- stopkę, header i menu.
Mixed content często wychodzi dopiero na podstronach, które korzystają z innych szablonów lub innych źródeł danych.
Najczęstsze błędy
Przy naprawie mixed content łatwo wpaść w pułapki, które wydłużają problem albo go pogłębiają.
- Usuwanie ostrzeżenia zamiast przyczyny. Samo „ukrycie” komunikatu nie naprawia strony.
- Masowa podmiana w bazie bez backupu. To szczególnie groźne przy danych serializowanych.
- Zmiana tylko strony głównej. Problem może siedzieć w dziesiątkach wpisów i szablonów.
- Ignorowanie motywu i wtyczek. Nawet idealna baza nie pomoże, jeśli komponent ładuje zasoby po HTTP.
- Brak czyszczenia cache. Wtedy wygląda, jakby naprawa nie działała.
- Próba naprawy bez diagnostyki konsoli. Strzelanie na ślepo zwykle kończy się dodatkowymi błędami.
- Instalowanie przypadkowych wtyczek od SSL. Część z nich jest zbędna, a część może wprowadzić konflikty.
- Zmiana adresów bez sprawdzenia przekierowań. Można łatwo utworzyć pętlę lub zablokować logowanie.
Kiedy nie robić tego samodzielnie
Nie każdy problem z mixed content warto naprawiać samemu. Są sytuacje, w których ryzyko przewyższa potencjalną oszczędność czasu.
Nie działaj samodzielnie, jeśli:
- strona jest sklepem i każdy błąd wpływa na sprzedaż,
- nie masz aktualnej kopii zapasowej,
- problem dotyczy danych w builderze lub rozbudowanych polach niestandardowych,
- strona działa w środowisku multisite,
- korzystasz z kilku warstw cache, CDN i reverse proxy jednocześnie,
- po migracji pojawiły się też inne błędy, np. brak stylów, błędy logowania, puste strony,
- nie wiesz, które zmiany są bezpieczne w bazie danych,
- strona ma niestandardowy motyw napisany pod Twoje zamówienie.
W takich przypadkach samodzielna próba „na szybko” może doprowadzić do sytuacji, w której problem z mixed content zostanie zamieniony na awarię layoutu, utratę ustawień lub uszkodzenie treści.
Kiedy zgłosić się do specjalisty
Do specjalisty warto zgłosić się wtedy, gdy mixed content jest tylko jednym z objawów większego problemu technicznego. To szczególnie ważne, jeśli strona ma znaczenie biznesowe i przestój oznacza realne straty.
Skontaktuj się z ekspertem, jeśli:
- ostrzeżenie wraca mimo poprawy adresów i czyszczenia cache,
- nie możesz ustalić, która wtyczka lub szablon generuje problem,
- potrzebna jest bezpieczna migracja treści z HTTP do HTTPS,
- na stronie pojawiają się błędy konsoli związane z mieszaniem zasobów z zewnętrznych źródeł,
- firma korzysta z rozbudowanego środowiska hostingowego,
- to sklep internetowy lub serwis z dużym ruchem,
- po naprawie znikają inne elementy strony,
- problem dotyczy też wydajności, przekierowań lub indeksacji.
Specjalista nie tylko naprawi mixed content, ale też sprawdzi, czy wdrożenie SSL jest kompletne: czy wszystkie zasoby są pobierane bezpiecznie, czy przekierowania są poprawne, czy nie ma konfliktu z cache i czy przeglądarka pokazuje pełną kłódkę bez ostrzeżeń.
Podsumowanie
Mixed content w WordPressie to bardzo częsty problem po wdrożeniu SSL, ale w większości przypadków da się go naprawić bez wymiany hostingu i bez stawiania strony od nowa. Kluczowe jest rozpoznanie, skąd pochodzą odwołania HTTP: z ustawień WordPressa, z bazy danych, z motywu, z wtyczek czy z cache/CDN.
Najważniejsza zasada brzmi: najpierw backup, potem diagnostyka, dopiero później poprawki. Nie podmieniaj adresów bez sprawdzenia, nie ufaj tylko jednej warstwie naprawy i nie ignoruj komunikatów w konsoli przeglądarki. Jeśli problem jest prosty, poradzisz sobie samodzielnie. Jeśli jest rozbudowany albo dotyczy strony firmowej, lepiej działać z pomocą specjalisty niż ryzykować przestój i utratę zaufania użytkowników.
CTA do kontaktu
Jeśli po wdrożeniu SSL Twoja strona WordPress nadal pokazuje ostrzeżenia o mixed content, nie czekaj aż problem zacznie wpływać na sprzedaż, formularze i zaufanie użytkowników. Skontaktuj się z nami, a pomożemy bezpiecznie zdiagnozować źródło błędu i przywrócić pełne HTTPS bez zbędnego ryzyka.
