Як перевірити, чи є на сайті robots.txt
Як перевірити, чи є на сайті файл robots.txt
Файл robots.txt — це невеликий текстовий файл із вказівками для ботів, які погоджуються їх дотримуватися. Перевіривши його, можна з’ясувати, які розділи сайту певним пошуковим роботам пропонують відвідувати або оминати. Цей файл не розкриває всіх налаштувань сайту й не є засобом захисту.
Якщо ви хочете дізнатися, чи є на сайті файл robots.txt, спершу перевірте точну адресу сайту, а потім — відповідь сервера та вміст файлу. Це важливо: файл на одному піддомені може нічого не повідомляти про інший, а помилка в браузері не завжди означає, що файл відсутній. Щоб розібратися, як перевірити файл robots.txt на сайті, почніть із правильної URL-адреси та перевірте, що саме повернув сервер.
1. З’ясуйте, що можна і чого не можна дізнатися з robots.txt
У robots.txt містяться правила для автоматизованих пошукових роботів. Наприклад, правило може просити пошукового бота, який його дотримується, не сканувати шлях на кшталт /private/. Це прохання, а не механізм контролю доступу: відвідувач усе одно може відкрити цю URL-адресу, а бот може проігнорувати вказівку.
Файл також не гарантує, що заблокована сторінка не потрапить до результатів пошуку. Пошукова система може дізнатися URL-адресу з посилань на інших сайтах і показати її в результатах, не скануючи вміст. Якщо сторінка має залишатися приватною, використовуйте справжній засіб контролю доступу, наприклад автентифікацію, а не покладайтеся на robots.txt.
Сприймайте цей файл як загальнодоступний набір вказівок. Він може допомогти зрозуміти поведінку пошукових роботів, але не підтверджує, що сторінка доступна, приватна чи проіндексована. Ці питання потрібно перевіряти окремо.
2. Знайдіть файл robots.txt за правильною адресою сайту
Для сайту за адресою https://example.com стандартне розташування файлу — https://example.com/robots.txt. Якщо ви з’ясовуєте, де знайти robots.txt сайту, збережіть протокол і ім’я хоста, указані в адресному рядку, а якщо сайт використовує нестандартний порт — додайте й його. Файл розміщується в корені цієї адреси, а не в папці на кшталт /blog/.
Зміна протоколу чи імені хоста може дати інший результат. Наприклад, http://example.com/robots.txt и https://example.com/robots.txt — це різні запити, навіть якщо один із них перенаправляє на інший. Так само налаштування для www.example.com и example.com можуть відрізнятися.
Піддомени мають окремі адреси. Файл за адресою https://shop.example.com/robots.txt автоматично не поширюється на https://example.com/ або https://help.example.com/. Перевірте потрібний вам хост — особливо якщо компанія розмістила інтернет-магазин, службу підтримки й основний сайт на окремих піддоменах.
Для першої перевірки скористайтеся адресним рядком: введіть повну URL-адресу robots.txt і подивіться, що відкриється. Часто файл відображається як звичайний текст, але форматоване подання в браузері теж цілком підходить. Головне — знати, яку URL-адресу ви запитали та що повернув сервер.
3. Перевірте відповідь сервера, а не лише сторінку в браузері
Успішна відповідь зазвичай означає, що сервер повернув вміст за цією URL-адресою. Багато сайтів відповідають кодом HTTP 200, але видимим вмістом можуть бути правила, порожній файл або навіть неочікувана сторінка. Перевіряйте код відповіді разом із вмістом, а не вважайте будь-яку сторінку, що завантажилася, доказом наявності коректного robots.txt.
Відповідь «не знайдено», часто з кодом 404, вказує, що на цей момент на вказаному сайті такого шляху, імовірно, немає. Це корисна ознака, але спершу перевірте ім’я хоста та перенаправлення. Такий самий результат можуть дати помилка в URL-адресі або інший піддомен.
З перенаправленнями слід бути уважними. Початковий запит може перенаправити вас на інший хост або шлях, а кінцева адреса — повернути вміст, що стосується іншого сайту. Перш ніж вирішувати, правила якого сайту ви прочитали, зафіксуйте і початкову URL-адресу, і кінцеву.
Помилки доступу й збої сервера не означають, що файл відсутній. Наприклад, відповідь 403 може означати, що сервер відхилив запит, а код 5xx — що виникла тимчасова проблема на сервері. Перевірці також можуть завадити тайм-аут мережі чи помилка з’єднання в браузері. Спробуйте ще раз пізніше або скористайтеся іншим способом, перш ніж робити остаточний висновок.
Для іншої перевірки сайту можна також дізнатися, як перевірити, чи публікує сайт інформацію про партнерські посилання. Така перевірка стосується видимої для користувачів політики, а не вказівок для пошукових роботів.
4. Перевірте, які директиви robots.txt стосуються потрібного вам робота
Щоб зрозуміти, як читати директиви robots.txt, читайте кожну групу правил у контексті. У рядку User-agent зазначено назву робота, а рядки Disallow і Allow описують шляхи, сканувати які цьому роботу не рекомендується або дозволено. Точне тлумачення може залежати від конкретного робота, тож у важливих випадках зверніться до його документації.
Наприклад, група, що починається з User-agent: ExampleBot, може стосуватися лише робота з такою назвою. Окрема група з рядком User-agent: * призначена для роботів, для яких немає спеціальнішої групи. Не вважайте, що правило для одного бота поширюється на всі пошукові системи чи інші автоматизовані сервіси.
Важливі також шляхи. Правило для /images/ — це не те саме, що правило для /, а правило для /drafts/ не обов’язково стосується схожого шляху в іншому місці. Перш ніж застосовувати правило до URL-адреси, перевірте повний шлях і групу, у якій воно міститься.
Наприклад, у файлі може бути рядок Disallow: /private/у загальній групі для пошукових роботів. Ця вказівка просить роботів, на яких вона поширюється, не сканувати сторінки в цій папці. Вона не заважає комусь відкрити відому URL-адресу й не доводить, що кожен бот її дотримуватиметься.
Деякі файли містять коментарі, порожні рядки або правила для окремих сервісів. Зосередьтеся на групі User-agent, яка стосується вашого запитання, а потім перевірте опубліковані правила пошукового робота: вони допоможуть з’ясувати, як він обробляє конфліктні або незвичні директиви. Якщо ви перевіряєте конкретну пошукову систему, для тлумачення її поведінки найкраще звернутися до її документації.
5. Відрізняйте порожній файл від відсутнього чи некоректного
Порожня відповідь і відсутній файл — це різні результати. Якщо сервер повертає успішну відповідь, але видимого тексту немає, файл може існувати, проте не містити директив. Якщо сервер відповідає кодом «не знайдено», це означає, що файл не знайдено за вказаною URL-адресою. Фіксуйте і код відповіді, і вміст, щоб не плутати ці випадки.
Неочікуваний вміст варто перевірити повторно. Якщо сторінка містить повідомлення про помилку для всього сайту, вікно входу або HTML-розмітку, можливо, замість звичайного файлу robots.txt запит відкрив сторінку-заглушку. URL-адреса може успішно завантажитися, але повернутий вміст усе одно не міститиме корисних вказівок для пошукових роботів.
Не варто навмання тлумачити некоректні чи незнайомі рядки. Збережіть точну відповідь сервера та звірте її з документацією пошукового робота, якого перевіряєте. Якщо вміст файлу змінюється між перевірками, зазначте час: пізніша відповідь може містити виправлену версію, а не той самий текст.
6. Перевірте результат іншим способом
Якщо результат у браузері незрозумілий, надішліть запит із командного рядка. Наприклад, команда curl -i https://example.com/robots.txt в межах одного запиту покаже заголовки відповіді та повернутий вміст. Замініть адресу прикладу на точну адресу сайту, який перевіряєте, і за потреби вкажіть правильний піддомен та порт.
Ще один спосіб — інструменти розробника в браузері. Відкрийте панель Network, завантажте URL-адресу robots.txt і виберіть відповідний запит, щоб переглянути його код, заголовки та вміст відповіді. Це зручно, коли браузер показує перенаправлення або форматовану сторінку, але не дає зрозуміти кінцеву адресу.
Якщо результати різняться, порівняйте точні URL-адреси, час перевірки, коди відповідей, перенаправлення та вміст. Запит із командного рядка й запит у браузері можуть по-різному обробляти перенаправлення або зіткнутися з тимчасовою проблемою сервера. Якщо ви користуєтеся корпоративним проксі, VPN чи розширенням браузера, за потреби перевірте результат без них: зміна відповіді може свідчити про втручання посередника, а не самого сайту.
Ще один приклад перевірки сайту — дізнатися, як перевірити, чи розміщено на сайтіповідомлення про авторські права. Не плутайте це з robots.txt: повідомлення адресоване читачам, а файл — пошуковим роботам.
7. Зафіксуйте межі та обмеження перевірки
Запишіть точну URL-адресу robots.txt, дату й час запиту, код HTTP-відповіді, адресу перенаправлення (якщо воно було) та побачений вміст. Якщо ви тлумачите певну групу директив, також зазначте, якого пошукового робота або User-agent стосується перевірка. Таку перевірку можна буде повторити, якщо сайт зміниться.
Формулюйте висновок обережно. Успішна відповідь показує лише те, що сервер повернув для одного сайту в певний момент. Вона не доводить, що сторінку проіндексовано, що вона доступна всім відвідувачам або що її заблоковано для кожного пошукового робота. Відповідь про відсутність файлу стосується саме запитаної URL-адреси, а не автоматично всіх піддоменів чи версій протоколу.
Файл robots.txt може змінитися будь-коли й без попередження. Якщо ваше рішення залежить від чинних правил, знову перевірте точну адресу сайту та збережіть нову відповідь, а не покладайтеся на стару копію.
