Plik robots.txt, czasem wpisywany potocznie jako robot txt, porządkuje to, jak roboty wyszukiwarek przechodzą przez serwis. W praktyce pomaga ograniczyć crawlowanie zbędnych adresów, odciążyć serwer i lepiej skupić uwagę bota na treściach, które naprawdę mają pracować na widoczność. Poniżej pokazuję, jak ten plik działa, co warto w nim umieścić, czego nie blokować i kiedy lepiej sięgnąć po inne rozwiązanie niż sama blokada crawl.
Najważniejsze rzeczy, które warto zapamiętać o pliku robots.txt
- Plik musi leżeć w katalogu głównym hosta i działa tylko dla tej jednej kombinacji domeny, protokołu i portu.
- Jego zadaniem jest kontrola crawlowania, a nie bezpieczne ukrywanie treści przed wyszukiwarką.
- Jeśli chcesz usunąć stronę z wyników, zwykle potrzebujesz noindex albo ochrony hasłem, nie samego robots.txt.
- Nie blokuj zasobów CSS i JS, jeśli są potrzebne do poprawnego renderowania strony.
- W serwisach turystycznych najczęściej blokuje się filtry, wyniki wewnętrznego wyszukiwania i zaplecze techniczne.
- Dobrze napisane reguły oszczędzają crawl budget, czyli limit uwagi bota wobec Twojego serwisu.
Co naprawdę robi plik robots.txt i kiedy ma znaczenie
Ja traktuję ten plik jak regulator ruchu, a nie jak sejf. Jego podstawowa rola polega na tym, by powiedzieć robotom wyszukiwarek, które adresy mogą odwiedzać, a które lepiej pominąć. To przydatne zwłaszcza wtedy, gdy serwis generuje dużo podobnych URL-i, ma katalog techniczny, panel administracyjny albo mocno rozbudowane filtry.
Ważne jest jedno rozróżnienie: blokada crawl to nie to samo co blokada indeksowania. Strona zablokowana w robots.txt nadal może pojawić się w wynikach wyszukiwania jako sam adres, tylko bez sensownego opisu, jeśli bot zna ją z innych źródeł. Dlatego ten plik dobrze działa do porządkowania dostępu, ale słabo sprawdza się jako narzędzie do „ukrywania” treści.
W praktyce robots.txt najczęściej wykorzystuję do odciążenia serwisu i ograniczenia wejść w miejsca, które nie mają wartości SEO. Gdy to rozumiesz, łatwiej przejść do samej składni i zasad pisania reguł.
Jak zbudować poprawny plik krok po kroku
Plik jest prosty, ale łatwo go zepsuć drobnym błędem. Musi mieć nazwę robots.txt, być zapisany jako zwykły plik tekstowy UTF-8 i leżeć w katalogu głównym hosta, którego dotyczy. Jeden serwis, jeden host, jeden plik.
Najczęściej spotkasz w nim cztery podstawowe elementy: User-agent, Disallow, Allow i Sitemap. Pierwszy wskazuje, do którego robota kierujesz regułę, drugi blokuje dostęp, trzeci dopuszcza wyjątek w obrębie wcześniej zablokowanej ścieżki, a czwarty podaje mapę witryny. Komentarze zaczynają się od znaku #, a reguły są czułe na wielkość liter.
User-agent: *
Disallow: /panel/
Disallow: /szukaj/
Allow: /szukaj/oferty/Warto też pamiętać o znakach specjalnych. W praktyce przydają się przede wszystkim *, czyli dowolny ciąg znaków, oraz $, czyli koniec adresu. To pozwala precyzyjniej opisać wzorce URL-i, ale wymaga ostrożności, bo zbyt szeroka reguła potrafi odciąć więcej niż planujesz. Google interpretuje konflikty na zasadzie bardziej szczegółowej, mniej restrykcyjnej reguły, więc szczegóły składni naprawdę mają znaczenie.
Jeśli plik ma działać poprawnie, nie wystarczy go napisać. Trzeba jeszcze sprawdzić, czy nie blokuje ważnych sekcji i czy serwer udostępnia go bez błędów, najlepiej zanim wdrożysz go na produkcję.
Czego blokować, a czego lepiej nie ruszać
W SEO technicznym największy sens ma odcinanie rzeczy, które generują szum, a nie wartości. W mojej praktyce na liście do blokady najczęściej lądują panele administracyjne, wewnętrzne wyszukiwarki, strony z parametrami sortowania, duplikaty filtrowania i techniczne katalogi, których użytkownik nie powinien znaleźć z poziomu Google.
Nie blokuję natomiast stron, które mają budować widoczność i pomagać użytkownikowi wejść w temat. Jeśli katalog, landing lub artykuł ma pracować na ruch organiczny, robot musi mieć do niego dostęp. To samo dotyczy plików CSS i JavaScript, jeśli są potrzebne do zrozumienia układu strony, treści lub interakcji. Zablokowanie zasobów niepotrzebnych jest rozsądne, ale zablokowanie tych kluczowych utrudnia wyszukiwarce ocenę jakości strony.
| Co zwykle blokuję | Dlaczego | Na co uważam |
|---|---|---|
| Panel administracyjny i zaplecze | Nie mają wartości dla użytkownika i nie powinny marnować crawl budget | Nie mylić blokady crawla z ochroną dostępu |
| Wewnętrzne wyniki wyszukiwania | Często tworzą nieskończoną liczbę podobnych URL-i | Nie blokować stron, które pełnią rolę landing page |
| Parametry filtrowania i sortowania | Produkują duplikaty i rozpraszają roboty | Upewnić się, że nie blokujesz ważnych wersji kategorii |
| Środowisko testowe | Nie powinno trafiać do wyników wyszukiwania | Lepiej połączyć blokadę z inną formą zabezpieczenia |
| Zasoby techniczne niepotrzebne do renderowania | Zmniejszają zbędny ruch | Nie blokować CSS i JS wymaganych do oceny strony |
Jeśli masz wątpliwość, czy dana ścieżka powinna być blokowana, zadaję sobie proste pytanie: czy użytkownik powinien ją znaleźć w Google i czy bot musi ją zobaczyć, żeby zrozumieć stronę. To prowadzi naturalnie do specyfiki portali turystycznych, gdzie granica między treścią użyteczną a technicznym szumem bywa wyjątkowo cienka.
Jak wykorzystać go w portalu turystycznym
W serwisach takich jak Travelcamp.pl temat jest bardzo praktyczny, bo turystyka lubi rozbudowane systemy filtrów, ofert, kalendarzy i wersji lokalnych. Właśnie tu dobrze ustawiony robots.txt potrafi zrobić dużą różnicę: ogranicza crawl stron wynikowych, które nie wnoszą nic nowego, a jednocześnie zostawia dostęp do treści eksperckich, przewodników, landing page’y destynacyjnych i stron ofertowych.
Najczęściej blokowałbym w takim serwisie adresy związane z wewnętrznym wyszukiwaniem, parametry typu sortowanie po cenie czy terminie oraz duplikaty tworzone przez kombinacje filtrów. To szczególnie ważne przy listingach noclegów, atrakcji i usług turystycznych, gdzie ten sam zasób można pokazać na wiele sposobów. Jeśli każda kombinacja filtrów tworzy osobny URL, robot zaczyna kręcić się w kółko zamiast przechodzić do treści, które mają szansę zdobyć ruch.
Warto też rozdzielić logikę dla różnych części serwisu. Inaczej traktuję blog redakcyjny, inaczej bazę ofert, a jeszcze inaczej zaplecze CMS-a czy panel partnera. Jeśli booking engine działa na osobnym subdomenie, powinien mieć własny plik i własną politykę crawl, bo reguły nie przenoszą się automatycznie między hostami.
Na takich serwisach dobrze widać, że robots.txt nie jest dodatkiem „od SEO”, tylko elementem architektury informacji. Gdy to ustawisz porządnie, łatwiej potem porównać go z noindex i nagłówkami HTTP, które rozwiązują inny problem.
Kiedy robots.txt przegrywa z meta robots i X-Robots-Tag
Tu najczęściej pojawia się nieporozumienie. Robots.txt steruje tym, czy bot ma wchodzić na stronę, a meta robots oraz X-Robots-Tag mówią, co zrobić z treścią po wejściu. To dwa różne poziomy kontroli i w praktyce nie zamieniają się miejscami.
| Rozwiązanie | Co kontroluje | Kiedy używam | Ograniczenie |
|---|---|---|---|
| robots.txt | Crawling | Gdy chcę ograniczyć ruch robotów i pominąć techniczne lub duplikujące się adresy | Nie gwarantuje usunięcia z indeksu |
| meta robots | Indeksowanie strony | Gdy strona ma być dostępna dla bota, ale nie ma trafiać do wyników | Bot musi mieć dostęp do strony, by odczytać znacznik |
| X-Robots-Tag | Indeksowanie plików i odpowiedzi serwera | Gdy nie chcę edytować HTML albo dotyczy to PDF, obrazów czy innych zasobów | Wymaga konfiguracji po stronie serwera |
W praktyce najprościej pamiętać tak: jeśli coś ma przestać być odwiedzane, myśl o robots.txt; jeśli coś ma być odwiedzane, ale nie indeksowane, użyj noindex albo X-Robots-Tag. To rozróżnienie oszczędza sporo błędów, zwłaszcza gdy ktoś próbuje „ukryć” stronę samą blokadą crawl. Gdy te różnice są jasne, łatwiej wyłapać najczęstsze wpadki wdrożeniowe.
Najczęstsze błędy, które psują crawl
Najbardziej kosztowny błąd, jaki widuję, to przypadkowe zablokowanie całej witryny jedną regułą typu Disallow: /. Drugi klasyk to przekonanie, że robots.txt sam z siebie usuwa stronę z indeksu. Trzeci to blokowanie zasobów, bez których wyszukiwarka nie potrafi poprawnie wyrenderować strony.
- Blokada ważnych katalogów, bo reguła była zbyt szeroka.
- Zapomnienie, że plik działa osobno dla każdego hosta i subdomeny.
- Wrzucenie reguł do niewłaściwego miejsca zamiast do katalogu głównego hosta.
- Brak kodowania UTF-8, przez co część znaków może zostać zignorowana.
- Liczenie na to, że plik zadziała jak zabezpieczenie prywatnych danych.
- Nieprzetestowanie zmian po wdrożeniu, kiedy błąd jest już widoczny dla crawlerów.
Z mojej perspektywy najlepiej działa prosty rytm pracy: najpierw spis reguł, potem test w narzędziu do sprawdzania crawl, a dopiero później publikacja. Dobrze jest też od razu sprawdzić, czy najważniejsze adresy nadal mają dostęp do bota i czy nie zniknęły zasoby renderujące. Po takich kontrolach zostają już tylko szybkie sprawdzenia, które chronią przed przypadkowym odcięciem ruchu organicznego.
Co jeszcze warto sprawdzić po wdrożeniu
Po publikacji zawsze patrzę na ten plik jak na element większej układanki. Sam w sobie może być poprawny, a mimo to psuć efekt końcowy, jeśli mapa witryny prowadzi do stron, które właśnie zablokowano, albo jeśli ważna sekcja została odcięta przez zbyt agresywne reguły. Dlatego sprawdzam nie tylko składnię, ale też zgodność z architekturą serwisu i z tym, co naprawdę ma zdobywać ruch.
Jeżeli prowadzisz portal turystyczny, najbardziej opłaca się zostawić w spokoju treści eksperckie, przewodniki, poradniki i strony ofertowe, a porządkować wszystko, co techniczne, powtarzalne albo generowane przez filtry. Taki układ zwykle daje najlepszy balans między crawl budgetem a pełnym pokryciem ważnych podstron.
Na końcu zostaje jedna zasada, którą stosuję najchętniej: robots.txt ma pomagać wyszukiwarce szybciej dojść do sensu strony, a nie maskować problemy z jej budową. Jeśli dzięki niemu roboty trafiają w dobre miejsca, a nie błądzą po duplikatach i panelach, plik robi dokładnie to, do czego został stworzony.
