Що має містити файл robots.txt для WordPress?

Чотири речі й нічого понад те: рядок user-agent із зірочкою, Disallow для /wp-admin/, Allow для /wp-admin/admin-ajax.php і директива Sitemap із повною адресою вашої мапи сайту. Усе інше необов'язкове, а більшість довгих блоклистів, що ходять інтернетом, створюють більше проблем, ніж вирішують.

Чи створює WordPress файл robots.txt автоматично?

Так, але лише віртуальний. WordPress формує відповідь у пам'яті, коли надходить запит на /robots.txt, а реального файлу на диску немає. Туди входять правила для wp-admin і, починаючи з версії 5.5, рядок Sitemap для wp-sitemap.xml. На сервер при цьому нічого не записується.

Чому мій robots.txt не збігається з тим, що мав би віддавати WordPress?

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

Чи варто закривати wp-content або wp-includes у robots.txt?

Ні. У цих каталогах лежать CSS, JavaScript і зображення, потрібні вашим сторінкам для відображення. Заблокувавши їх, ви не даєте Google завантажити ці ресурси, тож він оцінює зламану версію вашого макета. Колись така порада була поширеною, а сьогодні вона відверто шкідлива.

Чи може robots.txt тримати сторінку поза індексом Google?

Ні. Robots.txt керує скануванням, а не індексуванням. Заблокована адреса все одно може потрапити в індекс, якщо на неї посилаються інші сторінки, і з'явитися в результатах без опису. Щоб сторінки не було в індексі, дозвольте сканування і віддавайте мета-тег robots із noindex або заголовок X-Robots-Tag.

Чи є robots.txt засобом безпеки?

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

robots.txt для WordPress у 2026 році (що туди справді треба класти)

Хороший robots.txt для WordPress має приблизно п’ять рядків. Закрийте /wp-admin/, дозвольте admin-ajax.php, вкажіть краулерам мапу сайту — і на цьому все: розлогі 40-рядкові блоклисти з форумів здебільшого або ламають рендеринг, або не роблять нічого. Ось увесь файл:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

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

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

WordPress уже генерує його — доки ви не створите справжній файл

WordPress постачає віртуальний robots.txt. Коли надходить запит на /robots.txt, а реального файлу в корені сайту немає, WordPress перехоплює запит і друкує відповідь у пам’яті. На диск нічого не записується. Стандартний вивід — це блок для wp-admin вище плюс рядок Sitemap: для wp-sitemap.xml, який ядро віддає ще з WordPress 5.5.

Дві речі змінюють цей вивід. Якщо позначено Налаштування → Читання → Попросити пошукові системи не індексувати цей сайт, WordPress замінює весь вміст на Disallow: /, що блокує геть усе. Саме цей прапорець — найпоширеніша причина зникнення сайту з пошуку після запуску. По-друге, плагіни й теми можуть змінювати віртуальний вивід через фільтр robots_txt — так SEO-плагіни підставляють власні рядки з мапами сайту й свої правила.

А тепер частина, яка з’їдає людям половину дня. Фізичний файл robots.txt у корені сайту мовчки перекриває все це. Вебсервер знаходить реальний файл на диску, віддає його, і WordPress навіть не завантажується. Віртуальний генератор не запускається. Фільтр robots_txt не спрацьовує. Редактор robots.txt у вашому SEO-плагіні може й далі показувати гарний інтерфейс із правильними правилами, і жодне з них не доходить до краулера.

Де живуть правила	Редагується в адмінці WordPress	Перемагає на живому запиті
Віртуальний (файлу на диску немає)	Так, через фільтр `robots_txt` або плагін	Лише коли фізичного файлу немає
Фізичний файл у корені сайту	Лише якщо плагін пише на диск	Завжди

Тож перш ніж щось налагоджувати: відкрийте https://yoursite.com/robots.txt у браузері, а потім підключіться через SFTP або файловий менеджер хостингу й перевірте, чи не лежить справжній robots.txt поруч із wp-config.php та .htaccess. Якщо лежить — саме він і є вашим robots.txt. Редагуйте його там або видаліть і дозвольте WordPress перебрати роль на себе, але оберіть щось одне. Одночасна робота обох — це шлях до застарілої адреси мапи сайту, якої ніхто не може знайти.

Чому /wp-admin/ заблоковано, а admin-ajax.php дозволено

У /wp-admin/ лежить панель керування. Ці адреси в пошуковій видачі не потрібні нікому, а їх сканування витрачає краул-бюджет на сторінки, що перенаправляють на форму входу. Блокування каталогу сумнівів не викликає.

admin-ajax.php лежить усередині того ж каталогу, але адмінсторінкою не є. Це кінцева точка, якою плагіни й теми обробляють AJAX-запити з фронтенду — кнопки «показати ще», відфільтровані сітки товарів, калькулятори, форми. Якщо краулер не може її завантажити, він не бачить контенту, який ці функції підвантажують, і Google рендерить вашу сторінку такою, якою її побачив би відвідувач зі зламаною функцією.

Чи справді Google потрібно завантажувати admin-ajax.php саме на вашому сайті — залежить від того, чи використовує його ваш фронтенд. Чесна відповідь: на багатьох сучасних сайтах це не має жодного значення, бо тема працює через REST API за адресою /wp-json/. Рядок Allow — це дешева страховка від реального сценарію поломки, а не фактор ранжування. Лишіть його, бо він нічого не коштує.

Не блокуйте /wp-content/ і /wp-includes/

Це найгірша порада щодо robots.txt із тих, що досі ходять інтернетом, і походить вона з часів, коли Google ще не рендерив сторінки.

У /wp-content/ лежать ваші теми, плагіни, завантаження — стилі, скрипти та зображення, які роблять ваші сторінки сторінками. У /wp-includes/ лежить JavaScript ядра, від якого залежать плагіни. Google рендерить ваші сторінки в безголовому браузері, перш ніж їх оцінити. Заблокуйте ці каталоги — і рендерер отримає сторінку без CSS і без зображень. Google оцінюватиме нестилізовану стіну тексту зі зламаним макетом, а це впливає і на розуміння вашого контенту, і на оцінку зручності для мобільних.

Якщо вам дістався файл із такими рядками, видаліть їх:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Переконатися у шкоді можна самостійно в інструменті перевірки URL у Google Search Console. Запустіть живий тест будь-якої сторінки, подивіться на знімок відрендереного вигляду й перегляньте список ресурсів сторінки на предмет заблокованих. Якщо ваш CSS позначено як заблокований — ось і причина.

Директива Sitemap

Один рядок, абсолютна адреса, і стояти він може будь-де у файлі — до групи User-agent він не прив’язаний.

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

Вказуйте ту адресу, яка справді відкривається. Ядро WordPress віддає wp-sitemap.xml. Більшість SEO-плагінів вимикають мапи ядра й віддають власний індекс за іншим шляхом, зазвичай sitemap_index.xml. Відкрийте свою адресу в браузері, перш ніж її фіксувати: рядок Sitemap, що вказує на 404, гірший за його відсутність, бо в аудиті виглядає правильним.

Перелічити кілька мап сайту — нормально, по одній на рядок. Подавати мапи в Search Console окремо все одно варто; директива в robots.txt потрібна для тих краулерів, які до вашого облікового запису Search Console ніколи не дістануться.

robots.txt — це не noindex і не безпека

Саме ці два непорозуміння завдають більшості шкоди через robots.txt.

Блокування адреси не прибирає її з Google. Robots.txt керує скануванням. Якщо на заблоковану адресу посилається інший сайт, Google може проіндексувати саму адресу — і ви отримаєте результат із голим посиланням і приміткою, що інформації немає. Є й підступніша пастка: якщо на сторінці вже стоїть мета-тег noindex, а ви потім блокуєте її в robots.txt, Google не може її просканувати, не бачить noindex — і сторінка може лишатися в індексі невизначено довго. Щоб прибрати сторінку, дозвольте сканування і віддайте мета-тег robots із noindex у head сторінки або HTTP-заголовок X-Robots-Tag. Директиви noindex всередині robots.txt Google перестав підтримувати ще у 2019 році.

Блокування шляху не захищає його. Ваш robots.txt публічний за визначенням. Рядок /private-client-files/ показує кожному відвідувачу й кожному сканеру, куди саме дивитися, а виконання правил добровільне: Google їх шанує, ворожі боти — ні. Усе, що потребує захисту, потребує автентифікації, обмеження за IP або правил рівня сервера в .htaccess, а не рядка в текстовому файлі, який рекламує ціль.

Правила, які варто додати, і правила, які варто пропустити

Два доповнення справді корисні на багатьох сайтах. Блокування шляху результатів пошуку не дає краулерам плодити нескінченні малоцінні адреси з вашого внутрішнього пошуку. Блокування кошика чи оформлення замовлення в WooCommerce тримає адреси з параметрами сесії поза скануванням.

Disallow: /?s=
Disallow: /search/

А ось це пропустіть:

Crawl-delay — Google повністю його ігнорує. Якщо у вас реальна проблема з навантаженням на сервер, користуйтеся налаштуваннями частоти сканування в Search Console.
Блокування /feed/ чи /trackback/ — це нешкідливі адреси, а стрічки ще й корисні.
Довгі списки назв окремих ботів — більшість ботів, яких намагаються блокувати, усе одно представляються нечесно.
Блокування /wp-json/ — цілком можливо, саме через нього ваша тема відображає контент.

Складіть файл у генераторі robots.txt для WordPress: він видає мінімальну коректну версію й дозволяє додати правила для пошуку та комерції без ручного редагування синтаксису.

Після того, як ви його змінили

Відкрийте https://yoursite.com/robots.txt напряму й переконайтеся, що віддані байти саме такі, як ви очікуєте, а не такі, як показує редактор плагіна. Потім запустіть живу перевірку URL у Search Console на звичайній сторінці й переконайтеся, що жоден ресурс CSS чи JavaScript не повертається заблокованим. Google кешує robots.txt приблизно добу, тож виправлення набуде чинності не миттєво — і помилка теж. Саме через цю затримку варто ретельно перевіряти, а не тестувати на живому сайті й чекати.