Certyfikat może być całkowicie poprawny, a przeglądarka nadal oznacza stronę jako nie w pełni bezpieczną. Dzieje się tak, gdy dokument otwarty po HTTPS próbuje pobrać obraz, skrypt, arkusz CSS, font albo iframe przez zwykłe HTTP. W zależności od rodzaju zasobu przeglądarka może go zablokować lub tylko wyświetlić ostrzeżenie.
Szybka odpowiedź
Otwórz DevTools → Console/Network i sprawdź dokładny adres zasobu ładowanego po HTTP. Jeśli to pojedynczy URL w treści, popraw go w źródle. Jeśli problem występuje w setkach miejsc po migracji, potrzebna jest kontrolowana zmiana adresów w bazie — z obsługą danych serializowanych — oraz weryfikacja motywu, CSS i konfiguracji CDN.
Nie każdy adres HTTP jest w bazie
Zasób może być wpisany w treści strony, ustawieniach motywu, wygenerowany w CSS, pochodzić z widgetu, zewnętrznego skryptu albo ustawień pluginu. Zanim wykonasz masowy search-replace, sprawdź, skąd konkretny URL jest generowany. Dzięki temu nie modyfikujesz tysięcy rekordów, gdy problemem jest jedna linia konfiguracji.
Uważaj na dane serializowane
WordPress i wtyczki przechowują część ustawień jako serializowane struktury. Zwykła zamiana tekstu bez aktualizacji długości może je uszkodzić. Do migracji adresów używaj narzędzi świadomych formatu danych, na przykład WP-CLI search-replace, po wcześniejszym backupie i najlepiej z --dry-run.
HTTP w CSS i builderach
Background-image, font lub asset zapisany w wygenerowanym CSS może pozostać po HTTP nawet po poprawieniu treści. Page builder może wymagać ponownego wygenerowania plików CSS. Po zmianie wyczyść cache aplikacji i CDN, bo stary arkusz może być nadal serwowany użytkownikom.
Zewnętrzne zasoby bez HTTPS
Jeżeli integracja odwołuje się do serwera, który w ogóle nie obsługuje HTTPS, nie da się tego naprawić zmianą protokołu. Trzeba znaleźć bezpieczne źródło, hostować zasób u siebie, użyć innej integracji albo zrezygnować z elementu. Nie warto obniżać bezpieczeństwa całej witryny dla jednego starego widgetu.
Po naprawie sprawdź więcej niż stronę główną
Mixed content może występować tylko na formularzu, starej podstronie, wpisie blogowym albo w panelu. Przeskanuj reprezentatywny zestaw adresów i zweryfikuj konsolę. Dodatkowo ustaw konsekwentne przekierowanie HTTP→HTTPS, aby użytkownicy nie wchodzili na nieszyfrowany wariant.
Jak potwierdzić, że naprawa naprawdę działa?
Po zmianie przeskanuj nie tylko HTML strony głównej, ale również CSS, widoki mobilne, podstrony z formularzami i starsze wpisy. Konsola przeglądarki powinna być wolna od komunikatów mixed content, a Network nie powinien zawierać zasobów http:// dla własnej domeny. Jeśli wykorzystujesz CDN do obrazów, zweryfikuj także warianty generowane dynamicznie — stary URL może być zapisany w cache lub regule transformacji.
Co obserwować po zmianie?
Warto sprawdzić bazę pod kątem starego protokołu, ale wynik traktuj jako listę do analizy, a nie automatyczny plan zamiany. Część adresów może celowo wskazywać zewnętrzne źródła lub tekst archiwalny. Po masowym search-replace porównaj liczbę zmienionych rekordów z dry-runem i sprawdź, czy serializowane ustawienia wtyczek nadal otwierają się poprawnie.
Kiedy przekazać temat dalej?
Jeśli mixed content dotyczy skryptu płatności, logowania lub formularza, potraktuj problem jako pilny. Aktywny zasób HTTP może zostać zablokowany przez przeglądarkę i zepsuć funkcję, nawet jeśli strona wygląda poprawnie. W takiej sytuacji lepiej usunąć lub zastąpić integrację niż próbować „wyciszyć” ostrzeżenie.
Praktyczny scenariusz diagnostyczny
Po włączeniu HTTPS często okazuje się, że ikona kłódki nadal nie jest poprawna, bo motyw ładuje obraz tła lub skrypt ze starego adresu http://. Otwórz narzędzia deweloperskie, zobacz dokładny URL blokowanego zasobu i ustal, skąd pochodzi: treść wpisu, opcja motywu, widget, CSS, baza czy zewnętrzna integracja. Następnie popraw źródło danych, a nie tylko wynik w HTML. Masowa zamiana w bazie wymaga ostrożności przy danych serializowanych, dlatego najlepiej używać narzędzia, które rozumie format WordPressa. Po zmianie wyczyść cache i sprawdź kilka typów podstron. Jedna czysta strona główna nie gwarantuje, że stary adres nie został zapisany np. w archiwalnym wpisie albo szablonie produktu.
Bezpieczna kolejność działań
- Sprawdź konsolę przeglądarki i zapisz adresy HTTP.
- Ustal źródło każdego problematycznego URL-u.
- Przed zmianą bazy wykonaj backup.
- Do masowej zmiany użyj narzędzia obsługującego serializację.
- Wyczyść i odtwórz cache/CSS po zmianach.
- Przetestuj różne typy podstron oraz przekierowanie HTTP→HTTPS.
Czego nie robić
Nie wykonuj globalnego replace http:// na https:// na surowym eksporcie SQL bez wiedzy o serializacji. Nie ignoruj aktywnego mixed content dla skryptów — przeglądarka może je blokować, co potrafi zepsuć formularze lub funkcje strony.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeśli po migracji lub wdrożeniu SSL strona nadal miesza HTTP z HTTPS, możemy znaleźć wszystkie źródła starych adresów, bezpiecznie poprawić bazę i konfigurację oraz przetestować cache i CDN.
Najczęściej zadawane pytania
Czy mixed content oznacza zły certyfikat?
Nie. Certyfikat może być ważny, a problem wynika z zasobów ładowanych przez niezabezpieczony HTTP.
Czy wystarczy wtyczka do SSL?
Czasem maskuje część problemów, ale lepiej poprawić źródłowe adresy i konfigurację, zamiast polegać na przepisywaniu URL-i przy każdym żądaniu.
Czy obrazy po HTTP są groźne?
To tzw. pasywny mixed content; przeglądarki traktują go łagodniej niż skrypty, ale nadal psuje spójność bezpieczeństwa i powinien być poprawiony.
Czy po zmianie trzeba czyścić cache?
Tak. Stare HTML lub CSS mogą nadal zawierać adresy HTTP mimo poprawionej bazy.