Robots.txt a indeksacja – jak uniknąć przypadkowego blokowania strony?

Czym jest robots.txt i jaką rolę pełni w technicznym SEO?

Plik robots.txt a indeksacja Google to dwa powiązane, lecz odrębne zagadnienia: robots.txt steruje dostępem robotów do ścieżek hosta, ale nie gwarantuje usunięcia adresu z wyników. Standard Robots Exclusion Protocol opisano w 2022 roku jako RFC 9309. Korzystają z niego między innymi Googlebot i Bingbot, choć poszczególne roboty mogą respektować reguły inaczej.

Robots.txt to publicznie dostępny plik tekstowy, charakteryzujący się lokalizacją w katalogu głównym hosta, regułami przypisanymi do robotów oraz dopasowaniem ścieżek URL. Dla domeny agencjaitp.pl poprawny adres pliku ma postać https://agencjaitp.pl/robots.txt. Plik umieszczony w innym katalogu nie steruje całym serwisem.

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

Plik robots.txt służy do kontroli crawlowania, czyli określania, które zasoby robot może pobierać z konkretnego hosta. Nie jest mechanizmem uwierzytelniania, ochrony danych ani bezpośrednim poleceniem usunięcia strony z indeksu.

W praktyce redakcyjnej i podczas audytów wykorzystuję go głównie do ograniczania pobierania technicznych wariantów adresów, wyników wyszukiwania wewnętrznego lub niepotrzebnych filtrów. Każdą taką blokadę zestawiam jednak z linkowaniem, adresami kanonicznymi i rzeczywistym zachowaniem Googlebota w logach.

• Googlebot – robot Google odczytuje reguły przed próbą pobrania zasobu na potrzeby wyszukiwarki.
• Bingbot – robot wyszukiwarki Bing korzysta z tego samego protokołu, lecz diagnostykę należy prowadzić również w Bing Webmaster Tools.
• User-agent – pole identyfikuje robota albo grupę robotów, do których odnoszą się następujące po nim reguły.
• Disallow – dyrektywa wskazuje ścieżkę, której dany robot nie powinien pobierać.
• Allow – dyrektywa może dopuścić bardziej szczegółową ścieżkę znajdującą się wewnątrz szerszej blokady.

„Robots Exclusion Protocol określa reguły, według których właściciel usługi wskazuje robotom dozwolone i niedozwolone ścieżki. Nie stanowi jednak zabezpieczenia dostępu.” – parafraza standardu IETF, RFC 9309, 2022

Gdzie powinien znajdować się plik?

Plik powinien znajdować się pod adresem „/robots.txt” dla dokładnie tego protokołu, hosta i portu, którego dotyczą reguły. Plik z domeny głównej nie obejmuje automatycznie subdomeny blog, sklep ani panel.

To rozróżnienie ma znaczenie podczas migracji. Konfigurację należy sprawdzić oddzielnie dla wersji HTTPS, subdomen oraz hostów używanych przez serwis. Niedostępny plik, przekierowanie albo odpowiedź serwera mogą wpływać na sposób, w jaki robot przetworzy reguły. Szczegółową kontrolę można połączyć z usługą audyt techniczny SEO.

Jak robot pobiera i buforuje reguły?

Robot najpierw pobiera plik z katalogu głównego, interpretuje właściwą grupę User-agent, a następnie stosuje dopasowane reguły przy kolejnych żądaniach. Może przechowywać pobraną konfigurację, dlatego zmiana opublikowana na serwerze nie zawsze działa natychmiast.

Robots.txt kontroluje dostęp robota do ścieżek hosta, a RFC 9309 z 2022 roku nie definiuje tego protokołu jako narzędzia ochrony poufnych danych. Poufny zasób należy zabezpieczyć logowaniem, autoryzacją albo regułami serwera. Sam adres robots.txt jest publiczny i może wręcz ujawnić nazwę blokowanego katalogu.

Czy blokada w robots.txt usuwa adres z indeksu Google?

Nie. Dyrektywa Disallow ogranicza crawlowanie, lecz zablokowany adres może nadal pojawić się w Google, jeśli wyszukiwarka odkryje go przez linki lub wcześniejsze pobranie. Google może wtedy wyświetlić URL bez opisu. Do usunięcia dostępnej strony z indeksu służy między innymi meta robots noindex odczytany przez Googlebota (źródło: Google Search Central, dokumentacja sprawdzona w lipcu 2026).

Dlaczego zablokowany URL może pojawić się w Google?

Zablokowany URL może pojawić się w Google, ponieważ odkrycie adresu i pobranie jego zawartości stanowią osobne etapy. Link wewnętrzny, odnośnik zewnętrzny albo mapa XML mogą poinformować wyszukiwarkę o istnieniu strony, mimo że Disallow uniemożliwia odczyt treści.

To częsty punkt nieporozumienia: crawlowanie oznacza pobieranie zasobu, a indeksacja Google oznacza przetwarzanie i potencjalne zapisanie informacji w indeksie. Blokowanie Googlebota może utrudnić odczyt noindex, ponieważ robot nie zobaczy kodu HTML z tą dyrektywą.

• Link zewnętrzny – Google może poznać adres z odnośnika opublikowanego w innym serwisie.
• Link wewnętrzny – nawigacja lub archiwalny artykuł może nadal prowadzić do blokowanej podstrony.
• Mapa XML – umieszczenie URL-a w pliku sitemap sygnalizuje, że właściciel chce przedstawić go wyszukiwarce.
• Wcześniejszy crawl – wyszukiwarka mogła zapisać informacje o stronie przed wprowadzeniem blokady.
• Przekierowanie – łańcuch adresów może podtrzymywać odkrywanie starego URL-a mimo zmienionej konfiguracji.

Czym różnią się robots.txt, noindex i kod 404?

Robots.txt ogranicza pobieranie, noindex poleca nie umieszczać dostępnego zasobu w wynikach, a kod 404 informuje, że żądanego zasobu nie znaleziono. Wybór zależy od tego, czy strona istnieje, czy użytkownik ma ją otwierać i czy robot powinien odczytać jej zawartość.

Disallow nie jest odpowiednikiem noindex: według Google Search Central zablokowany URL może zostać pokazany w wynikach na podstawie sygnałów pochodzących z innych stron. Więcej o rozpoznawaniu takich stanów opisuje materiał dotyczący indeksowania strony w Google.

Jak Google interpretuje składnię i zasady dopasowania?

Google interpretuje robots.txt przez wybór grupy właściwej dla Googlebota i dopasowanie ścieżki adresu do reguł Allow oraz Disallow. Przy konflikcie znaczenie ma najbardziej szczegółowe dopasowanie, a nie samo położenie wiersza w pliku. RFC 9309 opisuje podstawy grupowania i porównywania reguł (źródło: IETF, 2022).

Jak działają User-agent, Disallow i Allow?

Najpierw wskaż User-agent, następnie dodaj reguły Disallow lub Allow odnoszące się do ścieżek URL. Pusta wartość Disallow nie blokuje zasobów, natomiast zapis „Disallow: /” obejmuje cały host dla wskazanej grupy.

Bezpieczny plik może udostępniać całą witrynę przez grupę „User-agent: *” i pustą wartość Disallow. Ryzykowna konfiguracja to pozostawienie pełnej blokady używanej wcześniej na stagingu. W przypadkach, które prowadziłem, taki jeden wiersz potrafił odciąć kategorię, artykuły i zasoby renderujące jednocześnie.

• User-agent: * – grupa odnosi reguły do wszystkich robotów respektujących protokół.
• User-agent: Googlebot – grupa wskazuje robota Google bez automatycznego objęcia Bingbota.
• Disallow: / – reguła blokuje crawlowanie wszystkich ścieżek danego hosta.
• Disallow: /panel/ – reguła obejmuje ścieżki zaczynające się od wskazanego katalogu.
• Allow: /panel/publiczny-poradnik/ – szczegółowy wyjątek dopuszcza wybraną ścieżkę wewnątrz blokowanego katalogu.

Jak kolejność i długość reguł wpływają na wynik?

Google wybiera regułę o najbardziej szczegółowym dopasowaniu ścieżki, dlatego dłuższy pasujący wzorzec może wygrać z krótszą blokadą. Nie należy zakładać, że ostatni wiersz zawsze unieważnia wcześniejsze polecenie.

Przykład: blokada „/oferta/” oraz zezwolenie „/oferta/seo/” powinny pozostawić sekcję SEO dostępną, jeśli mechanizm dopasowania danego robota obsługuje Allow. Przy regułach równoważnych trzeba opierać się na aktualnej dokumentacji konkretnej wyszukiwarki, a nie na intuicji wynikającej z kolejności tekstu.

Jak stosować gwiazdkę i znak końca adresu?

Gwiazdka zastępuje ciąg znaków, a symbol dolara wskazuje koniec dopasowywanego adresu w implementacji Google. Przed publikacją sprawdź każdy wzorzec na realnych URL-ach, ponieważ reguła obejmująca parametr może przypadkowo pasować również do adresu kanonicznego.

Przykładowe „Disallow: /*?sort=” ogranicza warianty sortowania, ale nie rozwiązuje automatycznie wszystkich problemów z parametrami. Najpierw trzeba ustalić, jak CMS buduje adresy, które wersje mają tag canonical i czy Googlebot rzeczywiście zużywa znaczną część żądań na filtry.

Czy można blokować pliki CSS, JavaScript i obrazy?

Tak, robots.txt może blokować CSS, JavaScript oraz obrazy, lecz odcięcie zasobów potrzebnych do renderowania utrudnia Google ocenę mobilnego układu, treści i interakcji. Zasoby wpływające na widoczny wygląd strony powinny pozostać dostępne bez wyraźnego, przetestowanego powodu blokady.

• CSS szablonu – dostępny arkusz pozwala Googlebotowi odtworzyć układ strony podobny do widoku użytkownika.
• JavaScript nawigacji – blokada skryptu może uniemożliwić wykrycie elementów renderowanych po stronie klienta.
• Obraz główny – dostępność pliku ma znaczenie, gdy grafika ma pojawić się w wynikach obrazów.
• Skrypt panelu administracyjnego – zasób używany wyłącznie po zalogowaniu zwykle nie pomaga w renderowaniu publicznej strony.
• Pliki analityczne – decyzję o blokadzie należy oddzielić od reguł obejmujących cały katalog skryptów witryny.

Reguła jest bezpieczna dopiero wtedy, gdy jej wynik potwierdzono na reprezentatywnych adresach i zasobach renderujących w Google Search Console.

Które błędy robots.txt najczęściej prowadzą do utraty widoczności?

Najgroźniejsze błędy to pozostawienie „Disallow: /” po migracji, blokada katalogu zawierającego strony docelowe, odcięcie CSS lub JavaScript oraz zbyt szerokie wzorce parametrów. Każdy z nich może ograniczyć kontrolę crawlowania dla setek URL-i jednym wdrożeniem, choć spadek widoczności zależy również od wcześniejszego indeksu i linkowania.

Co najczęściej blokuje całą witrynę po migracji?

Całą witrynę najczęściej blokuje reguła „Disallow: /” skopiowana ze środowiska stagingowego do wersji produkcyjnej. Błąd powstaje podczas zamiany hosta, automatycznego wdrożenia albo przeniesienia plików bez osobnej kontroli konfiguracji SEO.

Z mojej praktyki wynika, że kontrola robots.txt musi znaleźć się na liście odbiorowej jeszcze przed zmianą DNS. Po publikacji sprawdzam plik bezpośrednio z produkcyjnej domeny, a nie w repozytorium, panelu CMS czy kopii przekazanej przez programistę.

• Staging – środowisko testowe powinno korzystać z uwierzytelniania, a nie wyłącznie z publicznego Disallow.
• Produkcja – aktywny plik należy pobrać z docelowego protokołu i hosta zaraz po wdrożeniu.
• CDN – pamięć podręczna może nadal zwracać starszą wersję pomimo zmiany pliku na serwerze źródłowym.
• Automatyzacja deploymentu – proces publikacji powinien odróżniać konfigurację testową od produkcyjnej.
• Subdomena – osobny host wymaga własnego robots.txt i osobnej weryfikacji.
• Monitoring – alert na zmianę treści lub statusu HTTP skraca czas między błędem a reakcją.

Jak zbyt szerokie reguły blokują kategorie i strony usług?

Zbyt szeroka reguła blokuje ważne podstrony, gdy fragment użyty jako wzorzec występuje również w adresach kanonicznych. Przed wdrożeniem trzeba porównać wzorzec z pełną próbką kategorii, artykułów, ofert, filtrów i zasobów.

Przykład: blokada katalogu „/tag/” jest przewidywalna, ale wzorzec zawierający samo „?id=” może obejmować więcej wariantów, niż zakłada redaktor. Podobnie blokada „/assets/” odcina nie tylko pliki panelu, lecz czasem arkusze CSS całego frontendu.

Jakie sygnały wskazują na przypadkową blokadę?

Na przypadkową blokadę wskazują nagły spadek żądań Googlebota, komunikat o zablokowaniu przez robots.txt, problemy z renderowaniem oraz rozbieżność między mapą XML a dostępnością URL-i. Sam spadek kliknięć nie wystarcza do rozpoznania przyczyny.

• Google Search Console – raport dla konkretnego adresu może wskazać ograniczenie pobierania przez robots.txt.
• Logi serwera – brak żądań Googlebota po wdrożeniu potwierdza zmianę zachowania crawlu.
• Renderowanie strony – brak stylów lub elementów może ujawnić zablokowane zasoby CSS i JavaScript.
• Monitoring pozycji – spadki wielu katalogów w podobnym terminie sugerują problem obejmujący wzorzec URL.
• Historia wdrożeń – korelacja z migracją lub zmianą CDN pomaga zawęzić moment wystąpienia błędu.

Najbardziej ryzykowny błąd robots.txt to reguła obejmująca cały host, ponieważ jeden zapis może zatrzymać kolejne pobrania stron przez Googlebota i Bingbota. Dlatego plan migracji strony bez utraty widoczności powinien obejmować odbiór pliku przed zmianą domeny.

Jak sprawdzić robots.txt przed wdrożeniem i po publikacji?

Zacznij od pobrania aktywnego pliku z docelowej domeny, a następnie przetestuj co najmniej pięć grup adresów: stronę główną, usługi, kategorie, artykuły oraz zasoby CSS i JavaScript. Po publikacji sprawdź konkretne URL-e w Google Search Console i porównaj wyniki z logami serwera oraz mapą XML.

Jak przeprowadzić audyt robots.txt krok po kroku?

Przeprowadź audyt w sześciu krokach: pobierz aktywny plik, zinwentaryzuj reguły, utwórz próbkę adresów, ustal oczekiwany wynik, wykonaj testy i sprawdź logi. Każdy wynik zapisz jako „dozwolony” albo „zablokowany”, aby wychwycić rozbieżności przed wdrożeniem.

1. Pobierz plik produkcyjny – otwórz dokładny adres „/robots.txt” i sprawdź kod odpowiedzi oraz treść zwracaną przez CDN.
2. Rozdziel grupy robotów – ustal, które reguły dotyczą Googlebota, Bingbota i grupy oznaczonej gwiazdką.
3. Zbuduj próbkę URL-i – uwzględnij stronę główną, cztery typy podstron, parametry oraz zasoby renderujące.
4. Oznacz oczekiwany dostęp – każdemu adresowi przypisz decyzję biznesową, zanim poznasz wynik dopasowania.
5. Porównaj reguły z wynikiem – szukaj blokad obejmujących szerszy fragment ścieżki niż planowano.
6. Sprawdź logi serwera – potwierdź, czy Googlebot pobiera kluczowe strony i jak często wraca do robots.txt.

Jak sprawdzić konkretny adres w Google Search Console?

Wklej pełny URL do narzędzia Sprawdzanie adresu URL, odczytaj stan indeksowania, a następnie uruchom test bieżącego adresu. Wynik pokaże, czy Google może pobrać stronę oraz czy występują problemy z dostępem lub renderowaniem.

Interfejs Google Search Console może się zmieniać, dlatego dane i nazwy funkcji należy sprawdzić przed publikacją instrukcji. Stan „URL jest w Google” opisuje znany indeks, podczas gdy test bieżący bada aktualną wersję. To nie są identyczne pomiary.

„Narzędzie Sprawdzanie adresu URL pokazuje informacje o indeksowanej wersji strony i umożliwia przetestowanie wersji dostępnej obecnie.” – parafraza dokumentacji Google Search Console, dostęp sprawdzony w lipcu 2026

Jak połączyć test URL-i z analizą logów?

Połącz test ręczny z logami przez porównanie wyniku narzędzia z żądaniami zweryfikowanego Googlebota w tym samym okresie. Logi pokazują faktyczne pobrania, kody HTTP i częstotliwość wizyt, których nie da się wiarygodnie odtworzyć na podstawie samego interfejsu wyszukiwarki.

Obserwuję regularnie, że test pojedynczego URL-a nie ujawnia skali problemu. Dlatego próbka powinna reprezentować wszystkie szablony. Osobno analizuję adresy z mapy XML, strony generujące ruch oraz pliki niezbędne do renderowania.

Jak kontrolować plik po publikacji?

Kontroluj plik bezpośrednio po wdrożeniu, ponownie po odświeżeniu pamięci CDN i podczas kolejnych wizyt Googlebota widocznych w logach. Nie zakładaj, że wersja zapisana w CMS odpowiada treści zwracanej użytkownikom i robotom.

• Pierwsza kontrola – po publikacji porównaj aktywną treść z zatwierdzoną wersją pliku.
• Kontrola HTTP – sprawdź kod odpowiedzi, przekierowania oraz różnice między hostami.
• Kontrola krytycznych URL-i – powtórz test strony głównej, usług, kategorii i artykułów.
• Kontrola renderowania – zweryfikuj dostępność CSS, JavaScript i obrazów wpływających na główną treść.
• Kontrola sitemap – porównaj indeksowane adresy z aktualną mapą XML witryny.
• Kontrola logów – obserwuj powrót pobrań i kody odpowiedzi dla priorytetowych ścieżek.

Bezpieczna zmiana robots.txt wymaga testu wzorców przed publikacją i weryfikacji faktycznej odpowiedzi serwera po wdrożeniu, zgodnie z zasadami dopasowania opisanymi w RFC 9309.

Jak bezpiecznie naprawić przypadkową blokadę i odzyskać indeksację?

Najpierw usuń albo zawęź błędną regułę, potem potwierdź kod 200, dostęp Googlebota i prawidłowy meta robots na kluczowych stronach. Zaktualizuj mapę XML oraz użyj Google Search Console do weryfikacji priorytetowych adresów. Google nie gwarantuje terminu ponownego przetworzenia ani powrotu widoczności (źródło: Google Search Central, 2026).

Co zrobić bezpośrednio po usunięciu Disallow?

Po usunięciu Disallow wykonaj pięć kontroli: aktywnego pliku, odpowiedzi HTTP, meta robots, adresu kanonicznego i mapy XML. Dopiero spójność tych sygnałów daje Googlebotowi techniczną możliwość ponownego pobrania oraz oceny strony.

1. Opublikuj zawężoną regułę – usuń tylko wadliwy zakres i nie zmieniaj równocześnie niezwiązanych sekcji pliku.
2. Sprawdź odpowiedź produkcyjną – potwierdź, że serwer oraz CDN zwracają nową treść robots.txt.
3. Zweryfikuj kod strony – ważny URL powinien odpowiadać zgodnie z zamierzeniem, zwykle kodem 200.
4. Sprawdź meta robots – usuń niezamierzone noindex, jeśli strona ma wrócić do wyników.
5. Skontroluj canonical – adres kanoniczny powinien wskazywać właściwą wersję strony, a nie stary host.
6. Zaktualizuj sitemap – umieść w niej wyłącznie kanoniczne URL-e przeznaczone do indeksacji.
7. Przetestuj priorytetowe strony – użyj inspekcji URL i obserwuj rzeczywiste żądania w logach.

Jak długo trwa ponowne przetworzenie strony?

Nie ma gwarantowanego czasu: Google może ponownie pobrać robots.txt i stronę po kilku dniach, ale przy rzadko odwiedzanym serwisie proces może potrwać dłużej. Termin zależy między innymi od częstotliwości crawlowania, linkowania, odpowiedzi serwera i skali wcześniejszej blokady.

Nie obiecuję klientowi powrotu pozycji w konkretnym dniu. Najpierw obserwuję wznowienie crawlowania, później stan indeksacji, a dopiero na końcu wyświetlenia i kliknięcia. To cztery osobne etapy. Wzrost liczby żądań Googlebota nie oznacza jeszcze odzyskania wcześniejszych pozycji.

Jak mierzyć odzyskiwanie widoczności?

Mierz odzyskiwanie osobno dla dostępu robota, indeksacji i wyników organicznych. Pierwszym sygnałem są ponowne żądania w logach, drugim zmiana stanu URL-i w Search Console, a trzecim powrót wyświetleń, zapytań i kliknięć.

• Crawl – logi serwera pokazują, czy Googlebot ponownie pobiera odblokowane ścieżki.
• Renderowanie – test bieżący potwierdza, czy robot widzi treść oraz potrzebne zasoby.
• Indeksacja – raporty Google Search Console wskazują, które URL-e Google zna i przetwarza.
• Wyświetlenia – rosnąca liczba impresji sygnalizuje powrót stron do realnych wyników wyszukiwania.
• Kliknięcia – ruch organiczny należy oceniać z uwzględnieniem sezonowości i zmian popytu.
• Pozycje – porównanie katalogów pozwala oddzielić skutki blokady od zmian dotyczących pojedynczych treści.

Usunięcie Disallow przywraca możliwość crawlowania, ale nie gwarantuje terminu ponownej indeksacji ani odzyskania wcześniejszych pozycji, co potwierdza dokumentacja Google Search Central.

Najczęściej zadawane pytania

Czy Disallow usuwa stronę z indeksu Google?

Nie. Disallow ogranicza pobieranie strony, ale Google może nadal znać jej adres z linków zewnętrznych, nawigacji albo mapy XML. Jeśli dostępna strona ma zniknąć z wyników, Googlebot powinien móc odczytać dyrektywę noindex.

Czy można umieścić noindex w robots.txt?

Nie należy na tym polegać. Noindex w robots.txt nie należy do standardowych reguł indeksowania obsługiwanych przez Google. Dyrektywę trzeba przekazać w kodzie HTML jako meta robots albo w nagłówku HTTP X-Robots-Tag.

Czy robots.txt może blokować CSS i JavaScript?

Tak, reguły mogą obejmować pliki CSS i JavaScript. Taka blokada bywa jednak szkodliwa, gdy Googlebot potrzebuje zasobów do odtworzenia treści i układu. Przed jej użyciem należy przetestować renderowanie reprezentatywnych stron.

Gdzie znajduje się robots.txt?

Plik znajduje się w katalogu głównym konkretnego hosta, na przykład „https://example.com/robots.txt”. Reguły domeny głównej nie obejmują automatycznie wszystkich subdomen. Każdy istotny host trzeba sprawdzić oddzielnie.

Jak szybko Google zauważa zmianę robots.txt?

Nie ma stałego terminu, ponieważ Google musi ponownie pobrać i przetworzyć plik. Po zmianie należy obserwować aktywną odpowiedź serwera, logi oraz stan adresów w Google Search Console. Samo opublikowanie nowej wersji nie oznacza natychmiastowego odzyskania widoczności.

Czy robots.txt chroni panel administracyjny i dane klientów?

Nie. Plik jest publiczny, a wskazane w nim ścieżki może przeczytać każdy użytkownik lub robot. Panel i poufne dane trzeba zabezpieczyć uwierzytelnianiem, kontrolą uprawnień oraz konfiguracją serwera.

Czy adresy zablokowane w robots.txt powinny znajdować się w sitemap.xml?

Zwykle nie, jeśli są to techniczne adresy, których wyszukiwarka nie ma indeksować. Jednoczesne umieszczenie URL-a w mapie XML i zablokowanie jego crawlowania wysyła sprzeczne sygnały. Mapa powinna zawierać kanoniczne, dostępne strony przeznaczone do indeksacji.

Czy każda wyszukiwarka interpretuje Allow identycznie?

Nie należy tego zakładać. RFC 9309 opisuje wspólny protokół, lecz szczegóły obsługi rozszerzeń i diagnostyki trzeba potwierdzać w aktualnej dokumentacji wyszukiwarki. Reguły dla Googlebota i Bingbota warto testować osobno.

Źródła i literatura

Poniższe źródła opisują standard Robots Exclusion Protocol, sposób obsługi robots.txt przez Google oraz diagnostykę konkretnych adresów. Dokumentację funkcji Google Search Console i Bing Webmaster Tools sprawdzono w lipcu 2026, ponieważ nazwy elementów interfejsu oraz dostępne raporty mogą zmieniać się z czasem.

Jakie źródła definiują działanie robots.txt?

Podstawą techniczną jest RFC 9309 opublikowany przez IETF w 2022 roku, natomiast zachowanie Googlebota należy weryfikować w aktualnej dokumentacji Google Search Central. Standard i dokumentacja wyszukiwarki pełnią różne funkcje: pierwszy opisuje protokół, druga wyjaśnia konkretną implementację.

1. IETF – RFC 9309: Robots Exclusion Protocol, 2022.
2. Google Search Central – Introduction to robots.txt, dokumentacja aktualizowana przez Google.
3. Google Search Central – Block Search indexing with noindex, dokumentacja dotycząca noindex.
4. Google Search Console – Narzędzie Sprawdzanie adresu URL, pomoc Google.
5. Bing Webmaster Tools – Robots.txt Tester, dokumentacja narzędzia Bing.

Jak oceniać aktualność zaleceń?

Sprawdzaj dokumentację wyszukiwarek przed każdą większą migracją oraz zmianą reguł, ponieważ implementacje i narzędzia diagnostyczne mogą się rozwijać. RFC 9309 pozostaje punktem odniesienia dla protokołu, ale decyzję o konkretnej składni trzeba zestawić z bieżącą obsługą Googlebota i Bingbota.

• RFC 9309 – standard IETF stanowi źródło definicji grup, reguł i dopasowania ścieżek.
• Google Search Central – oficjalna dokumentacja opisuje zachowanie Googlebota oraz relację między crawlingiem i indeksacją.
• Google Search Console – dane pierwszej strony pomagają sprawdzić stan konkretnego URL-a po wdrożeniu naprawy.
• Bing Webmaster Tools – osobne narzędzia umożliwiają kontrolę reguł z perspektywy Bingbota.

Przeczytaj również

• Indeksacja strony w Google – jak sprawdzić, które podstrony są widoczne?
• Problemy z indeksacją strony – najczęstsze przyczyny i sposoby naprawy
• Mapa witryny XML – jak wspiera indeksację i kiedy wymaga poprawy?

Potrzebujesz wsparcia przy audycie SEO? Zobacz, jak pracujemy albo poproś o bezpłatną wycenę.

Jacek Ślesicki

W SEO od 2016 roku. Zbudowałem i utrzymuję własną sieć ponad 150 serwisów tematycznych, na których zrealizowałem ponad 1000 publikacji — publikuję u siebie, nie pośredniczę. Prowadzę Agencję ITP i osobiście odpowiadam za strategię każdego projektu.