На WordPress robots.txt часто правят по инерции: добавляют пару строк, закрывают всё подряд и потом удивляются, почему в индексе остаются дубли или, наоборот, поисковик перестаёт нормально обходить сайт. Если задача не в «красивом файле», а в том, чтобы убрать из обхода служебные URL и не трогать важные страницы, нужен более аккуратный подход.
Ниже разберём, какие технические страницы действительно имеет смысл закрывать, как это сделать без конфликтов с плагинами и как проверить, что robots.txt работает так, как вы ожидали.
Какие страницы WordPress обычно стоит закрывать
robots.txt не удаляет страницы из индекса напрямую. Он ограничивает обход. Поэтому закрывать нужно только то, что не должно тратить crawl budget и не несёт ценности для поиска.
Типичные кандидаты на закрытие
/wp-admin/— административная часть сайта;/wp-login.php— страница входа;/wp-json/— если у вас есть отдельная причина ограничить обход, но это не универсальная рекомендация;- служебные параметры и внутренние поисковые URL, если они создают мусорные дубли;
- временные каталоги и технические разделы, которые не должны попадать в выдачу.
А вот /wp-content/uploads/ закрывать целиком обычно не нужно: изображения и медиа часто должны индексироваться отдельно. То же касается CSS и JS — поисковым системам они нужны для рендеринга страницы.
Диагностика проблемы перед правкой robots.txt
Сначала проверьте, что именно вы хотите исправить. Если в индексе есть дубли, robots.txt может быть только частью решения. Иногда проблема в canonical, иногда в параметрах URL, иногда в генерации архивов темы.
- Откройте текущий
/robots.txtв браузере. - Проверьте, не создаёт ли его плагин SEO или кеширующий плагин.
- Посмотрите в Google Search Console, какие URL попадают в отчёт об обходе и индексации.
- Сравните, не закрыты ли случайно важные разделы: записи, рубрики, страницы, изображения.
Если robots.txt уже управляется SEO-плагином, ручная правка файла на сервере может не дать эффекта. В этом случае нужно либо менять настройки плагина, либо использовать фильтр WordPress для генерации содержимого robots.txt.
Пошаговая настройка robots.txt в WordPress
Есть два рабочих сценария: правка файла на сервере и генерация через WordPress. Для большинства сайтов безопаснее второй вариант, если robots.txt уже обслуживается системой или плагином.
Вариант 1: статический файл в корне сайта
Если у вас нет плагина, который подменяет robots.txt, можно создать обычный файл в корне сайта. Минимальный пример:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.phpТакой вариант простой, но у него есть минус: если позже SEO-плагин начнёт генерировать robots.txt динамически, статический файл может стать неактуальным или конфликтовать с логикой плагина.
Вариант 2: генерация через фильтр robots_txt
Если нужно управлять содержимым из темы или мини-плагина, используйте штатный фильтр WordPress. Это удобно, когда вы хотите добавить правила без ручного редактирования файла.
<?php
add_filter( 'robots_txt', function( $output, $public ) {
$lines = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /wp-login.php',
);
return implode( "\n", $lines ) . "\n";
}, 10, 2 );Этот код полностью заменяет вывод robots.txt. Если вам нужно не заменить, а дополнить существующие правила, сначала посмотрите, как именно формируется текущий файл, и не перетирайте нужные директивы SEO-плагина.
Когда лучше не закрывать URL через robots.txt
Если страница уже в индексе и вы хотите убрать её полностью, одного robots.txt недостаточно. Поисковик может перестать её обходить, но URL ещё долго будет висеть в выдаче без содержимого. В таких случаях обычно используют noindex на самой странице, а не запрет в robots.txt.
| Подход | Когда использовать | Компромисс |
|---|---|---|
| Статический robots.txt | Простой сайт без генерации файла плагинами | Нужно следить за конфликтами при установке SEO-плагинов |
Фильтр robots_txt | Нужно управлять правилами из кода | Требует аккуратности, можно случайно заменить весь файл |
noindex на странице | Нужно убрать URL из индекса | Страница должна оставаться доступной для обхода |
Проверка результата после внедрения
После правки не ограничивайтесь открытием файла в браузере. Проверьте, что поисковый робот видит именно ту версию, которую вы ожидаете.
- Откройте
https://ваш-домен/robots.txtв браузере. - Убедитесь, что там нет лишних
Disallowдля публичных разделов. - Проверьте файл в Google Search Console через инструмент проверки URL или отчёты по индексации.
- Посмотрите серверные логи, если нужно понять, продолжает ли бот ходить в закрытые разделы.
Если после правки в robots.txt всё выглядит корректно, но в индексе остаются старые URL, это нормально: robots.txt не удаляет уже проиндексированные страницы мгновенно. Для удаления используйте noindex, редирект или удаление страницы с корректным кодом ответа.
Частые ошибки и как их исправить
Закрыли слишком много
Самая частая ошибка — запретить весь сайт одной строкой вроде Disallow: /. После этого поисковик перестаёт обходить вообще всё. Если это уже произошло, уберите правило и проверьте, не осталось ли его в кеше плагина или CDN.
Путают robots.txt и noindex
robots.txt не гарантирует удаление URL из выдачи. Если цель — убрать страницу из индекса, нужен noindex или удаление страницы с редиректом на релевантный адрес.
Редактируют не тот robots.txt
На WordPress файл может генерироваться динамически. Вы меняете физический файл на сервере, а сайт отдаёт версию из плагина. Проверяйте именно то, что видит браузер по адресу /robots.txt.
Закрывают CSS и JS
Если запретить ресурсы темы и плагинов, поисковик может хуже рендерить страницы. Это особенно заметно на сайтах, где важна мобильная версия и корректная отрисовка блоков.
Практические советы по безопасности и производительности
robots.txt не защищает от доступа к файлам. Он только просит поисковики не обходить указанные URL. Не используйте его как средство безопасности для приватных данных, резервных копий или админки.
- Для закрытия приватных файлов используйте права доступа на сервере, а не robots.txt.
- Не блокируйте ресурсы, которые нужны для рендеринга страниц.
- После изменения robots.txt очистите кеш, если файл отдаётся через кеширующий плагин или CDN.
- Если сайт большой, сначала меняйте правила точечно, а не переписывайте файл целиком.
Если у вас уже есть проблемы с дублями, часто полезнее сначала почистить структуру архивов, параметров и служебных страниц, а затем уже настраивать robots.txt. В WordPress это обычно даёт более предсказуемый результат, чем попытка «запретить всё лишнее» одним файлом.