HTTPS, www i przekierowania 301 — jak ustawić jedną wersję adresu strony

Aktualizacja: 18.10.2026

Twoja strona może odpowiadać pod czterema adresami: http://firma.pl, http://www.firma.pl, https://firma.pl i https://www.firma.pl. Docelowo ma działać tylko jeden z nich, a pozostałe trzy mają na niego przekierowywać jednym przekierowaniem 301. Jeśli tak nie jest, Google widzi kopie tej samej strony, a w najgorszym przypadku — przy pętli przekierowań albo zepsutym certyfikacie — nie otwiera jej wcale.

Co dokładnie wykrył audyt

Pętla przekierowań (bloker) — adres przekierowuje w kółko albo przez tyle skoków, że nie dochodzi do treści. Przeglądarka pokazuje błąd „Too many redirects” (w Chrome: ERR_TOO_MANY_REDIRECTS), Google też nie dojdzie do strony, a dopóki to trwa, strona będzie stopniowo wypadać z wyników przy kolejnych wizytach robota. Audyt pokazuje wtedy w raporcie cały łańcuch skoków — kod odpowiedzi i adres każdego z nich — i sprawdza tylko to, co da się ocenić z zewnątrz (robots.txt, mapa strony, DNS), bo samej strony nie da się pobrać.
Strona nie działa po HTTPS (bloker) — nie udało się otworzyć strony po https://: certyfikat wygasł, nie pasuje do domeny albo serwer w ogóle nie obsługuje HTTPS. Audyt sprawdza wtedy wersję http://. Przeglądarki pokazują użytkownikom ostrzeżenie o niebezpiecznym połączeniu, a Google ma problem z pobraniem strony.
Certyfikat SSL jest niekompletny (poważny) — serwer nie wysyła certyfikatu pośredniego (niepełny łańcuch). W Chrome strona często działa, bo przeglądarka sama dociąga brakujący certyfikat, ale część urządzeń, narzędzi i robotów — w tym nasz audyt — odrzuca takie połączenie. To osobny komunikat, łagodniejszy niż wygasły czy zły certyfikat.
http:// nie przekierowuje na https:// (poważny) — strona działa po HTTPS, ale wersja bez szyfrowania też się otwiera, zamiast przekierować.
Wersja z www i bez www działają osobno (poważny) — pod firma.pl i www.firma.pl otwiera się ta sama strona, bez przekierowania. Dla Google to dwa osobne adresy z identyczną treścią.
Łańcuch przekierowań (do poprawy) — adres przechodzi przez dwa lub więcej przekierowań, zanim się otworzy, np. http://firma.pl → https://firma.pl → https://www.firma.pl. Każdy skok spowalnia otwieranie strony i dokłada pracy robotom; lepiej jedno przekierowanie prosto na adres docelowy.
Przekierowanie tymczasowe 302/307 (do poprawy) — adres przekierowuje, ale kodem „tymczasowo”, choć zmiana jest stała.
Mixed content (do poprawy) — strona działa po HTTPS, ale ładuje obrazki, skrypty, style lub ramki z adresów http://. Audyt sprawdza tylko adresy wskazane w kodzie HTML strony — adresów wewnątrz plików CSS i JS nie sprawdza, więc zielony wynik ich nie obejmuje.

Pętla przekierowań — skąd się bierze

Pętla to prawie zawsze dwa miejsca, które przekierowują w przeciwnych kierunkach. Najczęstsze scenariusze:

Cloudflare w trybie SSL „Flexible” + wymuszenie HTTPS na serwerze. W trybie Flexible Cloudflare łączy się z Twoim serwerem po zwykłym HTTP. Serwer (reguła w .htaccess, wtyczka) widzi „ktoś wszedł po http” i przekierowuje na https. Cloudflare znów pyta serwer po http — i tak w kółko.
Odwrotny kierunek w Cloudflare: tryb Full lub włączone „Always Use HTTPS”, a serwer przekierowuje z https z powrotem na http.
Sprzeczne reguły www / bez www. .htaccess przekierowuje na wersję z www, a wtyczka (albo Cloudflare, albo panel hostingu) — na wersję bez www. Każda z reguł osobno jest poprawna, razem tworzą pętlę.
Zły adres witryny w WordPressie. W Ustawienia → Ogólne wpisano http:// albo wersję z www, a serwer wymusza https lub wersję bez www. WordPress przekierowuje na „swój” adres, serwer z powrotem.
Serwer za pośrednikiem (proxy, load balancer) nie wie, że użytkownik wszedł po HTTPS, i ciągle próbuje go tam przekierować. Dokumentacja WordPressa opisuje to wprost jako przyczynę nieskończonej pętli.

Audyt uznaje za pętlę także bardzo długi łańcuch — ponad 10 przekierowań, czyli więcej, niż domyślnie śledzi Google. Przeglądarki śledzą trochę więcej, ale taki łańcuch i tak trzeba skrócić.

Jak sprawdzić samemu

Przeglądarka. W oknie prywatnym (bez zapisanych ciasteczek i przekierowań) wpisz po kolei wszystkie cztery warianty adresu. Każdy powinien skończyć na tym samym adresie w pasku. Jeśli widzisz „Too many redirects”, wyczyść ciasteczka dla tej domeny i spróbuj jeszcze raz — jeśli błąd wraca, problem jest po stronie serwera.
Łańcuch skoków w DevTools. Naciśnij F12, zakładka Network (Sieć), zaznacz Preserve log (Zachowaj dziennik) i wpisz adres. Zobaczysz każde przekierowanie z kodem (301, 302) i adresem docelowym.
Terminal (macOS, Linux, Windows 10+). Polecenie pokazuje nagłówki każdego skoku:
```
curl -sIL http://firma.pl/ | grep -iE "^HTTP|^location"
```
Poprawny wynik to jedno 301 i jedno 200. Pętla wygląda jak ta sama para adresów powtarzana w kółko. Powtórz dla http://www.firma.pl/ i https://www.firma.pl/.
Narzędzia online. Dowolny sprawdzacz przekierowań (wpisz w Google „redirect checker”) pokaże to samo co curl. Certyfikat sprawdzisz w SSL Labs SSL Server Test — pokaże datę ważności, czy certyfikat obejmuje www i czy łańcuch jest kompletny („Chain issues: Incomplete”).
Mixed content. W Chrome otwórz DevTools i zakładkę Issues (Problemy) albo konsolę — zablokowane lub podniesione do https zasoby są tam wypisane.
Google Search Console. Sprawdzenie adresu URL → wariant http:// lub bez www → powinien zostać rozpoznany jako przekierowanie, a strona kanoniczna wybrana przez Google — wskazywać Twoją wersję docelową.

Jak naprawić

Najpierw zdecyduj, która wersja jest główna — https://firma.pl czy https://www.firma.pl. Dla Google to bez różnicy; ważne, żeby była jedna i wszędzie ta sama (adres witryny w CMS, canonical, mapa strony XML, linki wewnętrzne). Potem zasada: przekierowania ustawiasz w jednym miejscu, a nie po trochu w serwerze, wtyczce i Cloudflare.

Najpierw certyfikat SSL

Bez działającego certyfikatu przekierowanie na https tylko pogorszy sprawę. Typowe problemy:

Wygasł — certyfikaty Let's Encrypt są ważne 90 dni i odnawiają się automatycznie, jeśli odnawianie działa. Sprawdź w panelu hostingu, czy autoodnawianie jest włączone, i odnów ręcznie.
Nie obejmuje www (albo wersji bez www) — wystaw certyfikat na obie nazwy, bo przekierowanie z https://www.firma.pl zadziała dopiero po nawiązaniu bezpiecznego połączenia.
Niepełny łańcuch — serwer wysyła sam certyfikat bez certyfikatu pośredniego. Chrome często to zamaskuje, dociągając brakujący certyfikat, ale inne programy (w tym część robotów i nasz audyt) odrzucą połączenie — audyt zgłasza to jako problem poważny. W nginx wskaż plik z pełnym łańcuchem (przy Let's Encrypt: fullchain.pem, nie cert.pem); na hostingu współdzielonym zgłoś to do supportu.

Apache (.htaccess)

Jedna reguła, która każdy wariant kieruje od razu na wersję docelową (tu: https bez www) — bez łańcucha. W WordPressie wklej ją nad blokiem # BEGIN WordPress i usuń inne, stare reguły przekierowań, żeby się nie dublowały.

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://firma.pl%{REQUEST_URI} [L,R=301]

Dla wersji z www zmień drugi warunek na RewriteCond %{HTTP_HOST} !^www\. [NC], a adres docelowy na https://www.firma.pl. Uwaga: jeśli strona stoi za Cloudflare w trybie Flexible albo za innym pośrednikiem, %{HTTPS} zawsze ma wartość off i ta reguła wywoła pętlę — najpierw popraw tryb SSL w Cloudflare (niżej). Zrób kopię .htaccess przed edycją; błąd w pliku kończy się błędem 500 całej strony.

nginx

Osobne bloki dla wariantów, które mają przekierowywać, i jeden blok z właściwą stroną:

server {
    listen 80;
    server_name firma.pl www.firma.pl;
    return 301 https://firma.pl$request_uri;
}
server {
    listen 443 ssl;
    server_name www.firma.pl;
    ssl_certificate     /etc/letsencrypt/live/firma.pl/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/firma.pl/privkey.pem;
    return 301 https://firma.pl$request_uri;
}
server {
    listen 443 ssl;
    server_name firma.pl;
    # ...właściwa konfiguracja strony
}

Po zmianie: nginx -t (test konfiguracji), potem nginx -s reload. Jeśli nie masz dostępu do serwera, zrobi to hosting lub administrator.

Cloudflare

SSL/TLS → Overview — tryb szyfrowania ustaw na Full (strict), jeśli serwer ma ważny certyfikat (Let's Encrypt albo darmowy Cloudflare Origin CA), ewentualnie Full. Flexible zostaw tylko wtedy, gdy serwer naprawdę nie obsługuje HTTPS — i wtedy usuń z serwera wszystkie przekierowania na https.
SSL/TLS → Edge Certificates → Always Use HTTPS — włącz. Cloudflare sam przekieruje http na https. Dokumentacja Cloudflare odradza wtedy dodatkowe przekierowanie na serwerze, bo to częsta przyczyna pętli.
www / bez www — przekierowanie ustawisz w Rules jako Redirect Rule (Single Redirect): adres źródłowy https://www.*, docelowy https://${1}, kod 301, z zachowaniem parametrów (query string). Stare Page Rules z „Forwarding URL” też działają — sprawdź, czy nie masz tam reguły sprzecznej z serwerem lub nową regułą.
Na mixed content pomaga opcja Automatic HTTPS Rewrites (Edge Certificates) — zamienia część adresów http na https w locie, ale nie wszystkie.

WordPress i WooCommerce

Ustawienia → Ogólne — pola Adres WordPressa (URL) i Adres witryny (URL) muszą mieć dokładnie wersję docelową, np. https://firma.pl. Po zapisie zostaniesz wylogowany — to normalne.
Jeśli pola są wyszarzone, adresy są ustawione w wp-config.php stałymi WP_HOME i WP_SITEURL — popraw je tam.
Jeśli przez pętlę nie możesz wejść do kokpitu, dopisz tymczasowo w wp-config.php (nad linią „That's all, stop editing”):
```
define( 'WP_HOME', 'https://firma.pl' );
define( 'WP_SITEURL', 'https://firma.pl' );
```

Strona za pośrednikiem (proxy) i pętla mimo poprawnych adresów — dokumentacja WordPressa zaleca w wp-config.php:

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

Really Simple SSL (obecnie „Really Simple Security”) ustawi przekierowanie 301 na https (przez .htaccess lub PHP) i ma opcję poprawiania adresów http w kodzie strony. Używaj go zamiast ręcznych reguł, nie razem z nimi — dwie warstwy przekierowań to proszenie się o pętlę.
Stare adresy http:// w treści (obrazki we wpisach, linki) najtrwalej poprawisz zamianą w bazie danych, np. wtyczką Better Search Replace albo poleceniem wp search-replace 'http://firma.pl' 'https://firma.pl'. Zrób wcześniej kopię bazy.
Wyczyść cache (wtyczka cache, LiteSpeed, Cloudflare) — stare przekierowania potrafią w nim zostać.

WooCommerce nie ma osobnych ustawień — korzysta z adresów WordPressa.

Shopify

Certyfikat SSL Shopify wystawia sam dla domen podłączonych do sklepu. Jedną wersję adresu ustawiasz w Ustawienia → Domeny: wybierz domenę (z www lub bez), Zmień typ domeny → Domena główna. Pozostałe domeny typu „przekierowanie” (w tym …myshopify.com) będą kierować na domenę główną. Sprawdź, czy żadna domena nie jest ustawiona jako alias — alias nie przekierowuje.

PrestaShop

Parametry sklepu → Ogólne — włącz Włącz SSL, a po zapisie Włącz SSL na wszystkich stronach. Bez drugiej opcji HTTPS działa tylko w koszyku i na koncie klienta.
Parametry sklepu → Ruch i SEO → SEO i URL, sekcja ustawień adresu sklepu — Domena sklepu i Domena SSL muszą być tą samą wersją (z www albo bez). Dokumentacja PrestaShop ostrzega, że pomyłka w tych polach potrafi wyłączyć sklep — zanotuj stare wartości.
Przekierowanie wersji bez www na www (lub odwrotnie) i http na https ustaw dodatkowo w .htaccess (wyżej) — reguły dopisz nad sekcją generowaną przez PrestaShop.

Shoper

Ustawienia → Ogólne → Domeny — upewnij się, że domena z certyfikatem SSL jest domeną główną sklepu. Tu kupisz też certyfikat; domena kupiona poza Shoperem musi najpierw wskazywać na serwery DNS Shopera.
Ustawienia → Zaawansowane → Zabezpieczenia — Obsługa HTTPS ustaw na wszędzie i zapisz.

Mixed content

Raport audytu wypisuje do ośmiu plików ładowanych po http:// (obrazki, skrypty, style, ramki). Każdy adres zmień na https:// — w treści wpisu, w ustawieniach motywu, w kodzie osadzonej ramki. Jeśli zasób nie działa po https (stary zewnętrzny serwis), pobierz go na swój serwer albo znajdź zamiennik. Adresy w plikach CSS i JS motywu poprawi tylko edycja tych plików — audyt ich nie sprawdza, więc przejrzyj je w zakładce Issues w DevTools.

301 czy 302?

Przenosiny na https albo na wersję z www to zmiana stała, więc kod 301 (albo 308). Według Google przekierowanie stałe to mocny sygnał, że adres docelowy ma się pokazywać w wynikach, a tymczasowe (302, 303, 307) — słaby; w wynikach może zostać stary adres. Przy stałej zmianie adresu 302 to więc nie awaria, ale niepotrzebnie niejasny sygnał.

Jak sprawdzić, że naprawione, i ile to trwa

Powtórz curl -sIL dla wszystkich czterech wariantów. Każdy: najwyżej jedno 301, potem 200 na tym samym adresie docelowym. Adres docelowy wpisany wprost: od razu 200.
SSL Labs nie pokazuje błędów łańcucha, data ważności jest w przyszłości, certyfikat obejmuje obie nazwy (z www i bez).
Uruchom ponownie nasz audyt — pozycje przekierowań, HTTPS, www i mixed content powinny być zielone.
W Search Console: Sprawdzenie adresu URL → Testuj URL na żywo dla strony głównej, potem Poproś o zindeksowanie. Jeśli zmieniła się wersja główna (np. z http na https), zgłoś też aktualną mapę strony z nowymi adresami.

Po usunięciu pętli lub naprawie certyfikatu strona jest dla Google dostępna od razu, ale wróci do wyników dopiero po ponownym odwiedzeniu przez robota — zwykle w kilka dni dla strony głównej, dłużej dla podstron. Scalenie wersji www/bez www i http/https przebiega stopniowo, przez kilka tygodni; przez jakiś czas w wynikach mogą się jeszcze pojawiać stare adresy, co Google opisuje jako normalne. Przekierowania zostaw na stałe — co najmniej na rok, a najlepiej na zawsze. Nie ma gwarancji, że pozycje po naprawie będą takie jak wcześniej.

Kiedy warto poprosić o pomoc

Gdy pętla wraca mimo poprawionych ustawień, nie wiesz, która z warstw (serwer, wtyczka, Cloudflare, hosting) przekierowuje, albo nie masz dostępu do konfiguracji serwera — lepiej oddać to komuś, kto sprawdzi cały łańcuch naraz. Pomyłka w .htaccess czy w adresie sklepu potrafi wyłączyć stronę. W IF.PL zajmujemy się SEO i stronami WWW — możemy ustawić przekierowania i certyfikat tak, żeby została jedna wersja adresu.