-
×
25 linków SEO AI
1 × 350,00 zł
Aktualizacja: 9 stycznia 2026
Sprawdzenie, czy noindex blokuje stronę w Google, polega na potwierdzeniu dyrektywy w odpowiedzi serwera i skonfrontowaniu jej z danymi z Google Search Console.
- obecność noindex w meta robots
- obecność noindex w nagłówku X-Robots-Tag
- wynik Inspekcji adresu URL w Google Search Console
Szybkie fakty
- Noindex może występować w kodzie strony (meta robots) albo w nagłówkach HTTP (X-Robots-Tag).
- Jeśli adres URL jest zablokowany w robots.txt, robot może nie zobaczyć noindex i strona może nadal pojawiać się w wynikach.
- Weryfikacja powinna obejmować: widok źródła HTML, nagłówki HTTP oraz Inspekcję URL w GSC.
- Noindex działa po ponownym odwiedzeniu strony przez robota (czas bywa różny w zależności od sygnałów i częstotliwości skanowania).
- Najczęstszy błąd to „noindex ustawiony gdzie indziej niż się zakłada” (np. na wersji kanonicznej, w szablonie, w regułach serwera).
Co oznacza noindex i gdzie może się pojawić
Noindex to dyrektywa, której celem jest wyłączenie konkretnej strony (lub zasobu) z indeksu wyszukiwarki. Najczęściej wdrażana jest na dwa sposoby: w kodzie HTML jako meta robots albo na poziomie serwera jako nagłówek HTTP. W praktyce diagnostyka zaczyna się od ustalenia, czy dyrektywa istnieje, a następnie od potwierdzenia, że robot ma możliwość ją zobaczyć (brak blokady skanowania).
Meta robots w HTML
Meta robots znajduje się w sekcji <head>. Występuje w wariantach ogólnych (dla robotów) lub kierowanych do konkretnego robota (np. Googlebot).
<meta name="robots" content="noindex">
<meta name="googlebot" content="noindex">X-Robots-Tag w nagłówkach HTTP
X-Robots-Tag jest przesyłany w nagłówkach odpowiedzi serwera. Ten wariant jest popularny przy zasobach innych niż HTML (PDF, grafiki, wideo), ale bywa też stosowany globalnie dla wybranych ścieżek lub typów plików.
X-Robots-Tag: noindexChecklista: jak szybko potwierdzić, czy noindex blokuje URL
Krok 1: sprawdzenie meta robots w kodzie strony
Należy otworzyć adres URL w przeglądarce, a następnie sprawdzić źródło HTML (funkcja „Wyświetl źródło strony” lub podgląd HTML w narzędziach deweloperskich). W sekcji <head> trzeba wyszukać frazy: noindex, meta name="robots", meta name="googlebot".
Jeśli strona generuje kod dynamicznie, kontrola powinna obejmować także HTML po renderowaniu (np. w zakładce Elements), bo część wdrożeń bywa wstrzykiwana w runtime.
Krok 2: sprawdzenie nagłówków odpowiedzi HTTP
Najpewniejsze jest odczytanie nagłówków na poziomie serwera. Do weryfikacji wystarczy komenda:
curl -I https://twojadomena.pl/twoj-url/W odpowiedzi należy wyszukać X-Robots-Tag i wartości typu noindex albo none. Warto też zweryfikować status HTTP (najczęściej 200), bo nietypowe odpowiedzi (np. 3xx, 4xx) potrafią komplikować diagnozę.
Krok 3: weryfikacja w Google Search Console (Inspekcja URL)
Inspekcja URL pozwala zestawić to, co serwer faktycznie zwraca, z tym, co widzi Googlebot. W raporcie należy sprawdzić:
- czy strona jest dopuszczona do skanowania,
- czy Google wykrył dyrektywę noindex,
- jaki jest stan „Czy strona jest w Google”.
Interpretacja ma sens dopiero po porównaniu: kod i nagłówki po stronie serwera vs. dane diagnostyczne z GSC. Pomocniczo przydatny bywa też wpis o czytaniu raportu „Strony” w GSC: Raport indeksowanie stron w GSC — jak czytać statusy.
Najczęstsze scenariusze, gdy noindex „jest”, ale strona nadal widnieje w Google
Robot nie ma dostępu do strony (robots.txt lub inna blokada skanowania)
Jeśli skanowanie jest zablokowane, robot może nie odczytać reguł indeksowania z HTML lub nagłówków. Dokumentacja Google opisuje to wprost:
„Aby wyszukiwarki stosowały się do reguł indeksowania i wyświetlania, adresy URL stron zawierających te reguły muszą być dostępne do skanowania.” Źródło: Google Search Central (robots meta / X-Robots-Tag) — developers.google.com
W takiej sytuacji diagnoza powinna objąć reguły robots.txt. Pomocniczo można odnieść się do artykułu o blokowaniu podstron w robots.txt: Jakie podstrony blokować w plikach robots.txt.
Noindex wdrożony na innej wersji URL niż analizowana
Różnice między wersjami z ukośnikiem i bez, parametrami UTM, wersją HTTP/HTTPS lub www/non-www często powodują, że noindex występuje na jednym wariancie, a drugi pozostaje bez dyrektywy. Weryfikacja nagłówków i źródła powinna zostać wykonana dla dokładnie tego adresu URL, który jest widoczny w wynikach.
Noindex w szablonie, a nie w konkretnej podstronie
W CMS-ach dyrektywa bywa ustawiona globalnie (np. na typ treści) albo zależnie od warunku (np. brak produktu na stanie, strona paginacji, filtr). Wtedy porównanie kilku URL-i tego samego typu pomaga zawęzić przyczynę.
Brak ponownego odwiedzenia po wdrożeniu noindex
Po wdrożeniu noindex Google musi ponownie odwiedzić stronę, żeby wyodrębnić dyrektywę. Google zwraca uwagę, by nie blokować dostępu robotowi, bo wtedy noindex nie zadziała:
„Ważne: aby reguła
noindexdziałała poprawnie, nie możesz blokować strony lub zasobu w pliku robots.txt.” Źródło: Google Search Central (blokowanie indeksowania noindex) — developers.google.com
Konflikty: noindex, robots.txt i canonical — jak je rozdzielić
W diagnozie blokad indeksacji często pojawiają się jednocześnie sygnały z kilku mechanizmów. Poniższa tabela ułatwia rozpoznanie, co faktycznie blokuje indeksowanie, a co jedynie utrudnia diagnozę.
| Mechanizm | Gdzie występuje | Jak potwierdzić | Typowy skutek | Następny krok |
|---|---|---|---|---|
| noindex | HTML (meta) lub nagłówki HTTP | Źródło strony + nagłówki + Inspekcja URL | Wykluczenie z indeksu po ponownym odwiedzeniu | Usunąć noindex lub dopuścić skanowanie, jeśli ma działać |
| robots.txt | Plik /robots.txt | Test reguł + Inspekcja URL | Robot nie pobiera treści, więc nie widzi meta/noindex | Odblokować URL, jeśli ma zostać odczytany noindex lub treść |
| canonical | HTML (rel=canonical) lub nagłówki | Źródło strony + Inspekcja URL (kanoniczny wybrany przez Google) | Google może indeksować inną stronę jako kanoniczną | Sprawdzić i ujednolicić sygnały kanoniczne |
Jeśli podejrzenie dotyczy kanoniczności, pomocny jest materiał o linkach kanonicznych: Linki kanoniczne — rel=canonical w SEO.
Google Search Console czy nagłówki serwera: które źródło lepiej potwierdza noindex w diagnostyce
Nagłówki serwera i źródło HTML pokazują stan wdrożenia „tu i teraz”, ale nie potwierdzają, czy robot widzi dokładnie tę samą wersję treści w procesie skanowania. Google Search Console prezentuje perspektywę robota i jest bliższa rzeczywistemu efektowi indeksowania. Najlepszą metodą jest zestawienie obu: nagłówki/HTML wykrywają wdrożenie, a Inspekcja URL potwierdza odczyt po stronie Google. Przy doborze źródeł do diagnozy priorytet mają dane z narzędzi Google (oficjalne), a materiały branżowe służą do interpretacji typowych wdrożeń i pułapek.
Dodatkowe testy, które przyspieszają diagnozę
Sprawdzenie przekierowań i wariantów URL
Jeśli URL przekierowuje (301/302), noindex może dotyczyć strony docelowej, a nie adresu wejściowego. Dlatego w curl -I należy zwrócić uwagę na: Location, status 3xx oraz końcowy URL po przekierowaniu.
Weryfikacja na poziomie cache i CDN
Część wdrożeń noindex bywa dodawana warunkowo przez warstwę cache/CDN (np. na podstawie nagłówków, cookies, geolokalizacji). Wtedy porównanie odpowiedzi dla kilku zapytań (np. z i bez cookies, różne nagłówki User-Agent) potrafi ujawnić rozjazd między tym, co widzi użytkownik, a tym, co widzi robot.
Ustalenie, czy robots.txt jest „prośbą”, a nie autoryzacją
Robots Exclusion Protocol opisuje robots.txt jako mechanizm reguł dla crawlerów, a nie jako system kontroli dostępu. W RFC 9309 zapisano:
“These rules are not a form of access authorization.” Źródło: RFC 9309 (Robots Exclusion Protocol) — rfc-editor.org
To rozróżnienie ma znaczenie przy ocenie ryzyka: robots.txt nie zabezpiecza zasobów, a jedynie komunikuje reguły dla crawlerów.
Mini-FAQ
Czy noindex działa, jeśli strona jest zablokowana w robots.txt?
Nie jest to poprawna konfiguracja diagnostyczna, bo robot może nie odczytać dyrektywy. Jeśli celem jest wykluczenie z indeksu, strona musi być dostępna do skanowania przynajmniej do czasu odczytu noindex.
Czy noindex usuwa stronę natychmiast z wyników Google?
Efekt pojawia się po ponownym odwiedzeniu strony przez robota i przetworzeniu sygnałów. Czas zależy od częstotliwości skanowania i znaczenia URL w strukturze witryny.
Co jest pewniejsze: meta robots czy X-Robots-Tag?
Oba mechanizmy mogą dawać taki sam efekt, różnią się miejscem wdrożenia. Meta robots dotyczy HTML, a X-Robots-Tag sprawdza się także dla zasobów nie-HTML i wdrożeń na poziomie serwera.
Dlaczego GSC nie pokazuje noindex, mimo że w kodzie jest noindex?
Najczęstsze przyczyny to blokada skanowania (robots.txt), rozjazd wariantów URL (przekierowania, parametry), cache/CDN lub warunkowe generowanie meta w zależności od kontekstu. Weryfikacja nagłówków i Inspekcji URL zwykle wskazuje różnicę.
Czy canonical może „przykryć” noindex?
Canonical dotyczy wyboru wersji preferowanej do indeksowania, a noindex dotyczy samej indeksacji URL. Jeśli Google wybiera inną stronę jako kanoniczną, analiza powinna objąć oba adresy: ten z noindex i ten wskazywany jako kanoniczny.
Gdzie sprawdzić pełny status indeksowania, gdy wynik w SERP wydaje się sprzeczny?
Najbardziej użyteczne jest zestawienie Inspekcji URL z raportem „Strony” w GSC oraz kontrola nagłówków HTTP. Pomocniczo można też wrócić do artykułu o sprawdzaniu indeksacji: jak sprawdzić, czy strona jest zaindeksowana w Google.
Źródła
- Google Search Central — Specyfikacje metatagów robots (cytat użyty w treści)
- Google Search Central — Blokowanie indeksowania przez noindex (cytat użyty w treści)
- RFC 9309 — Robots Exclusion Protocol (PDF; cytat użyty w treści)
- Senuto — materiał o indeksacji i znacznikach meta robots senuto.com
- Semcore — materiał o noindex i wdrożeniach semcore.pl
