Po migracji WordPress może działać technicznie poprawnie, zwracać HTTP 200 i być dostępny dla użytkowników, a mimo to pozostać wyłączony z indeksowania. Najczęstszy problem to nie DNS ani hosting, lecz pozostawiona blokada używana wcześniej na stagingu lub podczas prac wdrożeniowych.
Dlatego po przełączeniu strony warto sprawdzić kilka niezależnych warstw: ustawienie WordPressa, meta robots, nagłówki HTTP, robots.txt oraz canonical.
„Strona działa” i „strona może być indeksowana” to dwie różne rzeczy. HTTP 200 nie mówi nic o tym, czy robot wyszukiwarki dostał polecenie
noindex.
Najpierw sprawdź, gdzie dokładnie pojawia się blokada
Najważniejsze jest rozróżnienie, czy problem występuje:
- w HTML jako meta robots,
- w nagłówku HTTP jako
X-Robots-Tag, - w ustawieniu WordPressa lub pluginu SEO generującym takie dyrektywy,
- czy dotyczy dostępu crawlera przez
robots.txt, - czy zamiast blokady indeksowania witryna wysyła nieprawidłowy sygnał canonical.
| Co widzisz | Co oznacza |
|---|---|
<meta name="robots" content="noindex"> | Dokument przekazuje robotowi dyrektywę noindex |
X-Robots-Tag: noindex | Dyrektywa została przekazana w nagłówku HTTP |
Disallow: / w robots.txt | Crawler otrzymuje zakaz crawlowania ścieżek, ale to nie jest to samo co noindex |
| Canonical wskazuje staging lub starą domenę | Wysyłany jest nieprawidłowy sygnał kanonikalizacji i wyszukiwarka może preferować inny wariant URL |
Te mechanizmy rozwiązują różne problemy, dlatego nie należy traktować ich jako zamienników.
Skąd może pochodzić noindex?
Ustawienie WordPressa
WordPress ma ustawienie w sekcji:
Ustawienia → Czytanie → Widoczność dla wyszukiwarek
Ustawienie „Widoczność dla wyszukiwarek” zmienia opcję blog_public. Gdy indeksowanie jest zniechęcane, WordPress generuje dla publicznych stron dyrektywę noindex oraz nofollow.
W aktualnych wersjach WordPressa samo to ustawienie nie dodaje domyślnego Disallow: / do robots.txt, dlatego meta robots i robots.txt trzeba diagnozować osobno.
Na stagingu takie ustawienie jest rozsądnym zabezpieczeniem, ale po migracji na produkcję łatwo o nim zapomnieć. Jeżeli cała nowa witryna ma noindex, ten punkt jest jednym z pierwszych do sprawdzenia.
Plugin SEO, motyw albo własny kod
Nawet przy poprawnym ustawieniu globalnym konkretna podstrona może mieć noindex nadawany przez plugin SEO, motyw albo własny kod.
Sprawdź przede wszystkim:
- czy noindex dotyczy całej witryny czy jednego typu stron,
- czy plugin SEO ma ustawienia dla archiwów, kategorii, autorów lub custom post types,
- czy pojedynczy wpis nie ma własnego ustawienia robots,
- czy motyw lub własny kod nie dodaje meta robots warunkowo.
To ważne po migracji między środowiskami, jeśli konfiguracja pluginu została przeniesiona razem z bazą danych. Ustawienie poprawne dla stagingu może wtedy zostać skopiowane 1:1 na produkcję.
X-Robots-Tag
Dyrektywy robots mogą być wysyłane również w nagłówkach HTTP przez X-Robots-Tag. To szczególnie istotne przy plikach innych niż HTML, ale może dotyczyć także zwykłych stron.
Dlatego brak noindex w źródle HTML nie kończy diagnostyki. Warto sprawdzić odpowiedź HTTP i upewnić się, że nie zawiera na przykład:
X-Robots-Tag: noindexTaki nagłówek może zostać dodany przez konfigurację serwera, CDN, plugin bezpieczeństwa, własny kod albo inną warstwę infrastruktury.
robots.txt i noindex to nie to samo
Plik robots.txt służy przede wszystkim do sterowania crawlingiem. Reguła:
User-agent: *
Disallow: /informuje crawlera, żeby nie pobierał wskazanych ścieżek. Nie jest jednak odpowiednikiem meta robots noindex.
Jeżeli Googlebot nie może pobrać strony z powodu robots.txt, nie zobaczy znajdującej się w HTML dyrektywy noindex. Sam URL może mimo to zostać rozpoznany i w pewnych sytuacjach pojawić się w wynikach bez treści strony. Dlatego robots.txt nie powinien być traktowany jako zamiennik noindex.
Po migracji warto sprawdzić zarówno publiczny /robots.txt, jak i rzeczywiste dyrektywy robots generowane na stronie.
Canonical po migracji może nadal wskazywać staging lub starą domenę
Strona może nie mieć noindex, a mimo to wysyłać wyszukiwarce nieprawidłowy sygnał kanonikalizacji.
Canonical jest sygnałem wyboru preferowanego reprezentatywnego URL-a, a nie dyrektywą blokującą indeksowanie. Google może wybrać inny URL kanoniczny niż ten wskazany w kodzie.
Po przeniesieniu witryny sprawdź, czy canonical:
- używa docelowej domeny,
- ma właściwy protokół HTTPS,
- nie wskazuje środowiska stagingowego,
- nie prowadzi do starej domeny,
- odpowiada właściwemu URL-owi strony.
Nieprawidłowy canonical i noindex to różne mechanizmy. Nie należy więc „naprawiać indeksowania” zmianą canonical, jeśli dokument rzeczywiście wysyła dyrektywę noindex.
Jeżeli po migracji występują także problemy z domeną lub DNS, warto sprawdzić diagnostykę domeny przed migracją.
Cache może nadal podawać starą wersję z noindex
Po zmianie ustawienia WordPressa lub pluginu SEO publiczna strona nie zawsze zmieni się natychmiast we wszystkich warstwach.
Stary HTML może znajdować się w:
- page cache WordPressa,
- cache serwera,
- CDN,
- reverse proxy,
- wygenerowanych statycznie stronach.
Dlatego po usunięciu noindex trzeba sprawdzić rzeczywistą odpowiedź publicznego URL-a, a nie tylko ustawienie widoczne w panelu.
Najpierw napraw źródło dyrektywy, później odśwież odpowiednią warstwę cache i ponownie pobierz stronę.
Nie wystarczy sprawdzić tylko strony głównej
Po migracji warto przetestować kilka reprezentatywnych typów URL-i. Globalne ustawienie może być poprawne, ale plugin SEO nadal może mieć osobne reguły dla archiwów albo produktów.
Dobry zestaw kontrolny obejmuje na przykład:
- homepage,
- zwykłą podstronę,
- wpis,
- kategorię lub archiwum,
- produkt WooCommerce, jeśli sklep istnieje,
- ważny landing SEO.
Dla każdego sprawdź status HTTP, meta robots, X-Robots-Tag i canonical. Dzięki temu szybko widać, czy problem jest globalny, czy związany z konkretnym typem treści.
Po naprawie strona nie wraca do indeksu natychmiast
Usunięcie noindex przywraca możliwość indeksowania, ale nie oznacza natychmiastowego powrotu URL-a do wyników wyszukiwania. Wyszukiwarka musi stronę ponownie pobrać i przetworzyć.
Po poprawce sprawdź publiczną odpowiedź jeszcze raz. Dla ważnych URL-i warto również zweryfikować stan w Google Search Console przez URL Inspection i w razie potrzeby poprosić o ponowne zindeksowanie.
Trzeba przy tym rozdzielić dwie rzeczy: techniczny brak blokady oraz faktyczne ponowne pojawienie się strony w indeksie. To drugie może nastąpić później.
Bezpieczna procedura kontroli indeksowania po migracji
- Sprawdź HTTP status docelowego URL-a.
- Odczytaj meta robots w finalnym HTML.
- Sprawdź nagłówki pod kątem X-Robots-Tag.
- Zweryfikuj ustawienie widoczności wyszukiwarek w WordPressie.
- Sprawdź reguły pluginu SEO dla danego typu treści.
- Otwórz publiczny robots.txt.
- Sprawdź canonical.
- Usuń źródło błędnej dyrektywy.
- Odśwież odpowiednią warstwę cache.
- Powtórz kontrolę na kilku typach URL-i.
- Dla ważnych stron sprawdź stan w URL Inspection i uwzględnij czas potrzebny na ponowny crawl.
Jeżeli strona po migracji zmieniła adresy, a stare URL-e nadal występują w treści lub ustawieniach, przydatny może być także poradnik o wyszukiwaniu starych adresów po migracji.
Najważniejsze wnioski
- HTTP 200 nie oznacza automatycznie, że strona może być indeksowana;
- ustawienie WordPressa zmienia
blog_publici może generowaćnoindexoraznofollow, ale nie jest tym samym coDisallow: /w robots.txt; - noindex może pochodzić z meta robots albo nagłówka X-Robots-Tag;
- plugin SEO może nadawać robots osobno dla konkretnych typów treści;
- robots.txt steruje crawlingiem i nie jest tym samym co noindex;
- canonical jest sygnałem kanonikalizacji, a nie dyrektywą blokującą indeksowanie;
- cache może nadal podawać starą stronę z noindex po poprawieniu ustawień;
- po migracji warto sprawdzić kilka typów URL-i, a nie tylko homepage;
- usunięcie blokady przywraca możliwość indeksowania, ale faktyczny recrawl i powrót do indeksu mogą nastąpić później.
Źródła
- WordPress Developer Resources — wp_robots_noindex() — zachowanie
blog_publici generowanie noindex/nofollow. - WordPress Developer Resources — do_robots() — aktualne zachowanie domyślnego robots.txt WordPressa.
- WordPress Developer Resources — wp_robots() — generowanie meta robots.
- Google Search Central — Robots meta tag and X-Robots-Tag — noindex w HTML i nagłówkach HTTP.
- Google Search Central — Introduction to robots.txt — crawling i rola robots.txt.
- Google Search Central — robots.txt specification — zachowanie zablokowanych URL-i i relacja z noindex.
- Google Search Central — Canonicalization — canonical jako sygnał wyboru reprezentatywnego URL-a.
- Google Search Console Help — URL Inspection tool — sprawdzanie stanu URL-a i żądanie ponownego indeksowania.