Если у WordPress-сайта в robots.txt закрыть не то, что нужно, поисковик может перестать обходить важные страницы или, наоборот, продолжит тратить краулинговый бюджет на мусорные URL. На практике задача обычно одна: убрать из обхода служебные и бесполезные разделы, но не задеть то, что должно индексироваться и сканироваться.
Для WordPress это особенно важно, потому что у сайта есть типовые служебные адреса, архивы, параметры и технические страницы. Часть из них действительно не нужна поисковикам, но часть закрывать нельзя, даже если они кажутся «лишними».
Что делает robots.txt и чего от него не стоит ждать
Файл robots.txt управляет обходом сайта роботами, а не индексацией как таковой. Это значит, что директива Disallow запрещает роботу заходить в указанный путь, но не гарантирует, что URL исчезнет из поиска. Если на страницу ведут внешние ссылки, она может попасть в индекс и без обхода содержимого.
Из этого следуют две практические вещи:
- robots.txt подходит для ограничения обхода служебных разделов и дублей;
- если нужно именно убрать страницу из индекса, обычно используют
noindexна уровне страницы или заголовков, а не robots.txt.
Для WordPress это важное различие. Ошибка многих владельцев сайтов в том, что они пытаются robots.txt решить задачу «не показывать в поиске», хотя этот файл для этого не предназначен.
Что обычно закрывают в WordPress
Ниже — безопасная базовая логика. Она не универсальна для каждого сайта, но подходит как отправная точка для большинства проектов на WordPress.
Служебные и технические разделы
Имеет смысл ограничивать обход тех URL, которые не несут пользы посетителю и не должны регулярно сканироваться роботами:
/wp-admin/— административная часть сайта;/wp-login.php— страница входа;/wp-json/— если вы точно понимаете, что API не нужен для обхода поисковиком в вашем сценарии; в обычной практике этот путь лучше не закрывать без причины, потому что он может использоваться темами, плагинами и фронтендом;- служебные параметры и внутренние результаты поиска, если они создают большое количество бесполезных URL.
При этом закрывать /wp-admin/ в robots.txt нужно аккуратно: сам по себе этот запрет не защищает админку от доступа, а лишь говорит роботам не обходить её. Для безопасности это не инструмент защиты, а только рекомендация для поисковиков.
Страницы внутреннего поиска и фильтры
Если на сайте есть внутренний поиск, его результаты часто создают тонны бесполезных URL. Для WordPress это типичная ситуация: страницы вида /?s=... редко нужны в индексе и часто засоряют обход.
Похожая история с фильтрами, сортировками и параметрами в URL. Если они порождают множество комбинаций, которые не должны отдельно обходиться, их можно ограничить. Но здесь важно не переборщить: если параметр используется для важных посадочных страниц или навигации, закрывать его нельзя без анализа.
Архивы, которые не дают ценности
На некоторых сайтах бесполезными оказываются архивы по датам, автору или тегам. Но это не автоматическое правило. Если архивы реально помогают пользователю и содержат уникальные подборки материалов, закрывать их только из-за «лишности» не стоит.
Правильный вопрос здесь не «есть ли архив», а «нужен ли он поисковику и пользователю». Если архив пустой, тонкий или дублирует другие страницы, его можно ограничить. Если он работает как полноценная навигационная сущность, лучше оставить его доступным.
Что не нужно закрывать в robots.txt
Есть несколько частых ошибок, которые потом сложно исправлять. Самая неприятная из них — закрыть то, что поисковик должен видеть для нормальной работы сайта.
/wp-content/uploads/— если там лежат изображения и файлы, которые должны находиться в поиске по картинкам или использоваться на страницах;- CSS и JavaScript-файлы темы и плагинов, если они нужны для корректного рендеринга страниц;
- основные разделы сайта: записи, страницы, рубрики, если они должны индексироваться;
- файлы и папки, без которых поисковик не сможет нормально отрисовать страницу.
Особенно осторожно нужно относиться к блокировке ресурсов темы. Если поисковый робот не может загрузить CSS и JS, он может хуже понимать структуру и внешний вид страницы. Это не всегда приводит к мгновенной проблеме, но для диагностики и качества обхода это плохой сценарий.
Базовый robots.txt для WordPress: рабочий минимум
Для большинства обычных сайтов можно начать с простого и понятного файла. Он не пытается закрыть всё подряд, а убирает только очевидно служебные пути.
Пример:
User-agent: * Disallow: /wp-admin/ Disallow: /wp-login.php Allow: /wp-admin/admin-ajax.php Sitemap: https://example.com/sitemap.xml
Что здесь важно:
User-agent: *— правило для всех роботов;Disallow: /wp-admin/— закрывает административный раздел от обхода;Disallow: /wp-login.php— убирает страницу входа;Allow: /wp-admin/admin-ajax.php— оставляет доступ к AJAX-эндпоинту, который часто нужен теме и плагинам;Sitemap:— помогает поисковику быстрее найти карту сайта.
Если у вас уже есть XML-карта сайта, укажите её реальный адрес. Обычно WordPress и SEO-плагины генерируют sitemap автоматически, но путь зависит от конкретной настройки сайта.
Как не сломать сайт при правке robots.txt
Самый безопасный способ — менять файл постепенно и проверять результат после каждого изменения. Если вы редактируете robots.txt вручную через FTP, файловый менеджер хостинга или панель управления, сначала сделайте копию текущей версии. Это не формальность: одна лишняя строка может закрыть слишком много.
Перед сохранением проверьте три вещи:
- нет ли случайного запрета на весь сайт через
Disallow: /; - не закрыты ли важные каталоги с CSS, JS и изображениями;
- не конфликтуют ли правила между собой, если в файле несколько блоков для разных роботов.
Если сайт использует кэширование на уровне плагина или сервера, после изменения robots.txt иногда нужно очистить кэш, чтобы поисковики и браузеры увидели обновлённую версию файла. Это зависит от хостинга и конфигурации, но на практике проверка без очистки кэша иногда вводит в заблуждение.
Как проверить, что robots.txt настроен правильно
Проверка должна быть не «на глаз», а по факту. Откройте файл по адресу https://ваш-домен/robots.txt и убедитесь, что он отдается без редиректов и ошибок. Далее проверьте, что в нём действительно есть только нужные директивы.
Полезно проверить несколько конкретных URL:
- адрес записи или страницы, которая должна индексироваться;
- адрес внутреннего поиска;
- адрес входа в админку;
- адрес CSS или JS-файла темы, если вы сомневаетесь, не закрыли ли его случайно.
Если используете инструменты для вебмастеров поисковых систем, там обычно можно проверить, разрешён ли обход конкретного URL. Это удобнее, чем гадать по самому файлу. Но даже без внешних сервисов достаточно открыть robots.txt и вручную пройтись по ключевым путям сайта.
Когда robots.txt лучше не трогать радикально
Есть ситуации, в которых агрессивная настройка приносит больше вреда, чем пользы. Например, если сайт маленький, структура простая и лишних URL почти нет, сложный robots.txt не нужен. В таком случае достаточно базового файла с закрытием админки и логина.
То же самое относится к сайтам, где вы не уверены, какие именно URL генерируют темы и плагины. Если закрыть слишком много, можно случайно ограничить обход страниц, которые реально участвуют в ранжировании. Исправлять это потом можно, но поисковику потребуется время, чтобы заново обойти сайт.
Если сомневаетесь, начинайте с минимальной конфигурации и добавляйте только те запреты, которые действительно решают конкретную проблему: лишний поиск, мусорные параметры, технические дубли. Такой подход безопаснее, чем пытаться заранее «запереть» весь сайт от роботов.
Итоговая логика простая: в robots.txt для WordPress закрывают служебные разделы и очевидный мусор, но не трогают то, что нужно для обхода и рендеринга сайта. Если правило нельзя объяснить конкретной задачей, скорее всего, его лучше не добавлять.