Если в индексе появляются служебные URL, дубли архивов, страницы поиска, вложения медиафайлов или технические параметры, проблема часто не в «плохом SEO», а в том, что robots.txt не настроен под реальную структуру сайта. В WordPress это особенно заметно на проектах с плагинами, фильтрами, архивами и нестандартными шаблонами.
Ниже — рабочий сценарий: что именно закрывать, как собрать robots.txt без лишних запретов и как проверить, что вы не отрезали от обхода важные разделы.
Что обычно попадает в индекс по ошибке
Сначала стоит понять, какие URL вообще нужно ограничивать. robots.txt не удаляет страницы из индекса напрямую, он только управляет обходом. Если страница уже проиндексирована, одного robots.txt может быть недостаточно — тогда понадобится noindex или удаление через Search Console.
Типичные технические страницы WordPress
- страницы поиска вида
/?s=...; - архивы авторов на небольших сайтах, где они не несут пользы;
- страницы вложений медиафайлов;
- служебные URL плагинов и фильтров;
- параметры сортировки и пагинации, если они создают мусорные дубли;
- админка,
wp-login.php,wp-admin— их обычно не индексируют, но и закрывать агрессивно не нужно.
Важно не путать «закрыть от индексации» и «спрятать от пользователей». robots.txt не защищает контент, а только подсказывает роботам, что не стоит обходить.
Диагностика: что проверить до правки robots.txt
Перед изменением файла посмотрите, какие URL уже есть в индексе и какие из них реально создают шум. Иначе можно закрыть полезные страницы, а проблему не решить.
- Откройте отчеты индексации в Google Search Console.
- Проверьте, есть ли в выдаче URL с параметрами, архивами и поиском.
- Посмотрите, не генерирует ли тема или плагин отдельные страницы для вложений.
- Проверьте текущий robots.txt по адресу
/robots.txt. - Убедитесь, что в файле нет старых запретов, оставшихся после миграции или смены плагина.
Если сайт уже использует SEO-плагин, сначала проверьте его настройки. Часто robots.txt генерируется не вручную, а через интерфейс плагина, и правка файла на сервере просто не сработает.
| Подход | Когда уместен | Минус |
|---|---|---|
| Правка robots.txt вручную | Нужен точный контроль | Легко ошибиться и закрыть лишнее |
| Настройка через SEO-плагин | Сайт ведется без доступа к файлам | Зависимость от логики плагина |
| Комбинация robots.txt + noindex | Нужно убрать и обход, и индексацию | Требует аккуратной проверки |
Как настроить robots.txt в WordPress пошагово
Базовый вариант можно начать с минимального набора директив. Для большинства сайтов этого достаточно, если нет сложной фильтрации и нестандартных разделов.
Пример безопасного robots.txt
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/
Disallow: /attachment/
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть несколько важных моментов. admin-ajax.php оставляем доступным, потому что его используют темы и плагины. Строка Sitemap помогает поисковым системам быстрее находить актуальные карты сайта.
Но не копируйте этот шаблон без проверки. Например, если у вас поиск работает по другому URL, правило Disallow: /?s= может быть бесполезным. А если архив вложений уже закрыт через плагин, отдельный запрет на /attachment/ может не понадобиться.
Если robots.txt генерируется через PHP
Иногда удобнее не править файл вручную, а отдать robots.txt через WordPress-фильтр robots_txt. Это полезно, если правила зависят от среды или вы не хотите держать отдельный файл в корне.
<?php
add_filter('robots_txt', function ($output, $public) {
$rules = array(
'User-agent: *',
'Disallow: /wp-admin/',
'Allow: /wp-admin/admin-ajax.php',
'Disallow: /wp-login.php',
'Sitemap: ' . home_url('/sitemap_index.xml'),
);
return implode("\n", $rules) . "\n";
}, 10, 2);Такой вариант удобен в теме или небольшом кастомном плагине. Но если у вас уже есть SEO-плагин, проверьте, не перезаписывает ли он robots.txt своим выводом.
Что лучше закрывать, а что не трогать
Самая частая ошибка — закрыть слишком много. Например, некоторые пытаются запретить обход CSS, JS и изображений. Для современного поиска это плохая идея: роботам нужен доступ к ресурсам, чтобы корректно оценить страницу.
Обычно имеет смысл закрыть
- страницы поиска;
- служебные страницы входа;
- архивы вложений, если они не используются как отдельные посадочные страницы;
- дубли с параметрами, если они не нужны для индексации;
- технические каталоги плагинов, если они вообще доступны извне.
Обычно не стоит закрывать
/wp-content/uploads/целиком;/wp-includes/без понимания последствий;- CSS и JS, которые нужны для рендеринга;
- основные категории и записи, если они должны индексироваться.
Если нужно убрать из индекса именно дубли, а не только запретить обход, добавляйте noindex на уровне шаблона или через SEO-плагин. robots.txt для этого недостаточен.
Проверка результата после внедрения
После обновления robots.txt не ограничивайтесь открытием файла в браузере. Нужно проверить и доступность, и реакцию поисковых систем.
- Откройте
/robots.txtи убедитесь, что файл отдается без ошибок. - Проверьте, что sitemap указан корректно и ведет на существующий файл.
- В Search Console используйте проверку URL для страниц, которые должны быть закрыты или открыты.
- Посмотрите, не исчезли ли из обхода важные страницы после следующего сканирования.
- Если закрывали дубли, проверьте, уменьшается ли число таких URL в отчете индексации.
Полезно отдельно проверить, что robots.txt не блокирует ресурсы темы. Если страница стала отображаться без стилей или скриптов, значит, где-то закрыт лишний путь.
Частые ошибки и как их исправить
Закрыли весь сайт одной строкой
Ошибка выглядит так: Disallow: /. Это полностью запрещает обход. Если строка попала в рабочий файл по ошибке, поисковики перестанут сканировать сайт. Исправление простое — убрать правило и заново отправить sitemap в Search Console.
Пытаются убрать уже проиндексированные страницы только через robots.txt
Если URL уже в индексе, робот может перестать его обходить, но сам адрес какое-то время останется в выдаче. Для таких страниц нужен noindex или удаление через инструменты вебмастера.
Закрывают ресурсы темы и плагинов
Когда в robots.txt запрещают /wp-content/ или отдельные папки с CSS/JS, страницы могут начать рендериться некорректно. Это особенно заметно после обновлений темы или при использовании кеширования.
Редактируют не тот robots.txt
На некоторых хостингах и в SEO-плагинах файл генерируется виртуально. Если вы правите физический файл на сервере, а сайт отдает другой вариант, изменения не появятся. Проверьте ответ сервера и настройки плагина.
Практические советы по безопасности и производительности
robots.txt не защищает от сканеров и не заменяет серверные ограничения. Если нужно ограничить доступ к админке или API, используйте права доступа, basic auth, firewall или настройки сервера.
Для производительности полезно держать robots.txt коротким и понятным. Чем меньше лишних правил и экспериментальных директив, тем проще поддержка. Если сайт большой и структура часто меняется, держите список правил в репозитории или хотя бы в заметке рядом с конфигурацией SEO-плагина.
Если вы используете Clearfy Pro, у него есть инструменты для чистки сайта и управления техническими дублями; в таких случаях часть задач можно закрыть настройками плагина, а не ручной правкой файла. Но логику запретов все равно стоит проверять вручную, особенно после обновлений темы или миграции.
Хороший рабочий процесс такой: сначала определить, какие URL действительно мешают индексации, затем добавить минимальные правила, после этого проверить обход и индексацию в Search Console. Так robots.txt перестает быть «магическим файлом» и становится обычной частью технической настройки сайта.