Jak Google interpretuje specyfikację pliku robots.txt
Automatyczne roboty Google obsługują protokół Robots Exclusion Protocol (REP). Oznacza to, że przed zindeksowaniem witryny roboty Google pobierają i analizują jej plik robots.txt, aby wyodrębnić informacje o tym, które części witryny można zindeksować. Protokół REP nie dotyczy robotów Google kontrolowanych przez użytkowników (np. subskrypcja kanałów) ani robotów służących do zwiększania bezpieczeństwa użytkowników (np. analiza złośliwego oprogramowania).
Na tej stronie opisano, jak Google interpretuje protokół REP. Pierwotny standard znajdziesz w dokumencie RFC 9309.
Co to jest plik robots.txt?
Jeśli nie chcesz, aby roboty miały dostęp do pewnych sekcji Twojej witryny, możesz utworzyć plik robots.txt z odpowiednimi regułami. Plik robots.txt to prosty plik tekstowy z regułami określającymi, które roboty mogą uzyskać dostęp do poszczególnych części witryny. Na przykład plik robots.txt dla witryny example.com może wyglądać tak:
# This robots.txt file controls crawling of URLs under https://example.com. # All crawlers are disallowed to crawl files in the "includes" directory, such # as .css, .js, but Google needs them for rendering, so Googlebot is allowed # to crawl them. User-agent: * Disallow: /includes/ User-agent: Googlebot Allow: /includes/ Sitemap: https://example.com/sitemap.xml
Jeśli korzystasz z pliku robots.txt po raz pierwszy, zacznij od wprowadzenia do pliku robots.txt. Możesz też znaleźć wskazówki dotyczące tworzenia pliku robots.txt i obszerną listę najczęstszych pytań wraz z odpowiedziami.
Lokalizacja pliku i zasięg działania
Plik robots.txt musi się znajdować w katalogu głównym witryny i musi być dostępny za pomocą obsługiwanego protokołu. Wielkość liter w adresie URL pliku robots.txt (tak jak w innych adresach URL) jest rozróżniana. W przypadku wyszukiwarki Google obsługiwane protokoły to HTTP, HTTPS i FTP. Protokoły HTTP i HTTPS pozwalają odczytać plik robots.txt bezwarunkowym żądaniem HTTP GET. W przypadku protokołu FTP roboty używają standardowego polecenia RETR (RETRIEVE), korzystając z anonimowego loginu.
Reguły wymienione w pliku robots.txt odnoszą się tylko do hosta, protokołu i numeru portu używanych do jego udostępniania.
Przykłady prawidłowych adresów URL pliku robots.txt
Poniższa tabela zawiera przykładowe adresy URL pliku robots.txt i ścieżki, dla których są one prawidłowe. Pierwsza kolumna zawiera adres URL pliku robots.txt, a druga wskazuje domeny, do których dany plik robots.txt miałby zastosowanie lub nie miałby zastosowania.
| Przykłady adresów URL pliku robots.txt | |
|---|---|
https://example.com/robots.txt |
To sytuacja ogólna. Plik nie odnosi się do innych subdomen, protokołów ani numerów portów. Obowiązuje w przypadku każdego pliku we wszystkich podkatalogach z tym samym hostem, protokołem i numerem portu. Prawidłowy w przypadku adresów:
|
https://www.example.com/robots.txt |
Plik robots.txt w subdomenie obowiązuje tylko w niej. Prawidłowy w przypadku adresu: Nieprawidłowy w przypadku adresów:
|
https://example.com/folder/robots.txt |
Plik robots.txt jest nieprawidłowy. Roboty nie szukają plików robots.txt w podkatalogach. |
https://www.exämple.com/robots.txt |
Nazwy IDN mają swoje odpowiedniki w punycode. Zapoznaj się z normą RFC 3492. Prawidłowy w przypadku adresów:
Nieprawidłowy w przypadku adresu: |
ftp://example.com/robots.txt |
Prawidłowy w przypadku adresu: Nieprawidłowy w przypadku adresu: |
https://212.96.82.21/robots.txt |
Plik robots.txt z adresem IP jako nazwą hosta obowiązuje tylko podczas skanowania stron, które mają ten adres IP jako nazwę hosta. Nie obowiązuje automatycznie we wszystkich witrynach przechowywanych pod tym adresem IP (plik robots.txt może być jednak wspólny – wtedy jest też dostępny pod wspólną nazwą hosta). Prawidłowy w przypadku adresu: Nieprawidłowy w przypadku adresu: |
https://example.com:443/robots.txt |
Standardowe numery portów ( Prawidłowy w przypadku adresów:
Nieprawidłowy w przypadku adresu: |
https://example.com:8181/robots.txt |
Pliki robots.txt na portach o niestandardowych numerach obowiązują tylko w przypadku treści udostępnianych przez te porty. Prawidłowy w przypadku adresu: Nieprawidłowy w przypadku adresu: |
Obsługa błędów i kodów stanu HTTP
Po wysłaniu żądania pliku robots.txt kod stanu HTTP odpowiedzi serwera wpływa na sposób, w jaki roboty Google będą z tego pliku korzystać. W tabeli poniżej opisujemy, jak Googlebot traktuje pliki robots.txt w przypadku różnych kodów stanu HTTP.
| Obsługa błędów i kodów stanu HTTP | |
|---|---|
2xx (success) |
Kody stanu HTTP oznaczające, że próba przetworzenia pliku robots.txt w sposób podany przez serwer zakończyła się powodzeniem. |
3xx (redirection) |
Google śledzi co najmniej 5 przekierowań zgodnie z definicją podaną w specyfikacji RFC 1945, a następnie przerywa działanie i przyjmuje dla pliku robots.txt kod Google nie śledzi przekierowań logicznych w plikach robots.txt (ramki, JavaScript lub metaodświeżanie). |
4xx (client errors) |
Roboty Google traktują wszystkie błędy |
5xx (server errors) |
Ponieważ serwer nie mógł ostatecznie odpowiedzieć na żądanie dotyczące pliku robots.txt, Google tymczasowo interpretuje błędy serwera Jeśli chcesz tymczasowo zawiesić indeksowanie, zalecamy podawanie kodu stanu HTTP
Jeśli stwierdzimy, że witryna jest nieprawidłowo skonfigurowana i w przypadku brakujących stron zwraca kod stanu |
| Inne błędy | Jeśli pliku robots.txt nie można odczytać z powodu problemów z DNS lub siecią (przekroczone czasy oczekiwania, nieprawidłowe odpowiedzi, zresetowane/zerwane połączenia, błędy podziału danych HTTP itp.), jest to traktowane jako błąd serwera. |
Zapisywanie w pamięci podręcznej
Google zwykle przechowuje treść pliku robots.txt w pamięci podręcznej przez maksymalnie 24 godziny, ale w sytuacji, gdy nie można odświeżyć wersji w pamięci podręcznej (np. z powodu przekroczenia czasu oczekiwania lub błędów 5xx), okres ten może się wydłużyć. Z odpowiedzi zapisanej w pamięci podręcznej mogą korzystać różne roboty.
Google może wydłużyć lub skrócić czas przechowywania w pamięci podręcznej na podstawie nagłówków HTTP max-age Cache-Control.
Format pliku
Plik robots.txt musi być zwykłym plikiem tekstowym zakodowanym w formacie UTF-8. Wiersze muszą być oddzielone znakami CR, CR/LF lub LF.
Google ignoruje nieprawidłowe wiersze w plikach robots.txt, w tym znacznik kolejności bajtów (BOM) Unicode na początku pliku robots.txt, i wykorzystuje tylko prawidłowe wiersze. Jeśli na przykład pobrana treść ma format HTML zamiast reguł pliku robots.txt, Google spróbuje ją przeanalizować i wyodrębnić reguły, ignorując pozostałą zawartość.
Podobnie, jeśli znaki w pliku robots.txt nie są kodowane w formacie UTF-8, Google może zignorować znaki spoza zakresu UTF-8, co może spowodować, że reguły w pliku robots.txt będą renderowane nieprawidłowo.
Obecnie w Google obowiązuje limit rozmiaru pliku robots.txt wynoszący 500 kibibajtów (KiB). Po przekroczeniu maksymalnego rozmiaru pliku dalsza treść jest ignorowana. Możesz zmniejszyć rozmiar pliku robots.txt, konsolidując reguły, które powodują nadmierne zwiększenie jego rozmiaru. Możesz na przykład umieścić wykluczony materiał w osobnym katalogu.
Składnia
Prawidłowe wiersze pliku robots.txt składają się z pola, dwukropka i wartości. Spacje są opcjonalne, ale zalecane, aby zwiększyć czytelność. Spacje na początku i na końcu wiersza są ignorowane. Jeśli dodajesz komentarze, poprzedź je znakiem #. Pamiętaj, że wszystko, co jest po znaku #, zostanie zignorowane. Ogólny format to <field>:<value><#optional-comment>.
Google obsługuje te pola:
user-agent: wskazuje robota, którego dotyczą reguły.allow: ścieżka adresu URL, która może być indeksowana.disallow: ścieżka adresu URL, której nie można indeksować.sitemap: pełny adres URL mapy witryny.
Pola allow i disallow są też nazywane regułami. Reguły mają postać rule: [path], gdzie [path] jest wartością opcjonalną. Domyślnie nie ma ograniczeń w indeksowaniu stron przez określone roboty. Roboty ignorują reguły bez atrybutu [path].
Wartość [path] (jeśli została określona) jest względna wobec katalogu głównego witryny, z której pochodzi dany plik robots.txt (ma ten sam protokół, numer portu, hosta i domenę).
Wartość ścieżki musi zaczynać się znakiem / wskazującym katalog główny. Wielkość liter ma znaczenie. Dowiedz się więcej o zgodności adresów URL na podstawie wartości ścieżki.
user-agent
Wiersz user-agent wskazuje robota, którego dotyczą reguły. Pełną listę ciągów klienta użytkownika, których można użyć w pliku robots.txt, znajdziesz w sekcji dotyczącej robotów Google i ciągów klienta użytkownika.
Wielkość liter w wartości wiersza user-agent nie jest rozróżniana.
disallow
Reguła disallow określa ścieżki, do których nie mogą uzyskać dostępu roboty wskazane w wierszu user-agent, który występuje w grupie z regułą disallow.
Roboty ignorują regułę bez ścieżki.
Google nie może indeksować zawartości stron, których indeksowanie zablokowano, ale nadal może indeksować ich adresy URL i wyświetlać je w wynikach wyszukiwania bez fragmentu treści. Dowiedz się, jak zablokować indeksowanie.
Wielkość liter w wartości reguły disallow jest rozróżniana.
Sposób użycia:
disallow: [path]
allow
Reguła allow określa ścieżki, do których wskazane roboty mogą uzyskiwać dostęp. W przypadku braku ścieżki reguła jest ignorowana.
Wielkość liter w wartości pola allow jest rozróżniana.
Sposób użycia:
allow: [path]
sitemap
Pole sitemap w pliku robots.txt obsługują Google, Bing i inne popularne wyszukiwarki. Jego definicję znajdziesz na sitemaps.org.
Wielkość liter w wartości pola sitemap jest rozróżniana.
Sposób użycia:
sitemap: [absoluteURL]
Wiersz [absoluteURL] wskazuje lokalizację mapy witryny lub pliku indeksu map witryn.
Musi to być pełny i jednoznaczny URL obejmujący protokół i hosta. Nie musi być zakodowany. Adres URL nie musi należeć do tego samego hosta co plik robots.txt. Możesz określić wiele pól sitemap. Pole mapy witryny nie odnosi się do żadnego konkretnego klienta użytkownika – wszystkie roboty mogą z niego korzystać, o ile indeksowanie w danej lokalizacji nie jest zabronione.
Na przykład:
user-agent: otherbot disallow: /kale sitemap: https://example.com/sitemap.xml sitemap: https://cdn.example.org/other-sitemap.xml sitemap: https://ja.example.org/テスト-サイトマップ.xml
Grupowanie wierszy i reguł
Możesz grupować reguły dotyczące wielu klientów użytkownika, powtarzając wiersze user-agent na potrzeby poszczególnych robotów.
Na przykład:
user-agent: a disallow: /c user-agent: b disallow: /d user-agent: e user-agent: f disallow: /g user-agent: h
W tym przykładzie mamy 4 różne grupy reguł:
- Jedna grupa dla klienta użytkownika „a”.
- Jedna grupa dla klienta użytkownika „b”.
- Jedna grupa dla klientów użytkownika „e” i „f”.
- Jedna grupa dla klienta użytkownika „h”.
Techniczny opis grupy znajdziesz w sekcji 2.1 dokumentacji REP.
Pierwszeństwo obowiązywania dla klientów użytkownika
W przypadku konkretnego robota tylko jedna grupa jest prawidłowa. Roboty Google muszą ustalić właściwą grupę reguł, znajdując w pliku robots.txt grupę z najbardziej konkretnym pasującym do nich klientem użytkownika. Pozostałe grupy są ignorowane. Wszystkie niepasujące fragmenty tekstu są ignorowane (np. googlebot/1.2 i googlebot* to odpowiedniki wartości googlebot). Kolejność grup w pliku robots.txt nie ma znaczenia.
Jeśli dla klienta użytkownika istnieje więcej niż 1 określona grupa, wszystkie reguły z grup mające zastosowanie do tego klienta użytkownika są łączone wewnętrznie w 1 grupę. Określone grupy klientów użytkownika i grupy globalne (*) nie są połączone.
Przykłady
Dopasowywanie pól user-agent
user-agent: googlebot-news (group 1) user-agent: * (group 2) user-agent: googlebot (group 3)
Roboty wybierają odpowiednią grupę w ten sposób:
| Grupa, której dyrektyw przestrzega robot | |
|---|---|
| Googlebot News |
googlebot-news przestrzega reguł grupy 1, ponieważ grupa 1 jest najbardziej szczegółowa.
|
| Googlebot (internet) | googlebot przestrzega reguł grupy 3. |
| Googlebot Storebot | Storebot-Google przestrzega reguł grupy 2, ponieważ nie ma konkretnej grupy dotyczącej robota Storebot-Google. |
| Googlebot News (podczas indeksowania obrazów) |
Podczas indeksowania obrazów robot googlebot-news przestrzega reguł grupy 1.
googlebot-news nie indeksuje obrazów w Grafice Google, więc przestrzega tylko reguł grupy 1.
|
| Inny robot (internet) | Inne roboty Google przestrzegają reguł grupy 2. |
| Inny robot (wiadomości) |
Inne roboty Google, które indeksują treść wiadomości, ale nie są oznaczone jako googlebot-news, przestrzegają reguł grupy 2. Nawet wtedy, gdy istnieje grupa dla podobnego robota, obowiązuje ona tylko w przypadku dokładnego dopasowania nazwy.
|
Grupowanie reguł
Jeśli plik robots.txt zawiera wiele grup, które odnoszą się do konkretnego klienta użytkownika, roboty Google wewnętrznie scalają te grupy. Na przykład:
user-agent: googlebot-news disallow: /fish user-agent: * disallow: /carrots user-agent: googlebot-news disallow: /shrimp
Roboty grupują reguły wewnętrznie w zależności od klienta użytkownika, na przykład:
user-agent: googlebot-news disallow: /fish disallow: /shrimp user-agent: * disallow: /carrots
Parser pliku robots.txt ignoruje reguły inne niż allow,disallow i user-agent. Oznacza to, że ten fragment pliku robots.txt jest traktowany jako 1 grupa, dlatego reguła disallow: / obejmuje zarówno klienta użytkownika user-agent a, jak i b:
user-agent: a sitemap: https://example.com/sitemap.xml user-agent: b disallow: /
Gdy roboty przetwarzają reguły w pliku robots.txt, ignorują wiersz sitemap.
Tak na przykład roboty rozumieją poprzedni fragment pliku robots.txt:
user-agent: a user-agent: b disallow: /
Zgodność adresów URL na podstawie wartości ścieżki
Na podstawie wartości ścieżki w regułach allow i disallow Google określa, czy reguła ma zastosowanie do konkretnego adresu URL w witrynie. Jest to możliwe dzięki porównaniu reguły z komponentem ścieżki adresu URL, który robot próbuje pobrać.
Znaki ASCII inne niż 7-bitowe można umieścić w ścieżce jako znaki UTF-8 lub jako zakodowane zgodnie z RFC 3986 znaki UTF-8 ze zmianą znaczenia za pomocą znaku procenta.
Google, Bing i inne popularne wyszukiwarki obsługują w wartościach ścieżki ograniczone formy symboli wieloznacznych. Symbole wieloznaczne:
*oznacza 0 lub więcej wystąpień dowolnego prawidłowego znaku.$oznacza koniec adresu URL.
W tabeli poniżej pokazujemy, jak różne symbole wieloznaczne wpływają na analizę:
| Przykładowe dopasowania ścieżek | |
|---|---|
/ |
Pasuje do adresów URL na poziomie głównym i wszystkich niższych. |
/* |
Odpowiednik: /. Końcowy symbol wieloznaczny jest ignorowany. |
/$ |
Pasuje tylko do adresów na poziomie głównym. Wszystkie adresy URL na niższych poziomach mogą być indeksowane. |
/fish |
Pasuje do każdej ścieżki, która rozpoczyna się od Pasuje do wyrażeń:
Nie pasuje do wyrażeń:
|
/fish* |
Odpowiednik: Pasuje do wyrażeń:
Nie pasuje do wyrażeń:
|
/fish/ |
Pasuje do wszystkich elementów w folderze Pasuje do wyrażeń:
Nie pasuje do wyrażeń:
|
/*.php |
Pasuje do dowolnej ścieżki zawierającej Pasuje do wyrażeń:
Nie pasuje do wyrażeń:
|
/*.php$ |
Pasuje do każdej ścieżki, która kończy się Pasuje do wyrażeń:
Nie pasuje do wyrażeń:
|
/fish*.php |
Pasuje do każdej ścieżki zawierającej Pasuje do wyrażeń:
Nie pasuje do wyrażeń: |
Pierwszeństwo obowiązywania reguł
Dopasowując reguły pliku robots.txt do adresów URL, roboty korzystają z najbardziej szczegółowej reguły wybranej na podstawie długości ścieżki. W przypadku konfliktów reguł, w tym reguł z symbolami wieloznacznymi, Google przestrzega reguły najmniej restrykcyjnej.
Poniższe przykłady pokazują, którą regułę roboty Google zastosują do danego adresu URL.
| Przykładowe sytuacje: | |
|---|---|
https://example.com/page |
allow: /p disallow: /
Obowiązująca reguła: |
https://example.com/folder/page |
allow: /folder disallow: /folder
Obowiązująca reguła: |
https://example.com/page.htm |
allow: /page disallow: /*.htm
Obowiązująca reguła: |
https://example.com/page.php5 |
allow: /page disallow: /*.ph
Obowiązująca reguła: |
https://example.com/ |
allow: /$ disallow: /
Obowiązująca reguła: |
https://example.com/page.htm |
allow: /$ disallow: /
Obowiązująca reguła: |