Robots.txt w WordPress pod SEO: konfiguracja i testowanie

Robots.txt to publiczny plik tekstowy, który przekazuje robotom reguły crawlowania, czyli pobierania adresów i zasobów w witrynie. Dyrektywy są wskazówkami dla robotów, a plik nie zabezpiecza poufnych danych przed dostępem.

Blokada crawlowania nie oznacza usunięcia strony z wyników Google. Adres zablokowany przez robots.txt może nadal znaleźć się w indeksie, na przykład gdy prowadzą do niego linki. Do wykluczenia strony z wyników Google użyj dostępnej dla robota dyrektywy noindex albo zabezpiecz treść hasłem, zależnie od celu.

Google musi móc pobrać stronę, aby odczytać noindex zapisany w meta robots lub nagłówku X-Robots-Tag. Jeśli robots.txt blokuje adres, robot nie zobaczy tej dyrektywy. Dokumentacja Google o robots.txt i dyrektywach noindex opisują różne zastosowania tych mechanizmów.

Google pobiera robots.txt z adresu przypisanego do konkretnego hosta, protokołu i portu, więc sprawdź wariant witryny używany przez użytkowników i roboty. Otwórz https://twojadomena.pl/robots.txt i zanotuj treść oraz kod HTTP.

Kod odpowiedzi wymaga kontekstu: Google traktuje odpowiedzi 4xx, z wyjątkiem 429, tak, jakby plik robots.txt nie istniał, więc taka odpowiedź nie zawsze oznacza blokadę crawlowania. Przy 5xx Google może czasowo wstrzymać crawlowanie witryny lub używać ostatniej poprawnej wersji pliku. Odpowiedź 404 oznacza dla Google brak pliku i brak ograniczeń z robots.txt. Źródło: Google Search Central, sprawdzono w październiku 2026.

Ustal źródło odpowiedzi przez porównanie publicznej treści z ustawieniami wtyczki SEO i plikiem w katalogu głównym serwera. Jeśli treści się różnią, administrator powinien sprawdzić fizyczny plik, reguły hostingu, proxy i cache. Sam edytor w panelu WordPressa nie potwierdza, że serwer zwraca zapisane tam reguły.

Jeśli kontrola ujawnia szerszy problem indeksacji lub widoczności, pozycjonowanie SEO może obejmować analizę technicznych barier serwisu. Szczegóły zachowania kodów odpowiedzi opisuje specyfikacja Google robots.txt.

WordPress generuje wirtualną zawartość robots.txt, gdy witryna nie ma fizycznego pliku w katalogu głównym. Domyślne reguły zwykle blokują /wp-admin/ i dopuszczają /wp-admin/admin-ajax.php, ale wtyczki mogą zmieniać wynik.

Fizyczny plik robots.txt serwowany z katalogu głównego może zastąpić wirtualną odpowiedź WordPressa. Z tego powodu zawartość widoczna w edytorze wtyczki może różnić się od publicznego pliku. WordPress udostępnia filtr robots_txt, który pozwala modyfikować treść generowaną przez WordPress; filtr nie zmieni odpowiedzi, jeśli serwer podaje zamiast niej fizyczny plik. Dokumentacja WordPress Developer Resources o filtrze robots_txt.

Yoast SEO udostępnia edycję przez Yoast SEO > Tools > File Editor, jeśli instalacja i uprawnienia serwera pozwalają zapisywać pliki. Jeżeli edytora nie ma albo plik jest niezapisywalny, zmianę może wykonać administrator serwera przez FTP, SFTP lub menedżer plików hostingu. Instrukcja Yoast SEO.

Robots.txt obowiązuje dla konkretnego hosta i protokołu. Plik pod https://www.twojadomena.pl/robots.txt nie ustala reguł dla http://twojadomena.pl ani dla innej subdomeny.

Edytuj robots.txt w tym miejscu, które faktycznie dostarcza plik publiczny: we wtyczce, w katalogu głównym serwera albo w panelu hostingu. Przed zmianą zachowaj kopię obecnej treści i przygotuj plan cofnięcia modyfikacji.

Tabela porównuje metody edycji według wymaganego dostępu i typowego zastosowania. Wybór zależy od źródła publicznej odpowiedzi i uprawnień administratora.

Wniosek: metoda jest skuteczna tylko wtedy, gdy zmienia źródło odpowiedzi widzianej pod publicznym adresem.

Yoast SEO może mieć edytor pod Yoast SEO > Tools > File Editor, ale dostępność zależy od ustawień instalacji i zapisywalności plików. Po edycji sprawdź plik publiczny i kilka reprezentatywnych adresów, zamiast zakładać, że zapis w panelu zakończył konfigurację.

Dla typowej witryny WordPress przykładowym punktem wyjścia jest blokada katalogu administracyjnego z wyjątkiem endpointu admin-ajax.php, bez blokowania publicznych katalogów. Dopasuj adres mapy witryny i reguły do rzeczywistej instalacji:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://twojadomena.pl/wp-sitemap.xml

User-agent wskazuje robota, którego dotyczą kolejne reguły. Disallow ogranicza pobieranie wskazanej ścieżki, Allow dopuszcza wskazany adres w zakresie reguły, a Sitemap podaje pełny adres mapy witryny. Google obsługuje te dyrektywy, natomiast nie każda dyrektywa spotykana w przykładach z sieci jest przez niego obsługiwana.

WordPress udostępnia własną mapę pod adresem /wp-sitemap.xml, a wtyczka SEO może publikować inną, na przykład sitemap_index.xml. Otwórz adres mapy i potwierdź, że zwraca prawidłową zawartość przed dodaniem go do robots.txt. Zalecamy dodawać tylko reguły, dla których istnieje konkretny powód crawlowania.

Nie blokuj publicznych stron ani zasobów CSS, JavaScript i obrazów potrzebnych Google do zrozumienia witryny. Zablokowanie całego /wp-content/ może odciąć różne rodzaje plików, więc diagnozuj konkretną ścieżkę zamiast blokować cały katalog.

Tabela rozdziela typy blokowanych adresów, ich możliwe objawy i kontrolę diagnostyczną. Sprawdź w Inspekcji adresu URL, czy Google może pobrać stronę oraz zasoby użyte w jej renderowaniu.

Wniosek: problem renderowania diagnozuj na poziomie konkretnego pliku i reguły, a nie przez blokowanie lub odblokowanie całego katalogu bez kontroli.

Google zaleca sprawdzić wyrenderowaną wersję strony oraz dostępność zasobów w Search Console. Gdy CSS lub JavaScript jest niedostępny, porównaj adres zasobu z regułami robots.txt i odpowiedzią serwera. Dokumentacja Google o diagnostyce crawlowania.

Adres mapy witryny zweryfikujesz, otwierając jej URL, a następnie możesz zgłosić go w Google Search Console w sekcji Mapy witryn. Wpis Sitemap w robots.txt ułatwia robotom znalezienie mapy, ale nie zastępuje raportu zgłoszenia i przetwarzania mapy w Search Console.

Po zmianie sprawdź stronę główną, ważną podstronę, adres celowo zablokowany oraz zasoby używane na stronie. W Google Search Console otwórz Inspekcję adresu URL, wybierz test opublikowanego adresu i sprawdź, czy Google może pobrać stronę oraz jej zasoby.

Raport Mapy witryn w Search Console pokazuje przetwarzanie zgłoszonej mapy. Raport Skuteczność w wyszukiwarce służy do obserwacji kliknięć i wyświetleń, a nie do testowania reguł robots.txt. Przy większej zmianie porównaj dane dla konkretnych adresów przed i po wdrożeniu.

Po zmianie pobierz publiczny plik i sprawdź jego treść oraz kod odpowiedzi; jeśli widzisz poprzednią wersję, sprawdź cache wtyczki, hostingu lub CDN. Prywatne okno przeglądarki może ograniczyć wpływ lokalnej pamięci przeglądarki, ale nie omija cache serwera ani CDN.

Perspektywa KC Mobile: rozbieżność diagnozujemy, sprawdzając kolejno źródło odpowiedzi, cache i reguły wtyczki. Taka kolejność pomaga ustalić, która warstwa zwraca nieaktualną lub inną wersję pliku. W Google robots.txt jest zwykle buforowany do 24 godzin, a przy problemach z odświeżeniem może być przechowywany dłużej.

Wycofaj zmianę, gdy reguła niezamierzenie blokuje stronę główną albo ważne adresy. Przywróć poprzednią treść, sprawdź ponownie publiczną odpowiedź i przetestuj wybrane adresy w Search Console. Jeśli potrzebujesz analizy barier technicznych i dalszej pracy nad widocznością, pozycjonowanie SEO dla firmy może objąć takie działania. Plan optymalizacji SEO WordPress porządkuje dalszą kontrolę indeksacji.

• Yoast SEO w WordPressie: poradnik konfiguracji i optymalizacji treści
• Jak optymalizować linki wewnętrzne w sklepie internetowym? Praktyczny plan i audyt
• Wpływ microfrontends na SEO: renderowanie, indeksacja i testy
• Yoast SEO: cena wersji Premium, darmowa wersja i alternatywy