Przekierowanie 301 – teoria i praktyka, konfiguracja oraz zasady stosowania

Przekierowanie 301 Cześć, przyjaciele. Dziś chciałbym poruszyć temat dość popularny, ale zawsze aktualny – to Przekierowanie 301 (Permanent Redirect 301) – w kręgach SEO to właśnie pod to słowo podchodzi się bez zbędnych formalności. Technicznie rzecz biorąc, jest to odpowiedź serwera na zapytanie do niego; ta odpowiedź ma kod 301, oznaczający, że adres został zmieniony na stałe (przeniesiony na stałe). W rezultacie wszystkich tych zawiłych machinacji powinniśmy otrzymać jakiś nowy, ostateczny adres.

Uważam, że nie potrzebujecie tych wszystkich technicznych aspektów, dlatego chciałbym porozmawiać o praktycznych kwestiach – kiedy i w jakich sytuacjach lepiej jest używać przekierowania, w jaki sposób i za pomocą jakich poleceń można skonfigurować zasady przekierowywania itp. Oraz omówimy narzędzia i usługi, które pozwalają sprawdzić poprawność przekierowań.

Chciałbym również podzielić się przypadkami ze swojej praktyki, czasami zdarzają się takie, że nawet specjalnie nie wymyślisz. Dlatego ważne jest rozważanie takich sytuacji, ponieważ możesz nigdy nie dowiedzieć się o istniejącym problemie ze swoją stroną, a może on przeszkadzać w promocji…

Table of Contents

Kiedy WARTO stosować przekierowanie 301

Przede wszystkim przekierowanie jest używane, gdy strona (grupa stron lub cała sekcja) zmienia swój adres – zazwyczaj dzieje się to przy zmianie struktury strony, zmianie nazwy głównej części adresu URL lub zmianie zasady tworzenia adresów (inaczej mówiąc, SEO-friendly URL). Niestety nie wszyscy zastanawiają się nad tym, gdy coś zmieniają na stronie, co prowadzi do powstania wielu duplikatów, co prowadzi do utraty pozycji w wynikach wyszukiwania lub nawet nałożenia sankcji przez wyszukiwarki. W mojej pracy często spotykam się z takimi sytuacjami, i naprawa tego wymaga dużo wysiłku, aby wszystko naprawić i zminimalizować skutki. Mogę zalecić przed wszelkimi pracami nad zmianą rodzaju SEO URL lub przebudową struktury, stworzenie planu bieżącej struktury strony, wszystkich jej sekcji i przykładowych stron końcowych. Po zakończeniu prac trzeba sprawdzić, czy po wejściu pod starą nazwę adresu trafiamy na nowy, a serwer przekazuje przekierowanie z kodem 301 (a nie 302).

Kolejnym częstym przypadkiem stosowania przekierowania 301 jest zmiana adresu strony internetowej lub połączenie lustrzanych kopii. Jeśli zdecydujesz się zmienić adres strony z powodu rebrandingu firmy lub zarejestrujesz nową, bardziej atrakcyjną i krótką domenę do umieszczenia jej w materiałach promocyjnych – bardzo ważne jest, aby w przypadku odwołania do starej domeny użytkownik trafił na tę samą stronę (a nie na stronę główną), ale na nowej domenie. Jeśli chodzi o strony promocyjne, zazwyczaj składają się z jednej lub dwóch stron, których linki prowadzą do głównej strony, lub po przejściu do strony promocyjnej od razu następuje przekierowanie na specjalną stronę głównej witryny. Czasami podczas tworzenia witryny rejestruje się od razu kilka domen, na przykład z powodu wieloznacznego zapisu nazwy firmy w alfabecie łacińskim. Aby użytkownik intuicyjnie wpisując adres trafił tam, gdzie trzeba, i zarejestrowane zostały kilka domen „pomocniczych”, bardzo ważne jest, aby z każdej „pomocniczej” domeny prowadził 301 przekierowanie na jedno główne lustro. W żadnym przypadku nie wolno pozwolić, aby na wszystkich adresach była dostępna ta sama witryna.

Kolejna sytuacja podobna do poprzedniej to, kiedy kopia witryny jest dostępna i dostępna za pomocą serwisowej domeny testowej, na przykład site.hosting.pl. Takie przypadki zdarzają się w mojej praktyce, i w przeciwieństwie do poprzedniego przypadku, dotyczy to właśnie wirtualnych serwerów. Po co to istnieje? Na przykład, jeśli jeszcze nie kupiłeś domeny lub przenosisz stronę z jednego hostingu na drugi, a serwery DNS dla domeny nie zostały jeszcze zmienione lub rekordy DNS u dostawcy nie zostały jeszcze zaktualizowane. W takich sytuacjach tworzy się adresy testowe, gdzie można wszystko skonfigurować i ustawić, zanim przekierujesz adres strony na nowy hosting. I niektórzy dostawcy hostingu popełniają błąd, nie zamykając dostępu do takich adresów testowych, a przy tym nawet nie blokują ich indeksowania. Jeśli masz taką nieprzyjemną sytuację, spróbuj dodać przekierowanie 301 z adresu technicznego na główny w pliku .htaccess.

I, oczywiście, 301 przekierowanie jest często stosowane przez doświadczonych specjalistów SEO do zwalczania różnych duplikatów stron. Dlaczego tylko przez doświadczonych specjalistów SEO? Ponieważ niewłaściwi specjaliści kompletnie olewają witrynę klienta i, co jest całkiem prawdopodobne, nawet nie wchodząc na nią, zaczynają kupować linki – niestety, to nie rzadkość. Do mnie zwracają się klienci, którzy chcą sprawdzić sumienność swoich wykonawców/pracowników odpowiedzialnych za optymalizację i promocję strony internetowej, ocenić jakość pracy – zamawiają audyt SEO strony – i do tej pory nie było takiej sytuacji, abym nie znalazł błędów lub braków na witrynach. Dlatego zawsze jestem gotów pomóc. Wróćmy jednak do duplikatów – uważam, że zamiast zamykać duplikaty przed indeksacją, trzeba robić przekierowanie na podstawowy adres, a cała rel=”canonical” to już nie jest tak ciekawe. Oczywiście istnieje wiele przypadków, gdy duplikaty są nieuniknione, i wtedy nie obejdzie się bez kanonizacji, ale jeśli istnieje możliwość przekierowania, zawsze go stosuj. Częste przypadki duplikatów, które zawsze warto sprawdzać: adresy z ukośnikiem na końcu i bez, adresy z parametrami i etykietami – jak rozwiązywać te problemy, opowiem poniżej.

Kiedy MOŻNA stosować przekierowanie 301

W tym dziale trudno wiele napisać, ale postaram się. Mam nadzieję, że po przeczytaniu dodasz kilka pomysłów w komentarzach.

Przekierowanie 301 można użyć jako odpowiedzi serwera zamiast błędu 404 Not Found – innymi słowy, użytkownik, przechodząc przez niewłaściwy link lub nieistniejącą stronę, nie zobaczy komunikatu „Przepraszamy, taka strona nie istnieje”, ale zostanie przeniesiony na inną istniejącą stronę. To bardzo kontrowersyjny temat wśród specjalistów, dlatego nie narzucam mojej opinii nikomu. Jednak osobiście wolę używać przekierowania zamiast błędu 404, i istnieje kilka scenariuszy rozwoju wydarzeń… Zobacz, istnieją dwie kategorie błędów 404: pierwsza – klasyczna, gdy strona faktycznie została usunięta, a druga – gdy pojawienie się błędu wynika z krzywych zewnętrznych linków. W pierwszym przypadku prawdopodobnie nie warto przekierowywać, lepiej zostawić błąd 404 takim, jakim jest. Ale w drugim przypadku warto zastanowić się nad przekierowaniem na poprawny adres URL, jeśli można go odtworzyć z uszkodzonego linku, lub przekierowaniem na stronę główną (lub kategorię).

Kiedy NIE POWINIENEŚ stosować przekierowania 301

Kilka słów o tym, kiedy przekierowanie może ci zaszkodzić, dlatego nie powinieneś go używać w następujących sytuacjach.

Najważniejsze to, aby unikać błędów, nie rób przekierowań, jeśli nie jesteś w 100% pewien, co robisz lub masz jakiekolwiek wątpliwości. Weź to sobie do serca jako przyjacielską radę 🙂

Trwałe przekierowanie nie powinno być używane do tymczasowych rozwiązań, co jest oczywiste z samej nazwy – do tymczasowego przeniesienia użyj przekierowania 302 Moved Temporarily. W ten sposób strony nie zostaną scementowane, a stronę z przekierowaniem można w każdej chwili przywrócić.

Jeśli twój domeną występują problemy, takie jak filtry, bany, itp., i zdecydowałeś się zmienić adres strony internetowej (domenę), nie rób przekierowania 301 ze starej domeny na nową – w rezultacie „przylepisz” do nowej domeny wszystkie problemy starej. Innymi słowy, nic się nie zmieni. Tak, przez pewien czas istniało rozwiązanie wyjścia spod filtra Pingwina poprzez pełne przekierowanie 301 ze starej domeny na nową. Faktycznie wszystkie pozycje przywracały się do poziomu sprzed sankcji, i wydawało się, że to panaceum na złego Pingwina, ale podczas kolejnej aktualizacji algorytmu ta cecha została uwzględniona, a nowa domena również trafiła pod filtr, więc po zmianie domeny sytuacja nie uległa poprawie. Jeśli już zdecydowałeś się na zmianę domeny, spróbuj przenieść całą zawartość na nową domenę, a na starej usuń ją i umieść zastępczy komunikat o przeprowadzce, a jeszcze lepiej zacznij wszystko „od nowa”.

Istnieje wiele sposobów na wykonanie przekierowania 301: za pomocą htaccess, php, javascript, ustawień serwera itp. – więc nie próbuj używać od razu wszystkich metod jednocześnie, istnieje zbyt duże ryzyko „niezgodności” między różnymi sposobami, a można na przykład uzyskać nieskończony cykliczny przekierowanie.

Ważne wskazówki i rady przy pracy z przekierowaniami

Kiedy pracujesz ze skomplikowaną strukturą strony lub przekształcasz duży portal, często występują liczne przekierowania lub długie łańcuchy. Oznacza to, że przekierowanie następuje nie w jednym kroku, ale w dwóch i więcej – to zła sytuacja, którą trzeba unikać, o ile to możliwe. Przechodząc przez takie łańcuchy przekierowań lub złożoną strukturę strony, często możemy napotkać na problem. Gdy robot wyszukiwarki otrzymuje kilka przekierowań z rzędu, może uznać, że jest oszukiwany i zdecydować się przerwać śledzenie dalszych linków lub nawet zaprzestać uwzględniania ich w ogóle. Pozwól, że podam ci przykład z mojej praktyki. Pewnego dnia trafiłem na stronę podczas audytu, która miała nieoczekiwany łańcuch przekierowań:

http://site.pl/tax/term/30 ->
http://www.site.pl/tax/term/30 ->
http://www.site.pl/tax/term/30/ ->
http://www.site.hosting.pl/404.php ->
http://www.site.pl/404.php

Кońcowo strona http://www.site.pl/404.php, która powinna zwracać błąd 404, zamiast tego zwraca odpowiedź 200 OK. To nawet mnie zdezorientowało, a pomyślcie, co pomyślałby robot wyszukiwania, wpadając w taki wir! Nie tylko trzy różne domeny uczestniczyły w tej sekwencji, ale także strona błędu twierdzi, że to nie jest błąd i powinna być indeksowana.

Starań się unikać przekierowań wewnątrz strony – jeśli nie można poprawić zewnętrznych linków do strony i przekierowanie jest nieuniknione, należy starać się naprawić wewnętrzne linki. To może nie wpłynąć znacząco na jakość indeksacji i ranking, ale nie można być pewnym na pewno, dlatego lepiej unikać takich kontrowersyjnych sytuacji.

Tworząc reguły przekierowań w pliku .htaccess, wykluczaj rzeczywiste adresy katalogów i plików na serwerze i śledź ich wybór. Sytuacja dla strony, którą miałem raz na audycie – w walce z duplikatami stron kategorii z ukośnikiem na końcu i bez nich, webmaster przesadził nieco i odwrotnie tylko pogorszył problem. Nie tylko pod reguły przepisów wpadły rzeczywiste pliki skryptów JS i arkuszy stylów CSS, przez co przestały działać poprawnie, ale także niektóre strony otrzymały niechciany ukośnik na końcu i pojawiły się duplikaty. Przyjaciele, pilnujcie, aby stworzone reguły dotyczyły tylko tej grupy adresów, z którą pracujecie, i ograniczajcie wszystkie pozostałe.

Aby znaleźć problemy na stronie i ich adresy, których trzeba się pozbyć, korzystajcie z możliwości paneli webmastera od Yandex i Google. Dla Webmastera Yandex: Wybieramy stronę -> Indeksowanie strony -> Wyłączone strony. Dla Google Webmaster: Wybieramy stronę -> Optymalizacja -> Optymalizacja HTML; A także: Wybieramy stronę -> Konfiguracja -> Ustawienia URL.

Cechy indeksacji i ponownej indeksacji przekierowań w Yandex i Google. Gdy będziecie walczyć z duplikatami i problemowymi adresami, oczywiście będziesz czekać na usunięcie błędów z paneli webmastera, są pewne subtelności. Z Google jest to proste – skonfigurujecie przekierowania, zmiany zostaną zindeksowane w ciągu 2 tygodni, w tym samym czasie błędy zaczną znikać z panelu webmastera, zazwyczaj po miesiącu wszystkie błędy znikają. Z Yandexem jest jednak pewien haczyk, polega to na tym – po ustawieniu przekierowań można czekać na zniknięcie błędów z panelu czasami wiecznie, czekałem kiedyś pół roku, zanim napisałem do pomocy, gdzie poinformowano mnie, że oprócz przekierowania konieczne jest dodatkowo zamknięcie problematycznych stron w pliku robots.txt, a dopiero wtedy znikną one z panelu webmastera.

Zalecam również przeczytanie oficjalnych podręczników od wyszukiwarek na ten temat: Przekierowanie 301 od Google i Przetwarzanie przekierowań od Yandex.

Co z innymi przekierowaniami?

Przekierowania 301 to nie jedyny rodzaj. Pozwól, że przedstawię Ci bliskiego sąsiada, przekierowania 302.
Przekierowania 301 vs Przekierowania 302

Podczas gdy 301 sygnalizuje stałe przekierowanie, 302 sygnalizuje tymczasowe przekierowanie.

Istnieją sytuacje, kiedy 302 byłby preferowany, na przykład podczas aktualizacji strony internetowej, zachowując jednocześnie dostarczanie treści czytelnikom.

Większość czasu warto jednak trzymać się przekierowań 301. Zazwyczaj uważane są za lepsze dla SEO, ponieważ pozwalają utrzymać przychodzące linki.

Chociaż Google wydał oświadczenia wyjaśniające, że przekierowania 300 nie spowodują utraty PageRank, te strony mogą nie być traktowane w taki sam sposób. Oznacza to, że mogą potencjalnie cierpieć pod względem autorytetu domeny i ruchu.

Przekierowanie 307 to kolejny rodzaj tymczasowego przekierowania. Przekierowania 307 można użyć, aby powiadomić odwiedzających witrynę, że zawartość przeniosła się na nowe miejsce. Jeśli chcesz ponownie użyć istniejącego adresu URL, przekierowania 307 dają tę opcję.

Trwały przekierowanie 301 za pomocą .htaccess.

Taki sposób ustawiania przekierowań jest najbardziej popularny i prosty. Chociaż, szczerze mówiąc, daleko od tego, że jest tak łatwo, jak się wydaje, więc planuję napisać osobny post na temat htaccess. Z zalet tego sposobu można wymienić to, że przekierowanie działa na poziomie serwera i przed uruchomieniem przetwarzania jakichkolwiek skryptów na stronie, co nie generuje dodatkowego obciążenia.

Na pewno na serwerze (w głównym katalogu, tam gdzie główny plik index.php) już jest plik .htaccess. Jeśli nie widać tego pliku:

Sprawdź ustawienia menedżera ftp, który może ukrywać pliki systemowe, do których należy plik htaccess.
Wejdź do menedżera plików za pośrednictwem panelu sterowania hosta i sprawdź uprawnienia do pliku. Mam na myśli nie CHMOD, ale grupę i użytkownika, na przykład może być tam użytkownik root, a ty łączysz się przez ftp, używając dostępu użytkownika właściciela domeny.
Banalnie może nie być pliku 🙂 W takim przypadku należy go utworzyć, ale pod systemem Windows czasami pojawia się problem, ponieważ plik .htaccess jest postrzegany przez system jako plik bez nazwy i tylko z rozszerzeniem. Proponuję prosty sposób – utwórzmy zwykły plik txt, dodajmy do niego linię „RewriteEngine On” (bez cudzysłowów), załadujmy plik txt na serwer, a następnie na serwerze zmieńmy nazwę pliku na .htaccess.

Większość poprawek związanych z przekierowaniem należy umieszczać na samym początku pliku po linii „RewriteEngine On”, aby te reguły były stosowane w pierwszej kolejności. Ważne jest zachowanie kolejności działań, ponieważ polecenia są przetwarzane przez serwer sekwencyjnie , od początku do pierwszego dopasowania. Innymi słowy, zawsze zaczynaj od szczegółów i kończ ogólnym wyborem.

Przeanalizujmy kilka najczęściej spotykanych i przydatnych przykładów:

301 przekierowanie dla domeny z www.site.pl na site.pl

RewriteCond %{HTTP_HOST} ^www.(.) [NC] RewriteRule ^(.)$ http://%1/$1 [R=301,L]

301 przekierowanie dla domeny z site.pl na www.site.pl

RewriteCond %{HTTP_HOST} !^www.(.) [NC] RewriteRule ^(.)$ http://www.%1/$1 [R=301,L]

Opisane powyżej warianty przekierowań działają doskonale i nie wymagają żadnych zmian po Państwa stronie — wystarczy wkleić do pliku .htaccess. Niemniej jednak dla 100% pewności polecałbym inny wariant:

REWRITECOND %{HTTP_HOST} !^WWW.SITE.PL$ [NC] REWRITERULE ^(.*)$ HTTP://WWW.SITE.PL/$1 [R=301,L]

lub

REWRITECOND %{HTTP_HOST} !^SITE.PL$ [NC] REWRITERULE ^(.*)$ HTTP://SITE.PL/$1 [R=301,L]

Pierwszy dla tych, u których główna domena z www, drugi – dla tych bez www. Odpowiednio, w obu przykładach zamiast „site” należy wpisać nazwę swojej domeny.
Tak więc, dlaczego te warianty są lepsze? Bardzo prosto, sprawdzają one nie tylko obecność/brak www w nazwie domeny, ale także sprawdzają dokładne dopasowanie nazwy domeny.
Żywy przykład: Na pewno zetknęli się Państwo z sytuacją, gdy witryna niespodziewanie zostaje zindeksowana przez serwis na adresie służbowym hostingu (taki adres jest przypisany, aby można było uzyskać dostęp do witryny przed przypisaniem rzeczywistej domeny), jakimś zwierciadłem lub nawet adresem IP! Tak więc uniwersalne zasady będą tylko weryfikować brak/obecność www, przy czym bez znaczenia jest, pod jaką domenę zwraca się użytkownik lub robot wyszukiwarki.
Więc korzystając z zaawansowanego wariantu, będą Państwo mieć pewność na 100%, że Państwa witryna będzie dostępna tylko i wyłącznie pod właśnie przez Państwa podaną nazwą domeny i z www. Korzystam tylko z tego wariantu i polecam!

301 przekierowanie z http na https

W obliczu masowej migracji witryn na zabezpieczony protokół, ważne jest, aby wiedzieć, jak zrobić przekierowanie z http na https. Nawiasem mówiąc, jeśli jeszcze nie wybrali Państwo certyfikatu SSL, powinni Państwo przeczytać mój wpis o certyfikacie SSL dla witryny — po co jest potrzebny i gdzie go uzyskać.

Poniżej przedstawiam kilka wariantów 301 przekierowania z protokołu http na https, które mogą działać lub nie działać w zależności od konfiguracji własnie Państwa serwera, ale któreś z tych zasad na pewno będzie dla Państwa odpowiednie:

RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

RewriteCond %{ENV:HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteCond %{HTTP:X-HTTPS} !1
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

RewriteCond %{HTTP:CF-Visitor} '"scheme":"http"'
RewriteRule ^(.*)$ https://site.pl/$1 [R=301,L] #site.pl trzeba zamienić na Państwa domenę

RewriteCond %{HTTP:X-Forwarded-Protocol} !=https
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

Jeśli występuje cykliczne przekierowanie, skorzystajcie Państwo z tego wariantu:

RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Przekierowanie z protokołu https na http (szczerze mówiąc, nie wiem, po co może być to Państwu potrzebne):

RewriteCond %{HTTPS} =on
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1 [R=301,L]

Niedawno napisałem bardzo szczegółową instrukcję, jak prawidłowo przenieść witrynę z HTTP na HTTPS bez utraty. Jeśli planują Państwo przeniesienie z https na https, koniecznie ją przeczytajte!

Chcę rzucić pewne światło na niezrozumiałe zamieszanie:

RewriteCond oznacza warunek, który musi być spełniony, aby reguła RewriteRule została wykonana. Wyrażenia regularne są używane do określania wzorców ciągów znaków.

Zmienne serwera:

%{REQUEST_URI} — fragment adresu URL bez nazwy domeny i parametrów GET, na przykład, dla strony, którą teraz czytasz: blog/post/4393;
%{HTTP_HOST} — host lub nazwa domeny, na przykład: hotmonitoring.eu;
%{QUERY_STRING} — ciąg znaków z zestawem parametrów GET, czyli część adresu URL po znaku zapytania (i przed znakiem hash, jeśli istnieje);
%{REQUEST_FILENAME} — pełna ścieżka do pliku lub skryptu w systemie plików serwera odpowiadającego temu zapytaniu. Aby zrozumieć, adres skryptu, taki jak to dla nas normalne hotmonitoring.eu/index.php, to w systemie plików serwera to straszny ciąg /var/www/hotmonitoring.eu/index.php;
Czasem, wykonując przekierowanie, otrzymujesz nieoczekiwany wynik, na przykład chciałeś usunąć parametry post=17434801_4060 z adresu http://site.pl/page-name?post=17434801_4060, określiłeś odpowiednie zasady (o których będzie napisane poniżej), ale ostatecznie otrzymałeś ciąg http://site.pl/usr/local/www/site.pl/www/page-name — pozbyłeś się parametrów, ale uzyskałeś dziwny adres. To wszystko dlatego, że nie podałeś na początku pliku po RewriteEngine On dyrektywy RewriteBase /, która ustawia konkretne, podstawowe URL dla transformacji w kontekście katalogu.

Metaznaki są używane do określania grup znaków lub „etykiet” w szablonie:

^ — etykieta początku ciągu;
$ — etykieta końca ciągu;
! – negacja;
\ — ukośnik odwrotny, umożliwia traktowanie następującego po nim metaznaku jako zwykłego znaku;
. – kropka, oznacza dowolny znak, ale tylko jeden;
() – grupowanie.

Modyfikatory są umieszczane po zwykłych znakach, metaznakach lub ich grupach i rozszerzają możliwości stosowania szablonów:

? — znak powtarza się 0 lub 1 raz;
* — Powtarza się od 0 do 65536 razy;
+ — Powtarza się od 1 do 65536 razy;

Flagi określają dodatkowe opcje dla danej reguły i są wymieniane w nawiasach kwadratowych, oddzielone przecinkami:

NC — (nocase) wyłącza sprawdzanie wielkości liter;
R — (redirect) zatrzymuje proces transformacji i zwraca przeglądarce klienta wynik jako przekierowanie do tej strony (302, MOVED TEMPORARY). Z tą flagą można określić inny kod wyniku, na przykład R=301 zwróci przekierowanie z kodem 301 (MOVED PERMANENTLY). Jak rozumiecie, to to, czego potrzebujemy;
L — (last) zatrzymuje proces transformacji, a bieżący link uważa się za ostateczny.

Najpopularniejszym przypadkiem jest przekierowanie 301 z index.php (html) na stronę główną. W 90% witryn pojawia się problem zduplikowania strony głównej pod adresami http://site.pl i http://site.pl/index.php (lub index.html, index.htm lub dowolna inna wersja, nieważne, a może nawet wszystkie naraz). Gdzieś jest to oczywiste, na przykład, gdy link z logo prowadzi do site.pl, a link w menu prowadzi do site.pl/index.php, gdzieś niejasno, gdy dublet znajduje się podczas wprowadzania adresu ręcznie z index.php. Ważne jest po prostu rozwiązanie tego problemu. I proponuję uniwersalną opcję, oto ona:

RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /index.(php|html|htm)\ HTTP/ RewriteRule ^(.*)index.(php|html|htm)$ $1 [R=301,L]

Po prostu wklej ten kod bez zmian po linii „RewriteEngine On” i nie ma problemu!

Wielu osób, które zaczynają walczyć z duplikatami na stronie, zadaje sobie pytanie, skąd biorą się takie linki, które powielają główną stronę http://site.pl/page-name.html&post=-1234567_8901? Skąd wziął się dodatek &post=-1234567_8901 – to „dobro” pochodzi z blogów.

Aby raz na zawsze pozbyć się tego niepotrzebnego elementu, musisz dodać to do pliku .htaccess:

RewriteCond %{REQUEST_URI} ^(.)&post= RewriteRule ^(.)&post=(.*)$ $1 [R=301,L]

Aby zrozumieć zasadę, podam jeszcze jeden przykład, który ktoś właśnie zaproponował do rozwiązania w komentarzach. Czasami możesz natknąć się na takie linki:
http://site.pl/&sa=U&ei=AsguT72dLdHLtAaZ0tyVDQ&ved=0CCwQFjAIOFo&usg=AFQjCNFwbE9i0bqrQUGJLoDh6xyVd1nhxg
Co smutne, te linki są indeksowane przez Google i pojawiają się w wynikach wyszukiwania.

Ale nie o tym mówię, po prostu chcę, abyś zrozumiał mechanizm przekierowania 301 w takich przypadkach, a nie zadawał mi pytań w komentarzach do każdego przypadku. A rozwiązanie będzie takie samo:

RewriteCond %{REQUEST_URI} ^(.)&sa= RewriteRule ^(.)&sa=(.*)$ $1 [R=301,L]

Jak widzisz, nie ma żadnej różnicy między tym, a poprzednim przypadkiem, niech w twoim adresie URL będzie &post= lub &sa= lub cokolwiek innego — rozwiązanie jest takie same, wystarczy podmienić oczywiste części kodu. Zrozumiałe, prawda?

Pozbywamy się parametrów lub etykiet w adresie

To pytanie było zadawane zarówno w komentarzach, jak i wiele razy na forum, więc nie można go ominąć. Co zrobić z takimi duplikatami: http://site.pl/?abrakadabra lub bardziej realny przypadek http://site.pl?utm_source=twitterfeed&utm_medium=twitter

Ten przypadek nieco różni się od następnego, gdzie pozbywamy się parametrów dla skryptu PHP, ponieważ tutaj mamy zwykły adres, a parametry do skryptu nie są przekazywane. Oto rozwiązanie:

RewriteCond %{QUERY_STRING} ^utm_source= [NC] RewriteRule (.*) $1? [R=301,L]

Jak rozumiesz, wartość „utm_source=” można zamienić na swoje „abrakadabra”, a to spowoduje przekierowanie 301 na adres bez jakiejkolwiek abrakadabry.

Przykład pozbycia się parametrów skryptu w adresie URL

Załóżmy, że chcemy pozbyć się parametru lang=ru z adresu http://site.pl/index.php?lang=ru, aby uzyskać http://site.pl/index.php.

W pliku .htaccess musisz wprowadzić takie linie:

RewriteCond %{QUERY_STRING} ^lang=ru [NC] RewriteRule (.*) $1 [R=301,L]

Wstaw ten kod bez zmian po linii „RewriteEngine On” i po problemie!

Mam nadzieję, że powyższe wyjaśnienia i rozwiązania są jasne i pomocne!

RewriteCond %{QUERY_STRING} ^lang=ru$ RewriteRule ^(.).php\?(.)$ $1.php [R=301,NC,L]

%{QUERY_STRING} — to ciąg zmiennych dla PHP, część URL po znaku zapytania (i przed znakiem krzyżyka kotwicy, jeśli istnieje).

Wywołujemy URL — http://site.pl/index.php?lang=ru

RewriteCond %{QUERY_STRING} ^lang=ru$
Podany URL spełnia to kryterium, nie ma innych zasad, więc zostanie wykonane RewriteRule poniżej.
RewriteRule ^(.).php?(.)$ $1.php [R=301,NC,L]

Początkowy URL: http://site.pl/index.php?lang=ru
Szablon analizy URL-a: ^(.).php?(.)$
URL zostanie rozebrany na zmienne: $1 = http://site.pl/index, $2 = lang=ru, a następnie zostanie ponownie zmontowany jako http://site.pl/index.php ($1.php)
Następnie nastąpi 301 przekierowanie na nowy URL.

Przykład zasad przy zmianie struktury witryny

RewriteRule ^post/category/(.)$ blog/category/$1 [R=301,L] RewriteRule ^post/(.)$ blog/post/$1 [R=301,L]

Takie linie musiałem dodać do pliku htaccess, gdy zmieniłem strukturę mojego bloga.

Wcześniej moje adresy były takie: https://hotmonitoring.eu/?p=50 i https://hotmonitoring.eu/pl, co jakoś psuło logiczną strukturę — przecież blog to tylko część witryny, ale dlaczego posty należą do witryny, a nie bloga, a kategorie należą do postów, co też jest zupełnie nielogiczne. Postanowiłem przywrócić logiczną strukturę i uzyskałem: https://site.pl/post/50 i https://site.pl/seo — teraz blog to oddzielna sekcja witryny, a posty należą do niej, a kategorie należą do bloga, a nie postów.

Z tego samego przykładu widać, że ważne jest zachowanie kolejności zasad. Gdybym zamienił miejscami linie, czyli linia RewriteRule ^post/(.*)$ blog/post/$1 [R=301,L] byłaby pierwsza, to przekierowanie z adresu https://hotmonitoring.eu/post/category/seo prowadziłoby do strony https://logicznakuznia.eu/post/category/seo, a nie tak, jak trzeba, do https://logicznakuznia.eu/seo.

Ostatni przykład — analiza częstego błędu z adresem od korzenia serwera

Na przykład chcesz naprawić taki problem, gdy strona kategorii jest dostępna pod dwoma adresami http://site.pl/razdel/podrazdel/index.php i http://site.pl/razdel/podrazdel/. Drugi URL jest poprawny i podstawowy, a URL z index.php na końcu jest pełnym dublem, który trzeba usunąć.

Aby zrobić przekierowanie z index.php do kategorii, wpisujesz następujące zasady:

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

Ale ostatecznie, gdy odwołujesz się do strony: http://site.pl/razdel/podrazdel/index.php
Przekierowuje na coś w rodzaju: http://site.pl/home/site.pl/public_html/razdel/podrazdel/

Inaczej mówiąc, wypisuje pełną ścieżkę od korzenia serwera.

Aby rozwiązać ten problem (i nie tylko ten, zresztą), musisz mieć pewność, że na początku pliku .htaccess znajduje się nie tylko linia RewriteEngine On, ale po niej jest jeszcze jedna, która obcina pełną ścieżkę (od korzenia serwera) do korzenia witryny, tak:

RewriteEngine On RewriteBase /

301 przekierowanie ze strony na stronę, na nowy adres

Najprostszy przypadek, gdy trzeba przekierować jedną stronę na inny adres. Jeśli musisz przekierować kilka stron, będziesz musiał napisać kilka zasad, ale w tym przypadku lepiej skorzystać z opisanych powyżej szablonów. Istnieje kilka zupełnie identycznych składni:

Redirect 301 /page-name1.html http://site.pl/page-name2.html Redirect permanent /page-name1.html http://site.pl/page-name2.html RedirectPermanent /page-name1.html http://site.pl/page-name2.html

Wybierz jedno z trzech, ale osobiście preferuję pierwszą opcję — jest krótsza, prostsza i bardziej zrozumiała. Nawiasem mówiąc, tutaj site.pl może być niekoniecznie tym samym domenem, ale dowolnym innym.

To wszystko dotyczy .htaccess, teraz przejdźmy do PHP.

Stałe przekierowanie 301 za pomocą PHP

Zwykle używam przekierowania PHP, gdy napotykam trudności z .htaccess lub okazuje się, że funkcja w PHP jest bardziej logiczna i zrozumiała.

Składnia samego przekierowania 301 w PHP wygląda tak:

header("HTTP/1.1 301 Moved Permanently"); header("Location: http://site.pl"); die();

Te linie mówią przeglądarce klienta, że z pewnej strony potrzebny jest stały przekierowanie na adres http://site.pl. Przy tym http://site.pl może być nie tylko adresem głównej strony bieżącej witryny, ale może być dowolną inną stroną. Jeśli coś poszło nie tak i wystąpił błąd, w oknie przeglądarki zobaczymy napis „Redirect”.

Aby zrozumieć lepiej, przedstawię kilka przykładów funkcji, które napisałem dla mojego bloga hotmonitoring.eu, starając się rozwiązać konkretne problemy.

Funkcja umożliwiająca usunięcie określonego fragmentu z adresu URL:

<?php

function removeQueryString($url, $queryToRemove) {
    $urlParts = parse_url($url);
    parse_str($urlParts['query'], $queryParameters);

    // Usuwanie określonego klucza z tablicy parametrów zapytania
    unset($queryParameters[$queryToRemove]);

    // Ponowne złożenie adresu URL
    $urlParts['query'] = http_build_query($queryParameters);

    return $urlParts['scheme'] . '://' . $urlParts['host'] . $urlParts['path'] . '?' . $urlParts['query'];
}

// Przykład użycia:
$currentURL = "http://site.pl/index.php?lang=ru";
$newURL = removeQueryString($currentURL, 'lang');

Funkcja do przekierowania z PHP:

<?php

function redirect301($newLocation) {
header("HTTP/1.1 301 Moved Permanently");
header("Location: $newLocation");
die("Redirect");
}

// Przykład użycia:
$redirectURL = "http://site.pl/new-page";
redirect301($redirectURL);

Oczywiście, powyższe funkcje to tylko przykłady i mogą wymagać dostosowania do konkretnych wymagań. Warto również pamiętać, że skonfigurowanie odpowiednich reguł przekierowań w pliku .htaccess może być bardziej wydajne i łatwe w zarządzaniu, zwłaszcza w przypadku masowego przekierowywania wielu stron.

Jeśli masz konkretne pytania dotyczące kodu PHP lub .htaccess dla określonego przypadku, śmiało pytaj!

Pewnego dnia napotkałem problem z panelem webmastera, gdzie pojawiło się mnóstwo błędów 404. Adresy tych stron miały postać https://logicznakuznia.eu/?p=50, czyli gdzieś w adresie pojawił się zduplikowany adres strony. Wtedy napisałem funkcję, która sprawdza, czy w URI (zauważ, nie URL, ale URI) występuje „https://logicznakuznia.eu”, i jeśli tak, to wycinamy ten fragment z adresu i zapisujemy wynik do zmiennej $real_page_url, a następnie przekierowujemy na poprawny adres z tej zmiennej.

Funkcja usuwająca końcowy ukośnik z adresu URL:

<?php

if ( ( $_SERVER['REQUEST_URI'], - 1, 1 ) == '/' ) {
    $requested_url = rtrim($requested_url, '/');
    
    header("HTTP/1.0 301 Moved Permanently");
    header("Location: $requested_url");
    die();
}

To prosta funkcja, która sprawdza, czy w żądanym adresie strony jest ukośnik na końcu, i jeśli jest, to ukośnik jest obcinany, a następnie następuje przekierowanie 301 na adres bez ukośnika.

Istnieje wiele innych sposobów na wydanie polecenia przekierowania w różnych językach programowania, takich jak ASP, Ruby on Rail itp., ale nie znam się na tych językach, więc nie będę tutaj mądrzyć się i komplikować. Istnieją także przekierowania za pomocą meta refresh w meta tagu, a także przekierowania w JavaScript – ale to są praktyki podejrzane, których nie zaleca się, ponieważ wyszukiwarki nie rozumieją tych przekierowań i otrzymują odpowiedź od serwera 200 OK. Dlatego też te opcje nie są rozważane.

Permanentny przekierunek 301 dla serwera nginx:

Pamiętasz, że pisałem o lustrze mojej strony dostępnej poprzez adres IP? Ostatecznie problem rozwiązano za pomocą przekierowania zapisanego w pliku konfiguracyjnym serwera, zazwyczaj znajdującego się tutaj /etc/nginx/nginx.conf. Tam wpisano takie linie:

server {
    listen 1.2.34.123:80 default;
    server_name _;
    rewrite ^/(.*)$ http://site.pl/$1 permanent;
}

Mówi się tutaj, że jeśli jest zapytanie na adres IP przez port 80, to trzeba zrobić permanentne przekierowanie na site.pl.

Jednakże wsparcie techniczne odradzało mi takie postępowanie, mówiąc: „Bardziej poprawnym będzie skonfigurowanie serwera HTTP w taki sposób, aby po prostu zamykał połączenie, jeżeli ktoś do niego się odwołuje pod adresem, który nie jest wyraźnie wymieniony w konfiguracji serwera HTTP. To jest najbardziej niezawodny, prosty, bezpieczny i najmniej wymagający zasobów serwera wariant. Wkrótce strony, które będą niedostępne, prawdopodobnie zostaną usunięte z indeksu wyszukiwarek.”

Następna rada brzmiała: „Gdy będzie potrzebne zamykanie połączenia zamiast przekierowania, zamiast linii 'rewrite ^/(.*)$ http://site.pl/$1 permanent;’ wpisz taką linię 'return 444;’. Następnie wykonaj: 'invoke-rc.d nginx reload’.”

Mam nadzieję, że komuś to pomoże. Przykłady przekierowań w najczęściej spotykanych przypadkach:

Przekierowanie domeny www.site.pl na site.pl:

server {
    listen 80;
    server_name www.site.pl;
    rewrite ^ http://site.pl$request_uri? permanent;
}

Przekierowanie domeny z site.pl na www.site.pl:

server {
    listen 80;
    server_name site.pl;
    rewrite ^ http://www.site.pl$request_uri? permanent;
}

Przekierowanie z adresu http://site.pl/index.php na http://site.pl/

location = /index.php {
	if ($request_uri = /index.php) {
		rewrite ^ http://$host? permanent;#301 redirect
	}
	fastcgi_pass   unix:/tmp/fastcgi.sock;
	fastcgi_index  index.php;
	fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
	include        fastcgi_params;
}

Jak sprawdzić nagłówki HTTP i kody odpowiedzi serwera

Chciałem w tym wpisie opisać różne narzędzia i wtyczki do sprawdzania odpowiedzi serwera, ale rozumiem, że ten post jest już na tyle obszerny, że muszę ograniczyć się do prostych linków do rozszerzeń dla przeglądarek Chrome i Firefox.

Rozszerzenie HttpFox dla Firefoksa

HttpFox to moje ulubione narzędzie do śledzenia nagłówków http. HttpFox pokazuje krok po kroku przebieg ładowania strony, co pozwala na przykład śledzić łańcuchy przekierowań i w ogóle kolejność oraz szybkość ładowania strony. Jeśli korzystasz z Mozilli, zdecydowanie polecam.

Rozszerzenie HTTP Headers dla Chrome’a

Sam nie korzystam z rozszerzenia HTTP Headers, ale polecili mi zwrócić na nie uwagę. Jeśli masz lepsze propozycje, daj znać w komentarzach.

Ponadto chcę Ci polecić ciekawy serwis Hot Monitoring. W sekcji darmowych narzędzi znajdziesz „Na rzędzie do sprawdzania nagłówków Twojej przeglądarki„, a także narzędzie o nazwie „Sprawdź nagłówki HTTP i przekierowania strony internetowej„. Bardzo polecam z nich skorzystać.

Na tym kończę mój strasznie długi i nudny wpis, przyjaciele.

Dziękuję, że doczytaliście go do końca, mam nadzieję, że okazał się dla Was naprawdę przydatny.

Najczęściej Zadawane Pytania (FAQ)

1. Co to jest przekierowanie 301?

Przekierowanie 301 to rodzaj stałego objazdu online, który przekierowuje ruch z poprzedniej strony na nową. Przekierowania 301 są ważne dla optymalizacji SEO i pozycjonowania strony.

2. Jakie są korzyści z korzystania z przekierowania 301?

Przekierowania 301 pozwalają właścicielom witryn i twórcom treści kierować ruch z martwych lub niepopularnych stron na te lepiej wykonujące się. Korzystając z przekierowań 301, możesz zoptymalizować swoją stronę, nie rezygnując z istniejącego już pozycjonowania stron, które wymagały znacznej ilości czasu i wysiłku w celu ustanowienia.

3. Czy istnieją jakieś wady korzystania z przekierowania 301?

Chociaż jest to praktyka pomocna, korzystanie z przekierowań 301 nie zawsze jest idealne. Dotyczy to sytuacji, gdy chcesz utrzymać indeksowanie starej strony lub przeprowadzić testy A/B na osobnych adresach URL. Przekierowania 301 również nie są pomocne, jeśli chcesz ponownie wykorzystać przestarzały adres URL do przyszłej zawartości strony.

4. Jaka jest najlepsza metoda testowania przekierowania 301?

Testowanie przekierowania 301 jest proste. Wystarczy wprowadzić stary adres URL, który chcesz zastąpić. Jeśli przekierowania 301 są poprawnie skonfigurowane, zostaniesz automatycznie przekierowany na nową stronę.