Plik robots.txt: jedna linijka, która potrafi ukryć stronę przed Google

Plik robots.txt ma zwykle kilka wierszy i przez lata nikt do niego nie zagląda. Wystarczy jednak jeden wpis, żeby roboty Google przestały pobierać całą witrynę, a ruch z wyszukiwarki zaczął z tygodnia na tydzień maleć. Właściciel firmy widzi wtedy spadek zapytań i szuka przyczyny w treściach albo w linkach, a problem leży w dwóch linijkach tekstu.

Ta instrukcja jest przeznaczona dla osób, które prowadzą stronę firmową lub sklep i chcą samodzielnie ocenić, czy ich plik jest w porządku. Nie wymaga znajomości programowania. Wystarczy przeglądarka, dostęp do panelu strony i konto w Google Search Console.

Po lekturze czytelnik będzie umiał odnaleźć i odczytać swój plik, rozpoznać groźny wpis, napisać poprawne reguły, wprowadzić zmianę na serwerze lub we wtyczce, poprosić Google o ponowne pobranie pliku i sprawdzić, czy naprawa przyniosła skutek.

Do czego służy plik robots.txt, a do czego nie służy?

Robots.txt to zwykły plik tekstowy, który mówi robotom wyszukiwarek, których adresów w witrynie wolno im pobierać, a których nie. Według dokumentacji Google używa się go głównie po to, żeby witryna nie była przeciążona żądaniami robotów. Jest to więc narzędzie do kierowania ruchem robotów, a nie zamek do drzwi.

Ta sama dokumentacja mówi wprost, że plik nie jest mechanizmem służącym do ukrywania strony internetowej przed Google. Kto chce, żeby strona nie pojawiała się w wynikach, powinien zablokować jej indeksowanie znacznikiem noindex albo zabezpieczyć ją hasłem.

Z pliku wynikają też inne ograniczenia, które Google wymienia otwarcie. Reguły są prośbą, a nie nakazem: porządne roboty wyszukiwarek ich przestrzegają, ale programy zbierające dane bez pytania mogą je zignorować. Poszczególne roboty mogą też nieco inaczej rozumieć składnię. Wreszcie plik jest publiczny, więc każdy może przeczytać, jakich katalogów właściciel nie chce pokazywać.

Z tego powodu w pliku nie należy wpisywać adresów, które mają pozostać tajemnicą, na przykład ukrytego panelu logowania albo katalogu z dokumentami. Taki wpis działa jak drogowskaz. Poufne zasoby chroni się hasłem na serwerze.

Czym różni się blokada skanowania od noindex?

To rozróżnienie jest najważniejszą rzeczą w całym temacie, a mylą je nawet osoby pracujące przy stronach zawodowo. Google wykonuje dwie osobne czynności. Najpierw robot pobiera stronę, czyli ją skanuje. Dopiero potem treść trafia do indeksu, z którego powstają wyniki wyszukiwania.

Wpis Disallow w pliku robots.txt zatrzymuje tylko pierwszą czynność. Robot nie pobiera strony, ale jej adres nadal może znaleźć się w indeksie, jeśli prowadzą do niego linki z innych miejsc. W wynikach pojawia się wtedy sam adres, bez opisu. W Search Console taka strona ma stan „Strona zindeksowana, ale zablokowana przez plik robots.txt”.

Znacznik noindex działa odwrotnie. Robot pobiera stronę, odczytuje w jej kodzie polecenie i usuwa ją z wyników. Znacznik umieszcza się w sekcji head strony:

<meta name="robots" content="noindex">

W przypadku plików, które nie mają kodu HTML, na przykład dokumentów PDF, to samo polecenie wysyła serwer w nagłówku odpowiedzi:

X-Robots-Tag: noindex

Z tej różnicy wynika pułapka. Jeśli strona ma znacznik noindex i jednocześnie jest zablokowana w robots.txt, robot nigdy nie zobaczy znacznika, bo nie wolno mu pobrać strony. Dokumentacja Google zastrzega, że noindex działa tylko wtedy, gdy strona nie jest blokowana w pliku robots.txt. Obie metody stosowane naraz znoszą się nawzajem.

Google nie obsługuje też polecenia noindex wpisanego do samego pliku robots.txt. Wiersz „Noindex: /katalog/” zostanie pominięty jako nieznany.

Dla porządku jedna uwaga o słownictwie. Polskie strony pomocy Google często tłumaczą pobieranie stron przez robota słowem „indeksowanie”, a w Search Console przycisk dotyczący ponownego pobrania pliku nazywa się „Poproś o ponowne zindeksowanie”. W tym tekście pobieranie nazywam skanowaniem, a indeksowaniem tylko umieszczenie strony w indeksie.

Gdzie leży plik i jak go obejrzeć?

Plik musi nazywać się dokładnie robots.txt i leżeć w katalogu głównym witryny. Roboty szukają go tylko tam. Plik umieszczony w podkatalogu, na przykład pod adresem z dopiskiem /blog/robots.txt, jest dla nich niewidoczny.

Każdy może obejrzeć plik dowolnej witryny, także własnej, bez logowania. Wygląda to tak:

1. W pasku adresu przeglądarki wpisuje się adres strony głównej i dopisuje na końcu /robots.txt, na przykład https://www.przyklad.pl/robots.txt.
2. Adres należy otworzyć w oknie prywatnym przeglądarki, żeby zobaczyć to samo, co widzi osoba niezalogowana i robot.
3. Jeśli pojawia się kilka wierszy tekstu, plik istnieje i jest publicznie dostępny. Jego treść warto skopiować do notatnika jako kopię zapasową przed jakąkolwiek zmianą.
4. Jeśli pojawia się strona błędu 404, pliku nie ma. Nie jest to usterka: Google uznaje wtedy, że wolno mu skanować całą witrynę.
5. Czynność powtarza się dla każdej wersji adresu, pod którą działa firma: z przedrostkiem www i bez niego, a także dla subdomen, na przykład sklepu.

Ostatni krok ma znaczenie, ponieważ reguły obowiązują tylko dla tego protokołu, hosta i portu, pod którym plik został opublikowany. Plik z adresu z przedrostkiem www nie dotyczy subdomeny sklepu, a plik spod adresu http nie dotyczy wersji https. Każda subdomena potrzebuje własnego pliku.

Plik ma być zapisany jako zwykły tekst w kodowaniu UTF-8. Do pisania służy prosty edytor tekstu, taki jak Notatnik. Edytory biurowe dodają niewidoczne znaki formatowania, które psują reguły. Google czyta najwyżej 500 kibibajtów pliku, a wszystko, co znajduje się dalej, pomija. W praktyce firmowej stronie ten limit nie zagraża.

Jak czytać i pisać reguły w pliku?

Plik składa się z grup. Każda grupa zaczyna się od wskazania robota, a pod spodem ma listę zakazów i zezwoleń, po jednym w wierszu. Google obsługuje cztery pola: User-agent, Disallow, Allow i Sitemap. Wszystkie inne wiersze pomija, w tym popularne w starych plikach pole Crawl-delay.

User-agent: do kogo mówi reguła

Pole User-agent podaje nazwę robota, którego dotyczą kolejne wiersze. Gwiazdka oznacza wszystkie roboty:

User-agent: *
Disallow: /prywatne/

Można też zwrócić się do jednego robota po nazwie, na przykład Googlebot albo Googlebot-Image. Robot wybiera wtedy grupę najdokładniej do niego dopasowaną i pomija pozostałe. To częste źródło pomyłek: jeśli w pliku istnieje osobna grupa dla robota Googlebot, to robot ten nie stosuje już reguł z grupy oznaczonej gwiazdką. Zakazy trzeba w niej powtórzyć.

Disallow i Allow: zakaz i wyjątek od zakazu

Disallow wskazuje ścieżkę, której robot ma nie pobierać. Allow wskazuje wyjątek wewnątrz zakazanego obszaru. Ścieżka zawsze zaczyna się od ukośnika i jest liczona od katalogu głównego, bez nazwy domeny.

User-agent: *
Disallow: /archiwum/
Allow: /archiwum/cennik.pdf

Reguła obejmuje wszystkie adresy, które zaczynają się od podanego ciągu znaków. Wpis Disallow: /oferta zablokuje więc nie tylko katalog /oferta/, ale także adres /oferta-specjalna.html. Kto chce zablokować tylko katalog, kończy ścieżkę ukośnikiem: Disallow: /oferta/.

W ścieżkach liczy się wielkość liter. Dla robota /Oferta/ i /oferta/ to dwa różne adresy. Nazwy pól można natomiast pisać dowolnie, wielką lub małą literą.

Wiersz Disallow: bez żadnej ścieżki niczego nie blokuje. Wszystko, czego plik nie zakazuje, jest dozwolone, dlatego nie trzeba wypisywać zezwoleń dla zwykłych podstron.

Sitemap: adres mapy witryny

Pole Sitemap podaje robotom, gdzie leży mapa witryny. Adres musi być pełny, z protokołem i nazwą domeny. Wiersz nie należy do żadnej grupy, więc można go umieścić na początku lub na końcu pliku, a map można wskazać kilka.

Sitemap: https://www.przyklad.pl/sitemap.xml

Znaki * i $ oraz komentarze

Gwiazdka w ścieżce zastępuje dowolny ciąg znaków, także pusty. Znak dolara oznacza koniec adresu. Razem pozwalają objąć regułą na przykład wszystkie pliki jednego rodzaju albo wszystkie adresy z danym parametrem.

User-agent: *
# wszystkie adresy zakonczone na .pdf
Disallow: /*.pdf$
# wszystkie adresy z parametrem sortowania
Disallow: /*?orderby=

Bez znaku dolara reguła /*.pdf objęłaby też adres, w którym ciąg .pdf występuje w środku. Wiersz zaczynający się od krzyżyka jest komentarzem dla ludzi, a roboty go pomijają. Komentarze przydają się, gdy po roku trzeba ustalić, po co dana reguła powstała.

Która reguła wygrywa, gdy dwie do siebie nie pasują?

Kolejność wierszy w grupie nie ma dla Google znaczenia. Wygrywa reguła bardziej szczegółowa, czyli ta z dłuższą ścieżką. Gdy zakaz i zezwolenie mają tę samą długość, Google stosuje regułę mniej restrykcyjną, czyli zezwolenie. Dzięki temu w przykładzie z archiwum cennik pozostaje dostępny, mimo że cały katalog jest zakazany.

Kto na tym etapie woli nie zajmować się tym samodzielnie, może po prostu zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Chętnie przejmę sprawę: sprawdzę plik robots.txt, poprawię go i potwierdzę wynik w Search Console.

Która linijka blokuje całą witrynę i skąd się bierze na działającej stronie?

Najgroźniejszy wpis wygląda niewinnie:

User-agent: *
Disallow: /

Sam ukośnik oznacza katalog główny, a więc każdy adres w witrynie. Taki plik zakazuje wszystkim robotom pobierania czegokolwiek. Od poprawnego pliku, który niczego nie blokuje, różni go jeden znak: w wierszu Disallow: bez ukośnika zakazu nie ma, z ukośnikiem zakaz obejmuje całość.

Ten wpis jest potrzebny i prawidłowy na wersji roboczej strony, której wyszukiwarki nie powinny pobierać. Kłopot zaczyna się wtedy, gdy trafia na stronę produkcyjną. Z mojej praktyki wynika, że dzieje się to najczęściej na cztery sposoby:

• nowa strona jest budowana pod adresem roboczym z blokadą, a w dniu uruchomienia wszystkie pliki, razem z robots.txt, zostają skopiowane na właściwą domenę;
• wtyczka do przenoszenia lub klonowania witryny kopiuje ustawienia wersji roboczej, w tym treść pliku zapisaną w ustawieniach wtyczki SEO;
• firma hostingowa lub narzędzie do tworzenia kopii roboczych samo dodaje blokadę i nie zdejmuje jej po publikacji;
• ktoś wkleja gotowy plik znaleziony w sieci, nie czytając, co oznaczają jego wiersze.

Skutki nie są widoczne od razu, co utrudnia powiązanie ich z przyczyną. Strony pozostają w indeksie, ale Google przestaje je odświeżać. Z czasem wyniki tracą opisy, nowe podstrony nie pojawiają się wcale, a w raporcie „Indeksowanie stron” w Search Console rośnie liczba adresów ze stanem „URL zablokowany przez plik robots.txt”.

Dlatego kontrola pliku powinna być stałym punktem każdego uruchomienia nowej wersji serwisu. Opisałem to szerzej w tekście o tym, jak przeprowadzić migrację strony bez utraty pozycji w Google.

W WordPressie istnieje jeszcze drugi przełącznik o podobnym skutku, który łatwo pomylić z plikiem. W menu „Ustawienia”, w zakładce „Czytanie”, znajduje się pole „Proś wyszukiwarki o nieindeksowanie tej witryny”. W aktualnych wersjach WordPressa zaznaczenie tego pola nie zmienia pliku robots.txt, tylko dodaje do każdej strony znacznik noindex. Plik może więc wyglądać poprawnie, a witryna i tak znika z wyników. Po uruchomieniu strony pole musi być odznaczone.

Jak wygląda poprawny plik dla WordPressa i dla sklepu?

Dobry plik jest krótki. Blokuje tylko to, czego robot naprawdę nie powinien pobierać, i niczego więcej. WordPress sam podaje robotom rozsądne minimum, które wygląda tak:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.przyklad.pl/sitemap_index.xml

Pierwsza reguła zamyka przed robotami panel administracyjny. Druga zostawia otwarty jeden plik z tego katalogu, z którego korzystają motywy i wtyczki przy wyświetlaniu zwykłych stron. Wiersz z mapą witryny zależy od tego, co ją tworzy: sam WordPress wskazuje plik wp-sitemap.xml, a wtyczki SEO podają własny adres. Należy wpisać ten, który po otwarciu w przeglądarce rzeczywiście pokazuje mapę.

Dla większości stron firmowych taki plik w zupełności wystarcza. Nie ma potrzeby blokowania katalogów /wp-content/ ani /wp-includes/. Leżą w nich style, skrypty i obrazy, bez których Google nie zobaczy strony tak, jak widzi ją klient.

Sklep internetowy tworzy dodatkowo wiele adresów, które różnią się tylko parametrem: sortowanie listy produktów, filtry, dodanie produktu do koszyka. Robot traci na nie czas, a nie ma z nich żadnej nowej treści. Przykładowy plik dla sklepu na WooCommerce może wyglądać tak:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*?add-to-cart=
Disallow: /*&add-to-cart=
Disallow: /*?orderby=
Disallow: /*&orderby=
Disallow: /*?filter_
Disallow: /*&filter_

Sitemap: https://www.przyklad.pl/sitemap_index.xml

To przykład, a nie wzór do wklejenia bez zastanowienia. Nazwy parametrów zależą od motywu i wtyczek filtrujących, dlatego najpierw trzeba otworzyć sklep, użyć sortowania i filtrów i odczytać z paska adresu, jakie parametry naprawdę się pojawiają. Każdy parametr ma dwa wiersze, ponieważ może stać w adresie jako pierwszy, po znaku zapytania, albo jako kolejny, po znaku &.

Stron koszyka, zamówienia i konta klienta nie radzę blokować w pliku. One mają nie pojawiać się w wynikach, a do tego służy noindex, który wtyczka sklepu zwykle sama im nadaje. Blokada w robots.txt uniemożliwiłaby robotowi odczytanie tego znacznika.

Przed zablokowaniem filtrów trzeba też ustalić, czy któraś z filtrowanych list nie jest celowo budowana jako strona docelowa dla klientów z wyszukiwarki. Jeśli sklep ma kilka podobnych list walczących o tę samą frazę, lepszym narzędziem bywa uporządkowanie ich treści, o czym piszę w tekście o tym, czym jest kanibalizacja słów kluczowych.

Jak zmienić plik: serwer, wtyczka SEO czy wirtualny plik WordPressa?

Zanim cokolwiek zostanie zmienione, trzeba ustalić, skąd bierze się treść widoczna pod adresem /robots.txt. W WordPressie są trzy możliwości i od tego zależy, gdzie wprowadza się poprawkę.

Wirtualny plik WordPressa

Jeśli w katalogu głównym na serwerze nie ma pliku robots.txt, WordPress tworzy jego treść w locie, przy każdym wywołaniu adresu. Takiego pliku nie da się znaleźć ani otworzyć na serwerze, bo fizycznie nie istnieje. Jego treść można zmienić tylko przez wtyczkę albo przez wgranie prawdziwego pliku.

Prawdziwy plik na serwerze

Plik leżący fizycznie w katalogu głównym ma pierwszeństwo przed wirtualnym. Jeśli istnieje, to serwer wysyła jego treść, a ustawienia wtyczek przestają mieć znaczenie. Edytuje się go tak:

1. Zalogowanie do panelu firmy hostingowej i otwarcie menedżera plików albo połączenie z serwerem programem FTP.
2. Przejście do katalogu głównego witryny, czyli tego, w którym leżą katalogi wp-admin i wp-content oraz plik wp-config.php.
3. Pobranie obecnego pliku robots.txt na dysk jako kopii zapasowej.
4. Otwarcie pliku w edytorze menedżera plików lub w Notatniku, wprowadzenie zmian i zapisanie go jako zwykłego tekstu w kodowaniu UTF-8.
5. Wgranie pliku z powrotem do tego samego katalogu, pod tą samą nazwą, pisaną małymi literami.
6. Otwarcie adresu /robots.txt w oknie prywatnym przeglądarki i porównanie treści z tym, co zostało zapisane.

Jeśli po zapisaniu przeglądarka wciąż pokazuje starą treść, przyczyną jest zwykle pamięć podręczna: wtyczki, serwera albo sieci CDN. Należy ją wyczyścić i odświeżyć adres.

Edytor we wtyczce SEO

Popularne wtyczki SEO mają własny edytor pliku, co jest wygodne dla osób bez dostępu do serwera. Położenie edytora różni się między wtyczkami, a nazwy pozycji menu zależą od wersji językowej, dlatego podaję je w brzmieniu z dokumentacji producentów.

• Yoast SEO: w menu wtyczki pozycja „Tools” (w polskiej wersji „Narzędzia”), dalej „File editor”. Jeśli pliku nie ma, pojawia się przycisk „Create robots.txt file”. Edytor jest niewidoczny, gdy edycja plików została w WordPressie wyłączona.
• Rank Math: po włączeniu trybu zaawansowanego należy wejść w „General Settings” (ustawienia ogólne), a następnie „Edit robots.txt”. Wtyczka zmienia plik wirtualny, więc gdy na serwerze leży prawdziwy plik, producent zaleca najpierw go usunąć.
• SEOPress: w menu „SEO” zakładka „PRO”, a w niej „robots.txt”. Trzeba włączyć funkcję i zaznaczyć opcję wirtualnego pliku. Dokumentacja zastrzega, że prawdziwy plik na serwerze ma pierwszeństwo przed wirtualnym.

Po każdej zmianie we wtyczce obowiązuje ta sama kontrola co przy edycji na serwerze: otwarcie adresu /robots.txt w oknie prywatnym. Tylko to, co widać pod tym adresem, jest prawdą dla robota. To, co wyświetla edytor w panelu, bywa jedynie zapisanym ustawieniem, które przegrywa z plikiem na serwerze.

W systemach, które nie dają dostępu do plików, takich jak gotowe kreatory stron, bezpośrednia edycja może nie być możliwa. Google wskazuje, że w takim przypadku widoczność stron ustawia się w panelu danego systemu, a szczegółów trzeba szukać w jego pomocy.

Jak sprawdzić plik w Search Console i poprosić Google o ponowne pobranie?

Google nie pobiera pliku przy każdej wizycie. Przechowuje jego kopię w pamięci podręcznej, zwykle do 24 godzin, i przez ten czas stosuje starą wersję. Po naprawie groźnego wpisu nie trzeba więc czekać bezczynnie. Search Console ma osobny raport dotyczący pliku robots.txt, w którym widać, co Google faktycznie pobrał, i można poprosić o szybsze odświeżenie.

Raport jest dostępny dla usług domenowych oraz dla usług z prefiksem adresu URL obejmujących całą witrynę, a nie pojedynczy katalog. Pokazuje pliki znalezione dla 20 najważniejszych hostów w usłudze.

1. Po zalogowaniu do Search Console i wybraniu właściwej usługi należy otworzyć „Ustawienia” w menu bocznym.
2. W ustawieniach znajduje się wiersz dotyczący pliku robots.txt, z którego otwiera się raport.
3. Na liście widać każdy znaleziony plik z kolumnami: ścieżka pliku, stan pobierania, data sprawdzenia, rozmiar i liczba problemów.
4. Kliknięcie pliku pokazuje ostatnio pobraną treść. Należy porównać ją z tym, co wyświetla przeglądarka. Jeśli Google ma jeszcze starą wersję z blokadą, potrzebne jest odświeżenie.
5. Obok pliku na liście znajduje się ikona „Więcej ustawień”. Po jej kliknięciu należy wybrać „Poproś o ponowne zindeksowanie”.
6. Po pewnym czasie raport trzeba otworzyć ponownie i potwierdzić, że data sprawdzenia jest nowa, a w treści nie ma już blokady.

Stan pobierania ma trzy możliwe wartości. „Pobrano” oznacza, że Google odczytał plik i stosuje jego reguły, pomijając wiersze z błędami. Stan mówiący, że pliku nie znaleziono i serwer odpowiedział kodem 404, nie jest powodem do niepokoju: Google skanuje wtedy całą witrynę. Trzeci stan, niepobranie z innego powodu, wymaga uwagi, bo wskazuje na kłopot z serwerem.

Ten trzeci przypadek bywa groźniejszy niż zły wpis. Gdy serwer na żądanie pliku odpowiada błędem z grupy 5xx, Google przez pierwsze 12 godzin wstrzymuje skanowanie witryny i ponawia próby. Jeśli błąd trwa, przez kolejne 30 dni korzysta z ostatniej poprawnej kopii pliku. Przy takim stanie sprawę należy zgłosić firmie hostingowej, ponieważ zmiana treści pliku niczego nie naprawi.

Kolumna z problemami rozróżnia błędy i ostrzeżenia. Wiersz z błędem Google pomija, a pozostałe reguły stosuje. Literówka w nazwie pola może więc sprawić, że zakaz, na którym właścicielowi zależało, po prostu nie działa.

Raport przechowuje też wcześniejsze wersje pliku z ostatnich 30 dni. Po kliknięciu pliku dostępna jest lista „Wersje”. To bardzo przydatne przy ustalaniu, kiedy blokada się pojawiła i czy data zgadza się z początkiem spadku ruchu.

Prośba o ponowne pobranie pliku nie gwarantuje natychmiastowego powrotu odblokowanych stron. Google zastrzega to w pomocy. Plik zostanie odświeżony szybko, ale poszczególne adresy robot odwiedza we własnym tempie.

Jakie błędy pojawiają się najczęściej?

Blokada stylów i skryptów

Google przy ocenie strony wyświetla ją podobnie jak przeglądarka, a do tego potrzebuje plików CSS i JavaScript. Jeśli plik robots.txt zakazuje pobierania katalogów z motywem lub wtyczkami, robot widzi stronę bez układu, a czasem bez części treści. Dokumentacja pozwala blokować pliki zasobów tylko wtedy, gdy ich brak nie utrudnia zrozumienia strony. Stare pliki z zakazem dla /wp-content/plugins/ lub /wp-includes/ należy z tych wierszy oczyścić.

Blokada zamiast noindex

Właściciel chce usunąć z Google starą ofertę, regulamin promocji albo wyniki wewnętrznej wyszukiwarki i dopisuje zakaz w pliku. Efekt jest odwrotny do zamierzonego: adres zostaje w wynikach, tylko bez opisu. Prawidłowa kolejność to nadanie stronie znacznika noindex, pozostawienie jej otwartej dla robota i poczekanie, aż zniknie z wyników.

Zakaz o zbyt szerokim zasięgu

Brak ukośnika na końcu ścieżki albo zbyt krótki początek adresu potrafi zablokować więcej, niż planowano. Reguła Disallow: /p obejmie wszystkie adresy zaczynające się na tę literę, w tym produkty i wpisy. Każdą nową regułę trzeba przetestować na kilku prawdziwych adresach z witryny.

Poleganie na polach, których Google nie czyta

Wiersze Crawl-delay i Noindex nie mają dla Google żadnego znaczenia. Kto próbował w ten sposób spowolnić robota albo usunąć strony z wyników, nie osiągnął niczego. Inne wyszukiwarki mogą część takich pól respektować, jednak nie należy na tym opierać ochrony witryny.

Osobna grupa, która znosi reguły ogólne

Dopisanie na końcu pliku grupy dla jednego robota, na przykład z jednym zakazem dla Googlebota, powoduje, że ten robot przestaje stosować reguły z grupy z gwiazdką. Otwierają się dla niego adresy, które miały być zamknięte.

Pominięcie subdomen i drugiej wersji adresu

Plik poprawiony w głównej domenie nie zmienia niczego w subdomenie sklepu, bloga czy wersji roboczej. Każdy host trzeba sprawdzić osobno.

Jak sprawdzić, czy zmiana przyniosła skutek?

Kontrola ma trzy poziomy: plik, pojedynczy adres i cała witryna. Pierwszy poziom to raport opisany wyżej. Drugi i trzeci wykonuje się w tej kolejności:

1. W Search Console, w polu wyszukiwania na górze ekranu, wpisuje się pełny adres ważnej podstrony, która była zablokowana. Uruchamia to narzędzie do sprawdzania adresów URL.
2. Po kliknięciu „Sprawdź URL wersji opublikowanej” narzędzie pobiera stronę na żywo. W wynikach należy odszukać pole „Czy skanowanie jest dozwolone”. Odpowiedź twierdząca oznacza, że plik już nie blokuje tego adresu.
3. Poniżej znajduje się pole „Czy indeksowanie jest dozwolone”. Ono dotyczy znacznika noindex, a nie pliku. Odpowiedź przecząca oznacza, że strona ma noindex i to on jest teraz przeszkodą.
4. Dla najważniejszych odblokowanych adresów można kliknąć „Poproś o zindeksowanie”. Liczba takich próśb w ciągu doby jest ograniczona, więc warto zacząć od strony głównej, stron usług i głównych kategorii.
5. W raporcie „Indeksowanie stron” należy otworzyć wiersz „URL zablokowany przez plik robots.txt” i przejrzeć listę adresów. Powinny na niej zostać tylko te, które są blokowane celowo.
6. Jeśli lista zawierała adresy zablokowane przez pomyłkę, po naprawie klika się „Sprawdź poprawkę”. Według pomocy Google weryfikacja trwa zwykle do dwóch tygodni i w tym czasie nie należy uruchamiać jej ponownie.

Oznaką powodzenia jest malejąca liczba adresów w wierszu o blokadzie i powrót opisów w wynikach wyszukiwania. Więcej sposobów kontroli pojedynczych adresów opisałem w tekście o tym, jak sprawdzić, czy strona jest zaindeksowana w Google.

Co zrobić, gdy mimo poprawki strony nie wracają do wyników?

Jeśli po kilku dniach narzędzie do sprawdzania adresów nadal pokazuje blokadę, trzeba wrócić do źródła. Najpierw należy otworzyć /robots.txt w oknie prywatnym i upewnić się, że poprawka jest widoczna publicznie. Jeśli nie jest, na serwerze leży prawdziwy plik, który przesłania ustawienia wtyczki, albo działa pamięć podręczna.

Gdy plik jest poprawny, a strony wciąż nie wracają, przyczyna leży zwykle poza nim. Warto kolejno wykluczyć: zaznaczone pole o nieindeksowaniu w ustawieniach WordPressa, znacznik noindex ustawiony we wtyczce SEO dla całego typu treści, nagłówek X-Robots-Tag dodany na serwerze oraz hasło pozostawione po wersji roboczej. Każdą z tych rzeczy pokaże narzędzie do sprawdzania adresów URL w polu o dozwolonym indeksowaniu lub w polu „Pobranie strony”.

Trzeba też uczciwie powiedzieć, że powrót po długiej blokadzie wymaga czasu. Google musi ponownie pobrać każdą stronę, a przy dużych serwisach trwa to tygodnie. Nie da się tego przyspieszyć wielokrotnym wysyłaniem tych samych próśb. Pomaga aktualna mapa witryny przesłana w Search Console i sprawne linkowanie między podstronami.

Jeśli spadek ruchu ma więcej niż jedną przyczynę, sam plik jej nie wyjaśni. Wtedy potrzebny jest szerszy przegląd, którego zakres opisałem w tekście o tym, co obejmuje audyt SEO strony.

Najczęstsze pytania

Czy każda strona musi mieć plik robots.txt?

Nie. Brak pliku jest poprawnym stanem i oznacza dla Google zgodę na skanowanie całej witryny. Plik warto mieć, gdy trzeba wyłączyć ze skanowania panel, adresy z parametrami lub inne obszary bez wartości dla wyszukiwarki, a także po to, żeby wskazać robotom mapę witryny.

Czy zakaz w robots.txt usunie stronę z wyników Google?

Nie. Zakaz zatrzymuje pobieranie strony, ale jej adres może pozostać w wynikach bez opisu, jeśli prowadzą do niego linki. Do usunięcia strony z wyników służy znacznik noindex albo zabezpieczenie hasłem, a strona z noindex nie może być jednocześnie blokowana w pliku.

Jak szybko Google zauważa zmianę w pliku?

Google przechowuje kopię pliku zwykle do 24 godzin, więc zmiana jest uwzględniana najpóźniej po tym czasie. Proces można przyspieszyć w raporcie dotyczącym pliku robots.txt w Search Console, wybierając „Poproś o ponowne zindeksowanie”. Nie oznacza to jednak natychmiastowego powrotu odblokowanych stron do wyników.

Czy plik robots.txt chroni poufne dane?

Nie chroni. Plik jest publiczny, a jego reguły są jedynie prośbą, którą nieuczciwe programy mogą zignorować. Wpisanie do niego adresu poufnego katalogu wręcz ułatwia jego odnalezienie. Dane wymagające ochrony zabezpiecza się hasłem lub ograniczeniem dostępu na serwerze.

Czy w pliku trzeba podawać mapę witryny?

Nie ma takiego obowiązku, ale jest to dobra praktyka. Wiersz Sitemap pozwala każdemu robotowi odnaleźć mapę bez dodatkowych zgłoszeń. Adres musi być pełny, razem z protokołem i domeną, i musi prowadzić do działającej mapy.

Czy wielkość liter w pliku ma znaczenie?

W nazwach pól nie ma, więc zapis Disallow i disallow działa tak samo. W ścieżkach ma: reguła dla /Katalog/ nie obejmuje adresu /katalog/. Sama nazwa pliku powinna być zapisana małymi literami.

Co się stanie, gdy w pliku będzie błąd składni?

Google pominie wiersz, którego nie rozumie, i zastosuje pozostałe. Oznacza to, że reguła z literówką po prostu nie działa, a witryna nie zostaje przez to zablokowana. Liczbę takich wierszy pokazuje kolumna z problemami w raporcie dotyczącym pliku robots.txt w Search Console.

Czy plik można zmieniać bez dostępu do serwera?

W WordPressie tak, jeśli na serwerze nie leży prawdziwy plik: treść wirtualnego pliku zmienia się w edytorze wtyczki SEO. Gdy prawdziwy plik istnieje, ma pierwszeństwo i trzeba go zmienić lub usunąć przez menedżera plików w panelu hostingu, do czego potrzebny jest dostęp do tego panelu.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

To zupełnie zrozumiałe. Opisane czynności wymagają spokoju i kilku wolnych godzin, a w firmie zwykle brakuje jednego i drugiego. Chętnie zrobię to od początku do końca: sprawdzę plik robots.txt, poprawię go i potwierdzę wynik w Search Console.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i w kilku zdaniach opisać sprawę. Odpowiadam osobiście i od razu mówię, co da się zrobić.