Htaccess - wykorzystanie pliku w SEO

Czym jest htaccess

Plik htaccess (a dokładnie „.htaccess”) to plik konfiguracyjny serwera HTTP Apache mający zastosowanie do konkretnego katalogu. Stosowany w tym podfolderze (do tej ścieżki), w której się znalazł.

Nazwa .htaccess to skrót od Hypertext Access.

Można powiedzieć, że określamy w nim zasady, według których serwer ma odpowiadać na zapytania. Reguły, według których ma być obsługiwany protokół TCP/IP.

Technicznie rzecz biorąc .htaccess nie jest najważniejszy (httpd.conf)

Notka dla ścisłości: htaccess nie jest to domyślnym plikiem ustawień serwera. Funkcję tę spełnia plik httpd.conf. Oba z nich wykorzystują te same dyrektywy / tę samą składnię.

Co ciekawe, dokumentacja Apache odradza (!) stosowanie htaccess jeśli tylko mamy dostęp httpd.conf.

W praktyce jednak, przy korzystaniu z usług hostingów, zwykle dostaniemy możliwość modyfikacji lub stworzenia tylko i wyłącznie htaccess. Z prostego powodu: nasza strona jest wtedy tylko katalogiem na serwerze.

W niektórych przypadkach nie będziemy mieć nawet tego, a jedynie możliwość wprowadzania pojedynczych zmian z poziomu jakiegoś panelu użytkownika.

Dostęp do ogólnego pliku konfiguracyjnego będą mieć tylko osoby z własnymi serwerami dedykowanymi (i to nie zawsze, gdy mowa o korzystaniu z usługi takiego serwera, a nie o własnej fizycznej maszynie).

Htaccess a inne serwery

Choć htaccess jest plikiem konfiguracji Apache, to działa też w innych rozwiązaniach. Przede wszystkim na serwerach LiteSpeed, które są o wiele szybsze od Apache, ale powielają ich elementy, m.in. właśnie plik htaccess.

Serwery LiteSpeed znajdziemy u wielu dostawców usług hostingowych w Polsce. Na przykład w cyber_Folks, ale i w tzw. hostingach SEO, nastawionych na hostowanie zaplecza pozycjonerskiego.

Miej jednak na uwadze, że pliku tego nie obsługują inne, popularne serwery, jak np. NGINX.

Co prawda można w nim osiągnąć zbliżony efekt konfiguracji dot. określonych katalogów, ale dokumentacja, delikatnie mówiąc, tego nie zaleca…

Do czego w SEO przyda ci się htaccess

Przekierowania, przekierowania i jeszcze raz przekierowania – przede wszystkim te „globalne”, np. z HTTP na HTTPS. Plik htaccess przyda się jednak i do innych celów.

Htaccess możemy wykorzystać między innymi do:

• przekierowania jednego adresu na drugi (w tym do tworzenia przyjaznych URL-i),
• przekierowania wszystkich adresów w danym wariancie na inny (np. z „WWW” na początku, na bez WWW),
• ustawienia stron błędów 404, 500 i innych,
• kompletnego zablokowania dostępu dla wybranych botów oraz adresów IP,
• uruchomienia pamięci podręcznej przeglądarki oraz kompresji plików,
• blokowania hotlinkowania,
• zabezpieczenia strony hasłem.

Zanim wprowadzisz jakiekolwiek zmiany w htaccess

Modyfikacja htaccess działa od razu po zapisaniu pliku, nie trzeba do niej restartu serwera. Stąd jest to narzędzie o wielkiej mocy, a jak wiadomo, z wielką mocą wiąże się wielka odpowiedzialność…

W skrajnych przypadkach modyfikacja htaccess może doprowadzić do czegoś w stylu „zatrzaśnięcia kluczyków w samochodzie” – czyli utraty dostępu np. do panelu WordPressa od razu po zapisaniu błędnego pliku.

Zanim zabierzemy się za modyfikację htaccess, upewniamy się, że wiemy, co robimy. My stosujemy zasadę nietykania się htaccess jeśli nie mamy dostępu i umiejętności obsługi FTP serwera (np. przez program FileZilla).

Dostęp do plików w razie awarii będzie jak komplet zapasowych kluczy w domu. Pozwoli szybko dostać się do środka i uratować sytuację. W typ przypadku: cofnąć zmiany albo podmienić cały htaccess na domyślny.

Przekierowanie 301 w htaccess

W tej kwestii pozwolimy sobie po prostu wkleić jeden z przykładów, które padły już w części SEO Samodzielnych o przekierowaniach (link u góry, pod spisem treści):

RewriteRule ^stara-podstrona$ http://example.com/nowa-podstrona [R=301,L]

Do zastosowania takiego przekierowania serwer musi mieć aktywny moduł mod_rewrite. Uruchamiamy go dodając dyrektywę na początku pliku htaccess:

RewriteEngine On

Przekierowania w htaccess można wykonać też bez mod_rewrite (jeśli jest niedostępny). Jak to zrobić przeczytasz w naszym artykule o przekierowaniach.

Stosując takie przekierowania 1:1 możemy też tworzyć przyjazne adresy URL.

Przekierowanie z HTTP na HTTPS / z WWW na bez WWW

Tutaj ponownie, podajemy tylko przykłady. Żeby się nie powtarzać i żeby uniknąć kanibalizacji słów kluczowych z innym z naszych tekstów.

Przekierowanie z www na bez www:

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

Przekierowanie z HTTP na HTTPS:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

We wspomnianym tekście znajdziesz więcej o tym jak ustawić przekierowanie WWW i HTTP/HTTPS.

Za pomocą htaccess przekierować możemy też całą domenę, co wykorzystuje się do zachowania efektów SEO przy migracji strony.

Ustawienie strony błędu 404 (lub innego) w htaccess

Własna strona błędu wpływa pozytywnie na pozycjonowanie i doświadczenie użytkownika. Głównie dlatego, że sprawia pozwala przejść dalej mimo błędu, np. za pomocą menu strony.

Nie sprawia też wrażenia, że cały serwis nie działa, a tylko daje znać, że coś poszło nie tak z podstroną. No i wyjaśnia, co się stało.

A jak ustawić taką stronę w htaccess? To bardzo proste, wystarczy zastosować dyrektywę ErrorDocument, wskazać kod błędu HTTP i podstronę, którą chcemy do niego przypisać.

ErrorDocument 404 /podstrona.html

Taką stronę błędu możemy zdefiniować dla każdego kodu błędu.

Zablokowanie botów w htaccess

Boty internetowe można blokować w pliku robots, ale to są raczej zalecenia, co do których nawet te niezłośliwe boty mogą się nie stosować. W przypadku szkodliwych crawlerów jedynym rozwiązaniem jest htaccess.

Tutaj możemy zadziałać z blokadą po IP (o czym niżej), ale szkodliwe boty często mają dynamiczne IP / korzystają z proxy.

Możemy zablokować je jednak po wartości user-agent:

RewriteCond %{HTTP_USER_AGENT} .*user-agent* [NC,OR]
RewriteRule ^.* - [F,L]

A gdy wartość ta jest pusta, to możemy zastosować blokadę dla wszystkich zapytań bez user-agent:

RewriteCond %{HTTP_REFERER} ^-?$ [NC]
RewriteCond %{HTTP_USER_AGENT} ^-?$ [NC]
RewriteRule .* - [F,L]

Skrajnym przypadkiem będzie bot ze zmiennym user-agent, ale i z nim możemy walczyć. Choćby blokując w htaccess powtarzający się fragment URI zapytań:

<IfModule mod_alias.c>
  RedirectMatch 403 /fragment/
</IfModule>

W tym ostatnim przypadku musimy jednak najpierw wykryć powtarzalny element URI zapytań (np. słowo „crawl”), do czego trzeba będzie prześledzić logi serwera.

Przed dodaniem takiej dyrektywy sprawdzamy też, czy dany element URI nie jest wykorzystywany gdzie indziej.

Szczegółowo o tym jak zablokować roboty przeczytasz w innej części SEO Samodzielnych.

Zablokowanie adresów IP w htaccess

Zablokowanie adresu IP w htaccess pozwala pozbyć się wszystkich użytkowników czy robotów, który utrudniają nam prowadzenie serwisu. Co ważne, zablokować możemy zarówno adres IPv4 i IPv6, jak i hosta.

Dyrektywa blokowania adresu/hosta wygląda tak:

order allow,deny
deny from IP/host
allow from all

W miejscu IP/host możemy wskazać:

• konkretny adres IPv4 – np. 192.168.0.1
• konkretny adres IPv6 – np. 2001:0db8:85a3:0000:0000:8a2e:0370:7334
• cały zakres adresów – np. 192.168 / 2001:0db8:85a3:0000
• konkretny host w domenie – np. subdomena.example.com
• dowolny host z domeny – np. .example.com

Gdy blokujemy kilka adresów, oddzielamy je spacjami lub dodajemy jako osobne dyrektywy deny from:

order allow,deny
deny from 192.168.0.1 192.168.0.2 192.168.0.3
allow from all

lub

order allow,deny
deny from 192.168.0.1
deny from 192.168.0.2
deny from 192.168.0.3
allow from all

W pliku htaccess możemy też zablokować ruch z poszczególnych krajów. Żeby nie męczyć się z takim zadaniem ręcznie, możemy wykorzystać np. generator Country IP Blocks.

Gdyby z jakiegoś powodu było to konieczne, to sytuację da się też odwrócić, tj. zablokować cały ruch, a dopuścić tylko IP z konkretnego kraju. Niemniej nie polecamy, bo w 99,9% przypadków nie jest to dobry pomysł.

Uruchomienie kompresji plików

Kompresja plików przed przesłaniem ich przez serwer to prawie że domyślny zabieg, który pozwala przyspieszać działanie stron. Najczęściej stosowany rodzaj kompersji to z kolegi Gzip.

W skrócie działa to tak, że plik z serwera (np. strona HTML) jest kompresowana przed wysłaniem do użytkownika, a po jego odebraniu jest dekompresowana przez przeglądarkę.

Jeśli nasz serwis nie ma jej włączonej domyślnie, to możemy zmienić to w pliku htaccess:

AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript application/json

Absolutna większość stron korzysta dzisiaj z kompresji Gzip domyślnie, szczególnie na serwerach Apache/LiteSpeed.

Jeśli nie wiesz, czy Twoja strona ją stosuje, to możesz to sprawdzić za pomocą prostego narzędzia Gzip Test. Wystarczy wkleić w nim adres i kliknąć „check if gzip is enabled”.

Do sprawdzenia możemy wykorzystać też inny test gzip, np. ten na stronie whatsmyip.org.

Jak włączyć w htaccess kompresję plików o rozszerzeniach .eot i .ttf sprawdzisz w części SEO Samodzielnych o optymalizacji fontów.

Blokada hotlinkowania w htaccess

Hotlinkowanie to umieszczanie na swojej stronie zasobów z innego serwisu, np. osadzanie w tekście grafik hostowanych pod innym (nie naszym) adresem.

Taki zabieg jest uznawany za szkodliwy, bo obciąża serwer hostujący dany zasób za każdym razem, gdy wywoływana jest strona z niego hotlinkująca.

Tutaj podobnie jak z kompresją, sporo serwerów będzie mieć domyślną blokadę. Jeśli jednak nie znajdziemy takiej w htaccess, to śmiało możemy ją dodać.

RewriteCond %{HTTP_REFERER} !^http://(.+\.)?example\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule .*\.(jpe?g|gif|bmp|png|webp)$ - [L]

W ten sposób żadna domena poza example.com (normalnie wstawimy tu naszą domenę) nie będzie w stanie pobrać zasobów o wskazanych rozszerzeniach. Zamiast nich otrzyma błąd 403.

Jak dostać się do pliku htaccess

Gdzie jest plik htaccess? Nie ma on stałej ścieżki, ale jeśli został utworzony, to będzie znajdował się zwykle w katalogu public_html na naszym serwerze.

Możemy dostać się do niego na kilka sposobów:

1. Przez WebFTP, czyli przeglądarkowego klienta FTP, w którym możemy przeglądać i modyfikować nasze pliki na hostingu (dostęp i dane znajdziesz w panelu swojego usługodawcy hostingu).
2. Przez klienta FTP, np. FileZilla, w którym podobnie jak przez WebFTP, połaczymy się z FTP naszego serwera.
3. Przez panel klienta / administracyjny hostingu – większość dużych hostingów pozwala na edycję htaccess bez grzebania w plikach, zarówno opcja, jak i edytor często dostępne są gdzieś w ustawieniach.
4. Przez ustawienia platformy / CMS – w przypadku rozwiązań SaaS, gdzie płacimy abonamentowo za hosting i CMS jako za jedną usługę modyfikacja htaccess może być dostępna w ustawieniach (ale może też być kompletnie niedostępna).
5. Przez dodatkowe wtyczki i moduł – w niektórych CMS-ach opcja modyfikacji htaccess nie będzie dostępna domyślnie, ale da się dostać do niej przez dodatkowe moduły i wtyczki.

Zanim przejdziemy do edycji, upewniamy się, czy htaccess istnieje w tylko jednej lokalizacji. Plików tych może być wiele, a każdy z nich ma zastosowanie tylko do katalogu w którym się znajduje i podrzędnych (o ile nie ma w nich innych plików htaccess).

W przypadku braku pliku, htaccess możemy stworzyć od zera.

Na przykład w WordPressie plik ten generuje się często dopiero po pierwszej modyfikacji w sekcji Ustawienia > Bezpośrednie odnośniki. Jeśli go nie ma, wystarczy tam wejść i kliknąć „zapisz zmiany”.

Jak edytować htaccess

Plik .htaccess jest plikiem tekstowym. Możemy więc go pobrać i edytować (lub stworzyć) na naszym komputerze, nawet za pomocą systemowego notatnika. Lepiej jednak wybrać coś bardziej rozbudowanego, na przykład Notepad++.

Zasady są proste:

• Wszystkie reguły zaczynamy od nazwy dyrektywy w nowej linii.
• Poszczególne argumenty reguły oddzielamy od siebie spacjami.
• Kolejność reguł ma znaczenie, jeśli np. blokujesz adresy IP, to wszystkie blokady muszą znaleźć się przed regułą dopuszczenia pozostałych.
• Od # zaczynamy linie komentarzy pliku (bez funkcji, służące jako informacja dla nas).

Po dodaniu interesujących nas dyrektyw wystarczy umieścić plik z powrotem na serwerze i nadać mu odpowiednią nazwę.

Standardowa nazwa htaccess to „.htaccess”, bez żadnego rozszerzenia pliku. Czasem plik ten może jednak nazywać się inaczej (Administrator serwera może zmienić tę nazwę w httpd.conf).

Ostatni istotny drobiazg: przy zapisie pliku htaccess zwracamy uwagę na kodowanie tekstu. Pliki instrukcji w kodowaniu innymi niż UTF-8 nie będą działać.

Użyć htaccess czy nie?

Z czego skorzystać, jeśli mamy dostęp zarówno do htaccess, ale i do np. wtyczek WordPressa czy opcji w panelu innego CMS? To zależy.

Co do zasady, jeśli mamy domyślne opcje systemowe, np. w panelu oprogramowania sklepu, czy hostingu to z nich korzystamy. Im prościej, tym lepiej.

Sprawa wygląda jednak inaczej, gdy mamy wybierać między modyfikacją htaccess a doinstalowaniem jakiegoś modułu czy wtyczki specjalnie do wykonania danej czynności.

Wtedy zastanówmy się, czy to, co chcemy zrobić jest jednorazowe (np. ustawienie strony błędu 404), czy raczej powtarzalne (np. przekierowanie usuniętej strony).

Przy czynnościach „raz na zawsze” modyfikacja htaccess będzie zwykle lepsza. Nie obciąży naszej strony dodatkowym oprogramowaniem, które może ją spowalniać czy generować błędy.

Przy czynnościach powtarzalnych, lepiej będzie jednak skorzystać ze sprawdzonej wtyczki czy modułu. Po prostu będzie to dla nas szybsze, wygodniejsze i zminimalizuje ryzyko błędów. Ponownie: im prościej, tym lepiej – nie utrudniajmy sobie pracy.

Htaccess nie działa – najczęstsze błędy

Jeśli po zapisaniu pliku htaccess nic się nie zmieniło, to naprawdopodobniej wystąpił jeden z poniższych błędów:

1. Literówka w nazwie pliku – np. brak kropki na początku, zwykła pomyłka w nazwie lub wgranie pliku w złym formacie, przez co serwer rozpoznaje jego nazwę jako „.htaccess.txt” (plik ma nie mieć rozszerzenia).
2. Błąd w składni pliku – gdzieś zabrakło jakiegoś znaku, coś poszło w złej kolejności… tutaj pomoże htaccess tester, który zweryfikuje poprawność składni.
3. Kilka plików htaccess – możliwe, że serwer używa kilku plików htaccess, przez co Twój właśnie dodany jest ignorowany w danym katalogu.
4. Kolejność dyrektyw ma znaczenie – htaccess wykonuje instrukcję hierarchicznie, z góry na dół. Dodanie paru zasad na początku już wypełnionego pliku może anulować niektóre z poniższych dyrektyw.
5. Złe kodowanie pliku – jeśli plik był tworzony na komputerze, to mógł zostać zapisany w złym kodowaniu, np. ANSI. Właściwe to UTF-8.

Jeżeli żaden z powyższych błędów nie okazał się problemem, to źródłem niedziałającego htaccess może być sam serwer.

Jeśli w pliku httpd.conf opcja AllowOverride będzie ustawiona na „None”, to pliki htaccess nie będą działać. Domyślny plik konfiguracji będzie bowiem wtedy ustawiony tak, by nic nie mogło zmienić działania serwera (co robi .htaccess).

W pliku httpd.conf powinna znajdować się dyrektywa:

AllowOverride All

Ile przekierowań może być w pliku htaccess?

Plik htaccess nie ma limitu ani przekierowań, ani innych dyrektyw, które mogą się w nim znaleźć. W sieci można znaleźć testy liczby przekierowań, z których wynika, że nawet 100 tysięcy przekierowań w pliku nie wpływa znacząco na czas ładowania strony.

Liczba przekierowań w htaccess odbija się jednak na TTFB (Time to first byte), czyli czasie potrzebnym na odpowiedź serwera. Wspomniany testy wykazują, że każdy 1000 przekierowań dodaje w tej kwestii około 3-7 ms.

Trzeba jednak zaznaczyć, że ograniczenia co do plików htaccess mogą być wprowadzane oddolnie przez firmy hostingowe. Choćby po to, żeby uniknąć błędów.

Podsumowując

Htaccess to rozwiązanie megaużyteczne. To, co w nim zdefiniujemy będzie dotyczyć wszystkich zapytań jakie trafią do strony. Możemy zarządzać w nim ruchem na poziomie katalogów. No i wprowadzone w nim zmiany działają natychmiast, bez żadnych restartów.

Z odczytu pliku przy każdym zapytaniu jakie trafia do serwera wynikają naturalnie i wady, przede wszystkim wolniejsze działanie. W praktyce jednak ma to znaczenie tylko dla serwisów bardzo dużych, o ruchu liczonym w milionach wizyt.