Введення

Ця стаття зовсім не є спробою пояснити, як працюють пошукові машини взагалі (це know-how їх виробників). Однак, на мою думку, вона допоможе зрозуміти, як можна управляти поведінкою пошукових роботів (wanderers, павуки, robots — програми, з допомогою яких та чи інша пошукова система обшаривает мережу і індексує зустрічаються документи) і як правильно побудувати структуру сервера і містяться на ньому документів, щоб Ваш сервер легко і добре індексувався.

Першою причиною того, що я наважився написати цю статтю, був випадок, коли я досліджував файл логів доступу до мого сервера і виявив там наступні два рядки:

lycosidae.lycos.com — — [01/Mar/1997:21:27:32 -0500] «GET /robots.txt HTTP/1.0» 404 —
lycosidae.lycos.com — — [01/Mar/1997:21:27:39 -0500] «GET / HTTP/1.0» 200 3270

тобто Lycos звернувся до мого сервера, на перший запит отримав, що файл /robots.txt ні, обнюхав першу сторінку, і відвалив. Природно, мені це не сподобалося, і я почав з’ясовувати, що до чого.

Виявляється, всі «розумні» пошукові машини спочатку звертаються до цього файлу, який повинен бути присутнім на кожному сервері. Цей файл описує права доступу для пошукових роботів, причому існує можливість вказати для різних роботів різні права. Для нього існує стандарт під назвою Standart for Robot Exclusion.

На думку Луїса Моньє (Louis Monier, Altavista), тільки 5% всіх сайтів в даний час має не порожні файли /robots.txt якщо взагалі вони (ці файли) там існують. Це підтверджується інформацією, зібраної при недавньому дослідженні логів роботи робота Lycos. Шарль Коллар (Charles P. Kollar, Lycos) пише, що лише 6% від усіх запитів на предмет /robots.txt мають код результату 200. Ось кілька причин, за якими це відбувається:

  • люди, які встановлюють Веб-сервера, просто не знають ні про цьому стандарті, ні про необхідність існування файлу /robots.txt
  • не обов’язково людина, инсталлировавший Веб-сервер, займається його наповненням, а той, хто є вебмайстром, не має належного контакту з адміністратором самої «залізяки»
  • це число відображає число сайтів, які дійсно потребують виключення зайвих запитів роботів, оскільки не на всіх серверах є такий істотний трафік, при якому відвідування сервера пошуковим роботом, стає помітним для простих користувачів

Формат файлу /robots.txt

Файл /robots.txt призначений для вказівки всім пошуковим роботам (spiders) індексувати інформаційні сервера так, як визначено в цьому файлі, тобто тільки ті директорії і файли сервера, які НЕ описані в /robots.txt. Це файл повинен містити 0 або більше записів, які пов’язані з тим чи іншим роботом (що визначається значенням поля agent_id), і вказують для кожного робота або для всіх відразу що саме їм НЕ ТРЕБА індексувати. Той, хто пише файл /robots.txt мушу зазначити підрядок Product Token поля User-Agent, яку кожен робот видає на запит HTTP індексуємого сервера. Наприклад, нинішній робот Lycos на такий запит видає як поле User-Agent: Lycos_Spider_(Rex)/1.0 libwww/3.1.

Якщо робот Lycos не знайшов свого опису в /robots.txt — він чинить так, як вважає за потрібне. Як тільки робот Lycos «побачив» у файлі /robots.txt опис для себе — він поступає так, як йому наказано.

При створенні файлу /robots.txt слід враховувати ще один фактор — розмір файлу. Оскільки описується кожен файл, який не слід індексувати, та ще для багатьох типів роботів окремо, при великій кількості не підлягають індексуванню файлів розмір /robots.txt стає занадто великим. У цьому випадку слід застосовувати один або кілька наступних способів скорочення розміру /robots.txt:

  • вказувати директорію, яку не слід індексувати, і, відповідно, не підлягають індексуванню файли розташовувати саме в ній
  • створювати структуру сервера з урахуванням спрощення опису виключень в /robots.txt
  • вказувати один спосіб індексування для всіх agent_id
  • вказувати маски для директорій і файлів

Записів (records) файлу /robots.txt

Загальний опис формату запису.

[ # comment string NL ]*
User-Agent: [ [ WS ]+ agent_id ]+ [ [ WS ]* # comment string ]? NL
[ # comment string NL ]*
Disallow: [ [ WS ]+ path_root ]* [ [ WS ]* # comment string ]? NL
[
# comment string NL
|
Disallow: [ [ WS ]+ path_root ]* [ [ WS ]* # comment string ]? NL
]*
[ NL ]+

Параметри

Опис параметрів, що застосовуються в записах /robots.txt

[…]+ Квадратні дужки з наступним за ними знаком » + » означають, що в якості параметрів повинні бути вказані один або кілька термінів.

Наприклад, після «User-Agent:» через пропуск можуть бути вказані один або кілька agent_id.

[…]* Квадратні дужки з наступним за ними знайомий * означають, що в якості параметрів можуть бути вказані нуль або кілька термінів.

Наприклад, Ви можете писати або не писати коментарі.

[…]? Квадратні дужки з наступним за ними знайомий ? означають, що в якості параметрів можуть бути вказані нуль або один термін.

Наприклад, після «User-Agent: agent_id» може бути написаний коментар.

..|.. означає або те, що до межі, або те, що після.

WS один з символів — пробіл (011) або табуляція (040)

NL один з символів — кінець рядка 015) , повернення каретки (012) або обидва цих символу (Enter)

User-Agent: ключове слово (заголовні і малі літери ролі не грають).

Параметрами є agent_id пошукових роботів.

Disallow: ключове слово (заголовні і малі літери ролі не грають).

Параметрами є повні шляхи до неиндексируемым файлів або директорій

# початок рядка коментарів, comment string — власне тіло коментаря.

agent_id будь-яку кількість символів, не включають WS і NL, які визначають agent_id різних пошукових роботів. Знак * визначає всіх роботів відразу.

path_root будь-яку кількість символів, не включають WS і NL, які визначають файли і директорії, не підлягають індексуванню.

Розширені коментарі формату

Кожен запис починається з рядка User-Agent, в якій описується яким або якому пошуковому роботові ця запис призначається. Наступна рядок: Disallow. Тут описуються не підлягають індексації шляху і файли. КОЖНА запис ПОВИННА мати як мінімум ці два рядки (lines). Всі інші рядки є опціями. Запис може містити будь-яку кількість рядків коментарів. Кожна рядок коментаря повинна починатися з символу # . Рядки коментарів можуть бути поміщені в кінці рядків User-Agent і Disallow. Символ # наприкінці цих рядків іноді додається для того, щоб вказати пошуковому роботу, що довга рядок agent_id або path_root закінчена. Якщо в рядку User-Agent зазначено кілька agent_id, то умова path_root у рядку Disallow буде виконано для всіх однаково. Обмежень на довжину рядків User-Agent і Disallow немає. Якщо пошуковий робот не виявив у файлі /robots.txt свого agent_id, то він ігнорує /robots.txt.

Якщо не враховувати специфіку роботи кожного пошукового робота, можна вказати винятки для всіх роботів відразу. Це досягається завданням рядка User-Agent: *

Якщо пошуковий робот виявить у файлі /robots.txt кілька записів, що задовольняє його значенням agent_id, робот може вибирати будь-яку з них.

Кожен пошуковий робот буде визначати абсолютний URL для читання з сервера з використанням записів /robots.txt. Заголовні та малі літери в path_root МАЮТЬ значення.

Приклади

Приклад 1:

User-Agent: *
Disallow: /
User-Agent: Lycos
Disallow: /cgi-bin/ /tmp/

У прикладі 1 файл /robots.txt містить два записи. Перша відноситься до всіх пошуковим роботам і забороняє індексувати всі файли. Друга відноситься до пошуковому роботу Lycos і при індексуванні їм сервера забороняє директорії /cgi-bin/ і /tmp/, а решта — дозволяє. Таким чином, сервер буде проіндексований тільки системою Lycos.

Приклад 2

User-Agent: Copernicus Fred
Disallow:
User-Agent: * Rex
Disallow: /t

У прикладі 2 файл /robots.txt містить два записи. Перша дозволяє пошуковим роботам Copernicus і Fred індексувати весь сервер. Друга — забороняє всім і осебенно роботу Rex індексувати такі директорії і файли, як /tmp/, /tea-time/, /top-cat.txt, /traverse.this і т. д. Це як раз випадок завдання маски для директорій і файлів.

Приклад 3:

# This is for every spider!
User-Agent: *
# stay away from this
Disallow: /павуки/not/here/ #and everything in it
Disallow: # a little nothing
Disallow: #This could be habit forming!
# Don’t comments make code much more readable!!!

У прикладі 3 — одна запис. Тут всім роботам забороняється індексувати директорію /павуки/not/here/, включаючи такі шляхи і файли /павуки/not/here/really/, /spiders/not/here/yes/even/me.html. Проте сюди не входять /павуки/not/ або /павуки/not/her (у директорії ‘/павуки/not/’).

Деякі проблеми, пов’язані з пошуковими роботами

Незакінченість стандарту (Standart for Robot Exclusion)

На жаль, оскільки пошукові системи з’явилися не так давно, стандарт для роботів знаходиться в стадії розробки, доопрацювання, ну і т. д. Це означає, що в майбутньому зовсім необов’язково пошукові машини будуть ним керуватися.

Збільшення трафіку

Ця проблема дуже актуальна для російського сектора Internet, оскільки не так вже багато в Росії серверів з таким серйозним трафіком, що відвідування їх пошуковим роботом буде заважати звичайним користувачам. Власне, файл /robots.txt для того і призначений, щоб обмежувати дії роботів.

Не всі пошукові роботи використовують /robots.txt

На сьогоднішній день цей файл обов’язково запитується пошуковими роботами тільки таких систем як Altavista, Excite, Infoseek, Lycos, OpenText і WebCrawler.

Використання мета-тагов HTML

Початковий проект, який був створений у результаті угод між програмістами деякого числа комерційних яких індексується організацій (Excite, Infoseek, Lycos, Opentext і WebCrawler) на недавньому зібранні Distributing Indexing Workshop (W3C) , нижче.

На цьому зібранні обговорювалася використання мета-тагов HTML для управління поведінкою пошукових роботів, але остаточної угоди досягнуто не було. Були визначені такі проблеми для обговорення в майбутньому:

  • Невизначеності у специфікації файлу /robots.txt
  • Точне визначення використання мета-тагов HTML, або додаткові поля у файлі /robots.txt
  • Інформація «Please visit»
  • Поточний контроль інформації: інтервал або максимум відкритих з’єднань з сервером, при яких можна починати індексувати сервер

ROBOTS мета-таги

Цей таг призначений для користувачів, які не можуть контролювати файл /robots.txt на своїх веб-сайтах. Таг дозволяє задати поведінку пошукового робота для кожної HTML-сторінки, але при цьому не можна зовсім уникнути звернення робота до неї (як можливо вказати у файлі /robots.txt).

robot_terms — це розділений комами список ключових слів (великі чи малі літери ролі не грають): ALL NONE, INDEX, NOINDEX, FOLLOW, NOFOLLOW.

NONE — каже всім роботам ігнорувати цю сторінку при індексації (еквівалентно одночасного використання ключових слів NOINDEX, NOFOLLOW).

ALL — дозволяє індексувати цю сторінку, і всі посилання з неї (еквівалентно одночасного використання ключових слів INDEX, FOLLOW).

INDEX — дозволяє індексувати цю сторінку

NOINDEX — неразрешает індексувати цю сторінку

FOLLOW — дозволяє індексувати всі посилання з цієї сторінки

NOFOLLOW — неразрешает індексувати посилання з цієї сторінки

Якщо цей мета-тег пропущений або не зазначені robot_terms, то за замовчуванням пошуковий робот надходить як якщо б були вказані robot_terms= INDEX, FOLLOW (тобто ALL). Якщо у CONTENT виявлено ключове слово ALL, то робот надходить відповідно, ігноруючи можливо зазначені інші ключові слова.. Якщо CONTENT є протилежні за змістом ключові слова, наприклад, FOLLOW, NOFOLLOW, то робот надходить на свій розсуд (в цьому випадку FOLLOW).

Якщо robot_terms містить тільки NOINDEX, то посилання з цієї сторінки не індексуються. Якщо robot_terms містить тільки NOFOLLOW, то сторінка індексується, а посилання, відповідно, ігноруються.

KEYWORDS мета-таг

phrases — розділений комами список слів або словосполучень (заголовні і рядкові символи ролі не грають), які допомагають індексувати сторінку (тобто відображають зміст сторінки). Грубо кажучи, це ті слова, у відповідь на які пошукова система видасть цей документ.

DESCRIPTION мета-таг

text — текст, який буде виводитися в сумарному відповіді на запит користувача до пошукової системи. Цей текст не повинен містити тагов розмітки і логічно вписати в нього сенс даного документа на пару-трійку рядків.

Передбачувані варіанти виключення повторних відвідувань за допомогою мета-тагов HTML

Деякі комерційні пошукові роботи вже використовують мета-таги, що дозволяють здійснювати зв’язок між роботом і вебмайстром. Altavista використовує KEYWORDS мета-таг, а Infoseek використовує KEYWORDS і DESCRIPTION мета-таги.

Індексувати документ один раз або робити це регулярно?

Вебмастер може «сказати» пошуковому роботу або файлу bookmark користувача, що вміст того чи іншого файлу буде змінюватися. У цьому випадку робот не буде зберігати URL, а броузер користувача внесе або не внесе це файл в bookmark. Поки ця інформація описується лише у файлі /robots.txt користувач не буде знати про те, що ця сторінка буде змінюватися.

Мета-тег DOCUMENT-STATE може бути корисний для цього. За замовчуванням, цей мета-тег приймається з CONTENT=STATIC.

Як виключити індексування генеруються сторінок або дублювання документів, якщо є дзеркала сервера?

Генеруються сторінки — сторінки, що породжуються дією CGI-скриптів. Їх напевно не слід індексувати, оскільки якщо спробувати провалитися в них з пошукової системи, буде видана помилка. Що стосується дзеркал, то негоже, коли видаються дві різні посилання на різні сервера, але з одним і тим же вмістом. Щоб цього уникнути, слід використовувати мета-тег URL із зазначенням абсолютної URL цього документа (у разі дзеркал — на відповідну сторінку головного сервера).

Джерела

  • Charles P. Kollar, John R. R. Leavitt, Michael Mauldin, Robot Exclusion Standard Revisited, www.kollar.com/robots.html
  • Martijn Koster, Standard for robot exclusion, info.webcrawler.com/mak/projects/robots/robots.html