Strona działa na www, ale nie działa bez www — gdzie szukać przyczyny?

Jeżeli strona działa pod www.example.pl, ale nie działa pod example.pl — albo odwrotnie — problem zwykle nie leży w samej treści WordPressa. Najczęściej oba hosty nie są obsługiwane identycznie na jednej z warstw: DNS, TLS, vhost, redirect albo konfiguracji aplikacji.

Warto traktować example.pl i www.example.pl jako dwa osobne hosty. To, że jeden działa, nie oznacza automatycznie, że drugi ma poprawny rekord DNS, certyfikat i konfigurację serwera.

Najpierw sprawdź oba hosty osobno: DNS, HTTPS i odpowiedź HTTP. Dopiero potem ustawiaj docelowe przekierowanie między www i domeną bez www.

Najpierw ustal, na której warstwie wariant przestaje działać

Objaw	Pierwszy trop
Jeden host zwraca NXDOMAIN	Nazwa nie istnieje w aktywnej odpowiedzi DNS — sprawdź właściwą strefę i konkretny rekord dla tego hosta
Oba hosty rozwiązują DNS, ale jeden ma błąd certyfikatu	SAN/wildcard i konfiguracja TLS
Oba hosty mają poprawny TLS, ale jeden zwraca 404/403	Vhost lub routing serwera
Jeden host przekierowuje w złe miejsce	Redirect serwera, CDN albo WordPress
Oba działają, ale Google widzi różne wersje	Canonical i spójność redirectów

Takie rozdzielenie jest ważne, bo ten sam objaw użytkowy — „wersja bez www nie działa” — może mieć zupełnie inną przyczynę zależnie od tego, czy problem występuje przed DNS, przy TLS, czy dopiero po wejściu do aplikacji.

www i domena główna potrzebują własnej poprawnej obsługi DNS

Domena główna i www to różne nazwy DNS.

Dla przykładu:

• example.pl może mieć rekord A i AAAA,
• www.example.pl może mieć własny A/AAAA albo CNAME.

Rekord domeny głównej nie tworzy automatycznie rekordu www. Podobnie poprawny CNAME dla www nie oznacza, że apex domeny również wskazuje właściwy serwer.

Jeżeli jeden wariant nie rozwiązuje się w DNS, nie ma sensu zaczynać od WordPressa. Najpierw trzeba sprawdzić, czy dana nazwa w ogóle wskazuje na właściwy origin.

Przy rozbieżnościach DNS pomocny jest poradnik o diagnozie DNS_PROBE_FINISHED_NXDOMAIN.

Certyfikat musi obejmować oba hosty, jeśli oba mają działać po HTTPS

Nawet gdy example.pl i www.example.pl trafiają na ten sam adres IP, certyfikat musi obejmować nazwę używaną przez klienta.

W praktyce trzeba sprawdzić, czy SAN certyfikatu zawiera oba hosty albo czy zastosowany wildcard obejmuje potrzebny wariant.

Ważne rozróżnienie: certyfikat *.example.pl może obejmować www.example.pl, ale nie obejmuje automatycznie samego example.pl. Apex domeny musi być uwzględniony osobno.

Jeżeli jeden wariant działa po HTTPS, a drugi pokazuje hostname mismatch, problem jest w warstwie TLS, nie w canonicalu ani permalinkach.

Szerzej opisuje to poradnik o certyfikacie SSL niedopasowanym do domeny.

Serwer musi mieć vhost dla wariantu, który ma obsługiwać

DNS i certyfikat mogą być poprawne, a mimo to jeden host nie działać. Wtedy trzeba sprawdzić konfigurację serwera WWW.

Na jednym IP może działać wiele witryn, a serwer wybiera konfigurację na podstawie hosta. Jeśli www.example.pl jest przypisane do właściwego vhosta, ale example.pl nie, żądanie może trafić do domyślnej witryny, błędu 404 albo innej aplikacji.

Przy diagnozie sprawdź:

• czy oba hosty są przypisane do tej samej witryny,
• czy oba trafiają do właściwego document root,
• czy redirect jest zdefiniowany we właściwym vhoście,
• czy reverse proxy lub CDN nie rozdziela ich inaczej.

Jeżeli jeden host pokazuje zupełnie inną stronę lub certyfikat, szczególnie mocnym tropem jest błędne przypisanie vhosta.

Ustal jeden docelowy wariant hosta

Redirect

Najbezpieczniejszy model to:

1. oba hosty poprawnie rozwiązują DNS,
2. oba mają prawidłowy HTTPS,
3. serwer rozpoznaje oba hosty,
4. jeden wariant przekierowuje do drugiego.

Dzięki temu użytkownik wchodzący na dowolną wersję domeny trafia na tę samą witrynę.

Nie warto używać redirectu do maskowania brakującego DNS lub błędnego TLS. Przy wejściu przez HTTPS klient musi najpierw poprawnie zestawić połączenie TLS dla otwieranej nazwy, zanim otrzyma odpowiedź HTTP z przekierowaniem. Dla zwykłego HTTP etap TLS oczywiście nie występuje.

WordPress

Po wyborze wariantu docelowego sprawdź wartości home i siteurl, a także ewentualne WP_HOME i WP_SITEURL.

Jeżeli WordPress uważa za główny adres www.example.pl, a serwer wymusza wersję bez www, może powstać niepotrzebny dodatkowy redirect, a w źle skonfigurowanym środowisku nawet pętla.

Analogicznie po migracji stary host może nadal znajdować się w konfiguracji aplikacji.

Jeżeli WordPress przekierowuje na nieaktualną domenę, zobacz poradnik o przekierowaniu na starą domenę po migracji.

Canonical

Jeżeli oba hosty są dostępne, ale nie ma spójnego redirectu, wyszukiwarka może zobaczyć dwa zestawy URL-i prowadzących do tej samej treści.

Canonical pomaga wskazać preferowany wariant, ale nie powinien zastępować poprawnej normalizacji adresów tam, gdzie wersje www i bez www mają być jednoznacznie sprowadzone do jednego hosta.

Dobrą praktyką jest spójność trzech elementów:

• docelowego hosta w WordPressie,
• redirectu 3xx,
• canonicalu.

Nie oznacza to jednak, że canonical „naprawi” niedziałający DNS, certyfikat albo vhost. To sygnał kanonikalizacji, a nie mechanizm dostępności strony.

AAAA może sprawić, że tylko część użytkowników widzi problem

Po migracji łatwo zaktualizować rekord A i zostawić stary AAAA.

Wtedy:

• część klientów łączy się po IPv4 z nowym serwerem,
• część po IPv6 trafia na stary origin.

Jeżeli tylko na jednym z tych serwerów www i apex są skonfigurowane poprawnie, objaw może wyglądać losowo.

Dlatego przy problemie „u mnie działa, u kogoś nie” warto sprawdzić oba protokoły IP zamiast testować tylko rekord A.

Bezpieczna procedura diagnozy www vs bez www

1. Sprawdź osobno DNS dla apex i www.
2. Porównaj rekordy A, AAAA i CNAME.
3. Sprawdź HTTPS i certyfikat dla obu hostów.
4. Zweryfikuj, czy serwer ma poprawny vhost dla obu nazw.
5. Sprawdź document root i odpowiedź aplikacji.
6. Ustal docelowy wariant hosta.
7. Skonfiguruj jednoznaczny redirect do wariantu docelowego.
8. Sprawdź home, siteurl, WP_HOME i WP_SITEURL.
9. Zweryfikuj canonical.
10. Przetestuj ponownie oba hosty po IPv4 i IPv6.

Jeżeli migracja dopiero jest przygotowywana, warto wcześniej sprawdzić oba hosty narzędziem Diagnostyka domeny przed migracją.

Najważniejsze wnioski

• www.example.pl i example.pl to dwa osobne hosty;
• każdy z nich musi być poprawnie obsłużony w DNS, TLS i konfiguracji serwera;
• wildcard *.example.pl nie obejmuje apex domeny;
• przy wejściu przez HTTPS redirect zostanie odebrany dopiero po poprawnym zestawieniu TLS dla otwieranej nazwy;
• dla zwykłego HTTP etap TLS nie występuje;
• docelowy wariant powinien być spójny w WordPressie, redirectach i canonicalu;
• stary rekord AAAA może powodować różne zachowanie części użytkowników;
• diagnozę najlepiej prowadzić warstwami: DNS → TLS → vhost → redirect → WordPress → canonical.

Źródła

1. RFC 9525 — Service Identity in TLS — weryfikacja nazw hostów i wildcardy certyfikatów.
2. Cloudflare Developers — DNS record types — A, AAAA i CNAME.
3. WordPress Developer Resources — home_url() — publiczny adres witryny.
4. WordPress Developer Resources — site_url() — adres instalacji WordPressa.
5. WordPress Developer Resources — Editing wp-config.php — WP_HOME i WP_SITEURL.
6. Google Search Central — Canonicalization — canonical jako sygnał wyboru preferowanego URL-a.
7. MDN Web Docs — Redirections in HTTP — działanie przekierowań HTTP.