Robots.txt SEO: ефективно керуйте скануванням

Що робить robots.txt — і чого він не робить

Robots.txt — це текстовий файл, розміщений у корені сайту (https://example.com/robots.txt). Його роль вузько сфокусована: він дає інструкції по crawling для коректних краулерів. Використовуйте його, щоб зменшити зайві запити до низькоцінних ділянок і підвищити ефективність сканування; не покладайтеся на нього, щоб керувати індексацією або приховувати конфіденційний вміст.

Контролює сканування, а не індексацію

Директива Disallow забороняє сумлінним краулерам запитувати шлях URL. Якщо сторінка заблокована від сканування,пошукові системи все ще можуть індексувати її URL на основі зовнішніх сигналів (наприклад, посилань), але не побачать HTML сторінки або meta robots-теги. Щоб надійно запобігти індексації, дозвольте сканування, щобcrawler зміг прочитати meta robots noindex або щоб ресурс віддавав заголовок X-Robots-Tag з noindex.

Публічний, рекомендаційний і не засіб безпеки

Robots.txt доступний публічно й має рекомендаційний характер: будь-хто може прочитати його за /robots.txt, а зловмисні краулери можуть ігнорувати директиви. Не вказуйте в robots.txt секрети або приватні шляхи; розглядайте файл як інструмент контролю сканування, а не доступу.

Основний синтаксис і поширені директиви

Більшість сайтів використовують невелику підмножину директив. Специфікація та практичні розширення, які підтримують основні пошукові системи, дозволяють базові шаблони, wildcard-символи й вказівки на sitemap. Тримайте правила простими й документуйте намір у коментарях, коли це можливо.

Ключові директиви (приклади показані як буквальні рядки):

• User-agent: <bot-name> — націлює один краулер; використовуйте User-agent: * для всіх краулерів.
• Disallow: /path/ — забороняє запити до шляхів під /path/.
• Allow: /path/file.js — явне дозволення шляху в межах забороненого батьківського каталогу (підтримується основними рушіями).
• Sitemap: https://example.com/sitemap.xml — підказує краулерам ваші XML sitemap(и).
• Wildcard-и: * (відповідає будь-якій послідовності) і $ (кінець рядка) практично підтримуються основними рушіями; використовуйте їх обережно для шаблонів з параметрами запиту.
• Не-стандартні директиви: Crawl-delay та Host визнаються деякими краулерами, але не входять до оригінального стандарту — тестуйте поведінку для тих user-agent, які вам важливі.

Як robots.txt взаємодіє з індексацією та ранжуванням

Розділяйте сканування, індексацію й ранжування: robots.txt впливає на етап crawling (чи запитує краулер URL). Для індексації краулер повинен прочитати вміст сторінки або meta/X-Robots-Tag. Ранжування — наступний процес, що спирається на сигнали, частина з яких походить із вмісту сторінки; якщо краулер не може отримати сторінку, ці сигнали з вмісту стають недоступними.

Практичні наслідки:

• Блокування сторінки в robots.txt означає, що пошукова система не зможе отримати сторінку, щоб прочитати meta robots noindex або структуровані дані.
• Якщо важливий ресурс (CSS/JS) заблокований,mobile-first indexing і рендеринг можуть не побачити сторінку правильно; оскільки Google використовує мобільну версію як основну дляcrawling and indexing, і оскільки Googlebot Smartphone є стандартним краулером станом на July 2024, дозвольте ресурси, необхідні для рендерингу на мобільних пристроях.

Перевірка: як тестувати те, що бачать краулери

Перевіряйте доступність і вміст robots.txt зовні та підтверджуйте, як сайт реагує на реальні запити краулерів. Використовуйте серверні логи, прямі запити й інструменти Search Console для сторінок, якими ви керуєте.

Швидкі перевірки за допомогою curl

Щоб отримати HTTP-заголовки відповіді для robots.txt (лише заголовки):

• curl -I https://example.com/robots.txt — повертає лише заголовки відповіді; перевірте статус-код і Content-Type.

Щоб отримати повний файл як конкретний user-agent (тіло й директиви):

• curl -A "Googlebot" https://example.com/robots.txt — повертає тіло файлу з зазначеним user-agent.

Логи сервера й докази реального сканування

Переглядайте серверні логи на предмет запитів до /robots.txt і на предмет user-agent краулерів, як Googlebot або Bingbot. Логи показують частоту запитів, коди відповідей і чи намагалися краулери отримувати заборонені URL. Для сторінок, якими ви володієте, використовуйте URL Inspection у Search Console, щоб побачити спроби сканування та сигнали індексації; для сторонніх сторінок запит site: дає орієнтовну інформацію, але не є остаточною.

Поширені помилки й як їх виправити

Уникайте цих частих помилок при керуванні robots.txt.

• Блокування CSS/JS, потрібних для рендерингу: виправлення — дозвольте шляхи до ресурсів, необхідних для мобільного рендерингу, щоб Googlebot Smartphone міг коректно відтворювати сторінки.
• Очікування, що robots.txt виконає noindex для URL: виправлення — видаліть Disallow для сторінки й використайте meta robots noindex або заголовок X-Robots-Tag, щоб пошукові системи могли побачити інструкцію.
• Перерахування конфіденційних URL у robots.txt: виправлення — не викривайте приватні шляхи в robots.txt; захищайте їх через автентифікацію й належні серверні механізми контролю доступу.
• Надто складні wildcard-правила, що ненавмисно відповідають дійсним сторінкам: виправлення — тестуйте кожен шаблон на прикладах URL і документуйте намір у коментарях, тримаючи правила якомога конкретнішими.

Рекомендовані стратегії robots.txt

Приймайте консервативний і тестований підхід: тримайте robots.txt мінімальним, вказуйте краулерам sitemaps і надавайте перевагу управлінню індексацією на рівні сторінки через meta/X-Robots-Tag.

Практичні шаблони:

• Стандартний дозвіл плюс sitemap: включіть User-agent: * і директиву Sitemap, щоб краулери швидко знаходили структуру сайту.
• Блокування низькоцінних сторінок з параметрами або внутрішніх результатів пошуку, але уникайте блокування шаблонів параметрів, які також відповідають канонічному вмісту; надавайте перевагу обробці параметрів у sitemap або через canonical-теги.
• Стадійний або девелоперський сервер: блокуйте краулерів, поки стадійний сервер публічний, але видаліть або змініть блок перед запуском; не покладайтеся на robots.txt як єдиний захист для передвиробничих ресурсів.

Приклади, які можна адаптувати

Простий сайт із sitemap

User-agent: *
Disallow:
Sitemap: https://example.com/sitemap.xml

Поширена CMS (дозволити admin-ajax)

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml

Блокування для staging (публічний сервер, але ще не готовий)

User-agent: *
Disallow: /

Увага: блокування для staging потрібно зняти перед запуском; також захистіть staging автентифікацією, щоб пошукові системи та треті сторони не змогли випадково індексувати його, якщо файл robots змінять.

Підтримка robots.txt у масштабі

Для великих сайтів розглядайте robots.txt як артефакт конфігурації: тримайте його в системі контролю версій, переглядайте зміни через pull request-и і деплойте разом із сайтом, щоб staging і production мали коректні файли для відповідного середовища. Автоматизуйте тести, які завантажують розгорнутий robots.txt і перевіряють синтаксис правил на репрезентативних URL.

Якщо ви керуєте кількома субдоменами, пам’ятайте, що robots.txt специфічний для хоста: правила в example.com/robots.txt не застосовуються до sub.example.com.

FAQ