W poprzednim wpisie pisaliśmy o zmianie w Chrome, która ma wejść w październiku 2026 roku razem z Chrome 154 — przeglądarka domyślnie zapyta użytkownika, czy na pewno chce wejść na publiczną stronę bez HTTPS.
Wtedy wspomnieliśmy o jednej rzeczy tylko na marginesie.
Że samo „mam certyfikat SSL" nie zawsze wystarcza.
Bo jest osobny problem, który dotyczy stron, które już przeszły na HTTPS. Nazywa się mixed content, czyli mieszana zawartość. I jest o tyle podstępny, że zwykle nie widać go na pierwszy rzut oka.
Czym jest mixed content?
Mixed content to sytuacja, w której strona otwiera się po bezpiecznym adresie https://, ale część elementów na niej ładuje się starym, niezabezpieczonym adresem http://.
Czyli: sama strona jest zaszyfrowana, ale jej kawałki już nie.
Przykład z życia. Strona firmowa działa pod https://twojafirma.pl, ale w treści podstrony „O nas" zostało zdjęcie wstawione lata temu jako http://twojafirma.pl/wp-content/uploads/zespol.jpg.
Dla użytkownika to jedno zdjęcie. Dla przeglądarki — niezabezpieczone połączenie w środku bezpiecznej strony.
I przeglądarka musi jakoś zareagować.
Dlaczego przeglądarki się tym przejmują?
Bo zaszyfrowanie samej strony niewiele daje, jeśli ktoś może podmienić to, co się na niej ładuje.
Najpoważniejszy przypadek to skrypt. Jeśli plik JavaScript wczytuje się po HTTP, ktoś po drodze może go podmienić — a skrypt ma dostęp do całej strony. Może podmienić numer konta, przechwycić dane z formularza, dokleić przekierowanie.
Przy obrazku ryzyko jest mniejsze, ale nadal istnieje: obrazek zdradza, co użytkownik ogląda, i może zostać podmieniony na coś innego.
Dlatego przeglądarki od kilku lat konsekwentnie zaostrzają zasady.
Dwa rodzaje mixed content — i dwie różne reakcje
To rozróżnienie tłumaczy, dlaczego jedne błędy widać od razu, a innych nie widać wcale.
Zawartość blokowana — skrypty JavaScript, arkusze stylów CSS, ramki iframe, czcionki, zapytania do API. To elementy, które mogą ingerować w całą stronę.
Ta zawartość jest blokowana. Bez pytania, bez ostrzeżenia dla użytkownika. Po prostu się nie wczyta.
Efekt? Rozjeżdżony układ strony, nieklikalne menu, slider, który nie startuje, mapa Google, która się nie pokazuje, formularz, który nie wysyła.
Zawartość podnoszona — obrazy, audio, wideo. Nie może modyfikować strony, więc traktowana jest łagodniej.
Tu przeglądarka próbuje najpierw automatycznie podmienić adres z http:// na https:// i pobrać zasób bezpiecznie. Jeśli się uda — użytkownik niczego nie zauważy. Jeśli serwer, z którego pochodzi plik, nie obsługuje HTTPS — element po prostu nie wczyta się wcale.
Jest jeszcze jeden szczegół, który potrafi zaskoczyć po migracji serwera: automatyczna podmiana nie działa, gdy w adresie zamiast nazwy domeny jest adres IP. http://example.com/obraz.png zostanie podniesiony. http://93.184.215.14/obraz.png— zablokowany bez próby ratunku.
I tu dochodzimy do sedna problemu.
Bo jeśli pliki leżą na Twoim własnym serwerze, który ma już certyfikat, automatyczna podmiana prawie zawsze działa. Błąd zostaje w kodzie, ale nikt go nie widzi.
Przynajmniej nie w Twojej przeglądarce.
„U mnie wszystko działa" to nie jest argument
Tu jest pułapka, na którą łatwo się nabrać. Sprawdzamy stronę u siebie, wygląda dobrze, więc zakładamy, że u wszystkich wygląda tak samo.
A przeglądarki dochodziły do dzisiejszych zasad różnymi drogami i w bardzo różnym tempie.
Chrome zaczął najwcześniej. Automatyczne podnoszenie audio i wideo do HTTPS pojawiło się w 2020 roku, a obrazów kilka miesięcy później. Od tamtej pory Chrome po cichu naprawia większość drobnych błędów w locie.
Firefox dogonił go dopiero w czerwcu 2024, w wersji 127. Dopiero od tamtej pory cała mieszana zawartość jest albo podnoszona do HTTPS, albo blokowana. Wcześniej Firefox po prostu wyświetlał obrazki po HTTP i sygnalizował to osłabioną kłódką.
Safari od dawna jest najbardziej restrykcyjne. Blokowanie całej mieszanej zawartości to jego domyślne zachowanie.
Widać, do czego to prowadzi.
Przez kilka lat istniał stan, w którym ta sama strona w Chrome wyglądała kompletnie, a w Safari brakowało na niej zdjęć. Właściciel siedzący przy Chrome nie miał o tym pojęcia. Klient na iPhonie widział dziurę w galerii.
Dlatego zdanie „przecież u mnie wszystko działa" znaczy tylko tyle, że akurat Twoja przeglądarka akurat dziś umiała to naprawić.
Najprostszy test zajmuje minutę: otwórz stronę w drugiej przeglądarce, najlepiej w Safari albo na telefonie. Jeśli coś wygląda inaczej — masz odpowiedź.
Skąd w ogóle biorą się takie błędy?
Prawie zawsze z historii strony.
Najczęstsze źródła, jakie spotykamy:
- Klonowanie i przenoszenie strony — po skopiowaniu witryny na nowy adres, przywróceniu kopii zapasowej albo przeniesieniu wersji testowej na docelowy adres, ustawienia adresu potrafią wrócić do wersji
http://. Baza danych jest kopiowana razem z nimi. - Stare wpisy i podstrony — treści dodane przed migracją na HTTPS mają zapisane pełne adresy
http://przy zdjęciach i linkach. - Motyw lub szablon — adresy wpisane na sztywno w plikach motywu, w kodzie stopki albo w opcjach kreatora stron.
- Wtyczki — zwłaszcza starsze, dołączające zewnętrzne biblioteki po HTTP.
- Zewnętrzne osadzenia — fonty, mapy, widgety opinii, czaty, piksele reklamowe, playery wideo dodane skryptem sprzed lat.
- Pliki do pobrania — cennik czy katalog PDF podlinkowany starym adresem.
- Reklamy i banery — kod wklejony kiedyś od partnera albo z sieci afiliacyjnej.
Do tego dochodzą rzeczy, o których łatwo zapomnieć: favicon, obrazek Open Graph do udostępniania w mediach społecznościowych, adres kanoniczny, mapa witryny, linki w automatycznych e-mailach z formularza.
Jak sprawdzić, czy mam ten problem?
Dobra wiadomość: sprawdzenie zajmuje kilka minut i nie wymaga dostępu do serwera.
1. Konsola przeglądarki
Otwórz swoją stronę w Chrome i naciśnij F12. Przejdź do zakładki Console. Komunikaty o mieszanej zawartości wypisują się tam wprost — razem z dokładnym adresem problematycznego pliku.
Warto przejść tak przez kilka różnych podstron, nie tylko przez stronę główną. Bardzo często problem siedzi w jednym starym wpisie na blogu albo na podstronie, której nikt nie otwierał od dwóch lat.
2. Podgląd kodu strony
Kliknij prawym przyciskiem → „Pokaż źródło strony", a potem Ctrl+F i wyszukaj frazę http://.
Tu jedna uwaga, żeby się niepotrzebnie nie przestraszyć. W nagłówku każdej strony WordPress znajdziesz adresy w rodzaju http://gmpg.org/xfn/11 albo http://www.w3.org/.... To nie są zasoby — to techniczne identyfikatory, których przeglądarka w ogóle nie pobiera. Nie trzeba ich ruszać.
Liczy się to, co ładuje się jako plik: obraz, skrypt, styl, ramka.
3. Zakładka Network
W tych samych narzędziach deweloperskich, w zakładce Network, widać wszystkie pobierane pliki. Można tam sprawdzić, które żądania zostały automatycznie podniesione do HTTPS, a które padły.
4. Gotowe narzędzie
Jeśli nie chcesz grzebać w narzędziach deweloperskich, przygotowaliśmy skaner, który robi to za Ciebie. Wklejasz kod źródłowy strony, a narzędzie wypisuje wszystkie adresy http:// i dzieli je na kategorie: co przeglądarka zablokuje, co podniesie, a co dotyczy tylko linków i danych dla wyszukiwarek. Pomija przy tym opisane wyżej fałszywe alarmy.
Sprawdza też najważniejszą rzecz: czy dany plik jest w ogóle dostępny pod adresem https://. Od tego zależy, czy poprawka to kwestia jednej litery, czy znalezienia zamiennika.
5. Google Search Console
Nie pokaże bezpośrednio mixed content, ale pokaże, czy Google indeksuje właściwą wersję adresów i czy nie ma problemów z przekierowaniami. To dobre uzupełnienie.
Jak to naprawić?
Kolejność ma znaczenie. Zaczynamy od źródła, nie od objawów.
Krok 1 — adres strony w ustawieniach
W WordPressie: Ustawienia → Ogólne. Adres WordPressa i adres witryny muszą zaczynać się od https://.
Brzmi banalnie i właśnie dlatego jest tak często pomijane. Z naszej praktyki to najczęstsza pojedyncza przyczyna problemów na stronach, które „przecież mają certyfikat" — i szczególnie często pojawia się po klonowaniu strony, przywróceniu starszej kopii zapasowej albo po przeniesieniu wersji testowej na docelowy adres.
Mechanizm jest prosty: ta wartość jest zapisana w bazie danych, a operacje na bazie kopiują ją razem z resztą. Certyfikat na serwerze działa, strona otwiera się po HTTPS, ale WordPress wewnętrznie nadal uważa, że mieszka pod adresem http://— i tak generuje adresy obrazków, skryptów i linków.
Jeśli te pola są wyszarzone i nie da się ich edytować, adresy są wpisane na sztywno w pliku wp-config.php przez stałe WP_HOME i WP_SITEURL. Wtedy poprawka idzie tam.
Krok 2 — przekierowanie z HTTP na HTTPS
Całe wejście przez http:// powinno trafiać przekierowaniem 301 na wersję bezpieczną. To ważne także dla SEO, żeby nie mieć dwóch wersji tej samej strony.
Krok 3 — poprawa adresów w bazie danych
Tu nie da się iść na skróty. Stare adresy trzeba podmienić w treści wpisów, stron, w polach dodatkowych i w opcjach motywu.
Robi się to narzędziem typu „szukaj i zamień" w bazie danych albo przez WP-CLI.
Bezwzględnie przed tą operacją: kopia zapasowa. Zamiana w bazie to coś, czego nie cofa się przyciskiem „wstecz", a przy źle wykonanej podmianie można rozsypać serializowane dane w opcjach motywu i kreatora stron.
Krok 4 — motyw, wtyczki, kod osadzony
To, czego nie ma w bazie, siedzi w plikach. Adresy wpisane na sztywno w motywie, stare biblioteki w nieaktualizowanych wtyczkach, kod widgetu wklejony ręcznie w stopce.
Przy zasobach zewnętrznych zacznij od sprawdzenia, czy ten sam plik nie jest po prostu dostępny pod adresem https://. Bardzo często jest — tylko nikt nigdy nie poprawił linku.
Zdarza się jednak, że nie ma. Stary katalog producenta, archiwalny dokument, serwis instytucji, która nie zmodernizowała serwera.
Wtedy najrozsądniejsze jest napisanie tego wprost. Krótki dopisek w nawiasie obok linku:
„Katalog techniczny (plik na serwerze producenta, sprawdzone — brak wersji zabezpieczonej, przeglądarka może pokazać ostrzeżenie)".
To rozwiązuje trzy rzeczy naraz. Użytkownik wie, czego się spodziewać, i nie odczyta ostrzeżenia jako oznaki, że coś jest nie tak z Twoją stroną. Widać, że sprawę sprawdzono, a nie przeoczono. A jeśli ktoś wróci do tematu za rok, ma zapisane, że to świadoma decyzja, a nie zapomniany błąd.
Uczciwe „wiem o tym i to sprawdziłem" buduje więcej zaufania niż milczenie, po którym klient trafia na ekran ostrzegawczy bez uprzedzenia.
Krok 5 — nagłówek upgrade-insecure-requests
To element polityki bezpieczeństwa treści (CSP). Mówi przeglądarce, żeby wszystkie żądania z tej strony automatycznie podnosiła do HTTPS.
Świetne jako zabezpieczenie na wypadek przeoczenia.
Ale — i to jest ważne — nie zastępuje naprawy. To siatka bezpieczeństwa, a nie rozwiązanie. Kod nadal jest błędny, tylko przeglądarka to nadrabia.
Krok 6 — sprawdzenie po fakcie
Po poprawkach: wyczyszczenie cache (wtyczki, serwera, CDN) i ponowne przejście przez konsolę na kilku podstronach. I koniecznie test w drugiej przeglądarce.
Cache potrafi pokazywać starą wersję strony jeszcze długo po naprawie i niepotrzebnie nastraszyć.
Uwaga na wtyczki „naprawiające SSL jednym kliknięciem"
Wtyczki, które obiecują naprawę mixed content, bywają przydatne — ale warto rozumieć, jak działają.
Duża część z nich nie poprawia treści w bazie danych. One przechwytują generowany kod strony i podmieniają adresy „w locie", przy każdym wczytaniu.
Skutek jest poprawny, ale ma trzy wady:
- problem nadal siedzi w bazie, więc wyłączenie wtyczki przywraca wszystkie błędy,
- każde wczytanie strony wymaga dodatkowej pracy serwera,
- przy zmianie motywu albo migracji sprawa wraca.
Traktujmy to jak plaster, a nie jak leczenie. Dobre na już, żeby strona wyglądała poprawnie, ale docelowo adresy powinny być poprawne w źródle.
A co ze zwykłymi linkami do stron HTTP?
To osobna sprawa, ale warto o niej pomyśleć właśnie teraz.
Link w treści do zewnętrznej strony działającej po HTTP nie jest mixed content — nic się nie wczytuje na Twojej stronie, dopóki użytkownik nie kliknie.
Ale od października 2026 taki klik może pokazać użytkownikowi ostrzeżenie Chrome, o którym pisaliśmy poprzednio.
Z punktu widzenia odwiedzającego wygląda to tak: klika na Twojej stronie, a przeglądarka pokazuje ekran z ostrzeżeniem. Formalnie to nie Twój problem. Praktycznie — to Twoja strona go tam wysłała.
Dlatego przy okazji porządków warto przejrzeć linki wychodzące, zwłaszcza w starszych wpisach i w katalogach partnerów. A tam, gdzie nie da się nic zrobić — zastosować ten sam uczciwy dopisek, o którym pisaliśmy wyżej.
Szybka lista kontrolna
- Adres strony w ustawieniach zaczyna się od
https:// - Wejście przez
http://przekierowuje na wersję bezpieczną (301) - Konsola przeglądarki nie pokazuje ostrzeżeń o mieszanej zawartości
- Sprawdzone są różne typy podstron, nie tylko strona główna
- Strona wygląda tak samo w Chrome, Firefoksie i Safari
- Stare wpisy i galerie mają poprawne adresy zdjęć
- Formularze, mapy, czaty i playery wideo działają
- Pliki do pobrania (PDF, cenniki) linkują po HTTPS
- Obrazek Open Graph i favicon mają bezpieczne adresy
- Zasoby, których nie da się naprawić, są opisane wprost przy linku
- Certyfikat SSL jest ważny i odnawia się automatycznie
- Search Console indeksuje wersję HTTPS
Podsumowanie
Mixed content to problem, który łatwo przeoczyć, bo przeglądarka przez lata coraz mocniej go za nas maskowała.
Skrypty są blokowane po cichu. Obrazki są podmieniane automatycznie. Użytkownik często nic nie widzi — dopóki nie otworzy strony w innej przeglądarce albo dopóki serwer z jakimś starym plikiem nie przestanie odpowiadać.
A kierunek zmian jest jeden: przeglądarki są coraz mniej wyrozumiałe dla wszystkiego, co jedzie po HTTP.
Skoro październik 2026 i tak wymusza przegląd konfiguracji HTTPS, to dobry moment, żeby zrobić to raz i porządnie. Nie tylko sprawdzić, czy kłódka jest, ale czy pod nią wszystko faktycznie działa tak, jak powinno.
Sprawdź co Twoja strona serwuje bez SSL: iFox.pl Domieszka
Nie chcesz sprawdzać tego samodzielnie?
Konsola przeglądarki, podmiana adresów w bazie danych, nagłówki bezpieczeństwa, cache — to nie są rzeczy, którymi właściciel firmy powinien zajmować się między spotkaniami.
Ale ktoś powinien.
W Studio iFOX sprawdzamy konfigurację HTTPS od strony technicznej: certyfikat, przekierowania, mieszaną zawartość, poprawność adresów w treści i to, czy po poprawkach strona nadal działa tak, jak ma działać — we wszystkich przeglądarkach, nie tylko w tej jednej.
Jeśli nie masz pewności, czy Twoja strona jest gotowa na zmianę w Chrome — napisz do nas. Sprawdzimy i powiemy wprost, czy trzeba coś naprawiać, czy wszystko jest już ustawione poprawnie.