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).

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.

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. 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

Przykłady adresów URL pliku robots.txt
http://example.com/robots.txt Prawidłowy w przypadku adresów:
  • http://example.com/
  • http://example.com/folder/file
Nieprawidłowy w przypadku adresów:
  • http://other.example.com/
  • https://example.com/
  • http://example.com:8181/
http://www.example.com/robots.txt

Prawidłowy w przypadku adresu: http://www.example.com/

Nieprawidłowy w przypadku adresów:

  • http://example.com/
  • http://shop.www.example.com/
  • http://www.shop.example.com/
http://example.com/folder/robots.txt Plik robots.txt jest nieprawidłowy. Roboty nie szukają plików robots.txt w podkatalogach.
http://www.exämple.com/robots.txt Prawidłowy w przypadku adresów:
  • http://www.exämple.com/
  • http://xn--exmple-cua.com/

Nieprawidłowy w przypadku adresu: http://www.example.com/

ftp://example.com/robots.txt

Prawidłowy w przypadku adresu: ftp://example.com/

Nieprawidłowy w przypadku adresu: http://example.com/

http://212.96.82.21/robots.txt

Prawidłowy w przypadku adresu: http://212.96.82.21/

Nieprawidłowy w przypadku adresu: http://example.com/ (nawet na hoście 212.96.82.21)

http://example.com:80/robots.txt

Prawidłowy w przypadku adresów:

  • http://example.com:80/
  • http://example.com/

Nieprawidłowy w przypadku adresu: http://example.com:81/

http://example.com:8181/robots.txt

Prawidłowy w przypadku adresu: http://example.com:8181/

Nieprawidłowy w przypadku adresu: http://example.com/

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ć.

Obsługa błędów i kodów stanu HTTP
2xx (operacja powiodła się) Kody stanu HTTP oznaczające, że próba przetworzenia pliku robots.txt w sposób podany przez serwer zakończyła się powodzeniem.
3xx (przekierowanie)

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 404. Dotyczy to również wszelkich zablokowanych adresów URL w łańcuchu przekierowań, ponieważ robot nie mógł pobrać reguł z powodu tych przekierowań.

Google nie śledzi przekierowań logicznych w plikach robots.txt (ramki, JavaScript lub metaodświeżanie).

4xx (błędy klienta)

Roboty Google traktują wszystkie błędy 4xx tak, jakby prawidłowy plik robots.txt nie istniał, co oznacza, że mogą indeksować bez ograniczeń.

5xx (błąd serwera)

Ponieważ serwer nie mógł ostatecznie odpowiedzieć na żądanie dotyczące pliku robots.txt, Google tymczasowo interpretuje błędy serwera w taki sposób, jakby witryna była całkowicie zablokowana. Google będzie podejmować próby zindeksowania pliku robots.txt aż do uzyskania kodu stanu HTTP innego niż błąd serwera. Błąd 503 (service unavailable) powoduje dość częste ponawianie próby. Jeśli plik robots.txt jest niedostępny przez ponad 30 dni, Google użyje jego ostatniej kopii zapisanej w pamięci podręcznej. Jeśli plik jest niedostępny, zakładamy brak ograniczeń.

Jeśli stwierdzimy, że witryna jest nieprawidłowo skonfigurowana i w przypadku brakujących stron zwraca kod stanu 5xx zamiast 404, traktujemy błąd 5xx z tej witryny jako 404. Jeśli na przykład komunikat o błędzie na stronie, która zwraca kod stanu 5xx, to „Nie znaleziono strony”, zinterpretujemy ten kod jako 404 (not found).

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 dyrektywy, 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 allowdisallow są też nazywane dyrektywami. Dyrektywy mają postać directive: [path], gdzie [path] jest wartością opcjonalną. Domyślnie nie ma ograniczeń w indeksowaniu stron przez określone roboty. Roboty ignorują dyrektywy bez wartości [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

Dyrektywa disallow określa ścieżki, do których nie mogą uzyskać dostępu roboty wskazane w wierszu klienta użytkownika, który występuje w grupie z dyrektywą disallow. Roboty ignorują dyrektywę bez ścieżki.

Wielkość liter w wartości dyrektywy disallow jest rozróżniana.

Sposób użycia:

disallow: [path]

allow

Dyrektywa allow określa ścieżki, do których wskazane roboty mogą uzyskiwać dostęp. W przypadku braku ścieżki dyrektywa jest ignorowana.

Wielkość liter w wartości dyrektywy 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 określonego klienta użytkownika istnieje więcej niż 1 grupa, wszystkie reguły z grup mające zastosowanie do tego klienta użytkownika są łączone wewnętrznie w 1 grupę.

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 Images googlebot-images przestrzega reguł grupy 2, ponieważ nie ma konkretnej grupy dotyczącej robota googlebot-images.
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

Zgodność adresów URL na podstawie wartości ścieżki

Na podstawie wartości ścieżki w dyrektywach allowdisallow 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. Dostępne symbole:

  • * oznacza zero lub więcej wystąpień dowolnego prawidłowego znaku.
  • $ oznacza koniec adresu URL.
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 /fish.

Pasuje do wyrażeń:

  • /fish
  • /fish.html
  • /fish/salmon.html
  • /fishheads
  • /fishheads/yummy.html
  • /fish.php?id=anything

Nie pasuje do wyrażeń:

  • /Fish.asp
  • /catfish
  • /?id=fish
  • /desert/fish
/fish*

Odpowiednik: /fish. Końcowy symbol wieloznaczny jest ignorowany.

Pasuje do wyrażeń:

  • /fish
  • /fish.html
  • /fish/salmon.html
  • /fishheads
  • /fishheads/yummy.html
  • /fish.php?id=anything

Nie pasuje do wyrażeń:

  • /Fish.asp
  • /catfish
  • /?id=fish
/fish/

Pasuje do wszystkich elementów w folderze /fish/.

Pasuje do wyrażeń:

  • /fish/
  • /animals/fish/
  • /fish/?id=anything
  • /fish/salmon.htm

Nie pasuje do wyrażeń:

  • /fish
  • /fish.html
  • /Fish/Salmon.asp
/*.php

Pasuje do dowolnej ścieżki zawierającej .php.

Pasuje do wyrażeń:

  • /index.php
  • /filename.php
  • /folder/filename.php
  • /folder/filename.php?parameters
  • /folder/any.php.file.html
  • /filename.php/

Nie pasuje do wyrażeń:

  • / (nawet jeśli wskazuje /index.php)
  • /windows.PHP
/*.php$

Pasuje do każdej ścieżki, która kończy się .php.

Pasuje do wyrażeń:

  • /filename.php
  • /folder/filename.php

Nie pasuje do wyrażeń:

  • /filename.php?parameters
  • /filename.php/
  • /filename.php5
  • /windows.PHP
/fish*.php

Pasuje do każdej ścieżki zawierającej /fish.php (w tej kolejności).

Pasuje do wyrażeń:

  • /fish.php
  • /fishheads/catfish.php?parameters

Nie pasuje do wyrażeń:/Fish.PHP

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:
http://example.com/page

allow: /p
disallow: /

Obowiązująca reguła: allow: /p, bo jest bardziej szczegółowa.

http://example.com/folder/page

allow: /folder
disallow: /folder

Obowiązująca reguła: allow: /folder, ponieważ w przypadku pasujących reguł Google stosuje najmniej restrykcyjną regułę.

http://example.com/page.htm

allow: /page
disallow: /*.htm

Obowiązująca reguła: disallow: /*.htm, ponieważ pasuje do większej liczby znaków w adresie URL, więc jest bardziej szczegółowa.

http://example.com/page.php5

allow: /page
disallow: /*.ph

Obowiązująca reguła: allow: /page, ponieważ w przypadku pasujących reguł Google stosuje najmniej restrykcyjną regułę.

http://example.com/

allow: /$
disallow: /

Obowiązująca reguła: allow: /$, bo jest bardziej szczegółowa.

http://example.com/page.htm

allow: /$
disallow: /

Obowiązująca reguła: disallow: /, ponieważ reguła allow odnosi się tylko do głównego adresu URL.