Robots.txt – як користуватись і яких помилок слід уникати під час створення?

зміст

• Що таке robots.txt?
• Трохи історії
• Які із роботів опрацьовують файл robots.txt?
• Чому варто використовувати robots.txt?
• Помилки в robots.txt та їхні наслідки
• Чи потрібно звертати увагу на розмір файлу robots.txt file при створенні?
• Чи блокування за допомогою robots.txt ефективне?
• Що ще варто знати про robots.txt?
• Висновки

Що таке robots.txt?

Файл robots.txt використовується для того, щоб надати роботам-пошуковикам і пошуковим програмам інформацію про те, що вони повинні робити на сайті, а чого не повинні. Директиви надсилаються за допомогою стандарту винятків Robots Exclusion Protocol, однак варто зазначити, що деякі пошукові системи заявляють про те, що вони використовують нестандартні записи. Базові записи складаються з повідомлень щодо того, які частини сайту роботи не повинні опрацьовувати, але можливості застосування robots.txt є ширшими.

Трохи історії

Протокол винятків для роботів (Robots Exclusion Protocol) був розроблений чверть століття тому – в лютому 1994 року, і від того часу майже не змінився, за винятком вже згаданих нестандартних записів. Оскільки в той період на ринку існувало багато пошукових систем (достатньо згадати AltaVista, HotBot, Lycos або InfoSeek – список був досить довгим), протокол отримав статус неофіційного стандарту (unofficial standard). Тут, однак, варто згадати про те, що стандарт є незвичним, оскільки запис був і залишається на рівні пропозиції, яку боти часто частково або повністю ігнорують.

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

Які із роботів опрацьовують файл robots.txt?

Файл robots.txt розрахований на всі автоматичні системи, що сканують сайт. Це стосується не лише найвідоміших роботів-пошуковиків з пункту бачення SEO. Боти, до яких скеровані ці вказівки, це також і автоматизовані архівні пристрої (як-от Web Archive), програми для завантаження сайту до локального диску (наприклад, HTTrack Website Copier), засоби для аналізу сайтів (включно з засобами SEO на зразок Xenu, а також ботами Majestic SEO й Ahrefs) тощо.

В багатьох випадках розробникам не потрібно перейматись директивами. З іншого боку, деякі роботи дозволяють своїм користувачам обрати чи бажають вони враховувати виявлені директиви.

Чому варто використовувати robots.txt?

Це головне запитання, враховуючи вже згаданий факт того, що не завжди директиви з файлу robots.txt беруться до уваги. Відповідь проста: завжди краще мати трохи контролю над роботами, ніж не мати його зовсім. Що можна завдяки цьому отримати? Найперше, можна заборонити автоматичним системам сканувати ті розділи сайту, які вони з різних причин не повинні сканувати, а також вказати їм на місця, які  сканувати потрібно.

Блокування окремих розділів сайту може мати різні цілі:

• Питання безпеки – можливо ви не хочете, щоб роботи (чи випадкові користувачі, котрі пізніше можуть використати дані, знайдені роботами) мали можливість доступу до розділів, інформація з яких не повинна бути легкодоступною.
• Захист від дублювання контенту – якщо на сайті є велика кількість дубльованого контенту, а URL-адреса дозволяє його чітко ідентифікувати, через файл robots.txt можна дати сигнал про те, що певний розділ сайту не повинен опрацьовуватись.
• Економія трансферу – за допомогою записів в robots.txt можна спробувати видалити з маршрутів пересування роботів цілі підрозділи або окремі типи файлів – навіть каталог з графічними елементами або їхніми високоформатними версіями. У випадку окремих сайтів економія трансферу може бути значною.
• Захист віт «витоку» контенту назовні – зверніть увагу на те, що запропонований попередньо захист для каталогу з високоформатними графічними елементами можна використати також для представлення в пошукових системах менших версій зображень. Це може бути важливо для фотобанків, і не тільки.
• Оптимізація краулінгового бюджету – хоч цей пункт останній у списку, він є дуже важливим. Що більший вебсайт, то більше уваги потрібно надати оптимізації маршрутів, якими просуваються боти-індексатори пошукових систем. Блокуючи в robots.txt ділянки, невідповідні з пункту бачення SEO, ви збільшуєте ймовірність того, що роботи просуватимуться так як потрібно.

Основні директиви в robots.txt: user-agent, allow та disallow

Перейдемо до суті справи – який вигляд повинен мати файл robots.txt. За визначенням, це текстовий файл, розміщений в основному каталозі сайту, з яким він пов'язаний. Основними директивами є user-agent, allow та disallow. Використовуючи першу з перерахованих, можна визначити ботів, яких стосуватиметься те чи інше правило. Дві інші директиви визначають відповідно ділянки, до яких робот повинен мати доступ і де його присутність небажана.

Варто пам'ятати про те, що robots.txt підтримує змінну у вигляді зірочки, інакше – астериску (*), а поле маршрутів, яких стосується директива, завжди необхідно чим-небудь заповнити – принаймні скісною рискою (/). Відсутність заповнення рівнозначне ігноруванню поля.

Ось декілька зразків вдалого заповнення:

User-agent: *
Allow: /

– тобто, дозвіл для усіх ботів індексувати весь сайт. Подібно:

User-agent: *
Disallow: /img/

– означає заборону доступу до каталогу /img/.

З іншого боку:

User-agent: *
Disallow:

– не означає нічого, оскільки не вказано маршруту після директиви disallow.

Звісно, в одному файлі robots.txt полів allow та disallow може бути більше, наприклад:

User-agent: *
Allow: /
Disallow: /img/
Disallow: /panel/

– тобто, дозвіл для роботів сканувати увесь сайт, за винятком каталогів /img/ і /panel/.

Варто додати, що директиви можна застосовувати не лише для цілих каталогів, а й для окремих файлів.

Порядок розміщення директив allow і disallow в robots.txt

Якщо виникає проблема з інтерпретацією директив allow і disallow, наприклад, у ситуації заборони доступу до певного каталогу з винятком для окремого підкаталогу, пам'ятайте, що директиви дозволу повинні знаходитись над директивами заборони:

User-agent: *
Allow: /
Allow: /img/miniatury/
Disallow: /img/

User-agent: Ahrefsbot
Disallow: /

User-agent: MJ12bot
Disallow: /

Приклад вище також демонструє використання окремих правил для окремих ботів – так ви «просите» роботів Ahrefs і Majestic SEO не сканувати ваш сайт.

Директива Sitemap

Окрім «запрошень та пропозицій пропустити каталоги, файл robots.txt можна використати для того, щоб показати роботам розміщення мапи сайту. Для цього необхідно застосувати директиву sitemap, після якої повинна розміститись вся мапа. Нижче знаходиться приклад такої директиви:

Sitemap: http://www.domain.com/sitemap.xml

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

Директива Crawl-delay

У дуже великих вебсайтів часто виникає проблема – з одного боку, власник може бажати індексувати увесь сайт, з іншого боку, надмірна активність пошукових роботів може споживати чимало трансферу і постійно навантажувати сервер новими запитами. Для розв'язання цієї проблеми було створено спеціальну директиву crawl-delay.

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

User-agent: *
Crawl-delay: 2

– тобто, завантаження нових документів відбувається що дві секунди.

Варто пам'ятати про те, що більшість пошукових систем розглядає цю директиву як необов'язкову, часто повністю ігноруючи її. Протягом деякого часу в Google вказували на непотрібність директиви, а в липні 2019 року було офіційно заявлено про відмову від її підтримки. У Bing заявили, що запис сканує BingBot, а його значення повинно знаходитись в межах від 1 до 30. Директиву теоретично підтримує Yandex, однак на практиці буває по-різному.

Цікаво те, що чеська пошукова система Seznam пропонує використовувати іншу директиву, а саме – request-rate, і надавати їй значення у вигляді «кількість документів – скісна риска – час у вигляді числа і знаку (s як секунди, m як хвилини, h як години й дні, щоразу без пропусків після номеру)». Приклад такої директиви:

User-agent: SeznamBot
Request-rate: 500/1h

або:

User-agent: SeznamBot
Request-rate: 100/20m

В Seznam заявляють, що директива не повинна вимагати індексації, повільнішої за один документ що десять секунд.

Директива Clean-param

Clean-param є доволі цікавою директивою. На жаль, це загальний стандарт. Її враховують пошукові боти Yandex, дозволяючи обходити параметри, пов'язані з адресами маршрутів.

Як це працює? Припустимо, ваш сайт містить такі адреси:

domain.com/catalog/page?background=1&id=3
domain.com/catalog/page?background=2&id=3
domain.com/catalog/page?background=3&id=3

Що робити, якщо змінна background змінює лише вигляд сторінки, що завжди містить той самий контент? В таких випадках Yandex пропонує використовувати clean-param. Відповідний запис може мати такий вигляд:

User-agent: Yandex
Clean-param: background/catalog/

– тобто, усі три адреси з попереднього прикладу індексуватимуться як:

domain.com/catalog/page?id=3

Як бачите, ця директива є більш зручною, адже її можна звузити до окремих каталогів.

Директива Host

Стандарт robots.txt має у своєму переліку також команду host. Її ігнорують більшість пошукових систем, проте на сторінках довідки Yandex про неї згадувалось декілька разів, однак станом на сьогодні опис директиви відсутній.

Директива host використовується (або використовувалась) для позначення обраного домену у випадку наявності декількох реплікованих вебсайтів, розміщених за різними адресами. Важливо те, що в одному файлі robots.txt повинна знаходитись лише одна така директива (усі наступні ігноруватимуться), а запис домену після директиви host не повинен містити помилок чи номерів порту протоколу.

Приклад:

Host: domain.com

На жаль, ми не знаємо чи директива досі працює, але можемо припускати, знаючи винахідливість спеціалістів з позиціювання, існування тенденції до проведення різноманітних експериментів з розміщенням директиви на доменах, відмінних від тих, на яких вона повинна знаходитись. Втіхою для «простих вебмайстрів» буде інформація про те, що в Yandex, звертаючись до питань директив, оголосили host «пропозицією» для роботів – отже, не вважали її обов'язковою.

Помилки в robots.txt та їхні наслідки

Хоч зміст файлу robots.txt може допомогти «знайти спільну мову» з роботами-пошуковиками, він також може нашкодити. Як саме? Через виключення з пошуку контенту, який повинен з'явитись в індексі. В результаті можна отримати значні втрати у показниках видимості в результатах пошуку. Особливо це стосується файлів robots.txt з багатьма записами, що стосуються різних підкаталогів – у таких випадках дуже легко зробити помилку в записах і виключити занадто багато розділів сайту.

Друга основна помилка – це охоплення директивою disallow усіх зображень, CSS-стилів і файлів Java Script. Це може здатись хорошою стратегією, але насправді є дві причини чому це хибне уявлення. По-перше, в багатьох випадках можливість знайти сайт за результатами пошуку зображень є хорошим показником (звісно, можна заборонити доступ до, наприклад, високоформатних версій зображень, на що ми вже звертали увагу раніше у цій статті).

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

Чи потрібно звертати увагу на розмір файлу robots.txt file при створенні?

Джон Мюллер (John Mueller) у своєму профілі Google+ одного дня повідомив про те, що максимальний розмір файлу robots.txt повинен становити 500 кБ. Отже, можна зробити висновок, що запитання – риторичне, тому що таке збільшення списку директив було б абсурдним. Та все ж варто подбати про те, щоб короткий файл robots.txt не став величезним і залишився читабельним для ... кожного, хто бачитиме його і потенційно доповнюватиме чи вноситиме зміни.

Проте пам'ятайте, що йдеться лише про прийнятий розмір файлу для робота Google Bot – для інших пошукових систем ліміт розміру robots.txt може бути іншим.

Чи блокування за допомогою robots.txt ефективне?

На жаль, ні. По-перше, головні роботи не завжди беруть до уваги директиви (не згадуючи про окремі менш популярні засоби). По-друге, навіть ознайомившись із забороною, Google може увійти на сайт та індексувати його, беручи до уваги лише заголовок та URL-адресу, і додаючи іноді повідомлення з інформацією про те, що «Для цього сайту інформація недоступна».

Отже, дістатись до сайту з пошукової системи все ж можливо, однак це малоймовірно. Тому що боти і надалі скануватимуть сайти за посиланнями, навіть якщо вони більше не генерують жодної сили (так званий link juice), а результати ранжуванння не охоплюють даних, що походять з їхнього змісту.

Що ще варто знати про robots.txt?

Бажаючи обмежити індексування певних частин сайту, завжди можна додатково скористатись мета-тегом robots, який потрібно додати до частини <HEAD> відповідної підсторінки:

<meta name="robots" content="noindex, nofollow" />

– цей метод не 100% гарантією успіху (до того ж, він менш зручний), але посилає роботам додатковий сигнал.

Що робити, якщо потрібно повністю заблокувати доступ для ботів і випадкових користувачів? В такій ситуації замість пасивних методів, як-от сподівання на те, що ніхто не потрапить до визначеного місця, варто захистити потрібний розділу сайту паролем (навіть шляхом використання htaccess).

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

Висновки

Повернемось до питання наслідків можливих помилок у заповненні файлу robots.txt. Що б ви не записали до файлу, пам'ятайте про можливі ефекти й ... про мету. Бажаючи індексувати що-небудь, зверніть увагу на можливі побічні ефекти (приклад зі складністю рендерингу сайту Google Bot-ом). Тож, якщо вас хвилює питання безпеки, пам'ятайте, що заборона індексації для Google не блокує доступу для автоматичних систем веб-скрапінгу.

Бажаєте дізнатись більше? Перегляньте інші статті на тему позиціювання в нашій Базі знань.