Zmiana adresu podstrony, nowa domena, przejście na szyfrowane połączenie albo porządki w starej ofercie mają jedną wspólną cechę: stary adres przestaje działać, a prowadzą do niego linki, zakładki klientów i wyniki Google. Przekierowanie 301 sprawia, że każdy, kto trafi pod stary adres, zostaje od razu przeniesiony pod nowy. Na serwerach Apache i LiteSpeed najczęściej ustawia się je w pliku .htaccess.
Ten plik ma jednak pewną właściwość, o której właściciel firmy dowiaduje się zwykle w najgorszym momencie. Jedna literówka, brakująca spacja albo dyrektywa, której serwer nie obsługuje, i zamiast strony pojawia się komunikat o błędzie 500. Nie działa wtedy nic: ani strona główna, ani sklep, ani panel administracyjny.
Ta instrukcja jest przeznaczona dla osób, które prowadzą własną stronę i chcą ustawić przekierowanie samodzielnie, bez programisty. Po lekturze czytelnik będzie wiedział, gdzie leży plik, jak zrobić jego kopię, które wiersze wkleić w czterech najczęstszych sytuacjach, jak sprawdzić wynik i jak w dwie minuty przywrócić stronę, gdy coś pójdzie źle.
Czym jest przekierowanie 301 i kiedy się je stosuje?
Każda odpowiedź serwera na żądanie przeglądarki ma trzycyfrowy kod. Kod 200 oznacza, że strona została wysłana poprawnie, 404 – że jej nie ma, a 301 – że została przeniesiona na stałe pod inny adres. Razem z kodem 301 serwer wysyła nowy adres, a przeglądarka otwiera go sama. Odwiedzający widzi po prostu właściwą stronę i zwykle nie zauważa, że został przeniesiony.
Roboty wyszukiwarek odczytują ten sam sygnał. Według dokumentacji Google przekierowanie stałe, czyli 301 lub 308, jest informacją, że adres docelowy ma zastąpić stary w wynikach wyszukiwania. Przekierowanie tymczasowe, czyli 302, 303 lub 307, takiego sygnału nie daje i w wynikach nadal może się pojawiać stary adres.
Przekierowanie 301 stosuje się wtedy, gdy zmiana jest trwała i nie zostanie cofnięta. Najczęstsze sytuacje to:
- zmiana adresu pojedynczej podstrony, na przykład po poprawieniu jej nazwy,
- usunięcie podstrony, która ma swój odpowiednik w innym miejscu serwisu,
- połączenie kilku podobnych tekstów w jeden,
- przeniesienie całej strony na nową domenę,
- przejście z adresów http na https,
- ujednolicenie adresu do jednej wersji: z www albo bez www.
Kodu 301 nie należy używać przy zmianach chwilowych, na przykład gdy produkt jest niedostępny przez tydzień albo strona przechodzi krótką przerwę techniczną. Przeglądarki zapamiętują przekierowania stałe i potrafią stosować je długo po usunięciu reguły z serwera. Do zmian na chwilę służy przekierowanie tymczasowe 302.
Czym jest plik .htaccess i na jakich serwerach działa?
Plik .htaccess to zwykły plik tekstowy z ustawieniami serwera, który leży w katalogu strony. Dokumentacja serwera Apache nazywa takie pliki rozproszonymi plikami konfiguracyjnymi: zapisane w nich dyrektywy obowiązują w katalogu, w którym plik się znajduje, oraz we wszystkich jego podkatalogach. Serwer odczytuje plik przy każdym żądaniu, dlatego zmiana działa od razu po zapisaniu.
Nazwa zaczyna się od kropki i nie ma rozszerzenia. To nie jest pomyłka. Kropka na początku oznacza w systemach serwerowych plik ukryty, dlatego wiele programów domyślnie go nie pokazuje.
Z pliku korzystają dwa popularne serwery. Pierwszy to Apache, dla którego ten mechanizm powstał. Drugi to LiteSpeed Web Server, często spotykany na hostingach współdzielonych, który odczytuje konfigurację Apache i jest zgodny z jego plikami .htaccess. Przykłady z tej instrukcji działają na obu.
Na serwerze Nginx plik .htaccess nie jest w ogóle odczytywany. Przekierowania ustawia się tam w głównej konfiguracji serwera, do której na zwykłym hostingu klient nie ma dostępu, więc pozostaje panel hostingu albo wtyczka. W razie wątpliwości najprościej zapytać pomoc techniczną hostingu, na jakim serwerze działa strona.
Gdzie znaleźć plik .htaccess i jak zrobić jego kopię?
Plik leży w katalogu głównym strony, czyli tam, gdzie znajdują się pliki widoczne pod adresem domeny. Na wielu hostingach ten katalog nazywa się public_html, na innych nosi nazwę domeny. W przypadku WordPressa jest to katalog, w którym leży plik wp-config.php oraz foldery wp-admin, wp-content i wp-includes.
Do pliku prowadzą dwie drogi: menedżer plików w panelu hostingu albo program do połączeń FTP. Kopię zapasową trzeba zrobić przed każdą zmianą, nawet najmniejszą. To jedyne zabezpieczenie, które pozwala przywrócić stronę bez niczyjej pomocy.
- Należy zalogować się do panelu hostingu i otworzyć menedżer plików albo połączyć się z serwerem przez program FTP.
- Trzeba przejść do katalogu głównego strony.
- Jeśli pliku .htaccess nie widać, należy włączyć pokazywanie plików ukrytych. W menedżerach plików ta opcja znajduje się zwykle w ustawieniach widoku, a w programach FTP w menu dotyczącym serwera lub widoku.
- Plik należy pobrać na dysk komputera i zachować w niezmienionej postaci. Tej kopii nie wolno edytować.
- Dodatkowo warto utworzyć na serwerze drugą kopię pod nazwą, z której wynika, że to wersja sprzed zmiany, na przykład
htaccess-kopia.txt. - Dopiero teraz otwiera się właściwy plik do edycji w menedżerze plików albo w prostym edytorze tekstu.
Do edycji nadaje się wyłącznie edytor zwykłego tekstu. Programy biurowe do pisania dokumentów zamieniają cudzysłowy na drukarskie i dodają niewidoczne znaki formatowania, a serwer traktuje je jak błąd składni. Plik trzeba zapisać pod dokładnie tą samą nazwą: z kropką na początku i bez końcówki .txt.
Jeśli pliku w katalogu nie ma, mimo włączonego widoku plików ukrytych, można go utworzyć. W WordPressie plik powstaje sam po wejściu w „Ustawienia”, potem „Bezpośrednie odnośniki” i kliknięciu „Zapisz zmiany”. Na stronie bez WordPressa wystarczy utworzyć pusty plik tekstowy o nazwie .htaccess.
Jak przekierować jeden adres na inny?
Najprostszym narzędziem jest dyrektywa Redirect. Składa się z trzech części oddzielonych spacjami: kodu przekierowania, starej ścieżki i pełnego nowego adresu. W przykładach użyta jest domena example.com, którą trzeba zastąpić własną.
Redirect 301 /stara-oferta/ https://www.example.com/nowa-oferta/Stara ścieżka musi zaczynać się od ukośnika i nie zawiera nazwy domeny. Nowy adres najlepiej podać w całości, razem z https i domeną. Zamiast liczby 301 można wpisać słowo permanent, znaczenie jest takie samo. Kodu nie wolno pominąć: dyrektywa Redirect bez podanego kodu ustawia przekierowanie tymczasowe 302.
Dyrektywa Redirect ma cechę, która zaskakuje wiele osób. Nie porównuje całego adresu, tylko jego początek. Wiersz z przykładu przeniesie więc nie tylko adres /stara-oferta/, ale także /stara-oferta/cennik/ na /nowa-oferta/cennik/, bo dalszy ciąg ścieżki zostaje doklejony do adresu docelowego. Przy przenoszeniu całego działu jest to wygodne. Przy jednej podstronie może skierować ludzi pod adresy, które nie istnieją.
Gdy przekierowany ma być dokładnie jeden adres i nic więcej, stosuje się dyrektywę RedirectMatch, która porównuje adres ze wzorcem. Znak ^ oznacza początek ścieżki, znak $ jej koniec, a /? sprawia, że reguła zadziała dla adresu z ukośnikiem na końcu i bez niego.
RedirectMatch 301 ^/stara-oferta/?$ https://www.example.com/nowa-oferta/Serwer rozróżnia w ścieżce wielkie i małe litery, więc trzeba ją przepisać dokładnie tak, jak wygląda w pasku przeglądarki. Jeśli ścieżka zawiera spacje, całość ujmuje się w proste cudzysłowy. Każde przekierowanie zajmuje osobny wiersz.
Wersja dla stron na WordPressie
WordPress korzysta w pliku .htaccess z modułu przepisywania adresów mod_rewrite. Dyrektywy Redirect i RedirectMatch obsługuje inny moduł, mod_alias. Oba działają niezależnie od siebie i niezależnie od kolejności wierszy w pliku, co przy mieszaniu ich bywa źródłem niespodziewanych wyników. Dlatego na stronach z WordPressem radzę zapisywać przekierowania w tym samym module, z którego korzysta system.
RewriteEngine On
RewriteRule ^stara-oferta/?$ https://www.example.com/nowa-oferta/ [R=301,L]W tej wersji ścieżka we wzorcu nie ma ukośnika na początku. To częsty błąd: w pliku .htaccess serwer usuwa początkowy ukośnik przed porównaniem, więc wzorzec zaczynający się od ^/ nigdy nie zostanie dopasowany i reguła po prostu nie zadziała. W nawiasie kwadratowym R=301 ustawia kod przekierowania, a L kończy przetwarzanie kolejnych reguł.
Kto na tym etapie woli nie zajmować się tym samodzielnie, może po prostu zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Chętnie przejmę sprawę: przygotuję i przetestuję przekierowania, a przed zmianą zabezpieczę kopię pliku.
Jak przekierować całą domenę, wymusić https i ustalić wersję z www?
Trzy kolejne zadania dotyczą nie jednej podstrony, lecz wszystkich adresów naraz. Do każdego służą dwie dyrektywy modułu mod_rewrite. RewriteCond to warunek: określa, kiedy reguła ma zadziałać. RewriteRule to sama reguła: wskazuje, które adresy i dokąd przenieść. Wiersz RewriteEngine On włącza moduł i wystarczy, że pojawi się w pliku raz, przed pierwszą regułą.
Cała domena na nową
Poniższy fragment umieszcza się w pliku .htaccess starej domeny. Przenosi każdy adres na ten sam adres w nowej domenie: podstrona /kontakt/ trafia na /kontakt/, a wpis blogowy na swój odpowiednik.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.org/$1 [R=301,L]W warunku wpisuje się starą domenę, a w regule nową. Ukośnik odwrotny przed każdą kropką w nazwie domeny jest potrzebny, bo sama kropka oznacza we wzorcu dowolny znak. Fragment (www\.)? obejmuje obie wersje starego adresu, a [NC] wyłącza rozróżnianie wielkości liter. Zapis $1 wstawia do nowego adresu ścieżkę, którą ktoś próbował otworzyć.
Warunek ma tu duże znaczenie. Często stara i nowa domena wskazują na ten sam katalog na serwerze. Bez wiersza RewriteCond reguła obejmowałaby także nową domenę i przekierowywała ją na samą siebie bez końca.
Ten sposób zakłada, że struktura adresów w nowej domenie jest taka sama jak w starej. Jeśli przy okazji zmieniają się nazwy podstron, potrzebna jest lista par „stary adres – nowy adres” i osobne reguły dla zmienionych adresów, umieszczone nad regułą ogólną. Całą kolejność prac przy przenosinach opisuję w tekście o tym, jak przeprowadzić migrację strony bez utraty pozycji w Google.
Wymuszenie https
Przed wklejeniem tej reguły trzeba się upewnić, że certyfikat SSL jest zainstalowany i strona otwiera się poprawnie po ręcznym wpisaniu adresu z https. Przekierowanie na adres, pod którym certyfikat nie działa, kończy się ostrzeżeniem przeglądarki o niebezpiecznej witrynie.
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Warunek sprawdza, czy połączenie jest nieszyfrowane. Reguła przenosi wtedy na ten sam adres z przedrostkiem https, zachowując domenę i ścieżkę. W tym przykładzie nie trzeba niczego podmieniać.
Jest jedna sytuacja, w której ten fragment powoduje pętlę. Jeśli strona działa za pośrednikiem, na przykład za siecią CDN albo serwerem pośredniczącym, który sam obsługuje szyfrowanie, to do serwera z plikami ruch może docierać bez szyfrowania. Warunek jest wtedy zawsze spełniony i przekierowanie nigdy się nie kończy. W takim układzie wymuszenie https ustawia się w panelu pośrednika albo sprawdza nagłówek, który on przekazuje. Dokumentacja Apache podaje taki zapis warunku:
RewriteCond %{HTTP:X-Forwarded-Proto} =http [NC]Ten wariant wolno stosować tylko wtedy, gdy pośrednik rzeczywiście ustawia ten nagłówek przy każdym żądaniu. Warto to potwierdzić w pomocy technicznej hostingu lub dostawcy sieci CDN, zamiast wklejać na próbę.
Jedna wersja adresu: z www albo bez www
Strona powinna być dostępna pod jedną wersją adresu, a druga ma na nią przekierowywać. Która zostanie wybrana, nie ma znaczenia dla pozycji w Google. Ważne, żeby wybór był jeden i konsekwentny. Wersję z www ustawia taki fragment:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]Wersję bez www ustawia fragment odwrotny:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]Z dwóch powyższych fragmentów wkleja się tylko jeden. Oba naraz dają pętlę, bo każdy odsyła do adresu, który drugi natychmiast odsyła z powrotem.
Https i www w jednym kroku
Jeśli w pliku znajdą się osobno reguła https i reguła www, ktoś wpisujący adres bez szyfrowania i bez www zostanie przeniesiony dwa razy. Lepiej połączyć oba warunki tak, by każdy niewłaściwy wariant trafiał do celu jednym przeskokiem.
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]Dopisek [OR] oznacza „lub”: reguła zadziała, gdy połączenie nie jest szyfrowane albo gdy nazwa domeny jest inna niż docelowa. Bez tego dopisku serwer wymaga spełnienia obu warunków jednocześnie. Tego fragmentu nie należy używać, gdy w tym samym katalogu działają jeszcze inne domeny lub subdomeny, bo wszystkie zostałyby przeniesione na jeden adres.
W którym miejscu pliku wstawić reguły?
Serwer czyta reguły mod_rewrite od góry do dołu i wykonuje pierwszą, która pasuje. Kolejność ma więc znaczenie. Reguły szczegółowe, dotyczące pojedynczych adresów, umieszcza się wyżej, a ogólne, obejmujące całą domenę, niżej. W przeciwnym razie reguła ogólna przechwyci adres, zanim serwer dojdzie do szczegółowej.
W pliku strony na WordPressie znajduje się blok, który zaczyna się od wiersza # BEGIN WordPress i kończy wierszem # END WordPress. Odpowiada on za działanie przyjaznych adresów: każde żądanie, które nie jest istniejącym plikiem ani katalogiem, przekazuje do pliku index.php.
Z tym blokiem wiążą się dwie zasady. Pierwsza: własne przekierowania wkleja się nad nim, na samej górze pliku. Reguły umieszczone pod blokiem zwykle nie mają szansy zadziałać, bo WordPress wcześniej przejmuje żądanie. Druga: niczego nie wpisuje się między znaczniki BEGIN i END. Tę część system generuje sam i nadpisuje ją, między innymi przy zapisie ustawień bezpośrednich odnośników, więc własne wiersze po prostu znikną.
Podobne oznaczone bloki dodają wtyczki pamięci podręcznej i bezpieczeństwa. Ich też nie należy zmieniać. Poprawnie ułożony początek pliku wygląda tak:
RewriteEngine On
RewriteRule ^stara-oferta/?$ https://www.example.com/nowa-oferta/ [R=301,L]
RewriteRule ^cennik-stary/?$ https://www.example.com/cennik/ [R=301,L]
# BEGIN WordPress
# tu znajduje się blok WordPressa, bez zmian
# END WordPressWiersze zaczynające się od znaku # są komentarzami i serwer je pomija. Nad każdą grupą reguł dobrze jest zapisać w ten sposób, czego dotyczy. Komentarz musi zajmować osobny wiersz: dopisany na końcu wiersza z dyrektywą może wywołać błąd.
Jak sprawdzić, czy przekierowanie działa?
Samo otwarcie starego adresu w przeglądarce to za mało. Przeglądarka pokazuje stronę docelową, ale nie mówi, jakim kodem odpowiedział serwer ani ile przeskoków było po drodze. Do tego zapamiętuje przekierowania stałe, więc potrafi pokazywać stary wynik mimo poprawionej reguły. Test trzeba przeprowadzić tak, żeby zobaczyć kod odpowiedzi.
- Należy otworzyć nowe okno w trybie prywatnym, żeby wykluczyć zapamiętane wcześniej przekierowania.
- Trzeba otworzyć narzędzia deweloperskie przeglądarki klawiszem F12 i przejść do karty z ruchem sieciowym, w polskiej wersji Chrome nazwanej „Sieć”.
- W pasku adresu wpisuje się stary adres i zatwierdza klawiszem Enter.
- Na liście żądań pierwszy wiersz powinien mieć stan 301, a kolejny stan 200. Po kliknięciu pierwszego wiersza w nagłówkach odpowiedzi widać pole Location z adresem docelowym.
- Test należy powtórzyć dla wszystkich wariantów: z http i z https, z www i bez www, z ukośnikiem na końcu i bez niego.
- Na koniec trzeba otworzyć kilka zwykłych podstron, których przekierowanie nie dotyczyło, oraz panel administracyjny. Powinny działać tak jak wcześniej.
Kto ma dostęp do wiersza poleceń, zobaczy to samo jednym poleceniem. Wypisuje ono po kolei wszystkie odpowiedzi serwera aż do strony docelowej:
curl -sIL http://example.com/stara-oferta/Poprawny wynik to jeden blok z kodem 301 i nagłówkiem Location, a po nim blok z kodem 200. Kilka bloków 301 lub 302 pod rząd oznacza łańcuch przekierowań: adres A prowadzi do B, B do C, a dopiero C do celu. Każdy przeskok wydłuża ładowanie strony, dlatego regułę trzeba poprawić tak, by stary adres wskazywał od razu ostateczny cel.
Radzę też stosować prosty sposób ograniczający ryzyko: nową regułę najpierw zapisać z kodem 302, przetestować, a dopiero po potwierdzeniu, że działa, zmienić liczbę na 301. Błędne przekierowanie tymczasowe nie zostaje w pamięci przeglądarek odwiedzających, błędne stałe potrafi w niej zostać na długo.
Po kilku dniach warto zajrzeć do Google Search Console. Narzędzie „Sprawdzenie adresu URL” pokazuje, jak Google widzi stary adres, a w raporcie „Strony” stare adresy powinny pojawić się z powodem „Strona zawiera przekierowanie”. To stan prawidłowy, a nie błąd do naprawienia. Więcej o tym narzędziu piszę w tekście o tym, jak sprawdzić, czy strona jest zaindeksowana w Google.
Co zrobić, gdy po zapisie pojawia się błąd 500?
Komunikat o błędzie 500 zaraz po zapisaniu pliku .htaccess prawie zawsze oznacza, że serwer nie potrafił odczytać którejś dyrektywy. Dokumentacja Apache wymienia dwie przyczyny: błąd składni albo dyrektywę, której administrator nie zezwolił stosować w tym pliku. Skutek jest w obu przypadkach taki sam: serwer odmawia obsługi wszystkich adresów w katalogu, razem z panelem WordPressa.
Strona nie jest uszkodzona, a dane są bezpieczne. Wystarczy cofnąć zmianę w pliku. Panel hostingu i połączenie FTP działają niezależnie od strony, więc dostęp do plików pozostaje.
- Należy zalogować się do menedżera plików w panelu hostingu albo połączyć przez FTP.
- W katalogu głównym strony trzeba zmienić nazwę bieżącego pliku .htaccess, na przykład na
htaccess-blad.txt. Dzięki temu zostaje on do późniejszego sprawdzenia. - Na serwer wgrywa się kopię pobraną przed zmianą i nadaje jej nazwę .htaccess.
- Stronę otwiera się w oknie prywatnym. Powinna działać jak przed zmianą.
- Jeśli kopii nie ma, a strona działa na WordPressie, wystarczy samo usunięcie błędnego pliku z drogi przez zmianę nazwy. Następnie w panelu WordPressa trzeba wejść w „Ustawienia”, potem „Bezpośrednie odnośniki” i kliknąć „Zapisz zmiany”. System utworzy plik z podstawowym blokiem na nowo.
Gdy strona już działa, trzeba ustalić, co było nie tak. Dokładną odpowiedź daje dziennik błędów serwera, dostępny w panelu hostingu zwykle pod nazwą dziennika błędów lub logów. Wpis wskazuje plik i dyrektywę, która spowodowała problem. Bez dziennika warto przejrzeć błędny plik pod kątem najczęstszych przyczyn:
- literówka w nazwie dyrektywy, na przykład RewriteCondition zamiast RewriteCond,
- brak spacji między częściami wiersza albo spacja w środku wzorca lub adresu,
- cudzysłowy drukarskie albo inne znaki wstawione przez program biurowy,
- niezamknięty nawias kwadratowy lub okrągły,
- przecinek ze spacją w nawiasie z dopiskami, na przykład
[R=301, L]zamiast[R=301,L], - moduł mod_rewrite wyłączony na serwerze, co zgłasza się pomocy technicznej hostingu.
Poprawione reguły wprowadza się ponownie pojedynczo, sprawdzając stronę po każdym zapisie. Wklejenie kilkunastu wierszy naraz utrudnia znalezienie tego jednego, który zawiera błąd.
Skąd bierze się pętla przekierowań i jak ją przerwać?
Pętla to sytuacja, w której adres A odsyła do B, a B z powrotem do A, albo adres odsyła sam do siebie. Przeglądarka przerywa takie krążenie i wyświetla komunikat o zbyt wielu przekierowaniach. W odróżnieniu od błędu 500 plik jest tu poprawny składniowo. Zawodzi logika reguł.
Pierwsza typowa przyczyna to sprzeczność między plikiem .htaccess a ustawieniami WordPressa. System sam przekierowuje na adres wpisany w „Ustawienia”, „Ogólne”, w polach „Adres WordPressa (URL)” i „Adres witryny (URL)”. Jeśli w tych polach jest wersja z www, a plik wymusza wersję bez www, oba mechanizmy odsyłają odwiedzającego w kółko. Wersja adresu w regułach musi być dokładnie taka sama jak w tych dwóch polach.
Druga przyczyna to opisany wcześniej pośrednik obsługujący szyfrowanie. Trzecia to reguła bez warunku, która obejmuje także adres docelowy, na przykład przekierowanie całej domeny wklejone do katalogu wspólnego dla starej i nowej domeny. Czwarta to to samo przekierowanie ustawione w dwóch miejscach w przeciwne strony: jedno w pliku, drugie we wtyczce albo w panelu hostingu.
Diagnozę zaczyna się od polecenia curl albo karty „Sieć” z poprzedniej sekcji. Widać wtedy, między którymi adresami trwa odbijanie i czym się różnią: przedrostkiem https, obecnością www czy ukośnikiem na końcu. Ta różnica wskazuje regułę do poprawienia. Jeśli pętla blokuje dostęp do panelu WordPressa, trzeba najpierw przywrócić kopię pliku, tak jak przy błędzie 500.
Jak ustawić przekierowanie bez edycji pliku?
Edycja pliku .htaccess nie jest jedyną drogą. Przy kilku lub kilkunastu przekierowaniach pojedynczych podstron bezpieczniejsze są dwa inne sposoby, które nie grożą błędem 500.
Wtyczka w WordPressie
Wtyczki do przekierowań pozwalają dodać parę „stary adres – nowy adres” w formularzu, bez znajomości składni. Popularna wtyczka Redirection ma swoje ustawienia w menu „Narzędzia”, zapisuje przekierowania w bazie WordPressa i dodatkowo rejestruje adresy, które zwracają błąd 404. Dzięki temu widać, gdzie przekierowań jeszcze brakuje. Menedżer przekierowań mają także niektóre wtyczki SEO.
Ten sposób ma dwa ograniczenia. Przekierowanie wykonuje się dopiero po uruchomieniu WordPressa, więc jest nieco wolniejsze niż reguła na poziomie serwera i nie zadziała, gdy sam WordPress ma awarię. Nie nadaje się też do wymuszania https ani wersji z www, bo te sprawy powinny być załatwione, zanim żądanie dotrze do systemu.
Panel hostingu
Większość paneli hostingowych ma własne narzędzie do przekierowań, zwykle w części dotyczącej domen. Wybiera się w nim domenę, typ przekierowania i adres docelowy. Wiele firm hostingowych udostępnia też osobny przełącznik wymuszający https, często obok ustawień certyfikatu SSL. Jeśli taki przełącznik istnieje, radzę skorzystać z niego zamiast własnej reguły.
Trzeba przy tym wiedzieć, że część paneli zapisuje przekierowania właśnie w pliku .htaccess. Po użyciu panelu warto otworzyć plik i zobaczyć, co zostało dopisane, żeby nie powielić tej samej reguły ręcznie. Zasada jest jedna: każde przekierowanie ustawia się w jednym miejscu. To samo przekierowanie w pliku, we wtyczce i w panelu jednocześnie jest prostą drogą do pętli i do kłopotów przy późniejszych zmianach.
Co o przekierowaniach mówi Google?
Dokumentacja Google dla właścicieli stron zaleca przekierowania po stronie serwera wszędzie tam, gdzie da się je ustawić, ponieważ wyszukiwarka odczytuje je najpewniej. Przy trwałej zmianie adresu wskazuje kody 301 i 308. Podaje też przykłady dla serwera Apache. Jedna uwaga do drugiego z nich: wzorzec z ukośnikiem na początku działa w głównej konfiguracji serwera, a w pliku .htaccess zapisuje się go bez ukośnika.
Z zaleceń dotyczących przenoszenia stron wynika kilka praktycznych zasad. Po pierwsze, stary adres powinien prowadzić od razu do ostatecznego celu. Robot Google potrafi przejść do 10 przeskoków, ale dokumentacja zaleca, by łańcuch nie przekraczał 3 kolejnych adresów i w żadnym razie 5. Po drugie, każdy stary adres należy przekierować na jego rzeczywisty odpowiednik.
Druga zasada jest łamana najczęściej. Przekierowanie wszystkich usuniętych podstron na stronę główną wygląda na proste rozwiązanie, ale Google może potraktować je jak pozorny błąd 404 i nie przenieść na nowy adres niczego. Jeśli usunięta podstrona nie ma odpowiednika, uczciwszym wyjściem jest pozostawienie odpowiedzi 404 albo 410.
Po trzecie, przekierowania utrzymuje się długo. Google zaleca zostawić je najdłużej, jak to możliwe, zwykle co najmniej przez rok, a ze względu na odwiedzających z dawnych linków najlepiej na stałe. Oznacza to także, że starej domeny nie wolno przestać opłacać zaraz po przenosinach, bo razem z nią znikną przekierowania.
Po czwarte, samo przekierowanie nie kończy pracy. Linki w menu, w treści i w stopce powinny prowadzić bezpośrednio pod nowe adresy, a nie przez przekierowanie. To samo dotyczy mapy witryny i adresów kanonicznych. Taki przegląd dobrze połączyć z szerszą kontrolą, którą opisuję w tekście o tym, co sprawdzić w audycie SEO strony.
Przy zmianie domeny Search Console udostępnia dodatkowo narzędzie „Zmiana adresu”. Według dokumentacji stosuje się je tylko przy przenosinach między domenami lub subdomenami. Nie jest potrzebne przy przejściu z http na https ani przy wyborze wersji z www lub bez www.
Najczęstsze pytania
Czy przekierowanie 301 obniża pozycję strony w Google?
Poprawnie ustawione przekierowanie stałe na odpowiadającą treść jest sposobem zalecanym przez Google przy zmianie adresu. Po większych zmianach pozycje mogą się przez pewien czas wahać, bo wyszukiwarka musi odwiedzić stare i nowe adresy. Trwałe straty biorą się zwykle z błędów: przekierowań na nietrafne strony, łańcuchów albo zbyt wczesnego usunięcia reguł.
Jak cofnąć błędne przekierowanie 301?
Należy usunąć lub poprawić regułę w pliku i sprawdzić wynik w oknie prywatnym. Osoby, które odwiedziły stronę w czasie działania błędnej reguły, mogą nadal być przenoszone, dopóki ich przeglądarka nie odświeży zapamiętanych danych. Właściciel strony nie ma na to wpływu, dlatego nowe reguły warto najpierw testować z kodem 302.
Ile przekierowań można zapisać w pliku .htaccess?
Serwer nie narzuca praktycznego limitu, ale czyta cały plik przy każdym żądaniu, także przy obrazkach i plikach stylów. Kilkadziesiąt wierszy nie robi różnicy. Przy setkach i tysiącach przekierowań lepiej szukać wspólnego wzorca, który zastąpi wiele wierszy jedną regułą, albo przenieść je do konfiguracji serwera z pomocą administratora.
Dlaczego reguła nie działa, chociaż nie ma żadnego błędu?
Najczęstsze powody to: reguła wklejona pod blokiem WordPressa zamiast nad nim, ukośnik na początku wzorca w dyrektywie RewriteRule, inna wielkość liter niż w rzeczywistym adresie, przekierowanie zapamiętane wcześniej przez przeglądarkę oraz pamięć podręczna strony lub sieci CDN, którą trzeba wyczyścić. Zdarza się też, że serwer w ogóle nie odczytuje pliku, co wyjaśnia pomoc techniczna hostingu.
Czy po przekierowaniu można usunąć starą podstronę?
Tak. Serwer wykonuje przekierowanie, zanim sięgnie po treść, więc stara podstrona nie jest już nikomu pokazywana. W WordPressie trzeba jedynie uważać, by nie utworzyć później nowej podstrony pod tym samym adresem, bo przekierowanie nadal będzie ją zasłaniać.
Czy plik .htaccess działa także w podkatalogach?
Tak, dyrektywy z pliku obowiązują w jego katalogu i we wszystkich podkatalogach. W podkatalogu może leżeć osobny plik .htaccess, a jego ustawienia mają wtedy pierwszeństwo dla tej części strony. Jeśli przekierowanie nie działa tylko w jednym folderze, warto sprawdzić, czy nie ma w nim własnego pliku.
Brak czasu albo ochoty, żeby zająć się tym samodzielnie?
To zupełnie zrozumiałe. Opisane czynności wymagają spokoju i kilku wolnych godzin, a w firmie zwykle brakuje jednego i drugiego. Chętnie zrobię to od początku do końca: przygotuję i przetestuję przekierowania, a przed zmianą zabezpieczę kopię pliku.
Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i w kilku zdaniach opisać sprawę. Odpowiadam osobiście i od razu mówię, co da się zrobić.
