Robots.txt w WordPress: plik fizyczny, wirtualny, sitemap i noindex

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ę

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.

Najpierw wybierz właściwy mechanizm: robots.txt, noindex czy hasło

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.

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.

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.

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. 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

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. Wirtualny plik generuje funkcja do_robots(), a wtyczki mogą zmieniać jego tekst przez filtr robots_txt.

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(), kod metatagów WordPress 7.1 i historia do_robots(). Motyw, wtyczka i nagłówki hostingu mogą zmienić rezultat; rozstrzyga odpowiedź strony, nie sam checkbox.

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 <head> — metatagi robots i googlebot. Przykład intencji wyłączenia indeksacji HTML to <meta name="robots" content="noindex">. 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.

Warunek dostępności strony oraz dwa obsługiwane miejsca dla noindex opisuje Google: blokowanie indeksowania za pomocą noindex. 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ą.

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(), dopisanie mapy w WP_Sitemaps::add_robots(), a odpowiedź wyłączonego endpointu w kodzie sitemaps WordPress 7.1.

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

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. Potrzebę udostępnienia istotnych zasobów renderowania wyjaśnia Google 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.

Oficjalne źródła, sposób wywołania i ograniczenia są w repozytorium Google przypiętym do testowanego commitu. 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.

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.

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ź

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.

<?php
/**
 * Plugin Name: WebAlpha — correction of confirmed WordPress asset blocks
 * Description: Narrow correction for a public root install with one wildcard group.
 * Version: 1.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

function webalpha_robots_allow_wp_resources( $output, $public ) {
    if ( ! $public ) {
        return $output;
    }

    // Fail closed on an unfamiliar policy. This is an input guard, NOT a
    // substitute for Google's parser or a universal robots.txt editor.
    $groups = 0;
    foreach ( preg_split( '/\r\n|\n|\r/', $output ) as $line ) {
        $line = trim( explode( '#', $line, 2 )[0] );
        if ( '' === $line ) {
            continue;
        }
        if ( ! preg_match( '/^(User-agent|Disallow|Allow|Sitemap)[\t ]*:[\t ]*(.*)$/i', $line, $parts ) ) {
            return $output;
        }
        if ( 'user-agent' === strtolower( $parts[1] ) ) {
            ++$groups;
            if ( '*' !== trim( $parts[2] ) ) {
                return $output;
            }
        }
    }
    if ( 1 !== $groups ) {
        return $output;
    }

    // Only these two complete, confirmed erroneous root-path directives.
    // Do NOT remove narrower rules such as /wp-content/private/.
    $corrected = preg_replace(
        '/(*ANYCRLF)^[\t ]*(?i:Disallow)[\t ]*:[\t ]*\/(?:wp-content|wp-includes)\/[\t ]*(?:#[^\r\n]*)?(?:\r\n|\n|\r|$)/m',
        '',
        $output
    );
    return is_string( $corrected ) ? $corrected : $output;
}

add_filter( 'robots_txt', 'webalpha_robots_allow_wp_resources', 99, 2 );

Mechanizm opiera się na oficjalnym filtrze robots_txt. Automatyczne ładowanie pliku, jego lokalizację i ograniczenia utrzymania opisuje dokumentacja Must Use Plugins WordPress. Nie kopiujemy zamieszczanych przez użytkowników przykładowych blokad obrazów i zasobów z komentarzy do dokumentacji.

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.

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

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.

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.

# 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. Odpowiedź uzyskana z localhost potwierdza jedynie zachowanie naszej konfiguracji HTTP. Nie jest testem indeksowania w wyszukiwarce.

Rzeczywisty wynik naszego ćwiczenia

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

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, a odświeżanie pliku — Google: aktualizacja 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

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; bieżącą kontrolę zmian można połączyć z opieką nad stroną WordPress.