Jak przekierować HTTP na HTTPS w WordPress

Przeniesienie witryny WordPress z HTTP na HTTPS nie jest już opcjonalne. Przeglądarki oznaczają witryny HTTP jako "Niezabezpieczone", Google używa HTTPS jako sygnału rankingu, a dane Twoich odwiedzających są wysyłane w postaci tekstu jawnego bez szyfrowania. Po zainstalowaniu certyfikatu SSL musisz poprawnie przekierować cały ruch HTTP na HTTPS i rozwiązać wszelkie pozostałe problemy mixed content. Ten przewodnik obejmuje każdy krok procesu, od uzyskania certyfikatu po debugowanie pętli przekierowań za load balancerami.

Dlaczego HTTPS ma znaczenie poza podstawowym bezpieczeństwem

Oczywistym powodem HTTPS jest szyfrowanie. Bez niego wszystko między przeglądarką odwiedzającego a Twoim serwerem (zgłoszenia formularzy, dane uwierzytelniające, cookie, dane osobowe) może zostać przechwycone przez każdego w tej samej sieci. Ale HTTPS ma znaczenie z kilku innych powodów, które bezpośrednio wpływają na sukces Twojej witryny:

• Czynnik rankingu SEO: Google potwierdził w sierpniu 2014, że HTTPS jest sygnałem rankingu. Choć jest to lekki sygnał, wersja HTTPS strony, przy wszystkich pozostałych równych warunkach, będzie rankować wyżej niż wersja HTTP. W konkurencyjnych niszach każdy sygnał się liczy.
• Ostrzeżenia przeglądarki: Chrome, Firefox, Safari i Edge wyświetlają ostrzeżenia "Niezabezpieczone" dla stron HTTP, zwłaszcza tych z polami formularzy. To podkopuje zaufanie odwiedzających i zwiększa wskaźnik odrzuceń. Chrome zwiększa widoczność tych ostrzeżeń od Chrome 68 (lipiec 2018).
• Wsparcie HTTP/2 i HTTP/3: Nowoczesne protokoły takie jak HTTP/2 i HTTP/3, które drastycznie poprawiają szybkość ładowania stron poprzez multipleksowanie i kompresję nagłówków, w praktyce wymagają HTTPS. Wszystkie główne przeglądarki obsługują HTTP/2 tylko przez TLS.
• Dane referrer: Gdy odwiedzający klika link ze strony HTTPS na stronę HTTP, przeglądarka usuwa nagłówek referrer. Oznacza to, że tracisz dane analityczne o tym, skąd pochodzi Twój ruch. Jeśli Twoja witryna jest na HTTPS, zachowujesz dane referrer od innych witryn HTTPS.
• Service Workers i PWA: Funkcje Progressive Web App, takie jak buforowanie offline, powiadomienia push i komunikat "Dodaj do ekranu głównego", wymagają HTTPS.

Uzyskanie darmowego certyfikatu SSL z Let's Encrypt

Nie musisz płacić za certyfikat SSL. Let's Encrypt zapewnia darmowe, zautomatyzowane, walidowane domeną (DV) certyfikaty, którym ufają wszystkie główne przeglądarki. Większość hostingodawców zintegrowała Let's Encrypt ze swoimi panelami kontrolnymi, ale jeśli zarządzasz własnym serwerem, oto jak to skonfigurować z Certbot:

# Zainstaluj Certbot na Ubuntu/Debian
sudo apt update
sudo apt install certbot

# Dla Apache
sudo apt install python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

# Dla Nginx
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot automatycznie konfiguruje serwer webowy do używania certyfikatu i ustawia zadanie cron do automatycznego odnawiania. Certyfikaty Let's Encrypt są ważne 90 dni, ale proces automatycznego odnawiania obsługuje to przejrzyście. Aby zweryfikować, że automatyczne odnawianie działa:

# Przetestuj proces odnawiania (faktycznie nie odnawia)
sudo certbot renew --dry-run

# Sprawdź timer odnawiania
sudo systemctl status certbot.timer

Jeśli Twój hostingodawca oferuje one-click SSL przez panel kontrolny (SiteGround, Bluehost, HostGator, itd.), użyj tego. To ten sam certyfikat Let's Encrypt, ale zarządzany przez Twojego hosta, co oznacza, że masz jedną rzecz mniej do utrzymania.

Krok 1: Zaktualizuj adresy URL WordPress

Przed skonfigurowaniem przekierowań poinformuj WordPress, że Twoja witryna używa teraz HTTPS. Przejdź do Ustawienia > Ogólne i zaktualizuj oba pola:

• Adres WordPress (URL): Zmień http://example.com na https://example.com
• Adres witryny (URL): Zmień http://example.com na https://example.com

Jeśli nie masz dostępu do panelu administracyjnego (np. jeśli już jesteś w pętli przekierowań), możesz ustawić te wartości bezpośrednio w wp-config.php:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Lub zaktualizuj bazę danych bezpośrednio przez WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Krok 2: Przekierowanie HTTP na HTTPS na poziomie serwera

Przekierowanie musi odbywać się na poziomie serwera (nie w PHP) z dwóch powodów: jest szybsze, ponieważ nie wymaga ładowania WordPress, i zapewnia, że wszystkie żądania (w tym pliki statyczne, obrazy i wywołania API) są przekierowywane, a nie tylko adresy URL obsługiwane przez WordPress.

Apache (.htaccess)

Dodaj to na samej górze pliku .htaccess, przed regułami przepisywania WordPress (przed komentarzem # BEGIN WordPress):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Flaga R=301 wysyła stałe przekierowanie, które mówi wyszukiwarkom, aby zaktualizowały swój indeks do wersji HTTPS. Nie używaj R=302 (tymczasowe przekierowanie), ponieważ wyszukiwarki nie przeniosą wówczas link equity na nowy URL.

Nginx

W konfiguracji Nginx utwórz osobny blok server dla HTTP, który przekierowuje wszystko na HTTPS:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... reszta konfiguracji
}

Użycie return 301 w Nginx jest wydajniejsze niż użycie rewrite, ponieważ nie wymaga przetwarzania regex.

Krok 3: Wymuś HTTPS w wp-config.php

Dodaj te linie do pliku wp-config.php, nad komentarzem "That's all, stop editing!":

// Wymuś SSL dla panelu administracyjnego WordPress
define('FORCE_SSL_ADMIN', true);

// Obsługa SSL za reverse proxy lub load balancerem
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Stała FORCE_SSL_ADMIN zapewnia, że strona logowania WordPress i panel administracyjny zawsze używają HTTPS, nawet jeśli ktoś spróbuje uzyskać do nich dostęp bezpośrednio przez HTTP.

Rozwiązywanie pętli przekierowań za load balancerami i reverse proxy

To jeden z najczęstszych problemów z instalacjami HTTPS WordPress i wprawia w zakłopotanie wiele osób. Jeśli Twoja witryna znajduje się za load balancerem, Cloudflare, reverse proxy lub CDN, połączenie między proxy a Twoim serwerem często jest zwykłym HTTP, mimo że połączenie między odwiedzającym a proxy jest HTTPS. Twój serwer widzi żądanie HTTP i próbuje przekierować na HTTPS, proxy wysyła żądanie z powrotem jako HTTP, i kończysz w nieskończonej pętli przekierowań. Przeglądarka wyświetla "ERR_TOO_MANY_REDIRECTS".

Rozwiązaniem jest powyższe sprawdzenie nagłówka X-Forwarded-Proto. Proxy dodaje ten nagłówek, aby powiedzieć serwerowi, jakiego protokołu używało oryginalne żądanie. Gdy WordPress widzi, że przekazany protokół to HTTPS, traktuje połączenie jako bezpieczne i nie wyzwala przekierowania.

Jeśli domyślne sprawdzenie nagłówka nie działa, Twój proxy może używać innego nagłówka. Sprawdź to u swojego hostingodawcy. Częste warianty to:

// Dla niektórych load balancerów używających X-Forwarded-Ssl
if (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') {
    $_SERVER['HTTPS'] = 'on';
}

// Dla Cloudflare (które również ustawia X-Forwarded-Proto, ale dla pewności)
if (isset($_SERVER['HTTP_CF_VISITOR'])) {
    $visitor = json_decode($_SERVER['HTTP_CF_VISITOR']);
    if (isset($visitor->scheme) && $visitor->scheme === 'https') {
        $_SERVER['HTTPS'] = 'on';
    }
}

Krok 4: Zastąp adresy URL HTTP w bazie danych

Twoja baza danych WordPress zawiera zakodowane adresy URL HTTP w treści postów, ustawieniach widżetów, opcjach motywów i danych zserializowanych. Musisz zastąpić je wszystkie wersjami HTTPS. Najlepszym narzędziem do tego jest polecenie search-replace WP-CLI:

# Najpierw wykonaj dry run, aby zobaczyć, co by się zmieniło
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Jeśli dry run wygląda dobrze, wykonaj prawdziwe zastąpienie
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# Obsłuż również warianty www/non-www, jeśli dotyczy
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables

Flaga --dry-run jest ważna. Pokazuje dokładnie, ile zastąpień zostanie wykonanych w każdej tabeli, bez faktycznej zmiany czegokolwiek. Przejrzyj wynik przed wykonaniem prawdziwego zastąpienia. Flaga --all-tables zapewnia, że niestandardowe tabele (z wtyczek takich jak WooCommerce, ACF lub konstruktory stron) są uwzględnione.

WP-CLI poprawnie obsługuje dane zserializowane, co jest kluczowe. Jeśli spróbujesz zwykłego wyszukiwania i zastępowania SQL, zepsujesz zserializowane tablice, ponieważ wartości długości stringów nie będą się już zgadzać. Nigdy nie wykonuj surowego zapytania SQL REPLACE() do tego celu.

Rozwiązywanie problemów mixed content

Mixed content występuje, gdy Twoja strona HTTPS ładuje zasoby (obrazy, skrypty, arkusze stylów, ramki) przez HTTP. Przeglądarki całkowicie blokują aktywny mixed content (skrypty, arkusze stylów) i mogą ostrzegać przed pasywnym mixed content (obrazy). To skutkuje zepsutą funkcjonalnością lub żółtymi ikonami ostrzeżenia w pasku adresu.

Aby znaleźć problemy mixed content:

1. Konsola przeglądarki: Otwórz DevTools (F12) i przejrzyj zakładkę Console. Ostrzeżenia mixed content pojawiają się jako żółte lub czerwone wiadomości z dokładnymi URL-ami naruszających zasobów.
2. InspectWP: Uruchom skan i przejrzyj sekcję HTML. InspectWP wykrywa niezabezpieczone (HTTP) zasoby ładowane na stronach HTTPS i wymienia każdy zasób.
3. Why No Padlock: Witryna whynopadlock.com skanuje Twoją stronę i raportuje wszystkie zasoby mixed content wraz z ich URL-ami źródłowymi.

Częste przyczyny mixed content i jak je rozwiązać:

• Zakodowane URL w plikach motywu: Przeszukaj pliki PHP i CSS motywu pod kątem odwołań http://. Zastąp je https:// lub, lepiej, użyj URL-i niezależnych od protokołu (//) lub funkcji WordPress takich jak esc_url().
• Obrazy w treści postów: Polecenie search-replace WP-CLI (Krok 4) obsługuje większość z nich. W przypadku uporczywych zajrzyj do surowego HTML w edytorze tekstu.
• Widżety i ustawienia Customizera: URL-e obrazów w widżetach, niestandardowych nagłówkach i ustawieniach Customizera są przechowywane jako dane zserializowane. WP-CLI search-replace obsługuje to poprawnie.
• Treść konstruktorów stron: Elementor, Beaver Builder, Divi i inne konstruktory stron przechowują swoją zawartość w niestandardowych formatach. WP-CLI z --all-tables zwykle je wychwytuje, ale zweryfikuj, ładując strony utworzone za pomocą konstruktora stron.
• Zasoby zewnętrzne: Jeśli ładujesz czcionki, skrypty lub obrazy z zewnętrznych domen przez HTTP, zaktualizuj te URL-e. Większość CDN i usług czcionek (Google Fonts, cdnjs, itd.) obsługuje HTTPS.

Używanie Really Simple SSL jako alternatywy

Jeśli podejście ręczne wydaje się przytłaczające, wtyczka Really Simple SSL automatyzuje większość procesu. Zainstaluj ją, aktywuj, a ona:

• Automatycznie wykryje Twój certyfikat SSL.
• Zaktualizuje Site URL i Home URL WordPress do HTTPS.
• Skonfiguruje przekierowanie 301 z HTTP na HTTPS przez PHP (lub .htaccess, jeśli to możliwe).
• Rozwiąże mixed content, zastępując URL-e HTTP w locie.

Wadą Really Simple SSL jest to, że rozwiązuje mixed content dynamicznie przy każdym ładowaniu strony, co dodaje niewielki narzut przetwarzania. Lepiej naprawić przyczyny źródłowe (URL-e bazy danych, zakodowane odwołania), a następnie usunąć wtyczkę. Traktuj ją jako użyteczny most podczas migracji, a nie stałe rozwiązanie.

Krok 5: Dodaj nagłówek HSTS

HTTP Strict Transport Security (HSTS) mówi przeglądarkom, aby zawsze używały HTTPS dla Twojej domeny, nawet jeśli użytkownik wpisze http:// w pasku adresu. Po potwierdzeniu, że HTTPS działa poprawnie w Twojej witrynie (brak mixed content, brak pętli przekierowań), dodaj nagłówek HSTS:

Apache (.htaccess)

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Wartość max-age=31536000 (jeden rok) mówi przeglądarkom, aby pamiętały politykę HSTS przez 12 miesięcy. Zacznij od krótszej wartości, takiej jak max-age=86400 (jeden dzień) podczas testowania, i zwiększ ją, gdy będziesz pewien, że wszystko działa. Dyrektywa includeSubDomains rozszerza politykę na wszystkie subdomeny. Dodaj preload tylko wtedy, gdy planujesz zgłosić swoją domenę do listy preload HSTS (hstspreload.org), która utrwala wymóg HTTPS Twojej domeny w samych przeglądarkach.

Konfiguracja HTTPS CDN i Cloudflare

Jeśli używasz Cloudflare lub innego CDN, konfiguracja HTTPS ma dodatkową warstwę złożoności:

• Cloudflare Flexible SSL: Ruch jest szyfrowany między odwiedzającym a Cloudflare, ale połączenie między Cloudflare a Twoim serwerem jest zwykłym HTTP. To najłatwiejsze do skonfigurowania (nie wymaga certyfikatu SSL na serwerze), ale zapewnia niepełne bezpieczeństwo. Dane między Cloudflare a serwerem są niezaszyfrowane.
• Cloudflare Full SSL: Ruch jest szyfrowany po obu stronach, ale Cloudflare nie weryfikuje certyfikatu Twojego serwera. Potrzebujesz certyfikatu SSL na serwerze, ale może być self-signed.
• Cloudflare Full (Strict) SSL: Zalecane ustawienie. Ruch jest szyfrowany po obu stronach, a Cloudflare weryfikuje certyfikat serwera. Użyj ważnego certyfikatu Let's Encrypt lub Cloudflare Origin Certificate.

Jeśli przełączasz się z Flexible na Full (Strict), upewnij się najpierw, że Twój serwer ma zainstalowany ważny certyfikat SSL. W przeciwnym razie Twoja witryna przestanie działać, ponieważ Cloudflare nie będzie mógł nawiązać bezpiecznego połączenia z Twoim serwerem.

Cloudflare oferuje również "Always Use HTTPS" w SSL/TLS > Edge Certificates, które wykonuje przekierowanie HTTP na HTTPS na krawędzi Cloudflare. Jest to szybsze niż przekierowanie na serwerze origin, ponieważ odwiedzający nigdy nie dociera do Twojego serwera w przypadku żądania HTTP.

Sprawdzanie daty wygaśnięcia certyfikatu SSL i automatycznego odnawiania

Wygasły certyfikat SSL jest gorszy niż brak certyfikatu. Przeglądarki wyświetlają ostrzeżenie na całą stronę, przez które większość odwiedzających nie kliknie, a Twoja witryna efektywnie znika z sieci. Oto jak monitorować certyfikat:

# Sprawdź datę wygaśnięcia certyfikatu
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Sprawdź dni do wygaśnięcia
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Jeśli używasz Let's Encrypt z Certbot, automatyczne odnawianie powinno być skonfigurowane automatycznie. Ale zweryfikuj, że rzeczywiście działa, sprawdzając logi odnawiania Certbot:

# Sprawdź log odnawiania Certbot
cat /var/log/letsencrypt/letsencrypt.log | tail -20

# Lista wszystkich certyfikatów i ich dat wygaśnięcia
sudo certbot certificates

Dla witryn produkcyjnych skonfiguruj monitoring, który ostrzega Cię, gdy certyfikat zbliża się do daty wygaśnięcia. Usługi takie jak UptimeRobot, StatusCake lub nawet proste zadanie cron sprawdzające datę certyfikatu mogą uchronić Cię przed nieoczekiwanym przestojem.

Zweryfikuj swoją instalację HTTPS za pomocą InspectWP

Po zakończeniu migracji uruchom skan InspectWP, aby sprawdzić, czy wszystko działa poprawnie. InspectWP sprawdza kilka aspektów związanych z HTTPS:

• Wykrywanie SSL/TLS: Potwierdza, że Twoja witryna jest serwowana przez HTTPS.
• Mixed content: Wykrywa zasoby HTTP (obrazy, skrypty, arkusze stylów) ładowane na Twoich stronach HTTPS.
• Nagłówek HSTS: Weryfikuje, że nagłówek Strict-Transport-Security jest obecny i poprawnie skonfigurowany.
• Przekierowanie HTTP: Sprawdza, czy wersja HTTP Twojej witryny poprawnie przekierowuje na HTTPS.
• Nagłówki bezpieczeństwa: Przegląda inne nagłówki bezpieczeństwa, które uzupełniają Twoją instalację HTTPS.

Jeśli InspectWP zgłasza ostrzeżenia mixed content, użyj konsoli przeglądarki, aby zidentyfikować konkretne zasoby i napraw je za pomocą metod opisanych powyżej. Po każdej poprawce uruchom nowy skan, aż raport wróci czysty.