Файл robots.txt — це текстовий файл у корені сайту, який задає правила доступу для пошукових роботів до окремих URL, папок і типів сторінок. Його головна задача — не «сховати сторінку з Google», а керувати crawling: підказати роботу, що варто сканувати, а на що не потрібно витрачати ресурси сервера та crawl budget.

Сканування — це коли бот запитує сторінку. Індексація — це коли сторінка після обробки може потрапити до бази пошукової системи. Noindex — окрема директива, яка говорить Google не додавати документ у результати пошуку. Саме тому robots.txt не варто подавати як універсальний спосіб прибрати URL із видачі: для Google це насамперед інструмент керування обходом.

Якщо сторінка вже не повинна з’являтися в пошуку, одного robots.txt недостатньо. Тут працює інша зв’язка: для контролю доступу — robots.txt, для деіндексації — noindex або X-Robots-Tag , для закритих розділів — авторизація чи парольний доступ. Коли ці задачі змішують, сайт або дарма віддає на обхід технічні URL, або випадково блокує важливі сторінки.

На практиці правильно налаштований robots.txt впливає не лише на технічну чистоту сайту, а й на ефективність просування сайту . Коли пошуковик не витрачає обхід на службові сторінки, фільтри, параметричні URL чи технічні розділи, він швидше доходить до контенту, який справді має SEO-цінність.

Матеріал спирається на офіційну документацію Google про robots.txt , технічну специфіку того, як Google інтерпретує robots.txt , рекомендації щодо noindex і дані WordPress Developer Resources .

Що таке robots txt і коли він справді потрібен

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

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

При цьому robots.txt не варто сприймати як інструмент захисту приватних даних. Якщо документ справді чутливий, його не потрібно просто «забороняти в robots.txt» — його треба забирати з публічного доступу, закривати авторизацією або налаштовувати серверний захист. Сам файл лише публікує правило для ботів, а не створює бар’єр для користувачів чи парсерів.

Сканування, індексація і noindex — не одне й те саме

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

З noindex логіка інша. Щоб Google побачив цю директиву, сторінка має залишатися доступною для обходу. Типова помилка — одночасно поставити Disallow у robots.txt і чекати, що бот прочитає noindex всередині сторінки. Не прочитає, бо доступ уже закритий.

Якщо потрібно глибше розібратися в самій логіці потрапляння сторінок у пошук, окремо перегляньте матеріал про індексацію сайту в пошукових системах . На практиці тут часто плутають саме причину проблеми: здається, що сторінка «не індексується», хоча насправді її просто неправильно відкрили або закрили для обходу.

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

У robots txt є кілька базових вимог, які не варто порушувати. Файл має називатися саме robots.txt , бути звичайним текстовим документом у кодуванні UTF-8 і лежати в корені того хоста, до якого застосовуються правила. Якщо файл покласти в підпапку, пошуковий робот не сприйматиме його як robots.txt.

Є й технічний нюанс, який часто губиться в загальних поясненнях. Robots.txt діє не «на весь сайт загалом», а в межах конкретного протоколу, хоста й порту. Тобто правила для https://example.com/robots.txt не стають автоматично правилами для https://www.example.com/ або для піддоменів. Якщо ресурс рознесений по кількох хостах, це треба враховувати ще на етапі розробки сайту та побудови його структури.

Ще один показовий момент: коли robots.txt розростається до сотень рядків і постійно обростає винятками, проблема часто вже не в самому файлі. Зазвичай це означає, що на сайті занадто багато хаотичних параметрів, службових URL або технічних сторінок, які варто впорядковувати на рівні архітектури, а не латати нескінченними правилами.

User-agent, Disallow, Allow і Sitemap — що означають основні директиви

User-agent показує, для якого саме робота діє блок правил. Із цієї директиви починається будь-яка логіка керування доступом у robots.txt. Якщо вказати User-agent: * , правило поширюється на всіх ботів, які підтримують Robots Exclusion Protocol.

Disallow — основна директива, якою обмежують сканування окремих розділів, папок або типів URL. Нею часто закривають внутрішній пошук, кошик, технічні каталоги, тестові папки або сторінки з низькою SEO-цінністю.

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

Sitemap не забороняє і не дозволяє обхід, а лише підказує, де лежить карта сайту. Саме тому додавати sitemap в robots txt — нормальна практика: це не замінює подання карти в Search Console, але дає ще одну точку виявлення sitemap.

Базовий приклад може виглядати так:

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

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

Який синтаксис robots txt справді важливий

Синтаксис robots txt не виглядає складним, але саме на дрібницях виникає більшість помилок. Шляхи задаються від кореня сайту, файл чутливий до структури URL, а невалідні або зайві рядки Google просто ігнорує. Через це неправильний robots.txt не завжди «ламається повністю» — іноді він частково працює, а частково ні, і саме тому помилки можуть довго лишатися непоміченими.

Є й важливий практичний момент: Google не підтримує частину директив, які досі кочують старими статтями та шаблонами. Зокрема, noindex , nofollow і crawl-delay не належать до підтримуваних правил robots.txt для Google. Тому якщо у файлі досі є подібні записи, вони не повинні бути опорою для сучасної технічної оптимізації.

Robots txt для WordPress — що перевірити окремо

Robots txt для WordPress — окрема тема, бо на цій платформі файл може віддаватися не лише як фізичний документ на сервері, а й динамічно. Крім того, у WordPress уже є вбудована підтримка XML-sitemap. Це зручно, але фінальний результат все одно потрібно перевіряти.

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

Для інтернет-магазинів на WordPress або WooCommerce це ще важливіше: там швидко накопичуються параметричні URL, фільтри, сторінки сортування, кошик, checkout та інші ділянки, які не варто безконтрольно віддавати на crawling.

Як перевірити robots txt у Google Search Console

Перевіряти robots.txt краще не ізольовано, а разом із Search Console, URL Inspection, Page Indexing і Crawl Stats. Сам файл може бути формально коректним, але це ще не означає, що він працює на користь сайту.

Сам robots txt report у Search Console допомагає побачити поточну версію файлу й швидше оновити кеш після змін. Для окремих URL корисний Google Search Console з URL Inspection: так видно, чи не блокує robots.txt сторінку, яка насправді має скануватися. Для ширшої картини варто дивитися Page Indexing і Crawl Stats — саме там видно, де сайт реально втрачає обхід.

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

Типові помилки в robots.txt

Найчастіше проблеми виникають не через складний синтаксис, а через неправильне розуміння того, для чого взагалі потрібен цей файл.

  • Закривають сторінку в robots.txt і чекають, що вона зникне з пошуку. Це не гарантований сценарій. Якщо URL уже відомий Google, він може ще з’являтися у видачі навіть без повноцінного контенту.

  • Блокують сторінки, які повинні скануватися. Через це пошуковик не бачить важливий контент, а проблема потім виглядає як «повільна індексація».

  • Закривають ресурси, потрібні для рендерингу. Якщо випадково обмежити важливі CSS або JavaScript, сторінка може відкриватися в браузері нормально, але для Google її рендер буде неповним.

  • Тримають у файлі застарілі або непідтримувані правила. Користі від них немає, але вони створюють хибне відчуття контролю.

  • Публікують файл не там. Robots.txt у підпапці, у неправильному кодуванні або з помилкою в назві — це фактично відсутній robots.txt.

  • Покладаються на robots.txt як на захист приватних розділів. Для закритої інформації потрібен контроль доступу, а не лише рекомендація для ботів.

Є і ще один цілком земний сценарій: на staging-домені або тестовій копії сайту robots.txt був налаштований правильно, а під час релізу його або забули змінити, або випадково перенесли на основний домен. Такі помилки трапляються значно частіше, ніж здається, особливо після редизайну чи переїзду.

Так само варто пам’ятати і про доступність самого файлу. Якщо robots.txt віддається з серверними помилками, це теж впливає на crawling. Тому під час редизайну, переїзду, зміни CDN або серверних налаштувань robots.txt треба перевіряти так само уважно, як sitemap, редиректи і canonical.

Висновок

Правильно налаштований файл robots txt — це не декоративний атрибут сайту і не спосіб «заховати все зайве від Google». Це робочий інструмент керування crawling, який допомагає прибрати шум, спрямувати робота до важливих розділів і не витрачати обхід на URL без цінності.

У практиці все зводиться до простого розділення ролей. Robots.txt потрібен для керування обходом. Якщо сторінку треба прибрати з пошуку, дивитися треба вже в бік noindex , X-Robots-Tag або серверних обмежень доступу. Коли ці задачі не підміняють одна одну, технічна SEO-логіка сайту стає значно чистішою.

Якщо ж на сайті вже є сумніви щодо того, які URL слід закривати, що потрібно залишити для обходу, де конфліктують robots.txt, meta robots, canonical і sitemap, такі питання краще вирішувати не точковими правками, а через повноцінний технічний розбір структури сайту.