robots.txt w WordPress w 2026 roku (co naprawdę powinno się w nim znaleźć)

Dobry robots.txt w WordPressie ma jakieś pięć linijek. Zablokuj /wp-admin/, dopuść admin-ajax.php, wskaż robotom mapę witryny i na tym poprzestań — rozdęte, czterdziestolinijkowe listy blokad, które znajdziesz na forach, w większości psują renderowanie albo nie robią nic. Cały plik:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Podmień domenę, a jeśli korzystasz z wtyczki SEO, która przejmuje mapy witryny, skieruj linię Sitemap na indeks tej wtyczki. To wszystko. Jeśli Twój plik jest dłuższy, dodatkowe linijki prawdopodobnie coś Cię kosztują.

WordPress już go generuje — dopóki nie utworzysz prawdziwego pliku

WordPress dostarcza wirtualny robots.txt. Kiedy przychodzi żądanie /robots.txt, a w katalogu głównym nie ma faktycznego pliku, WordPress przechwytuje je i wypisuje odpowiedź z pamięci. Nic nie ląduje na dysku. Domyślne wyjście to powyższy blok wp-admin plus linia Sitemap: dla wp-sitemap.xml, którą rdzeń wypisuje od WordPressa 5.5.

Dwie rzeczy potrafią to zmienić. Jeśli w Ustawienia → Czytanie → Proś wyszukiwarki o nieindeksowanie tej witryny jest zaznaczony haczyk, WordPress zastępuje całość przez Disallow: /, co blokuje wszystko. To pole wyboru jest najczęstszą pojedynczą przyczyną zniknięcia witryny z wyszukiwarki po starcie. Po drugie, wtyczki i motywy mogą modyfikować wirtualne wyjście przez filtr robots_txt — tak właśnie wtyczki SEO wstrzykują własne linie z mapą witryny i własne reguły.

A teraz część, która zjada ludziom popołudnia. Fizyczny plik robots.txt w katalogu głównym po cichu przebija to wszystko. Serwer znajduje prawdziwy plik na dysku, podaje go, a WordPress w ogóle się nie ładuje. Wirtualny generator nie startuje. Filtr robots_txt się nie odpala. Edytor robots.txt w Twojej wtyczce SEO może dalej pokazywać ładny interfejs z właściwymi regułami i nic z tego nie dociera do robota.

Gdzie leżą reguły	Edytowalne w kokpicie WordPressa	Wygrywa przy realnym żądaniu
Wirtualne (brak pliku na dysku)	Tak, przez filtr robots_txt lub wtyczkę	Tylko gdy nie ma fizycznego pliku
Fizyczny plik w katalogu głównym	Tylko jeśli wtyczka zapisuje na dysk	Zawsze

Zanim więc zaczniesz cokolwiek debugować: otwórz w przeglądarce https://twojastrona.pl/robots.txt, a potem połącz się przez SFTP albo menedżer plików hostingu i sprawdź, czy prawdziwy robots.txt nie leży obok wp-config.php i .htaccess. Jeśli leży, to on jest Twoim robots.txt. Edytuj go na miejscu albo skasuj i oddaj pole WordPressowi — ale wybierz jedno. Utrzymywanie obu naraz to prosta droga do nieaktualnego adresu mapy witryny, którego nikt nie umie znaleźć.

Dlaczego /wp-admin/ jest zablokowany, a admin-ajax.php dopuszczony

/wp-admin/ to kokpit. Te adresy są bezużyteczne w wynikach wyszukiwania, a ich skanowanie przepala budżet indeksowania na stronach, które i tak przekierowują do ekranu logowania. Blokowanie tego katalogu nie budzi kontrowersji.

admin-ajax.php leży w tym samym katalogu, ale nie jest stroną kokpitu. To punkt końcowy, z którego wtyczki i motywy korzystają przy obsłudze żądań AJAX na froncie — przyciski „pokaż więcej”, filtrowane siatki produktów, kalkulatory, formularze. Jeśli robot nie może go pobrać, nie zobaczy treści ładowanych przez te mechanizmy, a Google wyrenderuje stronę tak, jak zobaczyłby ją odwiedzający z zepsutą funkcją.

To, czy Google faktycznie musi pobierać admin-ajax.php akurat na Twojej witrynie, zależy od tego, czy Twój front z niego korzysta. Uczciwa odpowiedź: na wielu nowoczesnych stronach nie ma to żadnego znaczenia, bo motyw używa REST API pod /wp-json/. Linia Allow to tania polisa na wypadek realnej awarii, a nie czynnik rankingowy. Zostaw ją, bo nic nie kosztuje.

Nie blokuj /wp-content/ ani /wp-includes/

To najgorsza porada dotycząca robots.txt, jaka wciąż krąży po sieci, i pochodzi z czasów, gdy Google nie renderowało stron.

W /wp-content/ siedzą Twoje motywy, wtyczki i pliki wysłane na serwer — arkusze stylów, skrypty i obrazy, dzięki którym strony wyglądają jak strony. /wp-includes/ zawiera JavaScript rdzenia, od którego zależą wtyczki. Google renderuje Twoje strony w przeglądarce bezgłowej, zanim je oceni. Zablokuj te katalogi, a mechanizm renderujący dostanie stronę bez CSS i bez obrazów. Google oceni wtedy nieostylowaną ścianę tekstu z rozjechanym układem, co wpływa na to, jak rozumie Twoje treści i jak ocenia użyteczność na urządzeniach mobilnych.

Jeśli odziedziczyłeś plik z tymi linijkami, usuń je:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Szkody możesz potwierdzić sam w narzędziu Sprawdzenie adresu URL w Google Search Console. Uruchom test na żywo na dowolnej podstronie, obejrzyj zrzut ekranu z renderowania i sprawdź listę zasobów strony pod kątem zablokowanych elementów. Jeśli Twój CSS widnieje jako zablokowany, to jest właśnie przyczyna.

Dyrektywa Sitemap

Jedna linijka, bezwzględny adres URL, i może stać w dowolnym miejscu pliku — nie jest przypisana do żadnej grupy User-agent.

Sitemap: https://example.com/wp-sitemap.xml

Podaj adres, który faktycznie się otwiera. Rdzeń WordPressa serwuje wp-sitemap.xml. Większość wtyczek SEO wyłącza mapy rdzenia i podaje własny indeks pod innym adresem, zwykle sitemap_index.xml. Otwórz swój adres w przeglądarce, zanim go zapiszesz — linia Sitemap wskazująca na 404 jest gorsza niż jej brak, bo w audycie wygląda poprawnie.

Wypisanie kilku map witryny jest w porządku, po jednej na linię. Zgłaszanie map w Search Console nadal warto robić osobno; dyrektywa w robots.txt to sposób, w jaki znajdują je roboty, które nigdy nie zobaczą Twojego konta w Search Console.

robots.txt to nie noindex i nie zabezpieczenie

Te dwa nieporozumienia odpowiadają za większość szkód wyrządzonych przez robots.txt.

Zablokowanie adresu nie usuwa go z Google. Robots.txt rządzi skanowaniem. Jeśli inna witryna linkuje do zablokowanego adresu, Google może zaindeksować sam adres — dostajesz wynik z gołym URL-em i adnotacją, że brak informacji. Jest też paskudniejsza pułapka: jeśli strona ma już metatag noindex, a Ty dołożysz jej blokadę w robots.txt, Google nie może jej przeskanować, nie zobaczy noindex i strona potrafi zostać w indeksie w nieskończoność. Żeby usunąć stronę, dopuść skanowanie i podaj metatag robots z noindex w sekcji head albo nagłówek HTTP X-Robots-Tag. Google przestało obsługiwać dyrektywy noindex wewnątrz robots.txt w 2019 roku.

Zablokowanie ścieżki jej nie chroni. Twój robots.txt jest z definicji publiczny. Wypisanie /prywatne-pliki-klientow/ mówi każdemu odwiedzającemu i każdemu skanerowi dokładnie, gdzie szukać, a stosowanie się do reguł jest dobrowolne — Google je respektuje, wrogie boty nie. Cokolwiek wymaga ochrony, wymaga uwierzytelniania, ograniczenia po IP albo reguł serwera w .htaccess, a nie linijki w pliku tekstowym reklamującym cel.

Reguły warte dodania i reguły warte pominięcia

Dwa uzupełnienia są naprawdę przydatne na wielu witrynach. Zablokowanie ścieżki wyników wyszukiwania powstrzymuje roboty przed generowaniem nieskończonej liczby bezwartościowych adresów z Twojej wyszukiwarki wewnętrznej. Zablokowanie ścieżki koszyka lub zamówienia w WooCommerce trzyma adresy z parametrami sesji poza skanowaniem.

Disallow: /?s=
Disallow: /search/

Te odpuść:

• Crawl-delay — Google całkowicie to ignoruje. Jeśli masz realny problem z obciążeniem serwera, użyj sterowania częstotliwością skanowania w Search Console.
• Blokowanie /feed/ czy /trackback/ — to nieszkodliwe adresy, a kanały są przydatne.
• Długie listy nazw pojedynczych botów — większość botów, które ludzie próbują blokować, i tak nie przedstawia się uczciwie.
• Blokowanie /wp-json/ — to może być właśnie to, czego Twój motyw używa do wyświetlania treści.

Zbuduj plik generatorem robots.txt dla WordPressa, który tworzy minimalną poprawną wersję i pozwala dodać reguły dla wyszukiwania i sklepu bez ręcznego dłubania w składni.

Po zmianie pliku

Wczytaj bezpośrednio https://twojastrona.pl/robots.txt i potwierdź, że podane bajty to dokładnie to, czego oczekujesz — a nie to, co pokazuje edytor wtyczki. Potem uruchom w Search Console test na żywo dla zwykłej podstrony i sprawdź, czy żaden zasób CSS ani JavaScript nie wraca jako zablokowany. Google trzyma robots.txt w pamięci podręcznej mniej więcej dobę, więc poprawka nie zadziała natychmiast — ale błąd też nie. Właśnie to opóźnienie jest powodem, żeby weryfikować starannie, zamiast testować na produkcji i czekać.