Adres z www czy bez www? Jak ustawić jedną wersję i przekierować pozostałe?

Ta sama strona firmowa bardzo często otwiera się pod czterema adresami naraz: z przedrostkiem www i bez niego, a do tego w wersji http i https. Dla człowieka to jedna witryna. Dla wyszukiwarki to cztery osobne adresy z identyczną treścią, spośród których Google musi sam wybrać jeden do pokazania w wynikach.

Taki stan nie kończy się karą, ale wprowadza bałagan: linki z innych serwisów rozkładają się na kilka wersji, w raportach pojawiają się duplikaty, a w wynikach potrafi wyświetlać się nie ta wersja adresu, którą firma drukuje na wizytówkach.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które same opiekują się swoją stroną. Po lekturze będzie wiadomo, jak sprawdzić obecny stan, którą wersję adresu wybrać, jak ustawić stałe przekierowanie pozostałych wersji na serwerze i w WordPressie, co poprawić w samym serwisie oraz po czym poznać, że Google przyjął zmianę.

Dlaczego adres z www i bez www to dla Google dwie różne strony?

Przedrostek www jest z technicznego punktu widzenia zwykłą subdomeną. Adres www.przyklad.pl i adres przyklad.pl to dwie osobne nazwy, które mogą prowadzić na ten sam serwer, na dwa różne serwery albo jedna z nich może nie prowadzić nigdzie. O tym, co się pod nimi wyświetla, decydują ustawienia domeny i serwera, a nie przeglądarka.

Do tego dochodzi protokół. Każda z tych dwóch nazw może działać przez http oraz przez https, co daje razem cztery kombinacje. Jeśli wszystkie cztery zwracają tę samą treść i żadna nie odsyła do innej, w sieci istnieją cztery kopie każdej podstrony serwisu.

Google radzi sobie z tym na własną rękę: grupuje kopie i wybiera spośród nich jedną wersję, nazywaną w dokumentacji adresem kanonicznym. Kłopot polega na tym, że bez wyraźnej wskazówki wybór należy do wyszukiwarki i nie zawsze pokrywa się z oczekiwaniem właściciela.

Dokumentacja Google dodaje jeszcze jedną ważną informację: wyszukiwarka domyślnie woli wersję https od http. Wyjątkiem są sytuacje, w których strona https ma nieprawidłowy certyfikat, wczytuje niezabezpieczone elementy, przekierowuje na http albo sama wskazuje wersję http jako właściwą. Dlatego porządkowanie www i porządkowanie protokołu najlepiej wykonać jednocześnie, jednym zestawem reguł.

Po czym rozpoznać, że strona działa pod kilkoma adresami?

Najprostszy test nie wymaga żadnych narzędzi. Wystarczy przeglądarka i kartka, na której zapisuje się wynik każdej próby. Dobrze jest użyć okna prywatnego, ponieważ zwykłe okno potrafi zapamiętać wcześniejsze przekierowania i pokazać nieaktualny obraz sytuacji.

1. W pasku adresu wpisuje się kolejno cztery wersje strony głównej: http://przyklad.pl, http://www.przyklad.pl, https://przyklad.pl oraz https://www.przyklad.pl, za każdym razem z pełnym początkiem adresu.
2. Po załadowaniu strony należy kliknąć w pasek adresu i odczytać, jaki adres faktycznie się w nim znajduje. Przeglądarki często ukrywają początek adresu, a kliknięcie pokazuje go w całości.
3. Jeśli po każdej z czterech prób w pasku widnieje ten sam adres, serwis ma jedną wersję i przekierowania działają. Jeśli adres zostaje taki, jaki został wpisany, dana wersja działa samodzielnie i jest kopią.
4. Ten sam test trzeba powtórzyć dla jednej dowolnej podstrony, na przykład oferty lub kontaktu. Zdarza się, że strona główna przekierowuje poprawnie, a podstrony już nie.
5. Na koniec należy zanotować wersje, które nie otwierają się wcale albo wyświetlają ostrzeżenie o bezpieczeństwie. To osobny rodzaj usterki, opisany w dalszej części.

Drugim źródłem wiedzy jest Google Search Console. W raporcie „Indeksowanie stron” na liście powodów niezindeksowania mogą pojawić się pozycje „Duplikat, użytkownik nie oznaczył strony kanonicznej” albo „Duplikat, wyszukiwarka Google wybrała inną stronę kanoniczną niż użytkownik”. Jeśli po kliknięciu takiej pozycji na liście widać adresy różniące się od właściwych tylko przedrostkiem www lub protokołem, diagnoza jest potwierdzona.

Którą wersję wybrać: z www czy bez www?

Z punktu widzenia pozycji w Google obie wersje są równie dobre. Wyszukiwarka nie premiuje żadnej z nich. Znaczenie ma wyłącznie to, żeby wybrać jedną i trzymać się jej konsekwentnie we wszystkich miejscach.

W praktyce o wyborze decydują trzy okoliczności, które należy ocenić w podanej kolejności.

Która wersja jest już znana wyszukiwarce i klientom?

Jeśli strona działa od dawna, bezpieczniej jest zostać przy wersji, którą Google już pokazuje w wynikach i do której prowadzi większość linków z innych serwisów. Stałe przekierowanie przenosi ruch na nową wersję, ale każda zmiana oznacza dla wyszukiwarki okres ponownego odczytywania adresów. Nie ma powodu wywoływać go bez potrzeby.

Wersję obecną w wynikach najłatwiej ustalić w Search Console. W narzędziu „Sprawdzanie adresów URL” po wklejeniu adresu strony głównej pole „Adres kanoniczny wybrany przez Google” pokazuje, którą wersję wyszukiwarka uznała za właściwą.

Jak skonfigurowana jest domena i hosting?

Część usług, przez które przepuszcza się ruch do strony, wymaga wskazania ich rekordem CNAME. Na samej domenie bez przedrostka taki rekord w wielu panelach nie jest dostępny, natomiast na subdomenie www nie sprawia trudności. Jeżeli firma korzysta z takiej usługi lub planuje ją w przyszłości, wersja z www daje większą swobodę. Przy zwykłym hostingu ta różnica nie ma znaczenia.

Jak adres wygląda w materiałach firmy?

Krótszy adres bez www lepiej prezentuje się na wizytówkach i samochodach firmowych, dlatego wiele firm wybiera właśnie tę wersję. To w pełni uzasadniony argument, o ile dwie poprzednie okoliczności nie przemawiają za czymś innym.

W dalszej części przyjmuję dla przykładu, że wybraną wersją jest https://www.przyklad.pl. Dla wersji bez www wszystkie czynności wykonuje się tak samo, z odwróconym kierunkiem przekierowania, a gotowa reguła dla tego wariantu również jest podana.

Co trzeba przygotować, zanim powstanie przekierowanie?

Przekierowanie jest ostatnim ogniwem. Zanim zacznie działać, obie nazwy muszą w ogóle trafiać na serwer i obie muszą być objęte certyfikatem. Pominięcie tego etapu jest najczęstszą przyczyną sytuacji, w której reguła jest wpisana poprawnie, a jedna z wersji nadal nie działa.

Czy obie nazwy prowadzą na serwer?

W panelu, w którym zarządza się domeną, w strefie DNS powinny istnieć wpisy zarówno dla samej domeny, jak i dla subdomeny www. Jeżeli brakuje wpisu dla www, adres z przedrostkiem kończy się komunikatem przeglądarki o nieznalezionej witrynie i żadne przekierowanie tego nie naprawi, bo zapytanie nigdy nie dociera do serwera.

Po stronie hostingu obie nazwy muszą być przypisane do tego samego serwisu. W większości paneli nazwa z www jest dodawana automatycznie jako alias domeny głównej. Jeżeli wersja z www pokazuje pustą stronę dostawcy hostingu zamiast witryny, należy dodać ją w panelu jako alias lub domenę dodatkową wskazującą ten sam katalog.

Czy certyfikat obejmuje obie nazwy?

Przeglądarka sprawdza certyfikat, zanim odczyta przekierowanie. Jeśli certyfikat został wystawiony tylko dla przyklad.pl, wejście na https://www.przyklad.pl kończy się ostrzeżeniem o niezabezpieczonym połączeniu i użytkownik nie zostaje nigdzie przeniesiony. Certyfikat musi zawierać obie nazwy.

Sprawdza się to w przeglądarce: po otwarciu strony przez https należy kliknąć ikonę przy adresie i wyświetlić szczegóły certyfikatu, gdzie wymienione są nazwy, dla których go wystawiono. Jeśli brakuje jednej z nich, w panelu hostingu trzeba wystawić certyfikat ponownie z zaznaczeniem obu nazw. Przejście na szyfrowane połączenie opisałem osobno w tekście o tym, jak przejść na https bez strat.

Czy istnieje aktualna kopia zapasowa?

Zmiany dotyczą pliku serwera i ustawień adresu w systemie strony. Błąd w jednym znaku potrafi wyłączyć całą witrynę. Przed rozpoczęciem należy pobrać na dysk obecny plik .htaccess oraz wykonać kopię bazy danych, żeby w razie pomyłki przywrócić poprzedni stan w kilka minut.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a przejmę sprawę: sprawdzę wszystkie wersje adresu, ustawię jedno stałe przekierowanie na wybraną wersję i poprawię adresy w serwisie oraz w Search Console.

Jak ustawić przekierowanie 301 w pliku .htaccess?

Na większości hostingów współdzielonych w Polsce strony obsługuje serwer Apache albo zgodny z nim LiteSpeed. Oba odczytują plik .htaccess znajdujący się w głównym katalogu strony. To w nim zapisuje się regułę, która każde wejście na niewłaściwą wersję adresu odsyła na wersję wybraną.

Dokumentacja Google wskazuje przekierowanie wykonywane przez serwer jako najlepszy sposób i rozróżnia dwa rodzaje. Przekierowanie stałe, o kodzie 301 lub 308, jest dla wyszukiwarki wyraźnym sygnałem, że właściwy jest adres docelowy. Przekierowanie tymczasowe, o kodzie 302 lub 307, takiego sygnału nie daje. Przy porządkowaniu www potrzebne jest wyłącznie stałe.

Kolejność czynności jest następująca.

1. Po zalogowaniu do panelu hostingu należy otworzyć menedżer plików albo połączyć się z serwerem programem FTP i przejść do głównego katalogu strony, zwykle nazwanego public_html.
2. Plik .htaccess zaczyna się od kropki i bywa ukryty. W menedżerze plików trzeba włączyć wyświetlanie plików ukrytych, a następnie pobrać ten plik na dysk jako kopię.
3. Plik otwiera się do edycji i na samej jego górze, przed wszystkimi innymi wpisami, wkleja się jedną z dwóch reguł podanych poniżej, po zamianie przyklad.pl na własną domenę.
4. Po zapisaniu pliku należy od razu otworzyć stronę w oknie prywatnym. Jeśli pojawia się błąd serwera o numerze 500, w regule jest literówka i trzeba przywrócić pobraną kopię.
5. Na koniec powtarza się test czterech adresów opisany wcześniej, dla strony głównej i dla jednej podstrony.

Reguła dla wersji docelowej z www i z https:

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

Reguła dla wersji docelowej bez www i z https:

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

Dwa warunki połączone słowem OR oznaczają: jeśli połączenie nie jest szyfrowane albo nazwa nie jest tą właściwą, serwer odsyła na pełny adres docelowy z zachowaniem dalszej części adresu. Wejście na dowolną z trzech niewłaściwych wersji kończy się więc jednym skokiem, a osoba, która kliknęła link do oferty, trafia na ofertę, nie na stronę startową.

Co zrobić, gdy po wklejeniu reguły pojawia się pętla?

Jeżeli przeglądarka wyświetla komunikat o zbyt wielu przekierowaniach, najczęściej winny jest pierwszy warunek. Gdy przed serwerem stoi pośrednik, na przykład sieć dostarczania treści lub serwer pośredniczący dostawcy hostingu, szyfrowanie kończy się na pośredniku, a do właściwego serwera zapytanie dociera już bez niego. Serwer uznaje wtedy, że połączenie nie jest szyfrowane, i odsyła na https bez końca.

W takim układzie należy przywrócić kopię pliku i ustawić wymuszanie https w panelu pośrednika albo hostingu, a w pliku .htaccess zostawić tylko warunek dotyczący nazwy. Dokładny zapis zależy od dostawcy, dlatego bezpieczniej poprosić o niego pomoc techniczną hostingu, niż próbować kolejnych wariantów na działającej stronie.

Więcej o samej składni pliku, kolejności reguł i typowych pomyłkach znajduje się w osobnej instrukcji poświęconej temu, jak zapisać przekierowanie 301 w pliku .htaccess.

Jak zrobić to samo na serwerze Nginx albo w panelu hostingu?

Serwer Nginx nie odczytuje pliku .htaccess. Przekierowanie zapisuje się w pliku konfiguracyjnym serwera, do którego dostęp ma administrator. Na hostingu zarządzanym zmianę wprowadza zwykle dostawca na prośbę klienta albo udostępnia do tego formularz w panelu.

Zasada jest taka sama jak w Apache: dla każdej niewłaściwej nazwy tworzy się osobny blok, który niczego nie wyświetla, tylko odsyła dalej. Dla wersji docelowej z www wiersz odpowiedzialny za przekierowanie ma postać:

return 301 https://www.przyklad.pl$request_uri;

Zmienna na końcu wiersza przenosi dalszą część adresu, czyli pełni tę samą funkcję co w regule dla Apache. Blok obsługujący niewłaściwą nazwę przez https musi mieć wskazany certyfikat, w przeciwnym razie przeglądarka zatrzyma się na ostrzeżeniu, zanim odczyta przekierowanie. Po zmianie konfiguracji serwer wymaga przeładowania, które wykonuje administrator.

Wielu dostawców hostingu ma w panelu gotowy przełącznik, który wymusza https, oraz pole wyboru preferowanej wersji domeny. Jeśli taka opcja istnieje, jest najbezpieczniejszą drogą, bo nie wymaga ręcznej edycji plików. Po jej włączeniu trzeba jednak koniecznie wykonać test czterech adresów.

Jak ustawić jedną wersję adresu w WordPressie?

WordPress przechowuje własny adres w ustawieniach i sam odsyła odwiedzających na tę wersję, którą ma zapisaną. Jeśli w ustawieniach widnieje adres bez www, a reguła na serwerze odsyła na wersję z www, obie strony zaczynają przerzucać się odwiedzającym i powstaje pętla. Dlatego ustawienie w WordPressie musi być zgodne z regułą na serwerze co do znaku.

1. W panelu administracyjnym należy przejść do menu „Ustawienia” i wybrać pozycję „Ogólne”.
2. W polach „Adres WordPressa (URL)” oraz „Adres witryny (URL)” wpisuje się pełny adres w wybranej wersji, na przykład https://www.przyklad.pl, bez ukośnika na końcu. W typowej instalacji oba pola mają tę samą wartość.
3. Przed zatwierdzeniem trzeba przeczytać wpisany adres litera po literze. Literówka w tych polach odcina dostęp do panelu.
4. Zmianę zatwierdza przycisk „Zapisz zmiany” na dole ekranu. WordPress wyloguje użytkownika i poprosi o ponowne zalogowanie już pod nowym adresem.
5. Po zalogowaniu należy wyczyścić pamięć podręczną we wtyczce, która ją obsługuje, oraz w panelu hostingu, jeśli serwer ma własną.

Zdarza się, że oba pola są wyszarzone i nie dają się edytować. Oznacza to, że adres został wpisany na stałe w pliku wp-config.php za pomocą stałych WP_HOME i WP_SITEURL. Wtedy zmianę wprowadza się w tym pliku, poprawiając adres w obu wierszach.

Ten sam plik służy jako wyjście awaryjne. Jeśli po zmianie w ustawieniach panel przestał się otwierać, wystarczy dopisać w wp-config.php, powyżej wiersza z informacją o końcu edycji, dwa wiersze z poprawnym adresem:

define( 'WP_HOME', 'https://www.przyklad.pl' );
define( 'WP_SITEURL', 'https://www.przyklad.pl' );

Co ze starymi adresami zapisanymi w treści?

Zmiana w ustawieniach nie poprawia adresów wpisanych wcześniej w treść wpisów, w menu, w przyciskach i w adresach obrazków. Te odnośniki nadal prowadzą do poprzedniej wersji i dopiero przekierowanie odsyła je dalej. Strona działa, ale każde takie kliknięcie wykonuje zbędny skok.

Stare adresy zamienia się zbiorczo w bazie danych, narzędziem do wyszukiwania i zamiany obsługującym dane zapisane w formie zserializowanej. Zwykła zamiana tekstu w pliku bazy potrafi uszkodzić ustawienia wtyczek i motywu, dlatego nie należy jej wykonywać ręcznie. Przed uruchomieniem zamiany kopia bazy jest obowiązkowa, a narzędzie najlepiej najpierw uruchomić w trybie próbnym, który tylko pokazuje liczbę znalezionych wystąpień.

Co jeszcze poprawić w serwisie, żeby sygnały były spójne?

Przekierowanie jest najmocniejszym sygnałem, ale nie jedynym. Dokumentacja Google wymienia trzy sposoby wskazania właściwego adresu: przekierowanie, znacznik kanoniczny w kodzie strony oraz mapę witryny, która jest sygnałem najsłabszym. Zaleca też, by wszystkie wskazywały ten sam adres. Sprzeczne sygnały są jedną z głównych przyczyn, dla których wyszukiwarka wybiera inną wersję niż właściciel.

Po ustawieniu przekierowania należy więc przejść przez pozostałe miejsca.

• Znacznik kanoniczny na każdej podstronie powinien zawierać pełny adres w wybranej wersji, razem z protokołem i nazwą. Dokumentacja zaleca adresy bezwzględne, a nie skrócone.
• Mapa witryny powinna zawierać wyłącznie adresy w wybranej wersji. Wtyczki tworzą ją na podstawie ustawień adresu, więc po zmianie zwykle odświeża się sama, ale trzeba to sprawdzić, otwierając plik mapy w przeglądarce.
• Linki wewnętrzne w menu, stopce i treści powinny prowadzić od razu do wersji docelowej, a nie przez przekierowanie.
• Znaczniki wersji językowych, jeśli serwis je stosuje, również muszą zawierać adresy w wybranej wersji.
• Wiersz z adresem mapy witryny w pliku robots.txt powinien wskazywać wersję docelową.

Sposób poprawnego zapisania znacznika kanonicznego opisałem dokładnie w tekście o tym, jak wskazać Google właściwą wersję podstrony.

Jak sprawdzić, czy przekierowanie jest stałe i ma jeden skok?

To, że w pasku adresu pojawia się właściwa wersja, nie mówi jeszcze, jaką drogą przeglądarka do niej dotarła. Trzeba sprawdzić dwie rzeczy: kod odpowiedzi oraz liczbę skoków.

W przeglądarce Chrome służą do tego narzędzia dla programistów, otwierane klawiszem F12. Na karcie „Sieć” należy zaznaczyć pole zachowywania dziennika, a następnie wpisać w pasku jedną z niewłaściwych wersji adresu. Na górze listy pojawiają się kolejne zapytania wraz z kodem odpowiedzi w kolumnie stanu. Poprawny wynik to jeden wiersz z kodem 301 i zaraz po nim wiersz z kodem 200 pod adresem docelowym.

Wyniki należy odczytywać w następujący sposób. Kod 301 lub 308 z adresem docelowym w wybranej wersji oznacza poprawne ustawienie. Kod 302 lub 307 oznacza przekierowanie tymczasowe, które trzeba zamienić na stałe. Dwa lub trzy skoki pod rząd, na przykład najpierw na https, a dopiero potem na www, oznaczają łańcuch.

Łańcuch nie wyłącza strony, ale wydłuża czas wejścia i niepotrzebnie komplikuje odczyt adresów przez roboty. Raport Search Console wymienia zbyt długi łańcuch wśród przyczyn pozycji „Błąd przekierowania”. Najczęściej powstaje wtedy, gdy https wymusza jedno miejsce, na przykład panel hostingu, a wersję nazwy inne, na przykład WordPress. Naprawa polega na zastąpieniu obu jedną regułą, która od razu podaje pełny adres docelowy. Więcej o tym, jak skrócić łańcuch do jednego kroku, opisuję w osobnym tekście.

Co ustawić w Google Search Console po zmianie?

W Search Console nie ma dziś ustawienia, w którym wskazuje się preferowaną wersję domeny. Wyszukiwarka odczytuje ją z przekierowań, znaczników kanonicznych i mapy witryny. Panel służy natomiast do tego, żeby zobaczyć dane ze wszystkich wersji w jednym miejscu i potwierdzić, że zmiana została odczytana.

Najwygodniej pracuje się na usłudze typu „Usługa domeny”. Zgodnie z pomocą Search Console obejmuje ona wszystkie subdomeny oraz protokoły, czyli wszystkie cztery wersje adresu naraz. Usługa typu „Usługa z prefiksem URL” pokazuje wyłącznie adresy zaczynające się dokładnie od podanego początku, więc dane z pozostałych wersji są w niej niewidoczne. Usługę domeny weryfikuje się wyłącznie rekordem DNS.

1. W Search Console należy otworzyć listę usług w lewym górnym rogu i kliknąć „Dodaj usługę”.
2. W oknie wyboru typu wskazuje się usługę domeny i wpisuje samą nazwę domeny, bez protokołu i bez przedrostka www.
3. Panel wyświetla rekord tekstowy do dodania w strefie DNS domeny. Po jego dodaniu u operatora domeny należy wrócić do Search Console i kliknąć „Zweryfikuj”. Jeśli weryfikacja się nie powiedzie, trzeba odczekać, bo zmiany w DNS rozchodzą się z opóźnieniem, i spróbować ponownie.
4. W menu „Mapy witryn” przesyła się adres mapy w wybranej wersji. Jeśli wcześniej zgłoszona była mapa w innej wersji, należy ją usunąć z listy.
5. W narzędziu „Sprawdzanie adresów URL” wkleja się adres strony głównej w wersji docelowej i odczytuje pola „Adres kanoniczny określony przez użytkownika” oraz „Adres kanoniczny wybrany przez Google”. Oba powinny pokazywać wersję docelową.
6. Dla najważniejszych podstron można użyć przycisku „Poproś o zindeksowanie”. Liczba takich próśb w ciągu doby jest ograniczona, dlatego przy większym serwisie podstawą pozostaje mapa witryny.

Jedna uwaga, która oszczędza nerwów: do zmiany między www a wersją bez www nie służy narzędzie „Zmiana adresu”. Pomoc Search Console wyraźnie wymienia ten przypadek, podobnie jak przejście z http na https, wśród sytuacji, w których narzędzia się nie używa. Jest ono przeznaczone do przenosin na inną domenę.

Po czym poznać, że Google przyjął nową wersję, i ile to trwa?

Przekierowanie działa dla odwiedzających natychmiast. Wyszukiwarka potrzebuje czasu, żeby ponownie odwiedzić adresy i zaktualizować swoje dane. Przy małej stronie firmowej zmiany widać zwykle po kilku dniach lub tygodniach, przy dużym serwisie trwa to dłużej. Google nie podaje gwarantowanego terminu i nikt rzetelny go nie obieca.

O powodzeniu świadczą dwie obserwacje w Search Console. Po pierwsze, w raporcie „Indeksowanie stron” adresy w niewłaściwych wersjach przechodzą do pozycji „Strona zawiera przekierowanie”. Wbrew pozorom to dobra wiadomość: pomoc Google opisuje tę pozycję jako adres niekanoniczny, który przekierowuje do innej strony i nie będzie indeksowany. Dokładnie taki był cel.

Po drugie, liczba adresów w pozycjach dotyczących duplikatów zaczyna maleć. Po naprawie można w szczegółach danej pozycji kliknąć „Sprawdź poprawkę”. Według pomocy Search Console weryfikacja zajmuje zazwyczaj do 2 tygodni, choć bywa dłuższa.

Dokumentacja Google uprzedza, że po ustawieniu przekierowania stary adres może jeszcze przez pewien czas pojawiać się w wynikach jako nazwa alternatywna. Jest to zachowanie normalne i ustępuje samo, o ile sygnały pozostają spójne.

Co zrobić, gdy Google nadal pokazuje starą wersję?

Jeśli po kilku tygodniach pole „Adres kanoniczny wybrany przez Google” wciąż wskazuje starą wersję, należy po kolei wykluczyć przyczyny. Najpierw ponowny test kodu odpowiedzi, bo przekierowanie mogło zostać nadpisane przez aktualizację wtyczki lub zmianę w panelu hostingu. Następnie kontrola znacznika kanonicznego w kodzie źródłowym kilku podstron oraz zawartości mapy witryny.

Jakich błędów unikać przy porządkowaniu adresów?

Większość kłopotów po takiej zmianie nie wynika z samego przekierowania, tylko z prób przyspieszenia sprawy środkami, które do tego nie służą. Poniższe pomyłki widuję najczęściej.

• Blokowanie niewłaściwej wersji w pliku robots.txt. Dokumentacja Google wprost odradza ten sposób. Robot, który nie może wejść na adres, nie odczyta przekierowania, więc zmiana nigdy do niego nie dotrze.
• Dodawanie znacznika noindex do niewłaściwej wersji. Przy wspólnym katalogu obie nazwy wyświetlają te same pliki, więc znacznik trafia także na wersję docelową i usuwa z wyników całą witrynę.
• Zgłaszanie starej wersji w narzędziu do usuwania adresów. Według dokumentacji ukrywa ono w wyszukiwarce wszystkie wersje adresu, również tę właściwą.
• Przekierowanie tymczasowe zamiast stałego. Strona wygląda na działającą, a wyszukiwarka nie dostaje sygnału, że zmiana jest trwała.
• Zmiana zdania po kilku tygodniach. Każde odwrócenie kierunku przekierowania zmusza wyszukiwarkę do ponownego odczytania serwisu. Wersję wybiera się raz.

Najczęstsze pytania

Czy wersja z www jest lepsza dla pozycji w Google niż wersja bez www?

Nie. Wyszukiwarka traktuje obie wersje jednakowo i żadnej nie nagradza. Na widoczność wpływa konsekwencja: jedna wersja ustawiona przekierowaniem stałym, wpisana w znaczniki kanoniczne, w mapę witryny i w linki wewnętrzne. Wybór między nimi jest decyzją techniczną i wizerunkową.

Czy po ustawieniu przekierowania strona straci pozycje?

Przekierowanie stałe jest sposobem, który sama dokumentacja Google zaleca do wskazania właściwego adresu, więc poprawnie wykonane porządkuje sytuację, zamiast ją pogarszać. W okresie ponownego odczytywania adresów mogą wystąpić przejściowe wahania. Nikt nie jest w stanie zagwarantować ich braku ani określić z góry ich skali, dlatego zmianę najlepiej wykonać raz i w całości.

Czy wystarczy sam znacznik kanoniczny bez przekierowania?

Znacznik kanoniczny jest sygnałem dla wyszukiwarki, ale nie przenosi odwiedzających. Osoba, która wejdzie na niewłaściwą wersję, pozostanie na niej, a linki, które stamtąd skopiuje, będą utrwalać bałagan. Przy czterech wersjach tego samego serwisu właściwym rozwiązaniem jest przekierowanie, a znacznik je uzupełnia.

Dlaczego jedna wersja adresu pokazuje ostrzeżenie o bezpieczeństwie?

Najczęściej certyfikat został wystawiony tylko dla jednej nazwy. Przeglądarka sprawdza go przed odczytaniem przekierowania, więc zatrzymuje się na ostrzeżeniu. Rozwiązaniem jest ponowne wystawienie certyfikatu w panelu hostingu z uwzględnieniem obu nazw, z www i bez www.

Czy przekierowanie trzeba utrzymywać na stałe?

Tak. Do niewłaściwych wersji przez lata będą prowadzić stare linki, zakładki w przeglądarkach i adresy wpisywane z pamięci. Usunięcie reguły sprawia, że kopie wracają, a wyszukiwarka znów musi wybierać między nimi. Reguła nie obciąża serwera w zauważalny sposób, więc nie ma powodu jej zdejmować.

Co zrobić, gdy po zmianie nie można zalogować się do WordPressa?

Najpierw należy otworzyć panel w oknie prywatnym pod adresem w nowej wersji, ponieważ stare dane logowania zapisane w przeglądarce dotyczą poprzedniej nazwy. Jeśli panel nadal się nie otwiera, adres w ustawieniach zawiera błąd i trzeba go nadpisać stałymi w pliku wp-config.php, tak jak opisano wyżej. Gdy pojawia się pętla, przyczyną jest niezgodność adresu w ustawieniach z regułą na serwerze.

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

Porządkowanie adresów nie jest trudne, ale wymaga wejścia w kilka miejsc naraz: strefę domeny, pliki na serwerze, ustawienia strony i Search Console. Nie każdy chce to robić na stronie, z której firma na co dzień żyje, i w pełni to rozumiem. Chętnie przeprowadzę całość od początku do końca: sprawdzę wszystkie cztery wersje adresu, doradzę wybór, wykonam kopię, ustawię jedno stałe przekierowanie, poprawię adresy w serwisie i dopilnuję, żeby Google odczytał zmianę.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co widać po pierwszym sprawdzeniu i co należy zrobić dalej.