Robots.txt — Вікіпедія

Стандарт винятків для роботів, також відомий як протокол винятків для роботів або просто robots.txt, це стандартний спосіб комунікації вебсайтів з пошуковими роботами та іншими роботами. Стандарт визначає, як повідомити вебробота про те, які частини вебсайту не повинні бути оброблені або проскановані. Роботи часто використовуються пошуковими системами, щоб встановити категорію сайту. Не всі роботи співпрацюють з даним стандартом, наприклад: Email address harvesting[en], спам-боти[en], шкідливі програми, і роботи що сканують на уразливості можуть навпаки почати з тих частин, від яких їм сказано триматися осторонь. Хоча стандарт і відрізняється від Sitemaps, але може використовуватися в поєднанні з ним.

Історія[ред. | ред. код]

Стандарт був запропонований Мартіном Костером при роботі на Nexor в лютому 1994 року. Чарльз Стросс стверджує, що це він спровокував Костера до створення ідеї robots.txt після того, як він написав некоректно працюючий вебоглядач, що викликало випадкову DoS атаку на сервер Костера.

Він швидко став стандартом де-факто, якому нинішні та майбутні пошукові роботи повинні слідувати; більшість виконала, у тому числі в пошукових системах, таких як WebCrawler, Lycos та AltaVista.

Про стандарт[ред. | ред. код]

Коли власники сайтів хочуть дати вказівки пошуковим роботам, вони поміщають текстовий файл robots.txt в корінь їхнього сайту (e.g. https://www.example.com/robots.txt). Цей файл містить вказівки в специфічному форматі (дивись приклад нижче). Роботи, які працюють з цим стандартом, намагаються отримати цей файл і прочитати вказівки в ньому перед тим як отримають будь-який інший файл з вебсайту. Якщо файл не існує, пошукові роботи вважають, що власник не бажає надавати будь-яких конкретних інструкцій, та проглядають весь сайт.

robots.txt файл на вебсайті функціонуватиме як вказівка роботам ігнорувати певні файли або каталоги при скануванні сайту. Це може бути використано для збереження особистої інформації від пошукових систем, або якщо вміст певного каталогу може бути неправильно інтерпретований або не підходить до основної категорії сайту. Або, якщо якийсь додаток має працювати тільки з певними даними. Посилання на сторінки в списку robots.txt все ще можуть з'являтися в результатах пошуку, якщо вони прив'язані з сторінок, які проглядати дозволено.

Файл robots.txt покриває тільки одне походження. Для вебсайтів з багатьма субдоменами кожен має мати власний robots.txt файл. Якщо example.com має файл robots.txt, а a.example.com ні, то правила, які використовуються для example.com не будуть використовуватися на a.example.com. Також кожен протокол та порт має мати свій власний robots.txt файл; http://example.com/robots.txt не буде застосований на https://example.com:8080/ або https://example.com/.

Багато основних пошукових систем, таких як: Ask, AOL, Baidu, Bing, Google, Yahoo!, та Yandex слідують цьому стандарту.

Файл robots.txt встановлює правила сканування сайту для пошукових роботів пошукових систем. Перед тим як здійснити аналіз сайту пошукові роботи виконують перевірку цього файлу. Завдяки такій процедурі вони можуть підвищити ефективність сканування і заощадити свої ресурси.[1]

Безпека[ред. | ред. код]

Попри використання термінів «дозволити» і «заборонити», протокол є суто консультативний і спирається на чесність веброботів. Шкідливі веброботи навряд чи будуть слідувати robots.txt; деякі можуть навіть навпаки, використовувати robots.txt як підказку, щоб знайти заборонені посилання і перейти безпосередньо до них. У контексті robots.txt файли безпека через обмеження не рекомендується, як техніка безпеки.

Приклади[ред. | ред. код]

Цей приклад говорить всім роботам, що вони можуть переглядати всі файли через * знак доступу для всіх та Disallow вказівка, яка немає значень. Це значить, що жодна сторінка не є забороненою.

User-agent: * Disallow: 

Такий же результат може бути досягнутий порожнім або взагалі відсутнім файлом robots.txt.

Цей приклад говорить всім роботам триматися подалі від всього сайту:

User-agent: * Disallow: / 

А цей приклад говорить всім роботам не заходити в три каталоги:

User-agent: * Disallow: /cgi-bin/ Disallow: /tmp/ Disallow: /junk/ 

Цей приклад вказує всім роботам тримати подалі від одного певного файлу:

User-agent: * Disallow: /directory/file.html 

Зауважте, що всі інші файли в цьому каталозі будуть доступні.

Цей приклад забороняє доступ до сайту тільки певному роботу:

User-agent: BadBot # замістити 'BadBot' фактичним ботом користувача Disallow: / 

Цей приклад говорить двом певним роботам не заходити до певних каталогів:

User-agent: BadBot # замістити 'BadBot' фактичним ботом користувача User-agent: Googlebot Disallow: /private/ 

Приклад, який показує, як можуть бути використані коментарі:

# Коментар пишеться після символу "#" Символ пишеться на початку рядка, або після вказівок User-agent: * # відповідає всім роботам Disallow: / # вказує від чого триматися подалі 

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

Приклад що демонструє кілька агентів:

User-agent: googlebot        # Всі сервіси Google Disallow: /private/          # заборонити цей каталог  User-agent: googlebot-news   # Тільки сервіс новин Disallow: /                  # заборонити скрізь  User-agent: *                # Будь-який робот Disallow: /something/        # заборонити цей каталог 

Нестандартні розширення[ред. | ред. код]

Crawl-delay[ред. | ред. код]

Crawl-delay - значення, яке вказує пошуковикам затримку для повторного завантаження сторінки. Оскільки це значення не є частиною стандарту, то і його інтерпретація залежить від ботів, якими воно зчитується. Yandex інтерпретує crawl-delay як кількість секунд, які потрібно зачекати перед повторним пошуком. Bing інтерпретує як розмір часового вікна, (від 1 до 30 секунд) протягом якого BingBot зайде на сайт тільки раз.

User-agent: * Crawl-delay: 10 

З 15 лютого 2018 року Яндекс перестав враховувати[2] директиву Crawl-delay.

Щоб задати швидкість, з якою роботи будуть завантажувати сторінки сайту, використовуйте швидкість обходу сайту у Яндекс.Вебмастері.

Allow[ред. | ред. код]

Деякі з пошуковики підтримують вказівку Allow, яка є оберненою до вказівки Disallow. Це корисно, коли ви хочете вказати пошуковику оминати всю директорію, але хочете, щоб деякі HTML документи знаходилися та індексувалися.

Для сумісності з усіма роботами, якщо ви хочете дозволити доступ до одного файлу в повністю забороненій директорії, вам слід помістити директиву Allow першою, а за нею вже Disallow, наприклад:

Allow: /directory1/myfile.html Disallow: /directory1/ 

Цей приклад забороняє все в директиві /directory1/ за винятком /directory1/myfile.html, до поки вказівки розташовані в правильному порядку. Порядок важливий тільки для тих роботів, що слідують стандарту; у випадку з Google або Bing, порядок не важливий.

Sitemap[ред. | ред. код]

Деякі пошуковики підтримують вказівку Sitemap, що дозволяє використовувати декілька Sitemaps в одному файлі robots.txt в такій формі:

Sitemap: http://www.gstatic.com/s2/sitemaps/profiles-sitemap.xml   Sitemap: http://www.google.com/hostednews/sitemap_index.xml 

Host[ред. | ред. код]

Деякі пошуковики (Yandex) підтримують директиву Host, яка використовується на сайтах з багатьма дзеркалами, щоб вказати якийсь певний домен: Host: example.com Або альтернативний: Host: www.example.com Зауважте: Це не підтримується всіма пошуковиками і, якщо і використовується, то має бути вказано внизу файлу robots.txt після директиви Crawl-delay.

С 20 березня 2018 року Яндекс перестав враховувати[3] директиву Host.

Примітки[ред. | ред. код]

  1. Що таке robots.txt. Архів оригіналу за 17 липня 2020. 
  2. «Швидкість обходу» або про зміни в обліку директиви Crawl-delay. https://webmaster.yandex.ru (рос.). 15.02.2018. Архів оригіналу за 11 травня 2020. Процитовано 15.02.2018.  {{cite web}}: |first= з пропущеним |last= (довідка)
  3. 301-й редирект повністю замінив директиву Host (рос.). Архів оригіналу за 17 травня 2021. Процитовано 17 травня 2021. 

Див. також[ред. | ред. код]