Kłódka z ostrzeżeniem w WordPressie. Jak znaleźć zasoby wczytywane po http?

Certyfikat SSL jest zainstalowany, adres zaczyna się od https, a przeglądarka mimo to pokazuje przy adresie kłódkę z ostrzeżeniem albo informację, że strona nie jest w pełni bezpieczna. W zdecydowanej większości takich przypadków certyfikat działa poprawnie. Kłopot leży w samej stronie: część obrazków, arkuszy stylów, skryptów lub czcionek nadal jest pobierana pod starym adresem zaczynającym się od http.

Zjawisko nosi nazwę treści mieszanych (ang. mixed content) i w WordPressie pojawia się najczęściej po przejściu z http na https, po przeniesieniu witryny na inny serwer albo po wklejeniu do wpisu starego kodu. Ten tekst jest przeznaczony dla właścicieli firm i osób, które same opiekują się swoją witryną, bez pomocy programisty.

Po lekturze czytelnik będzie umiał wskazać w przeglądarce każdy zasób wczytywany po http, ustalić, w którym miejscu WordPressa zapisany jest jego adres, poprawić go w bezpieczny sposób i sprawdzić, czy ostrzeżenie zniknęło na dobre.

Po czym rozpoznać, że winne są zasoby wczytywane po http?

Objawy zależą od przeglądarki. Firefox pokazuje przy adresie kłódkę ze znakiem ostrzeżenia, a po jej kliknięciu informację, że części strony nie są zabezpieczone. Chrome po kliknięciu ikony obok adresu wyświetla opis stanu połączenia, a przy poważniejszych brakach napis „Niezabezpieczona”. Safari zachowuje się najsurowiej i niezabezpieczonych elementów zazwyczaj w ogóle nie wczytuje.

Drugi rodzaj objawów widać na samej stronie. Znika część obrazków, strona traci układ, bo nie wczytał się arkusz stylów, nie działa suwak, mapa, formularz albo osadzony film. Często dzieje się tak tylko na niektórych podstronach, na przykład na starszych wpisach, podczas gdy strona główna wygląda poprawnie.

Trzeba odróżnić tę sytuację od dwóch innych. Jeżeli cała strona otwiera się pod adresem zaczynającym się od http, problemem jest brak przekierowania na https, a nie treści mieszane. Jeżeli zamiast strony pojawia się pełnoekranowe ostrzeżenie „Połączenie nie jest prywatne”, kłopot dotyczy samego certyfikatu. Obie sprawy opisałem osobno w tekście o tym, jak przejść na https bez strat.

Najprostszy test rozstrzygający zajmuje minutę. Należy otworzyć podstronę z ostrzeżeniem, nacisnąć klawisz F12 i przejść do karty „Konsola”. Jeżeli pojawiają się tam wiersze zaczynające się od słów Mixed Content, diagnoza jest pewna i dalsze kroki z tej instrukcji mają zastosowanie.

Dlaczego przeglądarka ostrzega, skoro certyfikat działa?

Połączenie https szyfruje dokument strony, ale każdy obrazek, skrypt, arkusz stylów i czcionka to osobne żądanie wysyłane przez przeglądarkę. Jeśli adres takiego zasobu zaczyna się od http, to żądanie biegnie bez szyfrowania. Ktoś, kto ma dostęp do sieci po drodze, może taki zasób podejrzeć albo podmienić. Najgroźniejsze są skrypty, ponieważ podmieniony skrypt może zmienić dowolny fragment strony, łącznie z formularzem płatności.

Przeglądarki dzielą treści mieszane na dwie grupy i każdą traktują inaczej. Pierwsza grupa to zasoby, które przeglądarka sama próbuje pobrać po https: obrazki wstawione zwykłym znacznikiem <img src>, obrazy tła w stylach oraz pliki dźwiękowe i filmy. Jeżeli serwer udostępnia taki plik także po https, użytkownik niczego nie zauważy. Jeżeli nie udostępnia, w miejscu obrazka zostaje puste pole.

Druga grupa to zasoby blokowane od razu, bez próby naprawy. Należą do niej skrypty, arkusze stylów, ramki <iframe>, czcionki internetowe, żądania wysyłane przez skrypty w tle, a także obrazki podane w atrybucie srcset. Ten ostatni punkt jest w WordPressie szczególnie ważny, bo system sam dopisuje atrybut srcset do obrazków we wpisach. Blokowane są również zasoby wskazane adresem IP zamiast nazwy domeny.

Zwykłe odnośniki, czyli znaczniki <a href> prowadzące do innych stron, nie są treściami mieszanymi. Kliknięcie odnośnika otwiera nową stronę, a nie wczytuje zasobu do bieżącej. Wyjątkiem są galerie, w których kliknięcie miniatury otwiera duże zdjęcie w okienku na tej samej stronie. Wtedy adres z odnośnika staje się zasobem i musi zaczynać się od https.

Od czego zacząć: kopia zapasowa i adresy witryny w ustawieniach

Część napraw opisanych niżej zmienia zawartość bazy danych. Pomyłka w takiej operacji potrafi uszkodzić ustawienia motywu i widżetów, dlatego przed pierwszą zmianą trzeba wykonać pełną kopię plików i bazy oraz upewnić się, że da się ją odtworzyć. Sposób wykonania i sprawdzenia opisałem w tekście o tym, jak przygotować kopię zapasową WordPressa, która naprawdę działa.

Następnie należy sprawdzić dwa podstawowe adresy, z których WordPress buduje niemal wszystkie pozostałe. Kolejność czynności jest następująca:

1. W kokpicie należy otworzyć „Ustawienia”, a następnie „Ogólne”.
2. W polach „Adres WordPressa (URL)” oraz „Adres witryny (URL)” oba adresy powinny zaczynać się od https i mieć tę samą postać, z przedrostkiem www albo bez niego, zgodnie z adresem, pod którym witryna faktycznie działa.
3. Jeżeli któryś adres zaczyna się od http, trzeba dopisać literę „s” i kliknąć „Zapisz zmiany”. WordPress wyloguje użytkownika i poprosi o ponowne zalogowanie.
4. Jeżeli pola są wyszarzone i nie da się ich edytować, adresy zostały wpisane na stałe w pliku wp-config.php jako stałe WP_HOME i WP_SITEURL. Wtedy poprawkę wprowadza się w tym pliku, przez menedżer plików w panelu hostingu albo przez FTP.
5. Na koniec warto otworzyć „Narzędzia”, potem „Zdrowie witryny” i przeczytać wynik testu dotyczącego HTTPS. Jeżeli witryna obsługuje https, a adresy nadal są stare, WordPress proponuje tam przełączenie obu adresów jednym przyciskiem.

Przełączenie adresów przyciskiem na ekranie „Zdrowie witryny” ma dodatkowy skutek. WordPress zaczyna wtedy w locie zamieniać stare adresy własnej domeny w treści wpisów, zajawkach, widżetach tekstowych i dodatkowym kodzie CSS. To wygodne zabezpieczenie, ale niepełne: nie obejmuje ustawień motywu, pól kreatorów stron, plików motywu ani zasobów z obcych domen. Dlatego po tej czynności i tak trzeba przejść do szukania.

Zmiana obu adresów na https wymaga działającego certyfikatu. Jeśli certyfikatu nie ma albo wygasł, po zapisaniu zmian kokpit przestanie się otwierać. Przed kliknięciem „Zapisz zmiany” należy więc wpisać w przeglądarce adres witryny z https i potwierdzić, że strona się otwiera bez ostrzeżenia o certyfikacie.

Jak znaleźć zasoby wczytywane po http w narzędziach przeglądarki?

Najdokładniejszym źródłem informacji jest sama przeglądarka, ponieważ to ona decyduje, co zablokować. Opisuję przeglądarkę Chrome na komputerze. W Firefoksie i Edge’u czynności są bardzo podobne, a nazwy kart niemal takie same.

1. Należy otworzyć podstronę, na której pojawia się ostrzeżenie, najlepiej w oknie incognito, żeby wykluczyć wpływ rozszerzeń i zapisanych plików.
2. Narzędzia deweloperskie otwiera klawisz F12 albo skrót Ctrl + Shift + I (na komputerach Mac: Command + Option + I).
3. W karcie „Konsola” trzeba odświeżyć stronę klawiszem F5. Konsola jest czyszczona przy każdym przejściu na inną podstronę, więc odczyt dotyczy wyłącznie strony aktualnie wyświetlanej.
4. Każdy wiersz zaczynający się od słów Mixed Content zawiera dwa adresy: adres podstrony oraz adres zasobu wczytywanego po http. Ten drugi adres należy skopiować do notatki razem z adresem podstrony.
5. Po prawej stronie wiersza widać nazwę pliku i numer linii. Kliknięcie tej nazwy pokazuje miejsce w kodzie, z którego zasób został wywołany, co ułatwia ustalenie, czy odpowiada za niego treść wpisu, motyw czy wtyczka.

Komunikaty występują w dwóch odmianach i warto je rozróżniać. Pierwsza kończy się informacją, że żądanie zostało automatycznie zmienione na https:

Mixed Content: The page at 'https://example.pl/oferta/' was loaded over HTTPS, but requested an insecure element 'http://example.pl/wp-content/uploads/zdjecie.jpg'. This request was automatically upgraded to HTTPS

Druga informuje o zablokowaniu zasobu i to ona odpowiada za rozsypany wygląd lub niedziałające funkcje:

Mixed Content: The page at 'https://example.pl/oferta/' was loaded over HTTPS, but requested an insecure script 'http://example.pl/wp-content/themes/motyw/js/skrypt.js'. This request has been blocked; the content must be served over HTTPS.

Słowo po „insecure” mówi, jaki to rodzaj zasobu: obrazek, skrypt, arkusz stylów, ramka albo czcionka. Pierwszy rodzaj komunikatu oznacza, że plik jest dostępny po https i wystarczy poprawić adres. Drugi wymaga naprawy w pierwszej kolejności.

Panel „Prywatność i bezpieczeństwo” i filtr w karcie „Sieć”

Chrome ma także osobny panel, który zbiera te informacje w jednym miejscu. W prawym górnym rogu narzędzi deweloperskich trzeba kliknąć ikonę trzech kropek, wybrać „Więcej narzędzi”, a potem „Prywatność i bezpieczeństwo”. W części „Bezpieczeństwo” pojawia się pozycja „Niebezpieczne źródła” z listą domen, z których strona pobiera zasoby bez szyfrowania.

Po wybraniu tej pozycji należy kliknąć „Wyświetlaj żądania w panelu Sieć”. Narzędzia przechodzą wtedy do karty „Sieć” i same ustawiają filtr, dzięki któremu na liście zostają wyłącznie zasoby niezabezpieczone. Ten sam efekt daje wpisanie w polu filtra karty „Sieć” wyrażenia mixed-content:all i odświeżenie strony.

Na liście warto kliknąć prawym przyciskiem myszy nagłówek tabeli i włączyć kolumnę „Inicjator”. Pokazuje ona, który plik wywołał dane żądanie. Jeśli inicjatorem jest plik z katalogu /wp-content/plugins/, źródłem jest wtyczka o nazwie widocznej w ścieżce. Jeśli plik z katalogu /wp-content/themes/, odpowiada motyw.

Badanie trzeba powtórzyć na kilku typach podstron: stronie głównej, pojedynczym wpisie, stronie kategorii, stronie kontaktu z mapą i formularzem, a w sklepie także na karcie produktu i w koszyku. Każdy z tych szablonów wczytuje inne zasoby, więc czysta konsola na stronie głównej niczego jeszcze nie przesądza.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Przejmę wtedy sprawę: sprawdzę wszystkie typy podstron, wskażę każdy zasób wczytywany po http, poprawię adresy w bazie, motywie i wtyczkach, a na koniec potwierdzę, że ostrzeżenie zniknęło.

Jak ustalić, w którym miejscu WordPressa zapisany jest stary adres?

Lista z konsoli mówi, co jest wczytywane po http. Do naprawy trzeba jeszcze wiedzieć, skąd dany adres trafia do kodu strony. Pomaga w tym podgląd źródła: skrót Ctrl + U otwiera kod strony, a Ctrl + F pozwala wyszukać w nim ciąg http://. Wyniki należy przejrzeć po kolei i zwrócić uwagę na atrybuty src, srcset, data-src, action oraz na znaczniki <link> wczytujące arkusze stylów.

Nie każde wystąpienie tego ciągu jest błędem. Bez znaczenia są zwykłe odnośniki do innych stron, deklaracje przestrzeni nazw w znacznikach SVG oraz adresy w danych strukturalnych, ponieważ przeglądarka niczego spod nich nie pobiera. Liczą się wyłącznie adresy, spod których strona wczytuje pliki.

Adres własnej domeny w treści wpisu lub strony

To najczęstszy przypadek. Obrazki dodawane do wpisów w czasach, gdy witryna działała pod http, zostały zapisane w treści z pełnym adresem i zmiana ustawień ich nie przepisała. Rozpoznać go łatwo: adres zasobu prowadzi do katalogu /wp-content/uploads/, a problem dotyczy starszych wpisów. Naprawą jest zamiana adresów w bazie danych, opisana w kolejnej sekcji.

Adres zapisany w ustawieniach motywu, widżetach lub kreatorze stron

Logo, obrazek tła, ikona witryny, grafiki w stopce i suwaki są przechowywane poza treścią wpisów: w ustawieniach motywu, w widżetach albo w osobnych polach kreatora stron. Podpowiedzią jest to, że zasób pojawia się na każdej podstronie w tym samym miejscu, w nagłówku lub stopce. Tu również pomaga zamiana w bazie, a w razie potrzeby ponowne wybranie pliku w ustawieniach motywu.

Adres wpisany na stałe w plikach motywu lub wtyczki

Jeżeli zasób to skrypt, czcionka albo arkusz stylów, a kolumna „Inicjator” wskazuje plik motywu lub wtyczki, adres bywa wpisany bezpośrednio w kodzie. Zdarza się to w starszych, od dawna nieaktualizowanych motywach i w kodach wklejonych ręcznie do nagłówka, na przykład w kodzie czcionek lub starego licznika odwiedzin.

Adres wewnątrz arkusza stylów

Bywa, że sam arkusz stylów wczytuje się po https, ale w jego wnętrzu znajdują się adresy obrazów tła lub czcionek zaczynające się od http. W konsoli widać wtedy jako źródło plik z rozszerzeniem .css. Dotyczy to często plików tworzonych przez kreatory stron i wtyczki pamięci podręcznej, które raz wygenerowały arkusz ze starymi adresami i od tamtej pory podają go bez zmian.

Zasób z obcej domeny

Ostatnia grupa to elementy osadzone z zewnątrz: ramki z mapą lub filmem, skrypty czatu, banery partnerów, czcionki i obrazki podlinkowane z cudzych serwerów. Adres zasobu zaczyna się wtedy od innej domeny niż domena witryny. Zamiana w bazie własnego adresu niczego tu nie zmieni i każdy taki zasób trzeba poprawić osobno.

Jak poprawić stare adresy zapisane w bazie danych?

Zamiana adresu w bazie polega na wyszukaniu wszystkich wystąpień starego adresu witryny i zastąpieniu ich nowym. Nie wolno robić tego zwykłym zapytaniem SQL w phpMyAdmin ani przez edycję pliku z kopią bazy w edytorze tekstu. WordPress i wtyczki przechowują wiele ustawień w postaci danych serializowanych, w których zapisana jest także długość każdego tekstu. Dopisanie jednej litery bez przeliczenia tej długości sprawia, że całe ustawienie przestaje się odczytywać.

Bezpieczne są narzędzia, które tę budowę rozumieją. Na serwerach z dostępem do wiersza poleceń najlepszym wyborem jest WP-CLI, oficjalne narzędzie WordPressa. Tam, gdzie takiego dostępu nie ma, używa się wtyczki do wyszukiwania i zamiany w bazie, która obsługuje dane serializowane i ma tryb próbny, na przykład Better Search Replace.

1. Wykonanie i sprawdzenie kopii bazy danych. Bez tego kroku nie należy przechodzić dalej.
2. Ustalenie dokładnej postaci starego adresu. Jeżeli witryna działała kiedyś z przedrostkiem www i bez niego, zamianę trzeba będzie przeprowadzić osobno dla każdej postaci.
3. Uruchomienie trybu próbnego. W WP-CLI służy do tego parametr --dry-run, a we wtyczce pole wyboru opisujące przebieg testowy. Narzędzie pokazuje wtedy, w których tabelach i ile wystąpień znalazło, ale niczego nie zapisuje.
4. Ocena wyniku. Kilkadziesiąt lub kilkaset wystąpień w tabelach z wpisami, polami dodatkowymi i ustawieniami to typowy obraz. Zero wystąpień oznacza, że stary adres został wpisany w innej postaci albo problem leży poza bazą.
5. Uruchomienie właściwej zamiany, już bez trybu próbnego, z pominięciem kolumny guid.
6. Wyczyszczenie pamięci podręcznej witryny i ponowne sprawdzenie konsoli na tych samych podstronach co wcześniej.

W WP-CLI przebieg próbny dla przykładowej domeny wygląda tak:

wp search-replace 'http://example.pl' 'https://example.pl' --skip-columns=guid --dry-run

Po sprawdzeniu raportu to samo polecenie uruchamia się bez końcówki --dry-run. Jako szukany tekst należy podawać pełny adres z nazwą domeny, nigdy sam ciąg http://. Zamiana samego przedrostka zmieniłaby także adresy cudzych stron, do których prowadzą odnośniki we wpisach, a część z nich może nie działać po https.

Kolumnę guid pomija się celowo. Zawiera ona stały identyfikator wpisu, z którego korzystają czytniki kanałów RSS, i nie służy do wyświetlania czegokolwiek na stronie. Jej zmiana niczego nie naprawia, a może sprawić, że czytniki uznają stare wpisy za nowe.

Niektóre kreatory stron zapisują adresy w postaci, w której ukośniki są poprzedzone znakiem odwrotnego ukośnika, na przykład http:\/\/example.pl. Zwykła zamiana takich zapisów nie obejmie. Jeżeli po zamianie w konsoli nadal widać stare adresy na stronach zbudowanych kreatorem, trzeba poszukać w jego ustawieniach narzędzia do zamiany adresu URL oraz przycisku ponownego generowania plików CSS. Większość popularnych kreatorów ma obie funkcje w swoim dziale narzędzi.

Co zrobić z zasobami z motywu, wtyczek i obcych serwerów?

Zasoby spoza bazy danych wymagają pojedynczych poprawek. Zaczyna się od najprostszej czynności, czyli od aktualizacji motywu i wtyczek. Autorzy utrzymywanych rozszerzeń dawno usunęli adresy http ze swojego kodu, więc sama aktualizacja często rozwiązuje sprawę. Motyw lub wtyczkę, która od lat nie otrzymała aktualizacji i nadal wczytuje zasoby po http, radzę wymienić na utrzymywany odpowiednik.

Jeżeli adres został wklejony ręcznie, na przykład w polu na własny kod w nagłówku, w widżecie z kodem HTML albo w ustawieniach wtyczki do wstawiania skryptów, wystarczy otworzyć to pole i zmienić początek adresu na https. Zmian w plikach motywu nie należy wprowadzać bezpośrednio w motywie głównym, ponieważ najbliższa aktualizacja je nadpisze. Do tego służy motyw potomny.

Arkusze stylów ze starymi adresami w środku naprawia się przez ich ponowne wygenerowanie. W praktyce oznacza to wyczyszczenie pamięci podręcznej we wtyczce optymalizującej, usunięcie połączonych i zminimalizowanych plików CSS oraz użycie funkcji odtwarzania plików CSS w kreatorze stron. Jeśli witryna korzysta z sieci CDN, pamięć podręczną trzeba wyczyścić także w jej panelu.

Gdy zewnętrzny zasób nie jest dostępny po https

W przypadku zasobu z obcej domeny najpierw trzeba sprawdzić, czy jest on dostępny w wersji szyfrowanej. Wystarczy skopiować jego adres do nowej karty, zmienić początek na https i nacisnąć Enter. Jeżeli plik się otwiera, poprawka polega na zmianie adresu w miejscu, w którym został wstawiony.

Jeżeli pod adresem z https plik się nie otwiera, zostają trzy rozwiązania zalecane w dokumentacji Google dla twórców stron. Pierwsze to dołączenie tego samego zasobu z innego serwera, który obsługuje https. Drugie to pobranie pliku i umieszczenie go na własnym serwerze, o ile licencja na to pozwala. Trzecie to całkowita rezygnacja z zasobu.

Przy drugim rozwiązaniu potrzebna jest ostrożność prawna. Cudzego zdjęcia, czcionki czy skryptu nie wolno kopiować na własny serwer bez zgody uprawnionego albo licencji, która na to pozwala. W razie wątpliwości bezpieczniej jest poprosić dostawcę o wersję dostępną po https albo wybrać inny zasób o jasnych warunkach użycia.

Osadzone ramki z mapami, filmami i formularzami najłatwiej naprawić przez ponowne pobranie kodu do osadzenia ze strony dostawcy. Aktualne kody zawierają już adresy https, a stare, wklejone przed laty, często nie. Podobnie postępuje się z formularzami: jeżeli panel „Prywatność i bezpieczeństwo” zgłasza formularz wysyłający dane pod adres http, trzeba poprawić adres w atrybucie action albo w ustawieniach wtyczki formularza.

Dlaczego WordPress nadal tworzy adresy http, choć ustawienia są poprawne?

Zdarza się sytuacja pozornie bez wyjścia: oba adresy w ustawieniach zaczynają się od https, baza jest poprawiona, a WordPress nadal wstawia do kodu adresy skryptów i stylów z http. Przyczyną jest zwykle pośrednik stojący przed serwerem, na przykład sieć CDN, zapora aplikacyjna albo serwer pośredniczący u dostawcy hostingu.

W takim układzie odwiedzający łączy się z pośrednikiem po https, ale pośrednik przekazuje żądanie do serwera z WordPressem po http. WordPress widzi wtedy nieszyfrowane połączenie i uczciwie buduje adresy z http. Rozpoznać to można po tym, że stare adresy dotyczą plików samego WordPressa, motywu i wtyczek, a nie obrazków we wpisach.

Najlepszym rozwiązaniem jest szyfrowanie na całej drodze, czyli certyfikat także na serwerze z witryną i taki tryb pracy pośrednika, w którym łączy się on z serwerem po https. W panelach sieci CDN ustawienie to znajduje się w dziale dotyczącym SSL.

Dokumentacja WordPressa opisuje też poprawkę dla witryn, które muszą pozostać za takim pośrednikiem. Polega ona na dopisaniu w pliku wp-config.php, powyżej wiersza kończącego edycję ustawień, fragmentu rozpoznającego nagłówek przekazywany przez pośrednika:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

Fragment działa tylko wtedy, gdy pośrednik rzeczywiście wysyła nagłówek X-Forwarded-Proto. Przed zmianą trzeba zachować kopię pliku, ponieważ błąd składni w wp-config.php wyłącza całą witrynę. Jeżeli po zmianach ustawień SSL strona zaczyna krążyć między adresami, pomocny będzie mój tekst o tym, jak usunąć błąd ERR_TOO_MANY_REDIRECTS w WordPressie.

Czy nagłówek upgrade-insecure-requests załatwia sprawę?

Istnieje sposób, który usuwa ostrzeżenie bez poprawiania adresów. Serwer może wysyłać nagłówek z poleceniem, aby przeglądarka sama zamieniała każdy adres http na https jeszcze przed wysłaniem żądania. Obejmuje to także skrypty, arkusze stylów i ramki, których przeglądarka z własnej inicjatywy nie poprawia. Na serwerach Apache z włączonym modułem nagłówków wystarczy dopisać w pliku .htaccess:

<IfModule mod_headers.c>
Header always set Content-Security-Policy "upgrade-insecure-requests"
</IfModule>

Traktuję ten nagłówek jako zabezpieczenie na czas porządków, a nie jako naprawę, ponieważ ma dwa ograniczenia. Po pierwsze, jeśli zasób nie istnieje pod adresem z https, żądanie po zamianie po prostu się nie powiedzie i element nadal nie zostanie wczytany. Po drugie, stare adresy pozostają w bazie i w kodzie, więc wracają przy każdej okazji: w kanale RSS, w wiadomościach wysyłanych z witryny, po wyłączeniu nagłówka albo po przeniesieniu strony na inny serwer.

Po czym poznać, że naprawa zadziałała, i jakich błędów unikać?

Sprawdzenie trzeba przeprowadzić tak, aby wynik nie pochodził z plików zapamiętanych przez przeglądarkę lub serwer. Kolejność jest następująca:

1. Wyczyszczenie pamięci podręcznej we wtyczce, w panelu hostingu i w sieci CDN, jeżeli witryna z nich korzysta.
2. Otwarcie podstrony w oknie incognito z włączonymi narzędziami deweloperskimi i odświeżenie jej skrótem Ctrl + Shift + R, który pomija pliki zapisane w przeglądarce.
3. Kontrola karty „Konsola”: nie powinno w niej być żadnego wiersza zaczynającego się od słów Mixed Content, także tych z informacją o automatycznej zamianie.
4. Kontrola panelu „Prywatność i bezpieczeństwo”: na liście nie powinna występować pozycja „Niebezpieczne źródła”.
5. Powtórzenie sprawdzenia na wszystkich typach podstron zapisanych w notatce z etapu szukania oraz w drugiej przeglądarce, najlepiej w Firefoksie, gdzie przy adresie powinna pojawić się zwykła kłódka.

Na większych witrynach ręczne przeglądanie każdej podstrony nie jest realne. Wtedy używa się programu, który przechodzi po wszystkich adresach witryny i wypisuje podstrony z zasobami wczytywanymi po http. Taki przegląd wchodzi zwykle w zakres szerszej kontroli technicznej, którą opisałem w tekście o tym, co sprawdzić podczas audytu SEO strony.

Gdy ostrzeżenie nie znika

Jeżeli po naprawie konsola nadal pokazuje te same adresy, najczęstszą przyczyną jest pamięć podręczna, która wciąż podaje stary kod strony. Warto na chwilę wyłączyć wtyczkę pamięci podręcznej i sprawdzić podstronę ponownie. Jeżeli adresy znikły, wystarczy pełne wyczyszczenie pamięci i ponowne zbudowanie plików.

Drugą przyczyną bywa inna postać starego adresu: z przedrostkiem www, z odwrotnymi ukośnikami, z dawną domeną sprzed przeprowadzki albo z adresem tymczasowym serwera. Adres widoczny w konsoli należy porównać znak po znaku z tym, który był zamieniany, i powtórzyć zamianę dla właściwej postaci.

Błędy, które zdarzają się najczęściej

• Zamiana adresów w bazie bez kopii zapasowej albo zwykłym zapytaniem SQL, co uszkadza dane serializowane.
• Zamiana samego przedrostka http na https we wszystkich tabelach, łącznie z adresami cudzych stron.
• Poprzestanie na wtyczce lub nagłówku, które ukrywają ostrzeżenie, bez poprawienia adresów u źródła.
• Sprawdzenie wyłącznie strony głównej i uznanie sprawy za zamkniętą.
• Poprawki wprowadzane bezpośrednio w plikach motywu głównego, które znikają przy aktualizacji.
• Kopiowanie cudzych plików na własny serwer bez sprawdzenia, czy pozwala na to licencja.

Najczęstsze pytania

Czy treści mieszane szkodzą widoczności strony w Google?

Samo ostrzeżenie nie jest karą ze strony wyszukiwarki, ale skutki pośrednie są realne. Zablokowany arkusz stylów lub skrypt sprawia, że strona wyświetla się niepoprawnie, a odwiedzający szybciej z niej wychodzą. Google zaleca, aby strona działająca pod https wczytywała wszystkie swoje zasoby w ten sam sposób, dlatego radzę doprowadzić konsolę do stanu bez żadnych komunikatów.

Dlaczego ostrzeżenie pojawia się tylko na niektórych podstronach?

Ponieważ stary adres jest zapisany w treści konkretnego wpisu albo w elemencie używanym tylko przez jeden szablon. Typowe przykłady to wpis sprzed zmiany protokołu ze zdjęciem wstawionym z pełnym adresem, strona kontaktu ze starym kodem mapy oraz karta produktu z osadzonym filmem. Każdą taką podstronę trzeba sprawdzić w konsoli osobno.

Czy wystarczy zainstalować wtyczkę wymuszającą https?

Wtyczka usunie objaw, ale nie przyczynę. Przepisuje ona adresy w chwili wyświetlania strony, a w bazie pozostają one bez zmian. Dobrze sprawdza się jako pomoc na kilka dni porządków. Jako rozwiązanie stałe oznacza zależność od jednego dodatku i powrót problemu po jego wyłączeniu.

Czy zamiana adresów w bazie może zepsuć witrynę?

Może, jeżeli zostanie przeprowadzona narzędziem, które nie obsługuje danych serializowanych, albo jeśli szukany tekst będzie zbyt ogólny. Dlatego kolejność jest zawsze ta sama: kopia zapasowa, przebieg próbny, ocena raportu i dopiero potem właściwa zamiana. Przy zachowaniu tej kolejności ryzyko jest małe, a ewentualną pomyłkę da się cofnąć z kopii.

Czy odnośniki do cudzych stron z adresem http też trzeba poprawiać?

Nie powodują one ostrzeżenia, ponieważ odnośnik niczego nie wczytuje do bieżącej strony. Poprawianie ich hurtowo jest ryzykowne, bo część starych serwisów nadal nie działa po https i odnośnik przestałby prowadzić do celu. Odnośniki do własnych podstron warto natomiast poprawić, aby odwiedzający nie przechodzili przez zbędne przekierowanie.

Czy problem może wrócić po naprawie?

Tak, jeżeli ktoś wklei do wpisu stary kod do osadzenia, obrazek podlinkowany z obcego serwera albo treść skopiowaną z kopii sprzed zmiany protokołu. Powraca także po przywróceniu witryny ze starej kopii zapasowej. Dobrym zwyczajem jest kontrola konsoli po każdej większej zmianie na stronie i pozostawienie nagłówka upgrade-insecure-requests jako dodatkowej ochrony.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

To zrozumiałe. Szukanie pojedynczych adresów w konsoli, zamiana w bazie danych i porządki w motywie wymagają spokoju, a prowadzenie firmy rzadko go zostawia. Mogę zająć się tym od początku do końca: wykonam kopię zapasową, sprawdzę wszystkie rodzaje podstron, ustalę źródło każdego zasobu wczytywanego po http, poprawię adresy w bazie, motywie, wtyczkach i ustawieniach serwera, a potem pokażę wynik, czyli stronę bez ostrzeżenia przy adresie w każdej przeglądarce.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres witryny. Odpowiem, co widzę po pierwszym sprawdzeniu i jak wyglądałyby dalsze prace.