# Robots.txt w WordPress: plik fizyczny, wirtualny, sitemap i noindex
> Brak robots.txt na FTP nie oznacza braku odpowiedzi pod tym adresem. Sprawdź, co generuje WordPress, kiedy pierwszeństwo ma plik na serwerze i dlaczego Disallow nie zastępuje noindex. Z poleceniami, kontrolą HTTP i procedurą wycofania zmian.
Autor: WebAlpha (WebAlpha). Opublikowano: 2026-09-07. Zaktualizowano: 2026-09-07. Kanoniczny adres: https://webalpha.pl/blog/robots-txt-wordpress
Około 25 min czytania (szacunek; bez czasu wykonania instrukcji).
Robots.txt dla strony https://example.com znajduje się pod https://example.com/robots.txt. W WordPress odpowiedź może pochodzić z istniejącego pliku, z kodu aplikacji albo z konfiguracji hostingu. Najpierw ustal jej rzeczywiste źródło. Dopiero potem zmień reguły i sprawdź rezultat przez HTTP. Do wyłączenia publicznej strony HTML z indeksu służy noindex, a do ochrony prywatnych danych — kontrola dostępu. To trzy różne zadania.
## Nie używasz terminala? Wybierz swoją ścieżkę
**Zacznij od dostępu, który rzeczywiście masz**
| Masz dostęp do… | Pierwszy krok | Gdzie przejść dalej |
| --- | --- | --- |
| Tylko panelu WordPress | Otwórz /robots.txt w przeglądarce i zapisz treść. W Ustawienia → Czytanie odczytaj widoczność; niczego jeszcze nie przełączaj. | Jeśli zainstalowane narzędzie SEO ma edytor reguł, sprawdź jego dokumentację. Brak edytora → poproś hosting o ustalenie źródła odpowiedzi. |
| Menedżera plików hostingu lub SFTP | Ustal katalog publiczny właściwej domeny. Sprawdź, czy fizyczny robots.txt istnieje; pobierz jego kopię. | Plik istnieje → ścieżka fizyczna w kroku 6. Pliku nie ma, a URL działa → sprawdź generator w kroku 2 i korektę MU w kroku 6. |
| Terminala, WP-CLI i środowiska prób | Zapisz odpowiedzi HTTP oraz ustawienia wskazanymi poleceniami. | Przejdź przez całą procedurę, włącznie z macierzą parsera i testem wycofania. |
Brak opcji „Edytor plików” nie jest powodem do wyłączania DISALLOW_FILE_EDIT ani nadawania szerokich uprawnień zapisu. Nie instaluj kolejnego narzędzia SEO tylko dla tego przycisku. W zgłoszeniu do hostingu podaj domenę i poproś: „Proszę potwierdzić DocumentRoot, źródło odpowiedzi /robots.txt (plik, WordPress czy proxy), ewentualny cache tego URL oraz sposób zachowania kopii i wycofania zmiany”. To pozwala wybrać właściwy krok bez znajomości SSH.
Bez terminala status odpowiedzi możesz sprawdzić w narzędziach deweloperskich przeglądarki: otwórz kartę Network/Sieć, odśwież dokładny adres /robots.txt i wybierz to żądanie. Zapisz status, ewentualne przekierowanie oraz treść odpowiedzi. Sam widoczny napis w oknie nie rozstrzyga, czy serwer zwrócił 200, 404 czy dokument HTML. Jeśli nie korzystasz z tych narzędzi, poproś hosting o te trzy informacje.
> **Zakres i wymagany dostęp:** Poradnik dotyczy pojedynczego, samodzielnie hostowanego WordPressa. Odczyt i wybór ścieżki możesz zrobić bez terminala; dokładne polecenia i automatyczne testy są częścią techniczną. Edycja wymaga dostępu do hostingu lub mechanizmu zarządzającego robots.txt. WP-CLI jest opcjonalne. Przed zmianami potrzebujesz kopii ustawień i bezpiecznego środowiska prób. Multisite, instalacja w podkatalogu, reverse proxy i usługi zarządzane wymagają dodatkowego potwierdzenia routingu.
## Najpierw wybierz właściwy mechanizm: robots.txt, noindex czy hasło
**Cel zmiany a właściwe miejsce konfiguracji**
| Cel | Mechanizm | Czego nie zapewnia |
| --- | --- | --- |
| Ograniczyć pobieranie wybranych URL-i przez współpracujące roboty | Allow / Disallow w robots.txt | Nie blokuje użytkownikom dostępu HTTP i nie gwarantuje usunięcia URL z wyników. |
| Nie indeksować publicznej strony HTML | Metatag robots noindex albo nagłówek X-Robots-Tag | Nie jest hasłem. Robot musi móc odczytać tę odpowiedź. |
| Ukryć kopię strony lub dane klientów | Uwierzytelnianie, VPN lub ograniczenie dostępu na serwerze | Sam robots.txt ani noindex nie chronią poufnych danych. |
| Wskazać mapę witryny | Sitemap z pełnym adresem działającego XML | Nie odblokowuje URL-i i nie wymusza indeksacji. |
Robots.txt jest publiczną instrukcją dla robotów, nie zabezpieczeniem zasobów. Nie wpisuj tam ścieżek do kopii bazy z przekonaniem, że staną się prywatne. Granice tego mechanizmu wyjaśnia [Google: zastosowanie i ograniczenia robots.txt](https://developers.google.com/search/docs/crawling-indexing/robots/intro).
## 1. Odczytaj prawdziwy robots.txt i zachowaj stan wyjściowy
W poleceniach zastąp example.com własną domeną. WA_SITE ma zawierać protokół i host, bez końcowego ukośnika i bez ścieżki bloga. Dla https://example.com/blog/ nadal sprawdzasz https://example.com/robots.txt. Wersje www, bez www, HTTP i HTTPS mogą mieć różne odpowiedzi. Nie zgaduj właściwej wersji na podstawie nazwy katalogu na FTP.
Na swoim komputerze: odczyt GET z nagłówkami, bez automatycznego podążania za przekierowaniem
```bash
WA_SITE='https://example.com'
curl --silent --show-error --connect-timeout 5 --max-time 15 \
--include "$WA_SITE/robots.txt"
```
Zapisz datę, URL, status HTTP, Content-Type i pełną treść. Przy 301/302 najpierw sprawdź Location, dopiero potem odczytaj wskazany adres; nie przeocz zmiany hosta ani pętli. Dla poprawnie podanego pliku oczekujesz 200 i zwykłego tekstu UTF-8. HTML strony głównej z kodem 200 nie jest prawidłowym wynikiem tylko dlatego, że nie ma błędu HTTP. Te polecenia celowo nie używają curl --fail: musisz zobaczyć również treść błędów 404/500.
Opcjonalny zapis diagnostyczny w nowym prywatnym katalogu lokalnym — nie w katalogu strony
```bash
umask 077
WA_ROBOTS_AUDIT=$(mktemp -d)
curl --silent --show-error --connect-timeout 5 --max-time 15 \
--dump-header "$WA_ROBOTS_AUDIT/robots-before.headers" \
--output "$WA_ROBOTS_AUDIT/robots-before.txt" "$WA_SITE/robots.txt"
printf '%s\n' "$WA_ROBOTS_AUDIT"
```
Nazwę, umiejscowienie w katalogu głównym hosta i format pliku określa [instrukcja tworzenia robots.txt Google](https://developers.google.com/crawling/docs/robots-txt/create-robots-txt). Katalog tymczasowy z powyższego polecenia jest tylko zapisem odpowiedzi; nie zastępuje kopii fizycznego pliku ani ustawień wtyczki.
## 2. Ustal, czy odpowiedź jest fizyczna, wirtualna czy nadpisana przez hosting
### Krok 1: Sprawdź katalog publiczny przypisany do właściwej domeny
W panelu hostingu ustal DocumentRoot, czyli katalog obsługujący dany host. Poszukaj w nim dokładnie robots.txt, nie robots.txt.txt. Nie zakładaj, że każda instalacja ma ścieżkę public_html albo że katalog WordPressa jest jednocześnie katalogiem głównym hosta. Pobierz istniejący plik wraz z zapisem uprawnień i datą; zachowaj go poza katalogiem publicznym.
Jeśli pliku nie ma, a URL zwraca 200, odpowiedź może być prawidłowym plikiem wirtualnym. Nie twórz drugiego źródła reguł tylko po to, żeby plik pojawił się na FTP. Jeżeli jest fizyczny plik, porównaj jego treść z odpowiedzią HTTP. Różnica oznacza, że trzeba zbadać cache, inny katalog domeny albo regułę serwera/proxy.
W podstawowej konfiguracji Apache dla WordPressa istniejące pliki omijają przekazanie żądania do index.php. Fizyczny robots.txt może więc przesłonić odpowiedź WordPressa, a zmiana w panelu SEO nie zmieni tego, co pobiera robot. To wniosek dla takiego routingu, nie uniwersalna właściwość każdego hostingu. Nie zastępuj całego .htaccess fragmentem z poradnika; możesz usunąć potrzebne reguły bezpieczeństwa i przekierowania.
Mechanizm widać w warunkach !-f oraz !-d opisanych w [konfiguracji Apache dla WordPress](https://developer.wordpress.org/advanced-administration/server/web-server/httpd/). Wirtualny plik generuje [funkcja do_robots()](https://developer.wordpress.org/reference/functions/do_robots/), a wtyczki mogą zmieniać jego tekst przez [filtr robots_txt](https://developer.wordpress.org/reference/hooks/robots_txt/).
Opcjonalnie przez SSH: odczyt właściwej instalacji WP-CLI, bez wypisywania konfiguracji z hasłami
```bash
WA_WP_ROOT='/pelna/sciezka/do/wordpress'
wp --path="$WA_WP_ROOT" core version
wp --path="$WA_WP_ROOT" option get home
wp --path="$WA_WP_ROOT" option get siteurl
wp --path="$WA_WP_ROOT" option get blog_public
```
Zatrzymaj się, jeśli home wskazuje inną stronę albo polecenie nie działa. Nie traktuj błędu bazy jak pustej wartości. Parametr --path wybiera instalację; nie odczytuj całego wp-config.php do publicznego raportu. Opcja blog_public jest wskazówką do następnego kroku, a nie dowodem tego, jaki HTML wysyła CDN.
## 3. Sprawdź ustawienie widoczności WordPress i metatag noindex
Ustawienia → Czytanie zawierają prośbę o nieindeksowanie witryny. W core WordPress 7.1 wartość blog_public=0 powoduje dodanie noindex do metatagu robots. Nie oznacza automatycznego dopisania Disallow: / do robots.txt: takie zachowanie usunięto już w WordPress 5.3. Dlatego wirtualny plik może zawierać standardowe reguły panelu, chociaż HTML całej witryny ma noindex.
Źródła: [wp_robots_noindex()](https://developer.wordpress.org/reference/functions/wp_robots_noindex/), [kod metatagów WordPress 7.1](https://raw.githubusercontent.com/WordPress/wordpress-develop/7.1/src/wp-includes/robots-template.php) i historia [do_robots()](https://developer.wordpress.org/reference/functions/do_robots/). Motyw, wtyczka i nagłówki hostingu mogą zmienić rezultat; rozstrzyga odpowiedź strony, nie sam checkbox.
Odczytaj rzeczywistą stronę docelową — nie tylko stronę główną
```bash
WA_PAGE="$WA_SITE/przykladowa-strona/"
curl --silent --show-error --connect-timeout 5 --max-time 15 \
--include "$WA_PAGE"
```
W nagłówkach sprawdź X-Robots-Tag, a wewnątrz — metatagi robots i googlebot. Przykład intencji wyłączenia indeksacji HTML to . Nie wystarczy wyszukać słowa noindex w całym pliku: może wystąpić w treści poradnika lub komentarzu. Sprawdź też, czy oglądasz docelowe 200, a nie dokument pośredni z przekierowaniem.
> **Disallow i noindex nie są podwójnym zabezpieczeniem indeksacji:** Jeżeli blokujesz pobranie strony w robots.txt, Google może nie odczytać jej noindex. Gdy celem jest wyłączenie publicznego HTML z wyników, pozwól na pobranie tej odpowiedzi i podaj noindex. Dyrektywa Noindex: w samym robots.txt nie jest obsługiwana przez Google. Dla materiału poufnego zastosuj kontrolę dostępu zamiast tej procedury.
Warunek dostępności strony oraz dwa obsługiwane miejsca dla noindex opisuje [Google: blokowanie indeksowania za pomocą noindex](https://developers.google.com/search/docs/crawling-indexing/block-indexing). Nie usuwaj globalnego noindex ze stagingu, aby „naprawić SEO”. Na produkcji zmień ustawienie dopiero po potwierdzeniu, że witryna ma być publiczna, i sprawdź reprezentatywne podstrony po odświeżeniu cache.
## 4. Ustal właściwą sitemapę zamiast zgadywać jej adres
Wbudowana mapa WordPressa zwykle zaczyna się od /wp-sitemap.xml. Wtyczka SEO może dostarczać inny indeks i wyłączać mapę core. Sprawdź aktywnego dostawcę w panelu, a następnie pobierz wskazany indeks. Prawidłowy wynik ma zawierać XML sitemapindex albo urlset, nie formularz logowania, stronę błędu czy stronę główną.
Przykład dla mapy wbudowanej — użyj adresu faktycznie obsługiwanego przez Twoją instalację
```bash
curl --silent --show-error --connect-timeout 5 --max-time 15 \
--include "$WA_SITE/wp-sitemap.xml"
```
Przy blog_public=0 mapy core są domyślnie wyłączone; ich endpoint może zwrócić 404. Wirtualny robots.txt nie powinien wtedy automatycznie reklamować mapy core. Nie rozwiązuj tego przez wpisanie nieistniejącego URL do pliku fizycznego. Najpierw ustal, czy strona celowo jest prywatna i czy mapami nie zarządza inny mechanizm. Filtry i wtyczki mogą nadpisać ustawienia domyślne.
Powiązanie z blog_public jest w [WP_Sitemaps::sitemaps_enabled()](https://developer.wordpress.org/reference/classes/wp_sitemaps/sitemaps_enabled/), dopisanie mapy w [WP_Sitemaps::add_robots()](https://developer.wordpress.org/reference/classes/wp_sitemaps/add_robots/), a odpowiedź wyłączonego endpointu w [kodzie sitemaps WordPress 7.1](https://raw.githubusercontent.com/WordPress/wordpress-develop/7.1/src/wp-includes/sitemaps/class-wp-sitemaps.php).
Otwórz co najmniej jedną mapę podrzędną z indeksu i kilka znajdujących się w niej URL-i. Adresy powinny wskazywać zamierzoną domenę produkcyjną i wersję protokołu, nie localhost ani staging. Jeśli docelowa strona ma noindex, przekierowuje lub zwraca błąd, popraw źródło takiego wpisu. Sam status 200 indeksu mapy nie potwierdza poprawności całego zestawu.
## 5. Przygotuj minimalny robots.txt bez przypadkowych blokad
Przykład dla publicznego WordPressa w katalogu głównym, z działającą mapą core — nie uniwersalny szablon dla każdego hostingu
```text
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/wp-sitemap.xml
```
Przed użyciem zmień domenę i potwierdź ścieżkę mapy. Jeśli WordPress już generuje te reguły poprawnie, nie musisz tworzyć pliku fizycznego. Instalacja z innym adresem panelu wymaga właściwych ścieżek. Allow dla admin-ajax.php nie naprawia błędów PHP, nie omija hasła i nie uruchamia AJAX — dotyczy tylko reguły pobierania.
- Nie dodawaj bez powodu Disallow: /wp-content/ ani /wp-includes/. Mogą tam znajdować się CSS, JavaScript i obrazy potrzebne do odczytania strony.
- Nie kopiuj blokady wszystkich parametrów, koszyka, kategorii lub wyszukiwarki bez inwentaryzacji prawdziwych URL-i i ich funkcji. Ten poradnik nie ustala polityki faceted navigation dla każdego sklepu.
- Nie dopisuj Disallow: / na publicznej stronie, która ma być pobierana i indeksowana. Pusta wartość Disallow i ukośnik / nie oznaczają tego samego.
- Nie dodawaj drugiej, bardziej szczegółowej grupy Googlebot, zakładając, że automatycznie odziedziczy wszystkie reguły User-agent: *. Sprawdź wybraną grupę i konkretne URL-e.
Zasady grup robotów i dopasowania ścieżek opisuje [aktualna specyfikacja Google robots.txt](https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec). Potrzebę udostępnienia istotnych zasobów renderowania wyjaśnia [Google SEO Starter Guide](https://developers.google.com/search/docs/fundamentals/seo-starter-guide).
### Sprawdź regułę dla konkretnego robota i URL, nie tylko status 200
Dla ważnej podstrony, admin-ajax.php oraz używanych CSS i JS potrzebujesz osobnego wyniku dopasowania. W paczce uruchomiliśmy niezmodyfikowany parser i matcher google/robotstxt, commit 22b355ff855419e6a3ff8ff09c0ad7fdb17116f9. W pierwszej macierzy część wejść pochodzi z rzeczywistych odpowiedzi WordPressa, a konflikty i ścieżka CSS są jawnie syntetyczne. Osobna próba korekty w kroku 6 obejmuje także istniejący CSS pobrany przez HTTP. Nie zastąpiliśmy algorytmu Google własnym zestawem wyrażeń regularnych.
**Wybrane rzeczywiste wyniki parsera z macierzy 40/40 — ALLOWED/DISALLOWED oznacza dopasowanie reguł, nie indeksację**
| Plik / reguła | Token robota i ścieżka | Wynik |
| --- | --- | --- |
| Odczytany wirtualny plik WordPress | Googlebot → /wp-admin/ | DISALLOWED |
| Ten sam plik; dłuższy wyjątek Allow | Googlebot → /wp-admin/admin-ajax.php?action=test | ALLOWED |
| Odczytany fizyczny plik ćwiczenia | Googlebot → /wa-strona-1/ | DISALLOWED, choć osobny test HTTP strony zwrócił 200 |
| Syntetyczna blokada /wp-content/ i /wp-includes/ → korekta PHP | Googlebot → ścieżka CSS oraz ścieżka JS nawigacji | Przed: DISALLOWED; po: ALLOWED |
| Syntetyczne Disallow /wp-content/ + Allow /wp-content/assets/ | Googlebot → /wp-content/assets/theme.css | ALLOWED — dłuższe dopasowanie |
| Dodatkowe Disallow /wp-content/assets/private/ | Googlebot → /wp-content/assets/private/key.txt | DISALLOWED — jeszcze dłuższe dopasowanie |
| Równe Allow i Disallow /same/ | Googlebot → /same/item | ALLOWED — przy remisie wygrywa dopuszczenie |
| Disallow /common/ tylko w grupie *; osobna grupa Googlebot | Googlebot → /common/item; AuditBot → /common/item | Googlebot: ALLOWED; AuditBot: DISALLOWED w tym parserze |
| Dwie oddzielne grupy Googlebot, druga z Disallow /merged/ | Googlebot → /merged/item | DISALLOWED — grupy tego samego tokenu łączą reguły |
Oficjalne źródła, sposób wywołania i ograniczenia są w [repozytorium Google przypiętym do testowanego commitu](https://github.com/google/robotstxt/tree/22b355ff855419e6a3ff8ff09c0ad7fdb17116f9). Biblioteka ocenia podane reguły i token robota, ale nie pobiera robots.txt, nie obsługuje cache/statusów HTTP ani nie renderuje strony. Nie obejmuje również wszystkich dodatkowych zasad zachowania poszczególnych crawlerów. Wynik dla AuditBot nie jest testem innej wyszukiwarki.
Dla technicznego operatora: z rozpakowanej paczki, bez Dockera; wymagane już dostępne C++17, Abseil, pkg-config, PHP i Node
```bash
pkg-config --modversion absl_strings
php -v
node robots-parser-tests.mjs
```
Skrypt sprawdza SHA-256 źródeł Google, kompiluje oryginalne robots.cc i robots_main.cc, wykonuje wszystkie przypadki i zapisuje raport. Nie instaluje zależności; gdy brakuje kompilatora lub Abseil, zatrzymuje się. Nasza próba używała Apple clang 21.0.0, Abseil 20260107 i PHP 8.5.5. Raporty archiwalne są w evidence; nowy wynik zapisuje się obok skryptu, bez nadpisywania wcześniejszego. Przykładowa ścieżka CSS w macierzy nie jest twierdzeniem, że taki plik istnieje na Twojej stronie — dodaj jej rzeczywisty URL do własnej kontroli.
Do sprawdzenia własnej strony służy drugi helper. Umieść zapisany z HTTP tekst robots.txt jako robots-after.txt w rozpakowanej paczce, a w poleceniach zastąp domenę i ścieżki prawdziwymi URL-ami. Przekaż token Googlebot, nie cały nagłówek przeglądarki Mozilla/5.0. Helper zapisuje w wyniku hash wejścia oraz faktycznie oceniony URL, nie wysyła do niego żądania.
Własny plik i pojedynczy URL — oddzielne sprawdzenie każdej strony oraz rzeczywiście używanych zasobów
```bash
node robots-parser-check.mjs robots-after.txt Googlebot https://example.com/wazna-strona/
node robots-parser-check.mjs robots-after.txt Googlebot https://example.com/wp-admin/admin-ajax.php
```
Wynik ALLOWED daje kod wyjścia 0, DISALLOWED — 1, a błąd wejścia lub narzędzia — 2. Kod 1 nie oznacza awarii parsera; oceń, czy blokada tego konkretnego URL była zamierzona. Brak pliku, biblioteki albo wynik błędu nie są dowodem dopuszczenia. Dwa dołączone przykłady CLI sprawdziliśmy osobno: panel był blokowany, a admin-ajax.php z parametrem dopuszczony.
## 6. Wdróż zmianę w jednym miejscu i potwierdź odpowiedź
### Krok 2: Wybierz świadomie plik fizyczny albo generator
Dla istniejącego pliku fizycznego przygotuj nową wersję jako zwykły tekst UTF-8, porównaj ją z kopią i wgraj do ustalonego katalogu hosta. Zachowaj dotychczasowe poprawne uprawnienia. Użyj kontrolowanej podmiany zgodnej z procedurą hostingu; nie pozostawiaj archiwum konfiguracji w katalogu publicznym. Jeżeli nie ma pliku, przed jego utworzeniem zapisz, że stanem wyjściowym był generator.
Dla wersji wirtualnej zmień ustawienie w mechanizmie, który faktycznie ją generuje: panelu odpowiedniej wtyczki lub własnym, wersjonowanym kodzie. Nie edytuj plików core WordPressa. Gdy dwie wtyczki próbują zarządzać tym samym, ustal jednego właściciela konfiguracji. Nie zakładaj, że przycisk „edytuj robots.txt” w każdej wtyczce zapisuje ten sam rodzaj pliku.
Po zapisie odczytaj dokładny URL /robots.txt z komputera, a nie tylko podgląd panelu. Jeśli treść jest stara, sprawdź cache konkretnego zasobu w hostingu/CDN i właściwy host. Czyszczenie całej witryny nie powinno być pierwszym, niekontrolowanym działaniem. Dopóki publiczna odpowiedź nie odpowiada projektowi zmiany, wdrożenie nie jest zakończone.
Po zmianie: zachowaj odpowiedź i porównaj tekst w tym samym katalogu diagnostycznym
```bash
test -n "$WA_ROBOTS_AUDIT" && test -d "$WA_ROBOTS_AUDIT" || exit 1
curl --silent --show-error --connect-timeout 5 --max-time 15 \
--dump-header "$WA_ROBOTS_AUDIT/robots-after.headers" \
--output "$WA_ROBOTS_AUDIT/robots-after.txt" "$WA_SITE/robots.txt"
diff -u "$WA_ROBOTS_AUDIT/robots-before.txt" "$WA_ROBOTS_AUDIT/robots-after.txt"
```
Diff zwraca kod 1, gdy pliki różnią się — to nie błąd wdrożenia. Oceń, czy każda różnica była zamierzona. Następnie pobierz ważną podstronę, sitemapę i rzeczywiście używane zasoby CSS/JS z jej HTML. Kod 200 zasobu potwierdza dostęp HTTP dla Twojego żądania, ale sam nie dowodzi dopuszczenia Googlebota przez robots.txt. Reguły trzeba sprawdzić osobno dla konkretnych ścieżek.
### Pełna ścieżka korekty generatora: usuń dwie potwierdzone blokady CSS/JS
Przykład rozwiązuje jeden konkretny problem: publiczny WordPress w katalogu głównym generuje dokładnie Disallow: /wp-content/ i Disallow: /wp-includes/, mimo że zasoby z tych katalogów są potrzebne stronie. Najpierw usuń te błędne wpisy w ich źródle, jeśli masz kontrolę nad ustawieniem lub własnym kodem. Poniższy filtr MU jest jawną, wąsko ograniczoną korektą istniejącego generatora, gdy nie ma wygodnego edytora reguł. Nie jest uniwersalnym „SEO fixem” ani zaleceniem instalacji dodatkowej rozbudowanej wtyczki.
1. Potwierdź odpowiedź wirtualną: brak pliku fizycznego w poprawnym DocumentRoot i brak reguły proxy przesłaniającej WordPress. Zapisz treść oraz status przed zmianą. Jeśli plik jest fizyczny, popraw go zamiast instalować filtr, który nie obsłuży tej odpowiedzi.
2. W treści ma być jedna grupa User-agent: *, a błędne wpisy mają dotyczyć dokładnie dwóch wskazanych katalogów. Potwierdź, że strona ma być publiczna i blog_public=1. Wiele grup, inny podkatalog, szerszy Disallow: / lub reguły z gwiazdką wymagają osobnej analizy, nie tego fragmentu.
3. Na kopii testowej zachowaj istniejące pliki i ustawienia. Otwórz w menedżerze hostingu lub SFTP właściwy wp-content/mu-plugins. Jeśli katalogu nie ma, utwórz go zgodnie z uprawnieniami hostingu. Nie nadpisuj istniejącego pliku o naszej nazwie i nie zostawiaj dwóch kopii tej samej funkcji.
4. Z paczki weź robots-generator-correction.php lub zapisz dokładny kod poniżej jako zwykły UTF-8 bez BOM. Nazwij plik webalpha-robots-resources.php i umieść go bezpośrednio w mu-plugins, nie w dodatkowym podfolderze. Techniczny operator może przed wgraniem wykonać php -l na dokładnie tym pliku. Nie edytuj core, motywu ani wp-config.php.
5. MU ładuje się automatycznie — nie trzeba klikać Aktywuj. Odczytaj /robots.txt ponownie. Zniknąć mają wyłącznie dwie potwierdzone blokady; reguły panelu, mapa oraz węższe wyłączenia mają pozostać. Uruchom parser dla prawdziwych CSS/JS i strony docelowej, a niezależnie od niego sprawdź ich HTTP. Sprawdź też HTML noindex, sitemapę i działanie strony.
6. Jeśli wynik jest niezmieniony, sprawdź ograniczenia filtra, kolejny filtr o późniejszym priorytecie i cache konkretnego endpointu. Nie wyłączaj zabezpieczeń na chybił trafił. Jeśli nastąpi błąd PHP lub niezamierzona zmiana, usuń wyłącznie nowy plik MU albo przenieś go poza katalog ładowany przez WordPress, a następnie odczytaj odpowiedzi ponownie.
7. Po udanej próbie wdrażaj identyczny sprawdzony plik na docelowej instalacji, zachowując jej kopię i okno zmian. Zapisz właściciela tej korekty. Kiedy pierwotne źródło blokad zostanie poprawione, wycofaj filtr i sprawdź, że poprawny wynik pozostał. MU wymaga utrzymania przez operatora; nie zakładaj automatycznych aktualizacji.
Dokładny plik korekty z paczki — świadomie ograniczony do pojedynczej grupy wildcard i dwóch blokad
```php
**Co rzeczywiście sprawdziliśmy dla nowej korekty:** Dokładny callback przeszedł 12 testów jednostkowych w PHP 8.5.5: zakres dwóch reguł, zachowanie prywatności i węższych ścieżek, odmowę dla wielu grup, CRLF/CR, wielkość liter i komentarze. Następnie 7 września 2026 uruchomiliśmy ten sam plik jako MU w WordPress 7.1 z PHP 8.3.33. Osobny raport potwierdza 7/7 kontroli HTTP i 4/4 kontroli wycofania. Powróciły początkowa opcja blog_public, dokładna treść robots i brak obu plików testowych. To próba jednej izolowanej instalacji, nie wszystkich hostingów i wtyczek.
**Dodatkowe 10/10 przypadków oficjalnego parsera na dokładnych odpowiedziach HTTP przed i po załadowaniu MU — token Googlebot**
| Sprawdzany URL | Przed korektą | Po korekcie |
| --- | --- | --- |
| /wp-includes/css/dist/block-library/style.min.css | DISALLOWED | ALLOWED; osobny GET po zmianie: 200 text/css |
| /wp-includes/js/dist/script-modules/block-library/navigation/view.min.js | DISALLOWED | ALLOWED; osobny GET po zmianie: 200 text/javascript |
| /wp-admin/ | DISALLOWED | DISALLOWED |
| /wp-admin/admin-ajax.php | ALLOWED | ALLOWED |
| /wa-strona-1/ — syntetyczna strona kontrolna | ALLOWED | ALLOWED; osobny GET potwierdził 200 i treść |
Nowy test pobrał istniejący arkusz core, lecz nie twierdzimy, że był podpięty w HTML strony kontrolnej. Skrypt nawigacji jest zasobem wykrytym we wcześniejszej próbie. Reguły przed/po oceniono offline na treści HTTP o zgodnym SHA-256. Nie wysyłaliśmy Googlebota ani żądania do Google i nie testowaliśmy renderowania. Na Twojej stronie wybierz rzeczywiście potrzebne URL-e oraz sprawdź je ponownie po wdrożeniu.
Opcjonalne odtworzenie w przygotowanym laboratorium z paczki: pierwszy skrypt zmienia wyłącznie source, drugi działa offline
```bash
node robots-generator-lab.mjs
node robots-generator-rules-test.mjs
```
Uruchamiaj to dopiero po przygotowaniu source według README i po zakończeniu innych prób. Raporty archiwalne pozostają w evidence. Runner nie uruchamia ani nie resetuje Dockera, a istniejących raportów nie nadpisuje. Jeśli raport HTTP nie ma passed: true oraz czterech zaliczonych kontroli cleanup, zatrzymaj się — nie przechodź do kolejnych zmian. Pełna próba parsera wymaga narzędzi C++/Abseil opisanych wcześniej.
## 7. Ćwiczenie: plik fizyczny przesłania WordPress, ale nie chroni strony
> **Sprawdzone w odseparowanym laboratorium 7 września 2026:** WordPress 7.1, PHP 8.3.33, WP-CLI 2.12.0, motyw Twenty Twenty-Five 1.5. Sześć faz testu HTTP zakończyło się 62 poprawnymi asercjami, a pięć kontroli wycofania potwierdziło powrót do stanu wyjściowego. Badaliśmy pojedynczą instalację z Apache za lokalnym proxy Nginx, bez wtyczki SEO i bez danych klientów. Nie testowaliśmy indeksacji Google, hostingu produkcyjnego ani wszystkich wtyczek. Kod i rzeczywisty raport udostępniamy poniżej; nowa korekta generatora ma osobny zakres testów opisany wyżej.
[Pobierz laboratorium robots.txt z kodem i rzeczywistym raportem](https://webalpha.pl/downloads/blog/robots-wordpress-2026-09-07.zip)
Kod i rzeczywiste raporty: fizyczny/wirtualny robots, oficjalny parser Google z licencją, 40 przypadków reguł, 12 testów PHP oraz osobna integracja MU z HTTP i kolejnymi 10 przypadkami parsera. Bez danych klientów.
Paczka zawiera README z pełnym uruchomieniem: budową kontenerów, przygotowaniem źródła i wywołaniem testu. Automatyczne ćwiczenie działa tylko z dedykowanym projektem oraz source na 127.0.0.1:18881; odmawia zastąpienia istniejącego pliku i wcześniejszych wyników. Nie kieruj skryptu na hosting. Poniższe kroki opisują także ręczne odtworzenie mechanizmu na własnej, odseparowanej kopii.
> **Ten eksperyment wykonuj tylko na odseparowanej kopii:** Nie przełączaj widoczności produkcji w celach demonstracyjnych i nie wymuszaj na niej błędu robots.txt. Kopia ma mieć kontrolę dostępu lub działać wyłącznie lokalnie, bez prawdziwych danych klientów. Przygotuj opublikowaną, syntetyczną stronę /wa-strona-1/ i zapisz obecne blog_public, odpowiedź robots.txt oraz istnienie i treść fizycznego pliku. Jeśli nie umiesz odtworzyć tych ustawień, zakończ na diagnostyce odczytowej.
1. Przy braku fizycznego robots.txt pobierz odpowiedź wirtualną oraz HTML strony kontrolnej. Dla ustawienia nieindeksowania sprawdź noindex w head; w domyślnym core sprawdź też brak deklaracji mapy i 404 jej endpointu.
2. Wyłącznie na niedostępnej publicznie kopii pozwól WordPressowi na indeksowanie w Ustawienia → Czytanie. Sprawdź, czy znika globalne noindex i pojawiają się poprawna mapa oraz jej deklaracja. Nie wnioskuj tego z samego kliknięcia Zapisz.
3. Utwórz w prawdziwym katalogu głównym hosta fizyczny robots.txt z poniższym markerem. Wstaw prawidłowy adres mapy kopii. Pobierz /robots.txt: marker pozwala rozpoznać nową odpowiedź.
4. Pobierz /wa-strona-1/. Mimo Disallow strona ma pozostać dostępna jako HTTP 200. To doświadczenie pokazuje brak ochrony dostępu, nie zachowanie Google i nie to, czy URL trafi do indeksu.
5. Przenieś wyłącznie utworzony przez siebie plik poza katalog publiczny, do prywatnej kopii ćwiczenia. Pobierz /robots.txt ponownie. Przy opisanym routingu ma wrócić odpowiedź wirtualna, nie 404.
6. Przywróć pierwotną wartość widoczności i ewentualny oryginalny plik. Potwierdź powrót odpowiedzi robots.txt, HTML strony kontrolnej i statusu mapy. Nie przywracaj całej bazy produkcji tylko dla tej jednej opcji — mogłoby to cofnąć nowsze dane.
Wyłącznie przykład fizycznego pliku ćwiczeniowego; domenę zastąp adresem odseparowanej kopii
```text
# WA robots physical experiment
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wa-strona-1/
Sitemap: https://example.com/wp-sitemap.xml
```
### Dlaczego usunięcie pliku nie jest testem odpowiedzi 404
Gdy po usunięciu pliku żądanie trafia do WordPressa, generator nadal może zwracać 200. Próba błędu 404 wymaga osobnej, tymczasowej odpowiedzi w dokładnym endpointcie — i sprawdzenia jej statusu. W kontrolowanym laboratorium można użyć hooka do_robotstxt, który zakończy obsługę odpowiedzią 404, po czym usunąć wyłącznie ten hook. Nie zmieniaj przy tym całego routingu witryny ani .htaccess, żeby wywołać błąd jednej ścieżki.
Dla Google odpowiedź 404 robots.txt oznacza brak dostępnego zestawu reguł, a nie blokadę całej witryny. Podobnie 403 nie jest sposobem na zakaz crawlowania. Błędy 5xx i problemy połączenia mają odrębną obsługę, uwzględniającą ostatnią poprawną wersję. Nie projektuj ochrony strony przez celowe psucie tego endpointu.
Interpretacja statusów pochodzi z [sekcji obsługi błędów HTTP w dokumentacji Google](https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec). Odpowiedź uzyskana z localhost potwierdza jedynie zachowanie naszej konfiguracji HTTP. Nie jest testem indeksowania w wyszukiwarce.
### Rzeczywisty wynik naszego ćwiczenia
**Odpowiedzi odczytane 7.09.2026, godz. 12:48 UTC; syntetyczna strona /wa-strona-1/**
| Faza | Robots.txt | HTML strony | Mapa core |
| --- | --- | --- | --- |
| Początkowe blog_public=0 | 200, reguły panelu, bez Sitemap | 200, noindex, nofollow | 404 |
| Lokalne blog_public=1 | 200, Sitemap i marker generatora | 200, bez noindex | 200, indeks XML |
| Plik fizyczny z Disallow strony kontrolnej | 200, marker fizyczny zamiast wirtualnego | Nadal 200, bez noindex | 200, indeks XML |
| Wycofanie fizycznego pliku | 200, powrót markera generatora | 200, bez noindex | 200, indeks XML |
| Kontrolowany hook 404 | 404, marker próby błędu | 200, bez noindex | 200, indeks XML |
| Pełne wycofanie ćwiczenia | 200, treść identyczna SHA-256 z początkiem | 200, noindex, nofollow | 404 |
W każdej fazie odczytaliśmy także rzeczywiście podpięty skrypt nawigacji motywu; zwracał HTTP 200. W badanym HTML nie było zewnętrznego arkusza przez link rel=stylesheet, więc raport jawnie oznacza próbkę CSS jako nieobecną, a nie zaliczoną. To kontrola próbek zasobów, nie pełne renderowanie ani parser zasad Googlebota. Po ćwiczeniu nie pozostały nasz plik fizyczny, wtyczka MU ani testowa opcja w bazie.
## 8. Zweryfikuj publiczne wdrożenie w Search Console
> **GSC — czynności do wykonania po wdrożeniu, nie wynik naszego laboratorium:** Poniższe kroki wymagają zweryfikowanej usługi publicznej strony. Nie oznaczamy ich jako PASS na podstawie localhost, parsera ani testów PHP. Oczekiwany wynik dla strony przeznaczonej do indeksacji to dopuszczone pobranie, brak niezamierzonego noindex i zgodny odczyt reguł; nawet taki wynik nie gwarantuje dodania do indeksu.
1. Wybierz zweryfikowaną usługę dla odpowiedniej domeny. W raporcie robots.txt sprawdź dokładny host, status pobrania, ostatnią odczytaną treść i datę. Przy prefiksie URL zawierającym ścieżkę raport może nie być dostępny.
2. Po naprawie krytycznej blokady albo błędu pobrania możesz poprosić o ponowne pobranie robots.txt. To osobna czynność od prośby o indeksowanie konkretnej strony; nie wymaga Indexing API.
3. Dla reprezentatywnej podstrony wykonaj test dostępności na żywo w inspekcji URL. Sprawdź dopuszczenie pobrania, wykryte noindex i dostępność zasobów. Jeśli wynik się różni od lokalnego odczytu, wróć do hosta, cache i reguł odpowiadających Googlebotowi.
4. Sprawdź raport mapy witryny oraz indeksowania stron. Zapisz datę zmiany i oceniaj późniejsze odczyty. Udany test na żywo nie jest potwierdzeniem dodania do indeksu ani obietnicą pozycji.
Zakres raportu i żądanie ponownego pobrania opisuje [pomoc Search Console: robots.txt](https://support.google.com/webmasters/answer/6062598), a odświeżanie pliku — [Google: aktualizacja robots.txt](https://developers.google.com/crawling/docs/robots-txt/submit-updated-robots-txt). Google może używać wersji z cache; natychmiastowa aktualizacja w Twoim curl nie oznacza natychmiastowej zmiany po stronie wyszukiwarki.
## Diagnostyka: objaw, przyczyna i test rozstrzygający
**Nie naprawiaj każdej usterki przez dodanie nowej reguły**
| Objaw | Co sprawdzić | Działanie i odbiór |
| --- | --- | --- |
| Nie ma pliku na FTP, ale /robots.txt zwraca tekst 200 | Generator WordPressa, routing hostingu | To może być poprawna wersja wirtualna. Ustal jej właściciela przed edycją. |
| Wtyczka pokazuje nowe reguły, HTTP stare | Fizyczny plik, właściwy DocumentRoot, cache/CDN | Porównaj źródła, popraw jedno właściwe miejsce, ponów GET dokładnego URL. |
| Robots.txt pozwala pobierać, strona ma noindex | blog_public, ustawienie SEO podstrony, meta i X-Robots-Tag | Zdecyduj o indeksacji tej strony. Nie dodawaj Allow jako „naprawy” metatagu. |
| Mapa core zwraca 404 | Prywatność witryny, wtyczka map, routing | Zweryfikuj faktycznego dostawcę; nie dopisuj nieistniejącej mapy do robots.txt. |
| Strona jest blokowana, choć widzisz Allow | Ścieżkę, wybraną grupę robota, bardziej szczegółowe reguły | Przetestuj dokładny URL, nie tylko nazwę katalogu. Nie oceniaj pliku samym HTTP 200. |
| Po usunięciu fizycznego pliku jest nadal robots.txt | Powrót do generatora | Oceń treść odpowiedzi wirtualnej. Nie usuwaj plików core, aby wymusić 404. |
| Robots.txt zwraca 500 lub stronę HTML błędu | Log aplikacji/serwera, ostatnia zmiana, routing | Wycofaj właściwą zmianę i sprawdź poprawny status oraz tekst; nie maskuj błędu przypadkowym Disallow. |
## Kryteria zakończenia i plan wycofania
- Wiesz, kto generuje robots.txt dla każdego objętego zmianą hosta; nie ma dwóch niezależnych źródeł walczących o wynik.
- Publiczna odpowiedź ma oczekiwany status, format i reguły. Przetestowano konkretne money pages oraz rzeczywiście używane zasoby, nie tylko stronę główną.
- Meta robots i X-Robots-Tag odpowiadają zamierzonej indeksacji, a strona z noindex nie jest jednocześnie blokowana przed odczytem tego sygnału.
- Deklarowana mapa działa, jej podmapy nie prowadzą na staging, a próbka URL-i ma właściwe odpowiedzi.
- Kopia pliku i zapis ustawień są poza katalogiem publicznym. Dla generatora zapisano zmienione pole/kod; dla nowego pliku — fakt, że wcześniej nie istniał.
- Wycofanie polega na odtworzeniu dokładnie zmienionego pliku lub ustawienia, a następnie ponownym sprawdzeniu HTTP i cache. Nie nadpisuje innych, późniejszych zmian strony.
Jeżeli po tych kontrolach indeksacja nadal jest niezgodna z celem, kolejnym krokiem jest sprawdzenie canonicali, linków wewnętrznych, odpowiedzi URL i danych GSC, nie rozbudowywanie robots.txt na ślepo. Taki zakres obejmuje [audyt techniczny SEO](https://webalpha.pl/seo/audyt); bieżącą kontrolę zmian można połączyć z [opieką nad stroną WordPress](https://webalpha.pl/opieka-techniczna/strony).
## Robots.txt wygląda poprawnie, a ważne strony nadal są wykluczone?
Prześlij adres strony i opis problemu z indeksacją. Ustalimy zakres analizy odpowiedzi serwera, reguł robotów, canonicali, sitemap i danych Search Console. Nie przesyłaj haseł, kopii bazy ani plików konfiguracyjnych przez formularz.
[Sprawdź zakres audytu SEO](https://webalpha.pl/seo/audyt)
## Najczęstsze pytania (FAQ)
### Gdzie jest robots.txt w WordPress, skoro nie ma go na FTP?
Sprawdź /robots.txt w katalogu głównym właściwego hosta przez HTTP. Przy braku pliku fizycznego WordPress może generować odpowiedź wirtualną. Brak pliku na FTP nie jest błędem, jeśli endpoint i reguły działają zgodnie z założeniem.
### Czy robots.txt trzeba tworzyć ręcznie?
Nie, jeśli generator już podaje właściwe reguły. Plik fizyczny warto tworzyć dopiero po świadomym wyborze sposobu zarządzania i potwierdzeniu routingu. Może przesłonić ustawienia WordPressa lub wtyczki.
### Czy Disallow: / usuwa stronę z Google?
Nie gwarantuje usunięcia URL z wyników. Ogranicza pobieranie przez roboty przestrzegające reguł. Dla publicznej strony HTML, którą chcesz wyłączyć z indeksu, użyj dostępnego do odczytu noindex; dane prywatne chroń kontrolą dostępu.
### Czy robots.txt z błędem 404 blokuje całą stronę?
Nie. Google traktuje 404 tego endpointu jako brak dostępnego pliku reguł. Usunięcie fizycznego pliku w WordPress może jednak przywrócić wersję wirtualną z kodem 200, więc status trzeba faktycznie odczytać.
### Dlaczego wp-sitemap.xml zwraca 404?
Sprawdź widoczność witryny, aktywnego dostawcę map i routing. Mapy core są domyślnie powiązane z blog_public; wtyczka SEO może je wyłączać i udostępniać inny indeks. Nie zmieniaj prywatnej witryny w publiczną wyłącznie po to, by usunąć 404 mapy.
### Czy po poprawieniu robots.txt Google od razu zaindeksuje stronę?
Nie ma takiej gwarancji. Najpierw sprawdź publiczną odpowiedź, potem ostatnie pobranie robots.txt i inspekcję URL w GSC. Odświeżenie reguł, ponowne pobranie podstrony i decyzja o jej indeksacji to odrębne etapy.