Plik robots.txt — to plik tekstowy znajdujący się w katalogu głównym strony, który określa zasady dostępu dla robotów wyszukiwarek do poszczególnych adresów URL, folderów i typów stron. Jego głównym zadaniem nie jest «ukrycie strony przed Google», lecz zarządzanie crawlingiem: podpowiedzenie robotowi, co warto skanować, a na co nie trzeba marnować zasobów serwera i crawl budgetu.

Skanowanie — to moment, w którym bot pobiera stronę. Indeksowanie — to etap, na którym strona po przetworzeniu może trafić do bazy wyszukiwarki. Noindex — to osobna dyrektywa, która mówi Google, aby nie dodawać dokumentu do wyników wyszukiwania. Właśnie dlatego robots.txt nie powinien być przedstawiany jako uniwersalny sposób usunięcia adresu URL z wyników: dla Google jest to przede wszystkim narzędzie do zarządzania crawlowaniem.

Jeśli strona nie powinna już pojawiać się w wyszukiwarce, sam robots.txt nie wystarczy. Tutaj działa inny podział ról: do kontroli dostępu — robots.txt, do deindeksacji — noindex albo X-Robots-Tag , a dla zamkniętych sekcji — autoryzacja lub dostęp chroniony hasłem. Gdy te zadania są mieszane, strona albo niepotrzebnie oddaje do crawlowania techniczne URL-e, albo przypadkowo blokuje ważne podstrony.

W praktyce prawidłowo skonfigurowany robots.txt wpływa nie tylko na techniczną czystość serwisu, ale też na skuteczność pozycjonowania strony . Gdy wyszukiwarka nie traci crawl budgetu na strony techniczne, filtry, parametryczne URL-e czy pomocnicze sekcje, szybciej dociera do treści, które rzeczywiście mają wartość SEO.

Materiał opiera się na oficjalnej dokumentacji Google o robots.txt , specyfikacji technicznej tego, jak Google interpretuje robots.txt , zaleceniach dotyczących noindex oraz materiałach WordPress Developer Resources .

Czym jest robots txt i kiedy naprawdę jest potrzebny

Robots txt — to plik reguł dla botów, dostępny pod adresem /robots.txt , który informuje, które części serwisu można skanować, a których lepiej nie crawlowć. W przypadku małej strony z kilkudziesięcioma podstronami może być bardzo prosty. Dla sklepu internetowego, projektu contentowego, strony na WordPressie, dużego serwisu firmowego czy struktury wielojęzycznej plik robots.txt staje się już częścią technicznego fundamentu witryny.

Najwięcej korzyści robots txt seo daje tam, gdzie w serwisie są filtry, strony wyszukiwania wewnętrznego, sortowania, parametry w URL-ach, katalogi techniczne, sekcje testowe, skrypty techniczne lub inne obszary bez wartości dla wyszukiwarki. W sklepach widać to szczególnie wyraźnie: jeśli nie kontrolować crawlowania, bot może bez końca przechodzić po kombinacjach filtrów i parametrów zamiast szybciej docierać do kategorii, kart produktów i stron contentowych.

Jednocześnie robots.txt nie należy traktować jako narzędzia ochrony prywatnych danych. Jeśli dokument jest naprawdę wrażliwy, nie wystarczy po prostu «zablokować go w robots.txt» — trzeba usunąć go z publicznego dostępu, zabezpieczyć autoryzacją albo wdrożyć ochronę po stronie serwera. Sam plik publikuje jedynie regułę dla botów, a nie tworzy realnej bariery dla użytkowników czy parserów.

Skanowanie, indeksowanie i noindex — to nie to samo

Jednym z najczęstszych błędów w starszych materiałach SEO jest mieszanie skanowania z indeksowaniem. Jeśli strona jest zablokowana w robots.txt, oznacza to, że Googlebot może na nią nie wejść i nie zobaczyć jej treści. Ale sam adres URL nadal może pojawić się w wyszukiwarce, jeśli prowadzą do niego linki z innych stron albo zewnętrznych źródeł.

Z noindex działa to inaczej. Żeby Google zobaczył tę dyrektywę, strona musi pozostać dostępna do crawlowania. Typowy błąd to jednoczesne ustawienie Disallow w robots.txt i oczekiwanie, że bot odczyta noindex wewnątrz strony. Nie odczyta, bo dostęp został już zablokowany.

Jeśli chcesz lepiej zrozumieć samą logikę trafiania stron do wyników wyszukiwania, zobacz osobny materiał o indeksowaniu strony w wyszukiwarkach . W praktyce często myli się tu samą przyczynę problemu: wydaje się, że strona «nie indeksuje się», chociaż w rzeczywistości została po prostu nieprawidłowo otwarta albo zamknięta dla crawlowania.

Gdzie powinien znajdować się plik robots.txt i jakie zasady są obowiązkowe

W robots txt jest kilka podstawowych wymagań, których nie warto naruszać. Plik musi nazywać się dokładnie robots.txt , być zwykłym dokumentem tekstowym w kodowaniu UTF-8 i znajdować się w katalogu głównym hosta, którego dotyczą reguły. Jeśli umieści się go w podfolderze, robot wyszukiwarki nie potraktuje go jako robots.txt.

Jest też techniczny niuans, który często ginie w ogólnych wyjaśnieniach. Robots.txt działa nie «na całą stronę jako całość», lecz w granicach konkretnego protokołu, hosta i portu. To znaczy, że reguły dla https://example.com/robots.txt nie stają się automatycznie regułami dla https://www.example.com/ ani dla subdomen. Jeśli zasób jest rozdzielony na kilka hostów, trzeba to uwzględnić już na etapie tworzenia strony i budowy jej struktury.

Kolejny wymowny moment: gdy robots.txt rozrasta się do setek wierszy i stale obrasta wyjątkami, problem często nie tkwi już w samym pliku. Zwykle oznacza to, że w serwisie jest zbyt wiele chaotycznych parametrów, technicznych URL-i lub pomocniczych stron, które lepiej uporządkować na poziomie architektury niż łatać nieskończonymi regułami.

User-agent, Disallow, Allow i Sitemap — co oznaczają podstawowe dyrektywy

User-agent pokazuje, dla którego dokładnie robota działa dany blok reguł. Od tej dyrektywy zaczyna się cała logika zarządzania dostępem w robots.txt. Jeśli podasz User-agent: * , reguła będzie dotyczyć wszystkich botów, które obsługują Robots Exclusion Protocol.

Disallow — to podstawowa dyrektywa, którą ogranicza się skanowanie poszczególnych sekcji, folderów albo typów URL-i. Często zamyka się nią wyszukiwanie wewnętrzne, koszyk, katalogi techniczne, foldery testowe albo strony o niskiej wartości SEO.

Allow stosuje się jako wyjątek, gdy trzeba odblokować konkretny plik lub podścieżkę wewnątrz już zamkniętego katalogu. Zdarza się to rzadziej, ale bywa przydatne, gdy cały katalog nie powinien być skanowany, a pojedynczy plik w nim ma pozostać dostępny dla bota.

Sitemap nie zabrania ani nie zezwala na crawling, a jedynie podpowiada, gdzie znajduje się mapa witryny. Właśnie dlatego dodawanie sitemap do robots txt to dobra praktyka: nie zastępuje to zgłoszenia mapy w Search Console, ale daje jeszcze jeden punkt odkrycia sitemap.

Podstawowy przykład może wyglądać tak:

User-agent: *
Disallow: /search
Disallow: /cart/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xml

Takie zasady robots txt lepiej utrzymywać krótkie i zrozumiałe. Im bardziej rozbudowany plik, tym łatwiej przypadkowo zamknąć nie ten folder, nie ten wzorzec URL albo nawet zasoby potrzebne do renderowania.

Jaka składnia robots txt naprawdę ma znaczenie

Składnia robots txt nie wygląda na skomplikowaną, ale to właśnie na drobiazgach pojawia się większość błędów. Ścieżki są określane od katalogu głównego strony, plik jest wrażliwy na strukturę URL, a niewalidne lub zbędne linie Google po prostu ignoruje. Przez to nieprawidłowy robots.txt nie zawsze «psuje się całkowicie» — czasem działa częściowo, a częściowo nie, dlatego błędy mogą długo pozostawać niezauważone.

Jest też ważna kwestia praktyczna: Google nie obsługuje części dyrektyw, które wciąż przewijają się w starych artykułach i szablonach. W szczególności noindex , nofollow i crawl-delay nie należą do wspieranych reguł robots.txt dla Google. Dlatego jeśli w pliku nadal są takie wpisy, nie powinny one stanowić podstawy współczesnej optymalizacji technicznej.

Robots txt dla WordPressa — co warto sprawdzić osobno

Robots txt dla WordPressa — to osobny temat, bo na tej platformie plik może być udostępniany nie tylko jako fizyczny dokument na serwerze, ale też dynamicznie. Poza tym WordPress ma już wbudowaną obsługę XML sitemap. To wygodne, ale końcowy efekt i tak trzeba sprawdzić.

W WordPressie problem często nie leży w samym pliku, lecz w tym, że jego zachowanie zmieniają wtyczki, motyw albo logika własna projektu. Właściciel strony może być przekonany, że robots.txt jest skonfigurowany od dawna i poprawnie, ale faktyczna treść pod adresem /robots.txt jest już inna. Właśnie dlatego kontrola robots.txt w WordPressie nie jest formalnością, tylko normalną częścią technicznego audytu strony .

Dla sklepów internetowych na WordPressie lub WooCommerce ma to jeszcze większe znaczenie: tam szybko gromadzą się parametryczne URL-e, filtry, strony sortowania, koszyk, checkout i inne obszary, których nie warto bez kontroli oddawać do crawlowania.

Jak sprawdzić robots txt w Google Search Console

Lepiej nie sprawdzać robots.txt w oderwaniu od reszty, ale razem z Search Console, URL Inspection, Page Indexing i Crawl Stats. Sam plik może być formalnie poprawny, ale to jeszcze nie znaczy, że działa na korzyść serwisu.

Sam robots txt report w Search Console pomaga zobaczyć aktualną wersję pliku i szybciej odświeżyć cache po zmianach. Dla pojedynczych URL-i przydaje się Google Search Console z URL Inspection: wtedy widać, czy robots.txt nie blokuje strony, która w rzeczywistości powinna być skanowana. Dla szerszego obrazu warto patrzeć na Page Indexing i Crawl Stats — właśnie tam widać, gdzie serwis realnie traci crawling.

Jeśli stron jest dużo, sprawdzanie robots.txt «na oko» nie wystarczy. Gdy plik zmienia się razem ze strukturą katalogów, migracją, nowymi wersjami językowymi albo redesignem, trzeba go weryfikować w ramach audytu SEO strony , a nie tylko według zasady «plik się otwiera, więc wszystko jest dobrze».

Typowe błędy w robots.txt

Najczęściej problemy pojawiają się nie przez skomplikowaną składnię, lecz przez błędne rozumienie tego, do czego ten plik w ogóle służy.

  • Zamykają stronę w robots.txt i czekają, aż zniknie z wyszukiwarki. To nie jest gwarantowany scenariusz. Jeśli URL jest już znany Google, nadal może pojawiać się w wynikach nawet bez pełnej treści.

  • Blokują strony, które powinny być skanowane. Przez to wyszukiwarka nie widzi ważnej treści, a problem potem wygląda jak «powolne indeksowanie».

  • Zamykają zasoby potrzebne do renderowania. Jeśli przypadkowo ograniczyć ważne pliki CSS albo JavaScript, strona może otwierać się w przeglądarce normalnie, ale dla Google jej render będzie niepełny.

  • Trzymają w pliku przestarzałe albo niewspierane reguły. Nie dają one żadnej korzyści, ale tworzą fałszywe poczucie kontroli.

  • Publikują plik nie tam, gdzie trzeba. Robots.txt w podfolderze, w niewłaściwym kodowaniu albo z błędem w nazwie to w praktyce brak robots.txt.

  • Traktują robots.txt jako ochronę prywatnych sekcji. Dla zamkniętych informacji potrzebna jest kontrola dostępu, a nie tylko rekomendacja dla botów.

Jest też jeszcze jeden bardzo życiowy scenariusz: na domenie stagingowej albo testowej kopii strony robots.txt był skonfigurowany poprawnie, a przy wdrożeniu albo zapomniano go zmienić, albo przypadkowo przeniesiono go na domenę główną. Takie błędy zdarzają się znacznie częściej, niż się wydaje, zwłaszcza po redesignie albo migracji.

Warto też pamiętać o dostępności samego pliku. Jeśli robots.txt zwraca błędy serwera, to również wpływa na crawling. Dlatego podczas redesignu, migracji, zmiany CDN albo konfiguracji serwera robots.txt trzeba sprawdzać tak samo uważnie jak sitemap, przekierowania i canonical.

Wnioski

Prawidłowo skonfigurowany plik robots txt nie jest dekoracyjnym elementem strony ani sposobem, by «ukryć wszystko zbędne przed Google». To robocze narzędzie do zarządzania crawlingiem, które pomaga usunąć szum, skierować robota do ważnych sekcji i nie marnować crawlowania na adresy URL bez wartości.

W praktyce wszystko sprowadza się do prostego rozdzielenia ról. Robots.txt jest potrzebny do zarządzania crawlowaniem. Jeśli stronę trzeba usunąć z wyszukiwarki, trzeba patrzeć już w stronę noindex , X-Robots-Tag albo serwerowych ograniczeń dostępu. Gdy te zadania nie są ze sobą mylone, techniczna logika SEO strony staje się znacznie czystsza.

Jeśli natomiast na stronie są już wątpliwości, które URL-e należy blokować, co powinno pozostać dostępne do crawlowania, gdzie konfliktują ze sobą robots.txt, meta robots, canonical i sitemap, takie kwestie lepiej rozwiązywać nie punktowymi poprawkami, lecz przez pełny techniczny przegląd struktury serwisu.