Masz już certyfikat SSL, a mimo to przeglądarka pokazuje „Niezabezpieczona” albo kłódkę z ostrzeżeniem? To jeden z najbardziej frustrujących problemów po przejściu WordPressa na HTTPS. Strona wygląda poprawnie, certyfikat jest aktywny, ale coś nadal „ciągnie” ją w stronę HTTP. Efekt? Ostrzeżenia bezpieczeństwa, spadek zaufania użytkowników, problemy z formularzami, a czasem także gorsza ocena techniczna witryny przez wyszukiwarki.
Ten problem nazywa się mixed content, czyli mieszana treść. W praktyce oznacza, że strona ładowana przez HTTPS zawiera zasoby pobierane przez niezabezpieczony HTTP: obrazy, skrypty, arkusze CSS, fonty, iframe, a nawet odwołania w kodzie motywu lub wtyczek. W WordPressie dzieje się to bardzo często po migracji na SSL, szczególnie jeśli strona działała wcześniej długo na HTTP i zawiera dużo starych adresów zapisanych w bazie danych.
W tym artykule dostajesz nie teorię, ale praktyczny plan działania: jak rozpoznać mixed content, skąd się bierze, co można naprawić samodzielnie, czego nie robić „na ślepo” oraz kiedy lepiej oddać sprawę specjaliście. Jeśli zależy Ci na tym, żeby kłódka była zielona lub przynajmniej brakowało ostrzeżeń, czytaj dalej uważnie.
Szybka odpowiedź
Mixed content w WordPress po SSL naprawisz najczęściej przez:
- ustawienie witryny na https:// w konfiguracji WordPressa,
- podmianę starych adresów http:// na https:// w bazie danych,
- sprawdzenie motywu i wtyczek pod kątem twardo wpisanych linków HTTP,
- oczyszczenie cache strony, serwera i przeglądarki,
- poprawę zasobów zewnętrznych, które nadal ładują się po HTTP.
Jeśli nie wiesz, gdzie dokładnie występuje problem, zacznij od konsoli przeglądarki i narzędzi developerskich. To one pokażą Ci konkretny plik albo adres, który psuje pełne HTTPS. W wielu przypadkach szybka naprawa jest możliwa bez przebudowy strony, ale przy rozbudowanych sklepach WooCommerce, starych motywach i ciężkich wtyczkach lepiej wykonać zmiany ostrożnie i zawsze po backupie.
Diagnoza problemu
Mixed content nie jest jednym błędem, tylko kategorią problemów. Czasem przeglądarka blokuje zasób całkowicie, czasem „tylko” ostrzega, a czasem część strony działa nieprawidłowo, bo skrypt lub styl nie zostały załadowane. W WordPressie może to wyglądać tak:
- kłódka przy adresie strony nie jest zamknięta lub przeglądarka pokazuje ostrzeżenie o niebezpiecznych treściach,
- na stronie widzisz błędy w konsoli związane z zasobami HTTP,
- niektóre obrazy się nie wyświetlają,
- formularz kontaktowy, slider, mapa lub koszyk działa niestabilnie,
- po zmianie na SSL nadal widzisz stare adresy http w źródle strony,
- Google Search Console zgłasza problemy z indeksacją lub bezpieczeństwem zasobów.
Najlepszą metodą diagnozy jest wejście na stronę w przeglądarce, otwarcie narzędzi deweloperskich i sprawdzenie zakładki Console oraz Network. Szukaj komunikatów typu „Mixed Content”, „blocked loading insecure content” albo listy adresów ładowanych przez HTTP. To właśnie te zasoby trzeba naprawić. Często problem nie siedzi na stronie głównej, tylko na podstronach z treścią z edytora, w nagłówkach, stopkach, widgetach lub w ustawieniach wtyczek.
Warto też rozróżnić dwa scenariusze. Pierwszy: WordPress sam generuje nieprawidłowe linki, bo w ustawieniach strony nadal wpisane jest HTTP. Drugi: treść lub kod motywu zawierają ręcznie wpisane stare adresy. W pierwszym przypadku naprawa jest zwykle szybka. W drugim trzeba przeszukać bazę danych i szablony. To ważne, bo nie każda metoda działa w każdym przypadku.
Możliwe przyczyny
Najczęstsze źródła mixed content po wdrożeniu SSL w WordPressie są zaskakująco prozaiczne. Problem nie polega na tym, że certyfikat jest „zły”, tylko na tym, że część strony nadal myśli, że działa po HTTP.
1. Niepoprawny adres WordPressa i adres witryny
Jeśli w ustawieniach WordPressa nadal widnieje HTTP, system może generować część linków bez SSL. Wystarczy, że jeden adres zostanie wpisany nieprawidłowo, a strona zacznie mieszać protokoły. Dotyczy to zarówno panelu administracyjnego, jak i adresów w treści.
2. Stare adresy zapisane w bazie danych
Po latach działania na HTTP baza danych zawiera setki lub tysiące wpisów z pełnymi adresami. Mogą to być obrazy w treści wpisów, odnośniki w ustawieniach motywu, pola ACF, dane WooCommerce, widgety, stopka, nagłówek, a nawet elementy w konstruktorach stron. Po przejściu na SSL stare URL-e dalej się renderują.
3. Motyw lub wtyczka hardkodują HTTP
Niektóre motywy i wtyczki nie korzystają z dynamicznych funkcji WordPressa, tylko wpisują adres zasobu „na sztywno”. Wtedy nawet jeśli cała strona ma już HTTPS, skrypt, font, ikona lub arkusz CSS nadal pobierane są z HTTP. To częste w starszych lub źle napisanych szablonach.
4. Zasoby zewnętrzne bez HTTPS
Bywa, że problem nie pochodzi z WordPressa, tylko z usług zewnętrznych: map, iframe, systemów analitycznych, osadzonych filmów, widgetów social media czy fontów hostowanych na obcej domenie. Jeśli zewnętrzny serwer nie udostępnia HTTPS, przeglądarka może zablokować zasób albo oznaczyć stronę jako częściowo niezabezpieczoną.
5. Cache po migracji
Po zmianie na SSL stara wersja strony może nadal być serwowana z cache. Wtedy użytkownik widzi „stare” HTTP, mimo że w panelu wszystko wygląda dobrze. Dotyczy to cache wtyczek, cache hostingu, CDN i samej przeglądarki.
6. Niepełna migracja adresów
Niektóre narzędzia podmieniają tylko część rekordów lub tylko wybrane tabele. Jeśli migracja była wykonana niedokładnie, w bazie zostają pojedyncze wyjątki, które potem trudno znaleźć bez pełnego audytu.
7. Mieszane zasoby w CSS i JS
Adresy HTTP mogą siedzieć nie tylko w treści strony, ale także w plikach CSS i JavaScript. Wtedy problem nie jest widoczny w edytorze wpisu, tylko w kodzie motywu, bibliotece slidera, efektach wizualnych lub zewnętrznych skryptach.
Rozwiązanie krok po kroku
Poniższy plan prowadzi od najprostszych do bardziej zaawansowanych działań. Najpierw wykonaj kopię zapasową bazy danych i plików. To ważne, ponieważ część operacji dotyka treści, ustawień i konfiguracji witryny. Jeśli coś pójdzie nie tak, backup pozwoli wrócić do poprzedniego stanu.
Krok 1: sprawdź, czy SSL działa poprawnie na poziomie serwera
Upewnij się, że certyfikat jest aktywny, nie wygasł i obejmuje właściwą domenę. Sprawdź, czy strona otwiera się po HTTPS bez błędów certyfikatu. Jeśli sam certyfikat jest źle zainstalowany, mixed content będzie tylko częścią większego problemu. W takiej sytuacji najpierw trzeba naprawić konfigurację SSL po stronie hostingu.
Krok 2: ustaw poprawne adresy w WordPressie
W panelu WordPressa wejdź w ustawienia ogólne i sprawdź pola „Adres WordPressa” oraz „Adres witryny”. Oba powinny zaczynać się od https://. Jeśli panel na to nie pozwala albo zmiany wracają do poprzedniej wartości, możliwe że adres jest nadpisywany w pliku konfiguracyjnym lub przez hosting.
Jeśli masz dostęp do pliku wp-config.php, sprawdź, czy nie ma tam stałych wymuszających HTTP. Czasem wpisy typu WP_HOME i WP_SITEURL blokują zmianę w panelu. Wtedy trzeba je poprawić lub usunąć, zachowując ostrożność.
Krok 3: zidentyfikuj konkretne zasoby HTTP
Otwórz stronę w przeglądarce, uruchom narzędzia deweloperskie i odszukaj zasoby ładowane po HTTP. Sprawdź:
- obrazki w treści wpisów,
- logo i ikony w nagłówku,
- pliki CSS i JS motywu,
- elementy osadzone z zewnętrznych serwisów,
- fonty i biblioteki ikon,
- adresy w stopce, widgetach i formularzach.
To ważne, ponieważ sama podmiana adresu strony nie usunie wszystkich problemów. Trzeba znaleźć źródło każdego błędnego odwołania.
Krok 4: wykonaj podmianę adresów w bazie danych
Najczęściej skuteczną metodą jest masowa podmiana http://twojadomena.pl na https://twojadomena.pl. Ale uwaga: nie należy robić tego zwykłym wyszukiwaniem i zamianą w dumpie SQL, jeśli baza zawiera dane serializowane. W WordPressie wiele wtyczek zapisuje dane w formacie serializowanym, a ręczna, nieprawidłowa podmiana może uszkodzić dane i rozbić stronę.
Bezpieczne podejście to narzędzie, które rozumie strukturę WordPressa i poprawnie aktualizuje serializowane dane. W praktyce używa się do tego dedykowanych narzędzi migracyjnych, WP-CLI albo wyspecjalizowanych wtyczek. Jeśli nie masz doświadczenia, nie rób „na skróty” globalnego replace bez wiedzy o serializacji.
Krok 5: sprawdź treści w edytorach i konstruktorach stron
Elementor, WPBakery, Divi i podobne narzędzia bardzo często przechowują adresy w osobnych polach. Jeśli problem dotyczy tylko części podstron, może się okazać, że trzeba przeliczyć lub odświeżyć dane w samym builderze. Warto przejrzeć ustawienia globalne: logo, faviconę, CTA, tła sekcji, ikony, przyciski, bannery i formularze.
Krok 6: przejrzyj motyw i wtyczki
Jeśli mixed content nadal występuje, sprawdź pliki motywu potomnego, własne fragmenty kodu, hooki i customowe wtyczki. Szukaj ręcznie wpisanych adresów http, także w plikach CSS i JS. Często winny jest pojedynczy fragment kodu, który lata całe działał poprawnie na HTTP i nikt go nie ruszał podczas migracji.
Krok 7: popraw zewnętrzne zasoby
Jeżeli problem dotyczy fontów, map, widgetów lub skryptów z zewnętrznych usług, spróbuj znaleźć ich wersję HTTPS. Jeśli dostawca jej nie oferuje, rozważ zastąpienie zasobu innym rozwiązaniem. Nie wszystkie zewnętrzne integracje są dziś bezpieczne lub kompatybilne z pełnym HTTPS.
Krok 8: wyczyść cache na każdym poziomie
Po zmianach usuń cache WordPressa, cache hostingu, CDN i przeglądarki. Jeśli używasz wtyczki do cache, wyczyść wszystkie warstwy, nie tylko frontend. Czasem stara wersja strony trzyma się właśnie w pamięci podręcznej i przez to wygląda, jakby naprawa nie zadziałała.
Krok 9: wymuś spójne HTTPS w zasobach wewnętrznych
Po naprawie głównych adresów warto upewnić się, że WordPress konsekwentnie generuje odnośniki HTTPS. Dobrą praktyką jest też sprawdzenie, czy wszystkie nowe treści, obrazy i linki wewnętrzne są dodawane już w bezpiecznej wersji. Inaczej problem wróci przy kolejnej publikacji lub aktualizacji.
Krok 10: przetestuj najważniejsze podstrony
Nie ograniczaj się do strony głównej. Sprawdź archiwum wpisów, stronę kontaktową, koszyk, checkout, formularze, landing page, galerie, sekcje z osadzonymi mapami i podstrony stworzone w builderze. Mixed content bardzo często ukrywa się właśnie tam, gdzie nikt nie zagląda na co dzień.
Najczęstsze błędy
- Zmiana tylko adresu strony w panelu bez sprawdzenia bazy danych i szablonów.
- Masowa podmiana SQL bez kopii zapasowej, co może uszkodzić serializowane dane.
- Ignorowanie cache, przez co naprawa wydaje się nieskuteczna.
- Zakładanie, że problem jest tylko w WordPressie, gdy winny jest serwer, CDN lub zewnętrzna usługa.
- Poprawianie jednego miejsca zamiast całego łańcucha zasobów: treść, motyw, wtyczki, CSS, JS.
- Wyłączanie ostrzeżeń przeglądarki zamiast usunięcia przyczyny.
- Pomijanie testów na mobile, gdzie niektóre zasoby mogą zachowywać się inaczej.
- Brak sprawdzenia formularzy i koszyka, choć właśnie tam mixed content potrafi najbardziej zaszkodzić.
Kiedy nie robić tego samodzielnie
Samodzielna naprawa jest sensowna, jeśli problem jest prosty i masz dostęp do panelu, plików oraz backupu. Są jednak sytuacje, w których lepiej się zatrzymać.
Nie działaj samodzielnie, jeśli:
- nie masz kopii zapasowej przed zmianami,
- strona jest sklepem internetowym i każda minuta przestoju kosztuje pieniądze,
- WordPress korzysta z rozbudowanego buildera i wielu niestandardowych pól,
- problem dotyczy danych serializowanych, a Ty nie wiesz, jak je bezpiecznie aktualizować,
- na stronie są niestandardowe integracje, API, systemy płatności lub rozbudowane formularze,
- hosting ma własne mechanizmy cache i nie masz pewności, jak je kontrolować,
- certyfikat SSL i konfiguracja serwera są nietypowe, na przykład za CDN lub reverse proxy.
W takich przypadkach jedno nieostrożne działanie może uszkodzić layout, formularze, koszyk lub treść. Mixed content bywa „niewinny” tylko z pozoru — czasem jego naprawa dotyka fundamentów działania strony.
Kiedy zgłosić się do specjalisty
Do specjalisty warto zgłosić się wtedy, gdy:
- próbowałeś już standardowych kroków, a ostrzeżenia nadal wracają,
- po zmianach pojawiają się błędy w wyglądzie lub działaniu strony,
- problem występuje tylko na wybranych podstronach i trudno go zlokalizować,
- strona korzysta z wielu wtyczek premium i customowego kodu,
- nie masz pewności, które zasoby są blokowane i dlaczego,
- potrzebujesz szybkiej naprawy bez ryzyka utraty danych,
- to witryna firmowa, sklep lub serwis, dla którego bezpieczeństwo i wiarygodność są kluczowe.
Specjalista nie tylko „przełączy HTTPS”, ale sprawdzi cały łańcuch: konfigurację serwera, certyfikat, ustawienia WordPressa, bazę danych, motyw, wtyczki, cache i zasoby zewnętrzne. Dzięki temu problem zwykle nie wraca po kilku dniach w nowej odsłonie.
Podsumowanie i CTA do kontaktu
Mixed content po wdrożeniu SSL w WordPressie to częsty, ale całkowicie realny problem. Nie oznacza, że certyfikat jest bezużyteczny. Oznacza raczej, że część strony nadal korzysta ze starych adresów HTTP albo z zasobów, które nie wspierają pełnego HTTPS. Dobra wiadomość jest taka, że w większości przypadków da się to naprawić bez przebudowy całej witryny.
Najważniejsze jest działanie w odpowiedniej kolejności: diagnoza, backup, poprawa ustawień, bezpieczna podmiana adresów, sprawdzenie motywu i wtyczek, a na końcu testy. Nie warto zgadywać. W mixed content liczy się dokładność, bo jeden nieprawidłowy adres może utrzymać ostrzeżenie mimo pozornie poprawnej konfiguracji.
Jeśli chcesz, żeby Twoja strona działała poprawnie po SSL, bez ostrzeżeń, bez ryzyka uszkodzenia danych i bez zgadywania, warto zlecić to osobie, która przeprowadzi pełną diagnozę i naprawę techniczną. Skontaktuj się ze specjalistą R99.PL, jeśli potrzebujesz bezpiecznego usunięcia mixed content w WordPressie i chcesz odzyskać pełne HTTPS bez stresu i przypadkowych błędów.
