Robots.txt для SEO: налаштування, ШІ-боти та помилки

Robots.txt для SEO — це звичайний текстовий файл у корені домену, який підказує пошуковим і ШІ-роботам, які URL їм можна запитувати. Він керує скануванням, а не індексацією. Правильне налаштування robots.txt не пускає ботів на малоцінні URL. Але один хибний рядок може сховати весь сайт від Google або від ШІ-пошуку, наприклад пошуку в ChatGPT.

У цьому посібнику розбираємо, що насправді підтримує Google, як поводитися зі щораз довшим списком ШІ-краулерів і які помилки в robots.txt найчастіше трапляються в реальних аудитах.

Що насправді робить robots.txt?

Коли сумлінний краулер заходить на https://example.com, він спершу запитує https://example.com/robots.txt і читає правила для свого user agent. Якщо URL заборонено, краулер його пропускає. І це все, що робить файл. Він не видаляє сторінки з пошукової видачі, нічого не захищає і не передає сигналів ранжування.

У документації Google про це сказано прямо: robots.txt «не є механізмом, який дозволяє не допустити вебсторінку в Google». Заборонена сторінка «все одно може бути проіндексована, якщо на неї посилаються інші сайти». Тоді вона зʼявляється у видачі без опису, бо Google так і не отримав дозволу її прочитати. Щоб закрити сторінку від індексації, Google радить noindex або захист паролем.

З цього випливає кілька практичних моментів:

• Кожен хост потребує власного файлу. blog.example.com і example.com — різні хости, так само як http і https.
• Файл має лежати в корені. /folder/robots.txt ігнорується.
• Шляхи чутливі до регістру. Disallow: /Admin/ не блокує /admin/.

Як правильно налаштувати robots.txt: синтаксис, який підтримує Google

За даними Google Search Central, Google розпізнає лише чотири поля: user-agent, allow, disallow і sitemap. Інші поля, зокрема crawl-delay, Google не підтримує, хоча деякі інші краулери їх враховують.

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

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /search
Disallow: /*?sort=
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-admin/

Sitemap: https://example.com/sitemap.xml

Як працюють символи підстановки та конфлікти правил

• * відповідає будь-якій послідовності символів. $ позначає кінець URL. Наприклад, Disallow: /*.pdf$ блокує URL, що закінчуються на .pdf.
• Коли під URL підпадають і правило allow, і правило disallow, Google застосовує найконкретніше з них, тобто те, де збіг шляху найдовший. Якщо вони однаково конкретні, діє найменш обмежувальне.
• Краулер виконує лише одну, найконкретнішу групу User-agent, яка йому відповідає. Якщо ви створите групу User-agent: Googlebot, Googlebot ігноруватиме все, що написано під User-agent: *. Спільні правила доведеться повторити всередині групи для Googlebot.

Обмеження, кешування та помилки сервера

Найчастіше підводить саме рядок про 5xx. Сервер або CDN, що віддає помилку на /robots.txt, може призупинити сканування всього сайту, навіть якщо кожна сторінка окремо завантажується без проблем.

Чи варто блокувати ШІ-краулерів у robots.txt?

Це питання тепер виникає майже на кожному аудиті. Більшість ШІ-компаній мають кілька окремих ботів: один збирає дані для навчання, інший індексує контент для ШІ-пошуку, а третій завантажує сторінки в реальному часі, коли користувач щось запитує. Заблокувавши не того бота, можна непомітно випасти з відповідей ШІ.

Джерела: документація Google про краулери, сторінка OpenAI про ботів, довідковий центр Anthropic і документація Perplexity про краулери; перевірено в жовтні 2026 року.

Що насправді змінює блокування кожного бота

Самі розробники пояснюють компроміси у своїй документації:

• Google-Extended, за словами Google, «не впливає на включення сайту в Google Пошук і не використовується як сигнал ранжування». Заблокувавши його, ви відмовляєтеся від використання контенту для навчання та grounding у Gemini. Але з AI Overviews (оглядів від ШІ) це вас не прибере, бо вони спираються на звичайне сканування Googlebot. Єдиний важіль для них у robots.txt — заблокувати Googlebot, а це прибере вас і з Пошуку. Точнішим інструментом тут є керування сніпетами, як-от nosnippet.
• OpenAI зазначає, що кожне налаштування незалежне. Можна дозволити OAI-SearchBot, щоб зʼявлятися у відповідях пошуку ChatGPT, і заборонити GPTBot, щоб ваш контент не використовували для навчання.
• Anthropic попереджає, що блокування Claude-SearchBot або Claude-User «може зменшити видимість вашого сайту» в результатах пошуку Claude.

Більшості компаній, яким потрібна видимість і в органічному, і в ШІ-пошуку, розумно за замовчуванням дозволити пошукових і користувацьких ботів, а щодо ботів для навчання ухвалити свідоме бізнес-рішення:

# Opt out of model training, stay visible in AI search
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: *
Disallow: /cart/
Disallow: /checkout/

Sitemap: https://example.com/sitemap.xml

OAI-SearchBot, Claude-SearchBot і PerplexityBot тут не мають власної групи, тому для них діє User-agent: *, і вони можуть сканувати ваш контент. Памʼятайте, що llms.txt — це окремий файл, який ніяк не впливає на Google Пошук. Краулери перевіряють саме robots.txt. Ширшу картину видимості в ШІ-пошуку дає наш чекліст оптимізації для ШІ-пошуку.

Robots.txt, noindex чи canonical: що обрати?

Кожен із цих інструментів виконує своє завдання, і плутанина між ними — одна з найпоширеніших помилок технічного SEO.

Чому robots.txt і noindex на одній сторінці не працюють

Якщо сторінку заборонено в robots.txt, Google її ніколи не завантажує, а отже, ніколи не бачить тегу noindex. Якщо на цей URL посилаються інші сайти, він може залишатися в індексі як завгодно довго — у вигляді голого запису без сніпета. Рішення здається нелогічним, але працює: спершу приберіть disallow, дайте Google просканувати сторінку й обробити noindex, а потім, якщо ще потрібно, поверніть блокування. Те саме стосується canonical: Google не може прочитати тег canonical на сторінці, яку йому заборонено сканувати.

Найпоширеніші помилки в robots.txt

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

1. Disallow: /, що лишився з тестового сервера. Розробник закриває staging від індексації, і файл потрапляє на продакшн разом із запуском. Протягом наступних днів трафік падає, бо Google перестає повторно сканувати сайт. Це одне з перших, що варто перевірити під час діагностики падіння трафіку.
2. Блокування папок із CSS, JavaScript або зображеннями. Старі правила ще з часів раннього WordPress, як-от Disallow: /wp-includes/ чи Disallow: /assets/, не дають Google коректно відрендерити сторінку. Google бачить зламаний макет і може хибно оцінити зручність для мобільних або пропустити контент, який завантажує JavaScript.
3. Блокування сторінок, які мають ранжуватися. Широке правило на кшталт Disallow: /product зачіпає також /products/ і /product-guides/, бо правила спрацьовують за префіксом URL.
4. robots.txt, що повертає 5xx або не відповідає вчасно. Як видно з таблиці вище, це може зупинити сканування всього сайту.
5. Блокування параметрів, за якими стоїть реальний контент. Якщо сторінки категорій мають пагінацію через ?page=2, правило /*? ховає ці товари від виявлення.
6. Випадкове блокування пошукових ШІ-ботів. Універсальний фрагмент «заблокувати весь ШІ», скопійований із форуму, часто містить OAI-SearchBot, Claude-SearchBot або PerplexityBot — і ви зникаєте з цих відповідних систем.
7. Розрахунок на директиви, які не підтримуються. Noindex:, Crawl-delay: (для Google) і коментарі в нестандартному форматі для Googlebot нічого не означають.
8. Відносна адреса sitemap. У рядку Sitemap: має бути повна абсолютна URL-адреса, наприклад https://example.com/sitemap.xml.

Як перевірити файл robots.txt?

Перевірка займає близько 15 хвилин, і її варто повторювати після кожного релізу сайту.

1. Відкрийте живий файл за адресою yourdomain.com/robots.txt. Переконайтеся, що він повертає HTTP 200 і вміст саме той, на який ви розраховуєте. Зробіть це для кожного піддомену й варіанта протоколу.
2. Перегляньте звіт robots.txt у Google Search Console (Налаштування → robots.txt). Він показує, які файли robots.txt знайшов Google, коли востаннє їх завантажував, а також помилки завантаження й попередження аналізу. Цей звіт замінив старий окремий інструмент перевірки robots.txt.
3. Запустіть перевірку URL-адрес для найважливіших сторінок. Якщо сторінка має статус «Заблоковано у файлі robots.txt», знайдіть правило, яке це спричиняє.
4. Звірте файл із картою сайту. Кожен URL, що є у вашому XML sitemap, але заборонений у robots.txt, дає Google суперечливі сигнали, і це треба виправити.
5. Перегляньте серверні логи або налаштування ботів у CDN. Деякі CDN і плагіни безпеки блокують ШІ-краулерів на рівні файрвола, хоч би що було написано в robots.txt. Переконайтеся, що потрібні вам боти отримують відповідь 200.

Якщо ключові сторінки потрапили в статус «Виявлено – наразі не проіндексовано» і водночас є обмеження сканування, наш посібник про статус «Виявлено – наразі не проіндексовано» пояснює, як повʼязані краулінговий бюджет і заблоковані ресурси.

Як SEORecheck перевіряє robots.txt під час аудиту

Проблеми з robots.txt легко пропустити, переглядаючи файл очима: він виглядає нормально, доки не порівняєш його з тим, що насправді є на сайті. Автоматичний SEO-аудит завантажує файл, а потім звіряє з ним кожен просканований URL. Він позначає важливі сторінки, які заблоковано, заблоковані ресурси для рендерингу, URL із sitemap, що суперечать правилам, і пошукових ШІ-краулерів, яким закрито доступ. Для кожної знахідки вказано URL, яких вона стосується, і конкретне правило, що її спричиняє. Формат можна побачити у зразку звіту.

Після виправлень повторна перевірка через 30–60 днів покаже, які проблеми виправлено, які покращено, які досі не розвʼязано, а які зʼявилися нові. Це допомагає, коли наступний деплой непомітно повертає старе правило. Ось приклад порівняння.

Головне

• Robots.txt керує скануванням, а не індексацією. Щоб закрити сторінки від Google, використовуйте noindex або автентифікацію.
• Google підтримує лише user-agent, allow, disallow і sitemap. crawl-delay і noindex у robots.txt він ігнорує.
• robots.txt, що повертає 5xx, може призупинити сканування всього сайту, тож стежте за ним, як за критично важливою сторінкою.
• Ніколи не забороняйте сторінку в robots.txt, якщо хочете, щоб Google побачив її noindex або тег canonical.
• ШІ-компанії мають окремих ботів для навчання й для пошуку. Блокування GPTBot, ClaudeBot чи Google-Extended не прибирає вас із пошуку ChatGPT, пошуку Claude чи Google Пошуку, а от блокування OAI-SearchBot, Claude-SearchBot або PerplexityBot прибирає вас із цих інструментів.
• Перевіряйте файл після кожного релізу: живий файл, звіт robots.txt у Search Console і перевірку URL-адрес для ключових сторінок.

Перевірте robots.txt у межах повного SEO-аудиту

Якщо ви не впевнені, чи не блокує ваш robots.txt важливі сторінки, ресурси або пошукових ШІ-краулерів, швидкий аудит це покаже. Замовте безкоштовний попередній перегляд SEO-аудиту — отримаєте SEO-оцінку та кілька реальних проблем, знайдених на ваших сторінках, без реєстрації. Повний перелік того, що охоплює аудит, дивіться в чеклісті SEO-аудиту.