Robots.txt a noindex: jak kontrolować indeksowanie strony w Google?

Kontrola indeksowania nie polega na dodaniu jednej uniwersalnej reguły. Najpierw trzeba ustalić, czy Google ma nie odwiedzać danego adresu, nie umieszczać go w wynikach wyszukiwania, wskazać inną wersję jako główną czy całkowicie wycofać URL z serwisu. Każdy z tych celów wymaga innego rozwiązania.

Plik robots.txt steruje dostępem crawlerów do określonych ścieżek. Dyrektywa noindex dotyczy natomiast obecności strony w indeksie. Połączenie tych mechanizmów bez zrozumienia kolejności działania może przynieść efekt odwrotny do zamierzonego: Google nie odczyta dyrektywy noindex albo nadal będzie wyświetlać sam adres URL.

Temat ma szczególne znaczenie podczas migracji, zmian CMS-a, wdrożeń wersji testowych i porządkowania rozbudowanej struktury serwisu. W takich sytuacjach kontrolę dyrektyw warto uwzględnić w ramach działań SEO i SEM.

Więcej praktycznych materiałów dotyczących widoczności stron znajdziesz na naszym blogu.

Najważniejsze informacje

• Robots.txt określa, które adresy zgodny crawler może pobierać. Nie jest narzędziem do trwałego usuwania stron z wyników wyszukiwania.
• Noindex informuje wyszukiwarkę, że strona lub plik nie powinny trafić do indeksu. Żeby Google odczytał tę regułę, musi mieć dostęp do adresu.
• Canonical, przekierowanie, status 404 lub 410 oraz ochrona hasłem rozwiązują inne problemy niż robots.txt i noindex. Nie należy używać ich zamiennie.
• Po każdej zmianie trzeba sprawdzić odpowiedź serwera, dyrektywy, canonical i status adresu w Google Search Console.

Crawlowanie i indeksowanie to dwa różne etapy

Google najpierw musi odkryć adres URL, a następnie może spróbować go pobrać. Dopiero po analizie zawartości podejmuje decyzję, czy i w jakiej formie umieścić stronę w indeksie. Crawlowanie oznacza odwiedzanie adresu przez robota, a indeksowanie to przetwarzanie i przechowywanie informacji potrzebnych do wyświetlania wyniku.

Adres może być znany Google nawet wtedy, gdy jego zawartość została zablokowana w robots.txt. Wyszukiwarka może odkryć URL przez linki zewnętrzne, linkowanie wewnętrzne lub mapę strony. W takim przypadku sam adres może pojawić się w wynikach bez standardowego opisu, ponieważ Google zna URL, ale nie mógł pobrać treści.

Dyrektywa noindex działa dopiero po pobraniu strony lub pliku. Jeżeli crawler nie może wejść na adres, nie zobaczy ustawienia wyłączającego stronę z indeksu. To dlatego jednoczesne zablokowanie adresu w robots.txt i ustawienie na nim noindex jest jednym z najczęstszych błędów technicznego SEO.

Czym jest robots.txt i co naprawdę kontroluje?

Robots.txt to publiczny plik tekstowy umieszczany w katalogu głównym hosta. Zawarte w nim reguły informują crawlery, które ścieżki mogą lub nie mogą być przez nie pobierane. Plik nie blokuje dostępu użytkownikom i nie stanowi zabezpieczenia przed botami, które nie respektują protokołu.

Zakres pliku jest precyzyjny. Reguły obowiązują tylko dla tego samego protokołu, hosta i portu, na którym znajduje się robots.txt. Oznacza to, że ustawienia dla głównej domeny nie muszą obejmować subdomeny, innego protokołu lub oddzielnej wersji serwisu.

Najważniejsze elementy robots.txt

• User-agent wskazuje crawlera, którego dotyczą kolejne reguły. Zapis ogólny może obejmować wszystkie roboty respektujące protokół.
• Disallow określa ścieżki, których crawler nie powinien pobierać.
• Allow pozwala zrobić wyjątek wewnątrz zablokowanej sekcji.
• Sitemap wskazuje lokalizację mapy XML. Nie blokuje i nie zezwala na crawlowanie, ale pomaga przekazać wyszukiwarce adres mapy strony.
• Wielkość liter w ścieżkach ma znaczenie, dlatego dwie pozornie podobne reguły mogą dotyczyć innych adresów.
• Google nie obsługuje w robots.txt polecenia crawl-delay ani noindex.

W praktyce robots.txt może ograniczyć dostęp robotów do panelu, wewnętrznych wyników wyszukiwania lub wybranych parametrów. Nie oznacza to jednak, że takie adresy zostaną automatycznie usunięte z indeksu.

Kiedy używać robots.txt?

Robots.txt ma sens wtedy, gdy głównym celem jest ograniczenie pobierania określonych grup adresów lub plików. Jest szczególnie przydatny w dużych i technicznie złożonych serwisach.

• ograniczanie crawlowania wewnętrznych wyników wyszukiwania i bardzo dużej liczby kombinacji parametrów,
• blokowanie technicznych ścieżek, które nie mają znaczenia dla wyszukiwarki,
• kontrolowanie dostępu konkretnych crawlerów do wybranych sekcji,
• ograniczanie pułapek crawlowania, takich jak kalendarze generujące nieograniczoną liczbę adresów,
• czasowe zmniejszanie liczby pobieranych wariantów URL-i po wcześniejszej analizie struktury.

Nie należy natomiast blokować plików CSS i JavaScript potrzebnych do prawidłowego renderowania strony. Jeżeli Google nie może pobrać zasobów niezbędnych do zrozumienia układu lub treści, analiza strony może być mniej dokładna.

Do czego robots.txt nie służy?

• do ochrony danych poufnych lub prywatnych,
• do trwałego usuwania stron z wyników wyszukiwania,
• do wskazywania wersji kanonicznej adresu,
• do przekierowywania użytkowników i robotów na nowy URL,
• do ukrywania wersji testowej serwisu przed osobami, które znają jej adres.

Jeżeli treść nie może być publicznie dostępna, potrzebna jest autoryzacja, logowanie, ograniczenie dostępu po adresach IP albo inne zabezpieczenie na poziomie serwera. Robots.txt jest publiczny i może wręcz ujawnić nazwy ścieżek, których właściciel nie chce eksponować.

Czym jest noindex i jak go wdrożyć?

Noindex to dyrektywa indeksowania. Informuje wyszukiwarki obsługujące tę regułę, że dana strona lub zasób nie powinny pojawiać się w wynikach wyszukiwania. Użytkownik nadal może wejść na adres bezpośrednio, a sam plik może być dostępny publicznie.

W przypadku stron HTML noindex najczęściej ustawia się w metadanych strony. Reguła może dotyczyć wszystkich robotów obsługujących to polecenie albo wyłącznie Googlebota. W praktyce wybór zależy od tego, czy strona ma zostać wyłączona ze wszystkich wyszukiwarek, czy tylko z wyników Google.

W przypadku plików innych niż HTML, takich jak PDF, obraz lub materiał wideo, noindex można przekazać w nagłówku odpowiedzi serwera za pomocą ustawienia X-Robots-Tag. Oba rozwiązania mają ten sam cel. Różnią się jedynie sposobem wdrożenia i typem zasobu, przy którym są najpraktyczniejsze.

W każdym przypadku Googlebot musi mieć możliwość pobrania adresu. Jeżeli strona lub plik są zablokowane w robots.txt, wyszukiwarka może nie zobaczyć dyrektywy noindex.

Kiedy noindex jest właściwym rozwiązaniem?

• strony podziękowania po wysłaniu formularza,
• wewnętrzne wyniki wyszukiwania, które nie stanowią wartościowych stron docelowych,
• publiczne podstrony użytkowe, które muszą działać, ale nie powinny pozyskiwać ruchu z Google,
• wybrane archiwa lub warianty stron bez samodzielnej wartości wyszukiwawczej,
• pliki PDF i inne zasoby, które mają być dostępne z linku, ale nie powinny pojawiać się w wynikach.

Noindex nie powinien być automatyczną odpowiedzią na każdą stronę o słabej jakości. Czasem właściwsze będzie optymalizacja SEO: poprawienie treści, połączenie kilku adresów, wskazanie wersji kanonicznej albo przekierowanie. Decyzja powinna wynikać z funkcji URL-a, a nie z chęci szybkiego ukrycia problemu.

Jak długo trwa usunięcie strony po dodaniu noindex?

Zmiana nie jest natychmiastowa. Google musi ponownie odwiedzić adres i odczytać dyrektywę. W przypadku pojedynczej ważnej strony można poprosić o ponowne sprawdzenie adresu w Google Search Console. Przy dużej liczbie stron trzeba monitorować raport indeksowania i poczekać na kolejne crawlowanie.

Jeżeli wynik trzeba ukryć szybko i tymczasowo, można skorzystać z narzędzia Usunięcia w Search Console. Taka blokada nie jest rozwiązaniem trwałym i musi zostać połączona z noindex, usunięciem treści albo zabezpieczeniem dostępu.

Robots.txt a noindex: najważniejsza różnica

• Robots.txt odpowiada za to, czy crawler może pobierać określone ścieżki.
• Noindex odpowiada za to, czy dostępna strona lub plik mają znaleźć się w indeksie.
• Adres zablokowany w robots.txt może nadal być znany Google i pojawić się w wynikach bez standardowego opisu.
• Adres z noindex powinien zniknąć z wyników po ponownym pobraniu i przetworzeniu strony przez wyszukiwarkę.
• Noindex nie chroni treści przed użytkownikami. Robots.txt również nie jest zabezpieczeniem dostępu.

Robots.txt, noindex, canonical, przekierowanie czy 404?

Najczęstsze błędy wynikają z próby rozwiązania różnych problemów jednym mechanizmem. Przed wdrożeniem trzeba określić docelowy stan adresu.

• Jeśli crawler nie powinien pobierać dużej grupy adresów, właściwym narzędziem może być robots.txt.
• Jeśli strona ma działać, ale nie powinna pojawiać się w wynikach, właściwe będzie noindex.
• Jeśli kilka adresów prezentuje tę samą lub bardzo podobną treść, należy wskazać wersję kanoniczną.
• Jeśli treść została trwale przeniesiona, należy zastosować przekierowanie stałe.
• Jeśli zasób został trwale usunięty i nie ma odpowiednika, powinien zwracać status 404 lub 410.
• Jeśli treść ma być dostępna tylko dla wybranych osób, potrzebne jest logowanie, hasło lub inne zabezpieczenie dostępu.
• Jeśli wynik trzeba szybko ukryć w Google, narzędzie Usunięcia może zadziałać tymczasowo, ale równolegle trzeba wdrożyć rozwiązanie trwałe.

Najczęstsze błędy przy robots.txt i noindex

• Jednoczesne zablokowanie adresu w robots.txt i ustawienie na nim noindex. Crawler nie może pobrać strony, więc może nie zobaczyć dyrektywy wyłączenia z indeksu.
• Dodawanie noindex bezpośrednio do pliku robots.txt. Google nie obsługuje takiego zastosowania.
• Traktowanie robots.txt jak zabezpieczenia. Plik jest publiczny, nie blokuje użytkowników i nie musi być respektowany przez wszystkie boty.
• Pozostawienie blokady po publikacji. Ustawienia wersji testowej bywają przenoszone na produkcję i mogą wyłączyć z indeksowania cały serwis.
• Używanie noindex zamiast canonicala. Przy duplikatach celem zwykle jest konsolidacja sygnałów, a nie samo ukrycie wariantów.
• Umieszczanie noindexowanych URL-i w mapie XML. Mapa powinna wskazywać adresy kanoniczne i przeznaczone do indeksowania.
• Globalne ustawienie noindex w szablonie, CMS-ie lub na poziomie serwera. Jedna odziedziczona reguła może objąć setki ważnych podstron.
• Blokowanie zasobów potrzebnych do renderowania. Zablokowane pliki CSS lub JavaScript mogą utrudnić Google poprawne zobaczenie strony.

Jak sprawdzić, dlaczego strona jest lub nie jest indeksowana?

Diagnozę warto prowadzić w stałej kolejności. Dzięki temu nie miesza się problemu z dostępem crawlera, dyrektywą indeksowania, canonicalem i jakością strony.

1. Ustal oczekiwany stan URL-a: indeksowany, wyłączony z indeksu, przekierowany, usunięty czy tylko ograniczony w crawlowaniu.
2. Sprawdź plik robots.txt pod właściwym hostem i protokołem. Zwróć uwagę na szerokie reguły, wielkość liter, wyjątki i działanie na subdomenach.
3. Sprawdź status odpowiedzi serwera. Działająca strona powinna zwracać status 200, przekierowanie status z grupy 3xx, a usunięty zasób 404 lub 410.
4. Sprawdź ustawienia indeksowania generowane przez CMS, wtyczki i serwer. Ustal, czy na stronie lub w odpowiedzi serwera nie ma noindex.
5. Sprawdź canonical. Powinien wskazywać właściwy, dostępny i indeksowalny adres, a inne sygnały nie powinny być z nim sprzeczne.
6. Użyj narzędzia Sprawdzanie adresu URL w Google Search Console. Porównaj wersję znajdującą się w indeksie z testem aktywnej strony.
7. Przejrzyj raport indeksowania oraz informacje dotyczące robots.txt. Przy większych serwisach szukaj powtarzających się wzorców, a nie tylko pojedynczych błędów.
8. Sprawdź mapę XML i linkowanie wewnętrzne. Nie kieruj Google do stron, które jednocześnie wykluczasz z indeksowania bez wyraźnego powodu.
9. Po wdrożeniu przetestuj adres ponownie i monitoruj zmianę. Poprawne ustawienie nie oznacza jeszcze, że Google zdążył je ponownie odczytać.

Praktyczne scenariusze i właściwe rozwiązania

Strona podziękowania po wysłaniu formularza

Strona musi być dostępna użytkownikowi, ale zwykle nie powinna pojawiać się w wynikach. Najczęściej właściwym rozwiązaniem jest noindex, pozostawienie możliwości crawlowania i usunięcie adresu z mapy XML. Robots.txt nie rozwiązuje tu problemu indeksacji.

Wyniki wyszukiwania wewnętrznego

Takie adresy często tworzą ogromną liczbę kombinacji o małej wartości. Jeśli część z nich znajduje się już w indeksie, najpierw należy pozwolić Google je pobrać i zastosować noindex. Dopiero po usunięciu z indeksu można rozważyć ograniczenie dalszego crawlowania przez robots.txt, jeżeli skala adresów rzeczywiście obciąża serwis.

Filtry w sklepie internetowym

Nie każdy filtr powinien być automatycznie blokowany lub oznaczany noindex. Niektóre kombinacje odpowiadają realnym zapytaniom i mogą zasługiwać na osobne, indeksowalne strony kategorii. Inne tworzą przypadkowe warianty sortowania, zakresy cen lub wielokrotne kombinacje bez wartości.

Najpierw trzeba podzielić adresy na grupy: wartościowe strony docelowe, duplikaty, warianty techniczne i pułapki crawlowania. Dopiero potem można dobrać canonical, noindex, robots.txt, przebudowę linkowania lub zmianę sposobu generowania URL-i. To element szerszych działań SEO, a nie jedna reguła stosowana do wszystkich filtrów. 

Wersja testowa lub środowisko stagingowe

Najbezpieczniejszym rozwiązaniem jest ograniczenie dostępu przez logowanie, hasło, VPN lub reguły serwera. Sam robots.txt ujawnia ścieżkę i nie zabezpiecza zawartości. Sam noindex nadal pozwala osobom znającym adres otworzyć stronę. Po publikacji trzeba sprawdzić, czy blokady testowe nie zostały przeniesione na wersję produkcyjną.

Produkt wycofany ze sprzedaży

Wybór zależy od sytuacji. Jeżeli istnieje bezpośredni odpowiednik, można przekierować użytkownika do najbardziej zbliżonego produktu lub kategorii. Jeśli strona nadal pomaga użytkownikom, może pozostać dostępna z informacją o niedostępności i alternatywach. Gdy produkt został trwale usunięty i nie ma odpowiednika, poprawnym sygnałem będzie 404 lub 410. Noindex nie powinien zastępować decyzji o dalszym losie URL-a.

Plik PDF, który nie powinien pojawiać się w Google

W przypadku pliku PDF noindex przekazuje się najczęściej w nagłówku odpowiedzi serwera za pomocą X-Robots-Tag. Googlebot musi mieć możliwość pobrania dokumentu, aby zobaczyć tę dyrektywę. Jeśli plik zawiera informacje poufne, noindex nie wystarczy i dostęp trzeba zabezpieczyć.

Insight ekspercki: przy usuwaniu adresów kolejność działań ma znaczenie

Jeżeli adres jest już widoczny w Google, a docelowo ma nie być ani indeksowany, ani intensywnie crawlowany, nie należy od razu blokować go w robots.txt. Najpierw Google musi zobaczyć noindex.

1. Usuń istniejącą blokadę robots.txt dla tej grupy URL-i.
2. Włącz noindex w ustawieniach strony, CMS-u lub odpowiedzi serwera.
3. Upewnij się, że adres zwraca status 200 i jest dostępny dla Googlebota.
4. Usuń URL-e z mapy XML i ogranicz niepotrzebne linkowanie wewnętrzne.
5. Poczekaj, aż Google ponownie odwiedzi strony i usunie je z indeksu.
6. Dopiero później rozważ blokadę crawlowania, jeśli adresy nadal generują niepotrzebne obciążenie.

Ten dwuetapowy proces jest szczególnie przydatny przy dużych zbiorach wyników wyszukiwania, parametrów i archiwów. Pozwala najpierw przekazać Google jednoznaczny sygnał indeksowania, a dopiero później ograniczyć zużycie zasobów crawlowania.

Mini-checklista przed wdrożeniem

• Czy dokładnie wiadomo, jaki ma być docelowy stan każdego typu URL-a?
• Czy robots.txt znajduje się pod właściwym hostem, protokołem i portem?
• Czy reguły blokujące nie obejmują ważnych stron lub zasobów potrzebnych do renderowania?
• Czy adres z noindex jest dostępny dla Googlebota?
• Czy noindex został wdrożony w ustawieniach strony lub odpowiedzi serwera, a nie w robots.txt?
• Czy status odpowiedzi, canonical i przekierowania są zgodne z celem?
• Czy mapa XML zawiera wyłącznie adresy przeznaczone do indeksowania i wersje kanoniczne?
• Czy wersja mobilna, szablony CMS i ustawienia serwera nie dodają innych dyrektyw?
• Czy zmiana została przetestowana w Google Search Console?
• Czy po wdrożeniu zaplanowano ponowną kontrolę indeksowania?

FAQ

Czy robots.txt usuwa stronę z indeksu Google?

Nie. Blokuje crawlowanie zgodnym robotom, ale Google może nadal znać adres z linków lub innych źródeł i wyświetlić sam URL bez standardowego opisu. Do wyłączenia strony z wyników służy noindex, usunięcie treści albo ochrona dostępu.

Czy noindex zadziała, jeśli URL jest zablokowany w robots.txt?

Google może nie odczytać dyrektywy, ponieważ nie będzie mógł pobrać strony ani odpowiedzi serwera. Adres może przez to pozostać widoczny, zwłaszcza jeśli wyszukiwarka zna go z linków.

Czy można dodać noindex bezpośrednio do robots.txt?

Nie. Google nie wspiera noindex w pliku robots.txt. Dyrektywę należy wdrożyć w ustawieniach strony lub w nagłówku odpowiedzi serwera.

Czy canonical zastępuje noindex?

Nie. Canonical wskazuje preferowaną wersję w grupie podobnych lub zduplikowanych adresów. Noindex mówi, że konkretny URL nie powinien znaleźć się w indeksie.

Czy stronę z noindex należy umieszczać w sitemapie?

Zwykle nie. Mapa XML powinna wskazywać adresy kanoniczne przeznaczone do indeksowania. Umieszczenie noindexowanego URL-a w sitemapie tworzy sprzeczne sygnały i utrudnia analizę.

Czy noindex chroni poufne dane?

Nie. Strona nadal może być dostępna po wpisaniu adresu i może zostać odwiedzona przez inne systemy. Poufne materiały trzeba zabezpieczyć przez autoryzację lub ograniczenie dostępu.

Jak wyłączyć z indeksu plik PDF?

Najczęściej stosuje się X-Robots-Tag w odpowiedzi serwera. Googlebot musi móc pobrać plik, aby zobaczyć tę dyrektywę.

Jak sprawdzić, czy Google widzi robots.txt i noindex?

Najlepiej użyć raportu robots.txt oraz narzędzia Sprawdzanie adresu URL w Search Console. Warto porównać dane o wersji znajdującej się w indeksie z testem aktywnej strony.

Dlaczego strona nie jest indeksowana, mimo że nie ma noindex ani blokady robots.txt?

Brak blokad nie gwarantuje indeksacji. Google może nie znać adresu, uznać go za duplikat, wybrać inny canonical, napotkać problem z renderowaniem albo nie uznać strony za wystarczająco wartościową do indeksowania.

Podsumowanie

Robots.txt i noindex nie są zamiennymi narzędziami. Pierwszy mechanizm kontroluje możliwość pobierania adresów przez crawlera, a drugi ich obecność w indeksie. Najważniejsza zasada brzmi: Google musi móc odwiedzić stronę, aby odczytać noindex.

W praktyce kontrola indeksowania wymaga szerszej decyzji. Duplikaty porządkuje się canonicalem, przeniesione strony przekierowaniem, usunięte zasoby statusem 404 lub 410, a treści prywatne zabezpieczeniem dostępu. Dopiero prawidłowe dopasowanie mechanizmu do celu pozwala uniknąć sytuacji, w której ważne strony znikają z Google albo niepotrzebne adresy pozostają w wynikach.

Po każdej zmianie trzeba sprawdzić rzeczywistą odpowiedź serwera, ustawienia indeksowania, canonical, mapę XML i dane w Search Console. W technicznym SEO jedna krótka dyrektywa potrafi zmienić widoczność tysięcy podstron, dlatego precyzja jest ważniejsza niż szybkie wdrożenie na wszelki wypadek.

Przeczytaj również: Linkowanie wewnętrzne: jak zaplanować strukturę linków na stronie?