Adres z www czy bez www: jak wybrać jedną wersję i przekierować pozostałe

Dlaczego cztery warianty adresu to cztery różne strony

Wyszukiwarka rozpoznaje stronę po pełnym adresie, a nie po tym, co na niej widać. Jeżeli więc ten sam tekst otwiera się pod czterema adresami, robot widzi cztery dokumenty o identycznej treści i sam musi zdecydować, który z nich pokazać w wynikach.

W typowym serwisie firmowym warianty różnią się dwoma elementami: protokołem (http albo https) oraz nazwą hosta (z przedrostkiem www albo bez niego).

http://example.pl/
http://www.example.pl/
https://example.pl/
https://www.example.pl/

Google opisuje ten mechanizm w dokumencie o wyborze strony kanonicznej. Wyszukiwarka grupuje strony, które wyglądają tak samo lub mają bardzo podobną główną treść, a następnie z każdej grupy bierze jeden adres reprezentatywny, nazywany kanonicznym. Wśród typowych źródeł duplikatów dokumentacja wymienia między innymi warianty protokołu. Wariant z www i bez www działa na tej samej zasadzie, co potwierdza pomoc Search Console: w usłudze z prefiksem adresu wersje z www i bez www trzeba zgłaszać osobno.

Co złego dzieje się, gdy działają wszystkie cztery

Powielona treść sama w sobie nie narusza zasad Google dotyczących spamu i nie jest powodem do kary. Dokumentacja zwraca jednak uwagę na skutki praktyczne. Linki prowadzące do różnych wariantów rozkładają się na kilka adresów zamiast wzmacniać jeden. Robot poświęca czas na odwiedzanie kopii, zamiast częściej zaglądać do nowych i zmienionych podstron. Dane o ruchu rozbijają się na kilka adresów i trudniej ocenić, jak radzi sobie konkretna podstrona.

Przykład z praktyki: kancelaria z Krakowa od lat podawała na wizytówkach adres z www, a po zmianie hostingu serwis zaczął odpowiadać także bez www, bez żadnego przekierowania. Po pewnym czasie część podstron była w wynikach z www, część bez, a linki z innych serwisów prowadziły raz do jednej, raz do drugiej wersji. Szerzej o tym zjawisku piszemy we wpisie o tym, skąd bierze się duplikacja treści w serwisie.

Czy wybór www lub wersji bez www wpływa na pozycje

Nie. W dokumentacji Google, do której sięgnęliśmy, nie ma żadnej wskazówki, że adres z www jest oceniany lepiej albo gorzej niż adres bez www. Wytyczne dotyczące określania adresu kanonicznego pokazują wariant z www jedynie jako jeden z możliwych przykładów i skupiają się na jednoznacznym wskazaniu jednej wersji.

Inaczej jest z protokołem. Tu Google ma wyraźną preferencję i domyślnie stawia wersję https ponad równoważną wersję http. Dokumentacja zastrzega, że ta preferencja może nie zadziałać, gdy certyfikat jest nieprawidłowy, gdy strona https przekierowuje na http albo gdy znacznik rel=canonical na stronie https wskazuje adres http. W praktyce z czterech wariantów w grze pozostają dwa: https z www oraz https bez www. Osobny wpis poświęciliśmy temu, jak przejść z HTTP na HTTPS bez utraty widoczności.

Wybór między dwoma pozostałymi wariantami jest więc decyzją organizacyjną i techniczną, a nie rankingową. Jeżeli wszystkie linki, mapa witryny i przekierowania wskazują ten sam adres, wyszukiwarka nie musi niczego zgadywać.

Różnice techniczne między adresem z www i bez www: DNS i pliki cookie

Różnice istnieją, ale dotyczą konfiguracji, a nie widoczności. Adres bez www to sama nazwa domeny, natomiast www jest jej subdomeną, czyli osobną nazwą hosta. Z tego wynikają dwie konsekwencje: inaczej ustawia się rekordy w systemie DNS i inaczej zachowują się pliki cookie.

DNS: rekord A i rekord CNAME

System DNS tłumaczy nazwę domeny na adres serwera. W podstawowych informacjach o DNS w pomocy Google Workspace opisane są dwa rekordy, które mają tu znaczenie. Rekord A łączy domenę z adresem IP serwera i to nim włącza się adres samej domeny, bez przedrostka www. Rekord CNAME, czyli rekord nazwy kanonicznej, wskazuje, że jedna nazwa jest aliasem innej, na przykład że www.example.pl prowadzi tam, gdzie example.pl.

Dla właściciela strony wniosek jest prosty: oba warianty muszą mieć swoje wpisy w DNS i oba muszą trafiać na serwer, który potrafi odpowiedzieć przekierowaniem. Jeżeli wpis dla www nie istnieje, osoba wpisująca adres z www otrzyma błąd przeglądarki, a nie przekierowanie. Z naszej praktyki wynika też, że niektóre usługi zewnętrzne, na przykład sieci dostarczania treści lub gotowe platformy sklepowe, proszą o podpięcie domeny rekordem CNAME, co najprościej zrobić właśnie dla www. Przy domenie bez przedrostka dostawcy stosują różne rozwiązania, dlatego przed decyzją warto zapytać firmę hostingową, jak obsługuje oba przypadki.

Ta sama strona pomocy wyjaśnia pojęcie TTL. Jest to wartość w rekordzie DNS, wyrażona w sekundach, od której zależy, jak długo trzeba czekać na wejście zmian w życie. Po poprawce w rekordach efekt nie jest więc natychmiastowy i test wykonany minutę później może jeszcze pokazywać stary stan.

Pliki cookie

Pliki cookie to niewielkie porcje danych zapisywane w przeglądarce, na przykład zawartość koszyka albo informacja o zalogowaniu. O tym, do których hostów przeglądarka je wysyła, decyduje atrybut Domain. Zgodnie z opisem w serwisie web.dev, w materiale First-party cookie recipes, pominięcie tego atrybutu ogranicza plik do hosta, który go ustawił, z wyłączeniem subdomen. Plik ustawiony przez example.com jest wtedy dołączany do żądań kierowanych do example.com, ale nie do images.example.com. Gdy jedna sesja ma działać w kilku subdomenach, atrybut Domain podaje się wprost.

Skutek dla naszego tematu jest następujący. Jeśli serwis działa równolegle z www i bez www, a pliki cookie są przypisane do jednego hosta, klient zalogowany w jednej wersji może okazać się niezalogowany w drugiej, a koszyk w sklepie może wyglądać na pusty. To częsta przyczyna zgłoszeń typu "produkty zniknęły z koszyka", zwłaszcza gdy część linków w wiadomościach e-mail prowadzi do innego wariantu niż ten, którego używa sklep. Jedna wersja adresu i przekierowanie z pozostałych usuwają ten problem u źródła.

Druga strona tej samej zasady dotyczy serwisów z wieloma subdomenami. Plik cookie z atrybutem Domain ustawionym na domenę główną trafia do wszystkich subdomen, także do tych, które go nie potrzebują, na przykład do subdomeny z plikami graficznymi. W dużych serwisach bywa to argumentem za wariantem z www, bo pliki cookie strony głównej można wtedy zamknąć w obrębie jednego hosta. W małej stronie firmowej bez dodatkowych subdomen ta różnica nie ma praktycznego znaczenia.

Jak wybrać wersję docelową adresu

Najlepszym wyborem jest wariant https, który serwis już faktycznie stosuje i który widać w wynikach wyszukiwania. Dopiero gdy strona jest nowa albo oba warianty są w użyciu po równo, warto rozważyć argumenty techniczne i wizerunkowe.

Przed decyzją dobrze jest odpowiedzieć sobie na kilka pytań. Który wariant pokazuje Google przy podstronach serwisu? Który adres jest wydrukowany na wizytówkach, samochodach firmowych i w materiałach reklamowych? Do którego prowadzą linki z Profilu Firmy w Google, z mediów społecznościowych i z serwisów partnerów? Czy serwis korzysta z subdomen albo z usług zewnętrznych, które narzucają sposób podpięcia domeny? Odpowiedzi zwykle wskazują jeden wariant bez większych wątpliwości.

Wybrany wariant powinien być używany wszędzie tak samo, także poza stroną. Ten sam adres w Profilu Firmy, w mediach społecznościowych i w katalogach ułatwia odbiorcom i wyszukiwarkom rozpoznanie firmy, o czym piszemy we wpisie o spójności danych firmy w sieci.

Jak ustawić przekierowania z pozostałych wersji w jednym kroku

Każdy z trzech zbędnych wariantów powinien odpowiadać trwałym przekierowaniem po stronie serwera, które od razu prowadzi do wersji docelowej. Jedno żądanie, jedna odpowiedź z kodem 301 i nowy adres, bez przystanków pośrednich.

Dokumentacja Google o przekierowaniach dzieli je na trwałe i tymczasowe. Przy trwałych, czyli przy kodach 301 i 308, adres docelowy jest dla wyszukiwarki sygnałem kanonicznym. Przy tymczasowych, czyli 302, 303 i 307, takiego sygnału nie ma i stary adres może pozostać w wynikach. Do uporządkowania wariantów adresu nadaje się więc wyłącznie przekierowanie trwałe. Różnice omawiamy szerzej we wpisie przekierowanie 301 a 302.

Czym jest łańcuch i dlaczego warto go unikać

Najczęstszy błąd polega na tym, że przekierowania działają, ale po kolei. Adres http z www prowadzi najpierw do https z www, a dopiero stamtąd do https bez www. Każda z reguł osobno jest poprawna, lecz razem tworzą łańcuch dwóch przeskoków. Wytyczne Google o przenoszeniu witryny zalecają przekierowanie bezpośrednie. Jeśli nie da się go uzyskać, łańcuch powinien być jak najkrótszy: najlepiej do trzech adresów i nie więcej niż pięć. Googlebot podąża najwyżej za dziesięcioma przeskokami.

W tabeli widać dwie ważne rzeczy. Przekierowanie zachowuje ścieżkę: adres podstrony oferty prowadzi do tej samej podstrony w wersji docelowej, a nie do strony głównej. Wersja docelowa sama nie przekierowuje nigdzie dalej.

Przykład reguł dla serwera Apache

Na hostingach z serwerem Apache przekierowania zapisuje się zwykle w pliku .htaccess w katalogu głównym serwisu. Poniższy przykład łączy oba warunki w jedną regułę: jeżeli połączenie nie jest szyfrowane albo nazwa hosta zaczyna się od www, serwer od razu odsyła pod adres docelowy.

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://example.pl/$1 [R=301,L]

Gdy wersją docelową ma być adres z www, logika jest ta sama: drugi warunek sprawdza, czy nazwa hosta nie zaczyna się od www, a adres w ostatniej linii zawiera przedrostek. Jest to przykład poglądowy. Na serwerach, które stoją za pośrednikiem, na przykład za siecią dostarczania treści, informacja o szyfrowaniu bywa przekazywana inaczej i reguły wymagają dostosowania. Na serwerach nginx to samo ustawia się w konfiguracji serwera poleceniem zwracającym kod 301, a wiele paneli hostingowych ma gotowy przełącznik preferowanej wersji domeny. Przed zmianą warto zachować kopię dotychczasowego pliku, ponieważ błąd w regułach potrafi unieruchomić cały serwis.

Wytyczne Google zalecają utrzymywanie przekierowań co najmniej przez rok, a najlepiej bezterminowo, dla wygody użytkowników. Przy wariantach adresu nie ma powodu, by kiedykolwiek je wyłączać: stare linki, zakładki w przeglądarkach i wydrukowane materiały będą krążyć latami.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Gdzie ustawia się wersję adresu w WordPressie

W WordPressie wariant adresu zapisany jest w panelu, w menu Ustawienia, na ekranie Ogólne, w dwóch polach: adres WordPressa oraz adres witryny. Według dokumentacji WordPressa pierwsze pole wskazuje miejsce, w którym znajdują się pliki systemu, a drugie adres, który odwiedzający wpisują w przeglądarce. Oba są identyczne, o ile WordPress nie został zainstalowany w osobnym katalogu.

To, co stoi w tych polach, powinno dokładnie odpowiadać wersji docelowej: ten sam protokół i ta sama nazwa hosta. Z naszej praktyki wynika, że na podstawie tych wartości system buduje adresy w menu, w linkach do wpisów i w wielu wtyczkach. Jeżeli serwer przekierowuje na wariant bez www, a w ustawieniach wpisany jest adres z www, obie warstwy zaczynają sobie przeczyć, co w skrajnym przypadku kończy się pętlą i komunikatem przeglądarki o zbyt wielu przekierowaniach.

Dokumentacja wspomina też o stałych WP_HOME i WP_SITEURL w pliku wp-config.php. Jeżeli są zdefiniowane, ich wartości pojawiają się w obu polach i nie da się ich zmienić z poziomu panelu. Zmianę tych adresów najlepiej powierzyć osobie, która ma dostęp do serwera, bo pomyłka w jednym znaku odcina dostęp do panelu. W sklepach na WooCommerce obowiązują te same ustawienia, ponieważ działa on w ramach WordPressa.

Spójność w mapie witryny, znaczniku canonical i linkach

Samo przekierowanie nie wystarcza, jeśli reszta serwisu nadal podaje stare warianty. Wszystkie miejsca, w których serwis sam wskazuje swoje adresy, powinny zawierać dokładnie tę wersję, która została uznana za docelową.

Google opisuje trzy sposoby wskazania preferowanego adresu i szereguje je według siły. Najsilniejsze są przekierowania, wyraźnym sygnałem jest znacznik rel=canonical, a najsłabszym obecność adresu w mapie witryny. Sposoby te się sumują, więc zgodne wskazanie we wszystkich trzech miejscach zwiększa szansę, że wyszukiwarka przyjmie wybór właściciela. Dokumentacja przestrzega przed wskazywaniem różnych adresów kanonicznych tej samej strony różnymi metodami.

Mapa witryny

Zgodnie z wytycznymi o przygotowywaniu mapy witryny plik powinien zawierać pełne, bezwzględne adresy tych stron, które mają pojawiać się w wynikach. Jeżeli treść jest dostępna pod kilkoma adresami, do mapy trafia tylko adres preferowany. Mapa z adresami z www w serwisie, który przekierowuje na wersję bez www, podaje więc robotowi listę adresów, z których żaden nie jest docelowy. Więcej o samym pliku piszemy we wpisie o tym, co umieścić w mapie witryny XML.

Znacznik rel=canonical

Znacznik rel=canonical w kodzie strony powinien zawierać pełny adres w wersji docelowej. Google zaleca adresy bezwzględne zamiast ścieżek względnych oraz znacznik wskazujący na samą siebie na stronie kanonicznej. Częsta pomyłka po zmianie wariantu polega na tym, że szablon nadal wstawia w znaczniku starą nazwę hosta. Zasady wdrożenia opisujemy we wpisie adres kanoniczny i rel=canonical.

Linki wewnętrzne i zewnętrzne

Linki w obrębie serwisu powinny prowadzić bezpośrednio do adresów kanonicznych, a nie do wariantów, które dopiero przekierowują. To zalecenie wprost z dokumentacji Google. W praktyce stare warianty najdłużej utrzymują się w treści wpisów, w stopce, w ręcznie wstawionych odnośnikach i w adresach obrazów.

Na linki z innych stron właściciel ma mniejszy wpływ, ale te najważniejsze można poprawić samodzielnie: adres w Profilu Firmy w Google, w profilach w mediach społecznościowych, w stopkach poczty i w kampaniach Google Ads. Pozostałe linki obsłuży przekierowanie, bo wytyczne Google potwierdzają, że trwałe przekierowania nie powodują utraty wartości przekazywanej przez linki.

Jak sprawdzić efekt w Search Console

Search Console pozwala potwierdzić dwie rzeczy: który adres Google uznał za kanoniczny oraz czy zbędne warianty są rozpoznawane jako przekierowania. Zanim jednak dojdzie do odczytywania raportów, warto zadbać o właściwy typ usługi.

Jak wyjaśnia pomoc Search Console, usługa z prefiksem adresu obejmuje tylko adresy zaczynające się dokładnie od podanego ciągu, razem z protokołem. Usługa założona dla adresu z www nie pokaże więc danych dla wersji bez www. Usługa domeny obejmuje domenę główną, wszystkie subdomeny i oba protokoły, czyli wszystkie cztery warianty naraz. Wymaga weryfikacji przez rekord DNS. Nową usługę zakłada się z rozwijanej listy usług, pozycją służącą do dodawania usługi, gdzie następnie wskazuje się typ: domena albo prefiks adresu.

Narzędzie do sprawdzania adresów URL

Pełny adres strony wpisuje się w pasku wyszukiwania u góry ekranu Search Console. W wyniku, w części Indeksowanie stron, znajdują się dwa pola opisane w pomocy narzędzia: "Adres kanoniczny określony przez użytkownika" oraz "Adres kanoniczny wybrany przez Google". W uporządkowanym serwisie oba pokazują ten sam adres w wersji docelowej. Pole "Strona odsyłająca" podpowiada, skąd Google trafił na dany adres, a pole "Mapy witryn" pokazuje, w których mapach go znalazł. To dobre miejsce, by wykryć mapę podającą stary wariant.

Pomoc zastrzega, że test wersji opublikowanej nie przewiduje, który adres kanoniczny uzna Google, i choć sprawdza przekierowania, nie pokazuje ich w wyniku. Poprawność samych przekierowań trzeba więc ocenić osobno, na przykład w narzędziach deweloperskich przeglądarki Chrome, na karcie z ruchem sieciowym.

Raport Indeksowanie stron

Raport Indeksowanie stron, dostępny w menu bocznym w grupie Indeksowanie pod pozycją Strony, wymienia powody, dla których adresy nie trafiły do indeksu. Pomoc do raportu opisuje kilka statusów związanych z naszym tematem. Status "Strona zawierająca przekierowanie" przy zbędnych wariantach jest wynikiem oczekiwanym i nie wymaga działania, o ile przekierowanie jest zamierzone. Status "Duplikat, użytkownik nie oznaczył strony kanonicznej" oznacza, że Google sam wskazał wersję, bo serwis tego nie zrobił. Status "Duplikat, wyszukiwarka Google wybrała inną stronę kanoniczną niż użytkownik" świadczy o tym, że sygnały w serwisie są ze sobą sprzeczne albo wskazana strona różni się treścią.

• Trzy zbędne warianty strony głównej odpowiadają kodem 301 i prowadzą do wersji docelowej w jednym przeskoku.
• To samo dzieje się dla kilku losowych podstron, a przekierowanie zachowuje ścieżkę.
• Certyfikat SSL obejmuje nazwę z www i bez www.
• Pola adresu w ustawieniach systemu zarządzania treścią zawierają wersję docelową.
• Znacznik rel=canonical i mapa witryny podają wyłącznie adresy w wersji docelowej.
• Linki w menu, stopce i treści nie przechodzą przez przekierowanie.
• W Search Console oba pola adresu kanonicznego pokazują ten sam adres.

Na zmianę w raportach trzeba poczekać. Wytyczne Google mówią, że przy przenoszeniu adresów wyszukiwarka potrzebuje zwykle kilku tygodni dla witryn średniej wielkości i więcej czasu dla dużych. Narzędzie zmiany adresu w Search Console nie jest tu potrzebne: pomoc narzędzia wprost wyłącza z jego zakresu przejście między wersją z www i bez www w tej samej domenie.

Typowe pomyłki i sytuacje, w których warto poprosić o pomoc

Większość kłopotów z wariantami adresu wynika nie z braku przekierowań, lecz z tego, że ustawiono je częściowo albo w kilku miejscach jednocześnie. Poniżej zebraliśmy przypadki, które spotykamy najczęściej.

Pierwsza pomyłka to przekierowanie tymczasowe zamiast trwałego. Strona zachowuje się poprawnie dla użytkownika, lecz Google nie otrzymuje sygnału kanonicznego. Druga to przekierowanie wszystkich podstron zbędnego wariantu na stronę główną, przez co linki prowadzące do konkretnych ofert tracą swój cel. Trzecia to reguły ustawione równocześnie w panelu hostingu, w pliku .htaccess i we wtyczce, które nakładają się na siebie i tworzą łańcuch albo pętlę. Czwarta to pominięcie wariantu, którego nikt nie skontrolował, najczęściej http z www. Piąta to próba rozwiązania sprawy plikiem robots.txt lub dyrektywą noindex. Dokumentacja Google odradza oba sposoby jako metodę wskazywania wersji kanonicznej: adres zablokowany w robots.txt może nadal trafić do indeksu bez treści, a noindex całkowicie wyklucza stronę z wyników. Różnice między tymi mechanizmami wyjaśniamy we wpisie canonical, noindex i robots.txt.

Przykład: sklep z Poznania po wdrożeniu certyfikatu miał poprawne przekierowanie z http na https, ale wersja z www i bez www działały równolegle. Wtyczka budowała mapę witryny z www, szablon wstawiał znacznik canonical bez www, a kampanie reklamowe kierowały raz tu, raz tam. Uporządkowanie polegało na jednej regule na serwerze, poprawce dwóch pól w ustawieniach i zbiorczej zamianie linków w treści.

Pomoc specjalisty przydaje się zwłaszcza wtedy, gdy serwis działa za pośrednikiem sieciowym, korzysta z kilku subdomen lub wersji językowych albo gdy zmiana wariantu łączy się z przenosinami na inny serwer. W takich sytuacjach kontrolę wariantów adresu wykonujemy w ramach SEO technicznego albo jako część, którą obejmuje kompleksowy audyt SEO. Przy większych zmianach przydatny będzie też nasz wpis o tym, jak zaplanować migrację strony bez utraty pozycji.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl