269

Techniczny przewodnik SEO po przekierowaniach

business-3080799-1280.png

Strony internetowe zmieniają strukturę, usuwają strony i często przenoszą się z jednej domeny do drugiej. Prawidłowe obchodzenie się z przekierowaniami jest kluczowe, aby uniknąć utraty pozycji w wynikach wyszukiwania popularnych wyszukiwarek i pomóc im zrozumieć dokonane zmiany. Przekierowania mają kod statusu zaczynający się od numeru trzy (tj. 3XX). Istnieje 100 różnych możliwych kodów stanu, ale zaimplementowano tylko kilka, aby przenosić pewne informacje. W tym poradniku omówimy przekierowania 3XX jedynie związane z SEO.

Przekierowanie 301

To przekierowanie niesie ze sobą informację dla wyszukiwarek, że zasób został zmieniony na inną lokalizację i że powinny używać nowego adresu URL do przyszłych żądań. Gdy wyszukiwarki widzą przekierowanie 301, przekazują „moc” starej strony do nowej. Przed dokonaniem zmiany musisz zachować ostrożność, decydując się na użycie przekierowania 301. Wynika to z faktu, że jeśli później zmienisz zdanie i zdecydujesz się usunąć przekierowanie 301, stary adres URL może już nie mieć tej samej mocy z punktu widzenia SEO co wcześniej. Nawet jeśli cofniesz przekierowania, nie pomoże ci to przywrócić starej strony do poprzedniej pozycji w rankingu. Najważniejszą rzeczą o jakiej musisz pamiętać jest to, że nie ma możliwości cofnięcia przekierowania 301.

307: Tymczasowe przekierowanie

W HTTP 1.1 przekierowanie 307 oznacza, że zasób jest tymczasowo przenoszony, a roboty i przeglądarki powinny używać adresu URL oryginalnego zasobu do przyszłych żądań. W przypadku SEO oznacza to, że klient powinien zastosować przekierowanie, ale wyszukiwarki nie powinny aktualizować swoich linków w SERP i zmieniać je na adres tymczasowej strony. W przekierowaniu 307 PageRank nie jest przekazywany z oryginalnego zasobu do nowego - w przeciwieństwie do przekierowania 301.

302: Znaleziono

Oznacza to, że zasób, którego szuka robot bądź przeglądarka, został znaleziony pod innym adresem URL w wersji HTTP 1.1, ale został tymczasowo przeniesiony w HTTP 1.0.

302 vs. 307

W prawie wszystkich przypadkach przekierowania 302 i 307 będą traktowane tak samo. Ale kod stanu 302 niekoniecznie oznacza, że ​​przeglądarka musi wykonać przekierowanie i nie jest uważany za błąd, jeśli zdecyduje się tam pozostać. Współczesne roboty najprawdopodobniej podążą za nowym miejscem docelowym, ale niektóre mogą niepoprawnie utrzymywać ten sam adres URL. W przeciwieństwie do kodu stanu 302, kod stanu 307 gwarantuje, że metoda żądania nie zostanie zmieniona. Na przykład żądanie GET musi być kontynuowane do GET i POST do POST. Dzięki 302 niektóre wyszukiwarki jak i ich roboty mogą zmienić metodę, co może spowodować nieoczekiwane zachowanie. Do tymczasowych przekierowań możesz użyć 302 lub 307 - ale ja wolę 307. W przypadku rutynowych zadań przekierowywania należy stosować kody stanu 301 (stałe przekierowanie) i 307 (tymczasowe przekierowanie) w zależności od rodzaju zmian wprowadzanych w witrynie. W obu przypadkach składnia przekierowań nie zmienia się. Możesz obsługiwać przekierowanie za pomocą plików konfiguracyjnych serwera .htaccess na Apache, plik example.conf na Nginx lub wtyczek, jeśli używasz np. WordPressa. We wszystkich przypadkach mają one tę samą składnię przy tworzeniu reguł przekierowań. Różnią się tylko poleceniami używanymi w plikach konfiguracyjnych. Na przykład przekierowanie na Apache będzie wyglądać następująco:

Options +FollowSymlinks

RewriteEngine on

RedirectMatch 301 ^/staryfolder/ /nowyfolder/

Na Nginx będzie to wyglądać tak:

rewrite ^/staryfolder/ /nowyfolder/ permanent;

Polecenia używane do informowania serwerów o statusie przekierowania i polecenie działania różnią się. Na przykład:

  • Kod statusu przekierowania: „301 ″ vs. „ permanent
  • Polecenie akcji: „RedirectMatch” vs. „rewrite”.

Jednak składnia przekierowania pozostaje taka sama:

^/staryfolder/ /nowyfolder/ 

Na serwerach z Apache upewnij się, że włączone są moduły mod_rewrite i mod_alias, które odpowiedzialne są za obsługę przekierowań.

Upewnij się zaczynając pisać reguły w .htaccess, że następujące dwie linie zostały dodane przed regułami przekierowującymi:

Options +FollowSymlinks

RewriteEngine on

Aby zrozumieć poniższe przykłady, możesz zapoznać się z poniższą tabelą dotyczącą podstaw RegExp. 

*

0 lub więcej razy

+

1 lub więcej razy

.

Każdy pojedynczy znak

?

0 lub jeden raz

^

Początek ciągu znaków

$

Koniec ciągu znaków

a|b

Operator OR “|” a lub b

(z)

Pamiętaj dopasowanie podczas wywoływania $1

 

Przekierowanie pojedynczego adresu URL

Powiedzmy na przykład, że zmieniłeś adres URL z / old-page / na / new-page /. Reguła przekierowania wyglądałaby następująco:

RewriteRule ^old-page(/?|/.*)$ /new-page/ [R=301,L]

albo

RedirectMatch 301 ^/old-page(/?|/.*)$ /new-page/

Jedyna różnica między tymi dwiema metodami polega na tym, że pierwsza używa modułu mod_rewrite, a druga mod_alias. Można to wykonać za pomocą obu metod – ale nie jednocześnie, zamiennie. Wyrażenie regularne „^” oznacza, że adres URL musi zaczynać się od „/stara-strona”, natomiast (/?|/.*)$ oznacza, że wszystko, co następuje po „/stara-strona/” z ukośnikiem „/” lub bez dokładnego dopasowania, musi zostać przekierowane do /nowa-strona/. Możemy również użyć (. *) Tj. ^/stara-strona (. *), ale problem polega na tym, że jeśli masz inną stronę o podobnym adresie URL, jak /stara-strona-rzeszowa/, zostanie ona również przekierowana, a chcemy przecież tylko przekierować /stara-strona/. Ale jeśli wykorzystamy (/?|/.*)$ to następujące adresy URL będą pasować do reguły:

  • /stara-strona/
  • /stara-strona
  • /stara-strona/?utm_source=facebook.com
  • /stara-strona/strona/

Jeśli użyjemy przekierowania w następującej formie to przekieruje każdą odmianę adresu URL strony na nową:

Redirect 301 /stara-strona/ /nowa-strona/

… bez wyrażeń regularnych wszystkie adresy URL zawierające ciąg zapytania UTM, np. /stara=-strona?utm_source=facebook.com (co jest powszechne, ponieważ adresy URL są udostępniane za pośrednictwem sieci społecznościowej), kończyłyby się wyrzuceniem błędu 404. Nawet /stara-strona bez ukośnika „/” wyrzuciłaby nam 404.

Przekierowanie „wszyscy oprócz” (All Except)

Załóżmy, że mamy kilka adresów URL, takich jak /category/old-subcategory-1/, /category/old-subcategory-2/, /category/final-subcategory/ i chcemy połączyć wszystkie te podkategorie w /category/final-subcategory/. Potrzebujemy tutaj zasady „wszyscy oprócz”.

RewriteCond %{REQUEST_URI} !/category/final-subcategory/

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(category/). /category/final-subcategory/ [R=301,L]

Tutaj chcemy przekierować wszystkie adres w /category/ co widać w trzeciej linii, z wyjątkiem sytuacji, gdy jest to /category/final-subcategory/ (patrz pierwszą linię). Mamy również zasadę „! -F” w drugim wierszu, co oznacza ignorowanie każdego pliku, takiego jak zdjęcia, CSS lub pliki JS. W przeciwnym razie, jeśli mamy jakieś zasoby, takie jak „/category/image.jpg”, zostanie również przekierowany do „/final-subcategory/” i spowoduje uszkodzenie pliku (brak jego wyświetlania / działania).

Zmiana folderu

Jeśli przebudowałeś np. strukturę kategorii i chcesz przenieść wszystko ze starego katalogu do nowego, możesz skorzystać z poniższej reguły.

RewriteRule ^old-directory$ /new-directory/ [R=301,NC,L]

RewriteRule ^old-directory/(.*)$ /new-directory/$1 [R=301,NC,L]

Użyłem $1 aby powiedzieć serwerowi, że powinien zapamiętać wszystko w adresie URL co znajduje się po /old-directory / (np. /old-directory /subdirectory/) i przekazać to (np. „/subdirectory /”) do miejsce docelowego. W rezultacie adres zostanie przekierowany do /new-directory/subdirectory/. Użyłem dwóch zasad: jedna bez końcowego ukośnika na końcu, a druga z końcowym ukośnikiem. Mógłbym połączyć je w jedną regułę przy użyciu RegExp (/?|.*)$ na końcu, ale spowodowałoby to problemy i dodałoby ukośnik  dwa razy „//” na końcu adresu URL, gdy żądany adres URL bez ukośnika końcowego zawiera ciąg zapytania (tzn. „/old-directory?utm_source = facebook” zostanie przekierowany do „/new-directory//? utm_source = facebook”).

Usuwanie słowa z adresu URL

Załóżmy, że masz w swojej witrynie 100 adresów URL z nazwą  „rzeszow” (http://strona.pl/cos-rzeszow-tam/) i chcesz je usunąć. Aby usunąć z pojedynczego adresu słowo „rzeszow” możemy wykorzystać następującą regułkę:

RewriteRule ^(.*)-rzeszow-(.*) http://%{SERVER_NAME}/$1-$2 [NC,R=301,L]

Jeśli adres URL będzie w formie np. folderu / kategorii (http://strona.pl/rzeszow/cos-tam/):

RewriteRule ^(.*)/rzeszow/(.*) http://%{SERVER_NAME}/$1/$2 [NC,R=301,L]

Kanoniczne adresy URL

Posiadanie kanonicznych adresów URL jest jedną z kluczowych kwestii jeśli mowa o SEO. Jeśli ich brakuje, możesz zagrozić swojej witrynie problemami z powielaniem treści, ponieważ wyszukiwarki traktują adresy URL z wersjami „www” i „bez www” jako różne strony o tej samej treści. Dlatego obowiązkowo upewnij się, że witryna działa tylko z jedną wybraną wersją. Jeśli chcesz uruchomić witrynę w wersji  z „www”, skorzystaj z tej reguły:

RewriteCond %{HTTP_HOST} ^twojastrona.pl [NC]

RewriteRule ^(.*)$ http://www.twojastrona.pl/$1 [L,R=301]

Dla wersji bez www:

RewriteCond %{HTTP_HOST} ^www.twojastrona.pl [NC]

RewriteRule ^(.*)$ http://twojastrona.pl/$1 [L,R=301]

Ukośnik końcowy jest również częścią kanonizacji, ponieważ adresy URL z ukośnikiem na końcu lub bez są również traktowane inaczej.

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*[^/])$ /$1/ [L,R=301]

To sprawi, że strona /example-page zostanie przekierowana do /example-page/. Możesz wybrać usunięcie ukośnika zamiast dodawania, wtedy będziesz potrzebować innej reguły jak przedstawiona poniżej:

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)/$ /$1 [L,R=301]

Przekierowanie HTTP na HTTPS

Po inicjatywie Google, która miała na celu zachęcić właścicieli witryn do korzystania z protokołu SSL, migracja do HTTPS jest jednym z najczęściej używanych przekierowań, które ma prawie każda witryna. Poniższej reguły przepisywania można użyć do wymuszenia HTTPS na każdej stronie internetowej.

RewriteCond %{HTTP_HOST} ^twojastrona.pl [NC,OR]

RewriteCond %{HTTP_HOST} ^www.twojastrona.pl [NC]

RewriteRule ^(.*)$ https://www.twojastrona.pl/$1 [L,R=301,NC]

Zasadniczo za pomocą tego można połączyć przekierowanie wersji www lub bez www w jedną regułę.

Przekierowanie starej domeny na nową

Jest to również jedno z najczęściej używanych przekierowań, gdy decydujesz się na rebranding i musisz zmienić domenę. Poniższa reguła przekierowuje stara-domena.pl na nowa-domena.pl.

RewriteCond %{HTTP_HOST} ^stara-domena.pl$ [OR]

RewriteCond %{HTTP_HOST} ^www.stara-domena.pl$

RewriteRule (.*)$ http://www.nowa-domena.pl/$1 [R=301,L]

Wykorzystuje dwa przypadki: jeden z wersją adresów URL z „www”, a drugi „bez www”, ponieważ każda strona ze względów historycznych może zawierać przychodzące linki do obu wersji. Większość właścicieli witryn korzysta z WordPress i może nie być konieczne użycie pliku .htaccess do przekierowań, ale zamiast tego można użyć wtyczki. Obsługa przekierowań przy użyciu wtyczek może nieco różnić się od tego co omówiliśmy powyżej i może być konieczne przeczytanie dokumentacji danej wtyczki, aby móc poprawnie obsługiwać RegExp. Z istniejących polecam darmową wtyczkę o nazwie Redirection, która posiada wiele parametrów do kontrolowania reguł i wiele przydatnych tutoriali.

Złe praktyki

Przekierowanie nieistniejących adresów (404) na stronę główną

Ten przypadek zdarza się dość często, gdy ktoś jest bardzo leniwy i nie chce mu się sprawdzić wszystkich swoich błędów 404, aby je później zmapować na odpowiednią stronę docelową. Według Google wszystkie adresy przekierowane tak bezmyślnie będą nadal są traktowane jako 404. Zresztą przekierowanie takich 404-rek na stronę podobną tematycznie daje nam dodatkowe korzyści, a rzucenie tego na stronę główną przysporzy jedynie dodatkowych zmartwień.

Wg. oficjalnego stanowiska Google takie przekierowanie na stronę główną może zostać uznane za miękkie 404 i utracisz rangę tej strony.

Nieprawidłowe przekierowania na stronę mobilną

Jeśli masz różne adresy URL dla witryn na komputery i urządzenia mobilne (tj. „strona.pl” na komputery i „m.strona.pl” na komórki), upewnij się, że przekierowujesz użytkowników na odpowiednią stronę wersji mobilnej. Prawidłowo: „strona.pl/sport/” na „m. strona.pl/sport/”. Źle: „strona.pl/sport/” na „m.strona.pl”. Musisz także upewnić się, że jeśli masz dedykowaną stronę 404 na komputerze, to powinna być też taka strona 404 na urządzenia mobilne.

Korzystanie z Meta Refresh

Przekierowanie można wykonać za pomocą metatagu, takiego jak w poniższym przykładzie:

<meta http-equiv = "refresh" content = "0; url = http: //strona.pl/nowa/" />

Jeśli wstawisz ten tag do podstrony /stara/, przekieruje on użytkownika natychmiast do /nowa/. To przekierowanie nie jest zabronione przez Google, ale wyraźnie nie zalecamy korzystania z niego.

Według Johna Muellera wyszukiwarki mogą nie być w stanie prawidłowo rozpoznać tego rodzaju przekierowania. To samo dotyczy przekierowań JavaScript.

Zbyt wiele przekierowań

Ten komunikat jest wyświetlany, gdy masz niewłaściwą konfigurację wyrażeń regularnych i kończy się to nieskończoną pętlą.

Zwykle dzieje się tak, gdy masz łańcuch przekierowań. Załóżmy, że już dawno przekierowałeś stronę 1 na stronę 2. Być może zapomniałeś, że strona 1 została przekierowana i ponownie zdecydujesz się przekierować stronę 2 na stronę 1.W rezultacie otrzymasz następującą zasadę:

RewriteRule ^strona1 /strona2 [R=301,NC,L]

RewriteRule ^strona2 /strona1 [R=301,NC,L]

Spowoduje to utworzenie nieskończonej pętli i wygenerowanie błędu pokazanego powyżej.

Podsumowanie

Po zainicjowaniu przekierowania 301 nie można go łatwo cofnąć z powrotem (słowo „permanent” oznacza „na stałe”). Wynika to z faktu, że gdy Google wykryje takie przekierowanie, przekaże PageRank do nowej strony i zmieni adres URL w serwerach SERP i będzie używać nowego adresu. W przypadku migracji dużej witryny z dziesiątkami tysięcy stron ze starej domeny do nowej lub nawet z HTTP na HTTPS, zalecamy najpierw wykonać tymczasowe przekierowanie 302 i upewnić się, że wszystkie reguły przekierowania działają poprawnie – można to sprawdzić dzięki narzędzi Search Console, aby upewnić się, że nie ma nieoczekiwanych błędów (tj. błąd składniowy, który powoduje powstanie błędu 404), a następnie przełączyć przekierowanie 302 na 301. Jeśli pomyliłeś się z miejscem docelowym stałego przekierowania 301 i chcesz przełączyć się na inny adres URL, zaleca się unikanie przekierowań łańcuchowych.

10-01-2020 1273 odsłon