Как настроить robots.txt для WordPress: что закрывать, а что не трогать

robots.txt в WordPress нужен не для «скрытия» страниц от всех подряд, а для управления обходом сайта поисковыми роботами. Если настроить его без понимания, можно случайно закрыть важные разделы, а можно вообще ничего не улучшить — потому что часть страниц всё равно будет попадать в индекс по внешним ссылкам или из-за других сигналов.

Для WordPress это особенно актуально: у сайта есть служебные URL, архивы, страницы поиска, технические эндпоинты и папки плагинов. Не все из них нужно закрывать, и не всё, что кажется «лишним», стоит запрещать в robots.txt. Ниже — практичный разбор, что действительно имеет смысл ограничивать, а что лучше оставить как есть.

Что делает robots.txt и чего он не умеет

Файл robots.txt лежит в корне сайта и отвечает на вопрос: какие URL поисковым роботам можно или нельзя обходить. Это именно про crawl, а не про гарантированное исключение из индекса. Если страница уже известна поисковику, на неё ведут ссылки или она была проиндексирована раньше, запрет в robots.txt не всегда уберёт её из выдачи.

Отсюда главное правило: robots.txt используют для экономии краулингового бюджета и отсечения служебных разделов от обхода, но не как инструмент «спрятать страницу». Если нужно убрать URL из индекса, обычно используют другие механизмы: мета-тег robots с noindex, заголовок X-Robots-Tag или удаление страницы с корректным ответом сервера.

Какие разделы WordPress обычно имеет смысл закрывать

В стандартной установке WordPress есть несколько зон, которые поисковым роботам не нужны. Их можно ограничить, если они не несут ценности для поиска и не должны расходовать обход.

Служебные и внутренние URL

Чаще всего закрывают:

  • /wp-admin/ — административную часть сайта;
  • /wp-login.php — страницу входа;
  • /wp-json/ — если у вас есть осознанная причина ограничить обход REST API-эндпоинтов, но это не универсальная рекомендация;
  • внутренние страницы поиска, если они создают много мусорных URL и не нужны в выдаче.

Админка и страница входа и так не должны индексироваться, но запрет на обход здесь логичен. При этом не стоит ожидать, что robots.txt защитит их от доступа: это не механизм безопасности, а лишь подсказка роботам.

Архивы и страницы, которые часто плодят дубли

На WordPress нередко появляются архивы по датам, тегам, авторам, страницам пагинации и параметрам сортировки. Не все из них нужно закрывать, но если на сайте есть явные дубли или пустые архивы, robots.txt может помочь сократить обход.

Однако здесь важно не действовать вслепую. Например, архивы категорий часто полезны для SEO и пользователей, а вот внутренний поиск по сайту или технические параметры URL обычно не нужны в индексе и не должны активно обходиться.

Что лучше не закрывать в robots.txt

Самая частая ошибка — закрывать в robots.txt то, что нужно поиску для нормальной оценки сайта. Если робот не может обойти страницу, он не увидит её содержимое, внутренние ссылки и часть сигналов качества.

Не стоит без необходимости закрывать:

  • CSS и JavaScript-файлы темы и плагинов;
  • изображения, если они важны для поиска по картинкам или для корректного рендеринга страницы;
  • публичные страницы и записи, которые должны ранжироваться;
  • категории и теги, если они реально используются как посадочные страницы;
  • файлы, которые нужны для корректного отображения сайта в браузере и для рендеринга у поисковых систем.

Особенно опасно запрещать доступ к статическим ресурсам, если после этого поисковый робот не может нормально отрисовать страницу. Тогда он видит сайт хуже, чем пользователь, и это уже влияет не только на обход, но и на качество оценки страницы.

Базовый robots.txt для WordPress: безопасный старт

Если вы не уверены, с чего начать, лучше использовать минимально агрессивный вариант. Он закрывает только админскую часть и не мешает обходу публичных страниц.

Пример:

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

Такой файл обычно подходит для большинства сайтов. Строка Allow: /wp-admin/admin-ajax.php нужна потому, что этот файл часто используется фронтендом темы и плагинами. Если его закрыть без понимания последствий, можно сломать часть функциональности сайта для роботов и иногда для пользователей через скрипты.

Если у вас нет особой причины, не добавляйте в robots.txt длинный список запретов «на всякий случай». Чем больше правил, тем выше риск случайно закрыть нужный URL.

Как редактировать robots.txt в WordPress

В WordPress robots.txt можно настроить несколькими способами. Выбор зависит от того, как устроен хостинг и есть ли у вас доступ к файловой системе.

Через файл в корне сайта

Самый прямой способ — создать или изменить файл robots.txt в корневой директории сайта. Это предпочтительный вариант, если у вас есть доступ по FTP, SFTP или через файловый менеджер хостинга.

После сохранения файл должен открываться по адресу https://ваш-домен/robots.txt. Если вместо вашего содержимого вы видите что-то другое, значит, его может подменять сервер, CDN, плагин или сам WordPress в режиме виртуального robots.txt.

Через SEO-плагин

Многие SEO-плагины позволяют редактировать robots.txt из админки. Это удобно, если вы не хотите лезть в файлы, но важно помнить: не каждый плагин одинаково хорошо работает с реальным файлом на сервере. Иногда изменения сохраняются в интерфейсе, но фактически отдаются не так, как ожидается, если есть конфликт с серверной конфигурацией.

Если используете плагин, после сохранения обязательно проверьте итоговый файл по прямому URL.

Типовые ошибки, которые встречаются чаще всего

В robots.txt ошибки обычно связаны не с синтаксисом, а с логикой. Файл может быть формально корректным, но вредным для сайта.

  • Закрывают весь сайт. Например, добавляют Disallow: / и потом удивляются, почему страницы перестали обходиться.
  • Закрывают CSS и JS. После этого робот хуже рендерит страницы.
  • Путают robots.txt и noindex. Запрет на обход не равен запрету на индексацию.
  • Копируют чужой файл без проверки. У другого сайта может быть другая структура URL, другие плагины и другие задачи.
  • Добавляют слишком много правил для параметров. В итоге можно случайно заблокировать полезные страницы с фильтрами, сортировкой или пагинацией.

Ещё одна практическая ошибка — ожидать мгновенного эффекта. Поисковики обновляют данные не сразу, и изменения в robots.txt могут проявиться с задержкой. Если URL уже в индексе, одного robots.txt обычно недостаточно.

Как проверить, что настройка работает

После правки robots.txt проверьте три вещи: файл доступен по прямому адресу, в нём нет лишних запретов и он не блокирует важные ресурсы.

Минимальная проверка выглядит так:

  1. Откройте /robots.txt в браузере и убедитесь, что видите именно свой файл.
  2. Проверьте, что публичные страницы не закрыты случайно.
  3. Посмотрите, не заблокированы ли CSS и JS, если они нужны для рендеринга.
  4. Если у вас есть доступ к инструментам для вебмастеров, проверьте, как поисковая система видит файл и нет ли ошибок обхода.

Если после изменения robots.txt важные страницы перестали обходиться, откатите правки сразу. Это одна из тех настроек, где лучше сначала сделать минимальный безопасный вариант, а потом уже добавлять точечные правила по необходимости.

Когда robots.txt не решает задачу

Если цель — убрать страницу из индекса, robots.txt сам по себе не всегда подходит. Он не удаляет уже известные URL и не гарантирует, что поисковик не покажет их в выдаче. Для этого нужен другой подход: закрыть страницу от индексации, отдать корректный статус или удалить её с сайта.

Поэтому robots.txt стоит использовать там, где нужно управлять обходом, а не подменять им все остальные SEO-задачи. Для WordPress это особенно важно: технических URL много, но далеко не каждый из них надо запрещать. Безопасная стратегия простая — закрывать только то, что действительно служебное, и не трогать публичные страницы, которые должны участвовать в поиске.

Если у вас уже есть хаотично настроенный robots.txt, начните с минимального набора правил, уберите лишние запреты и проверьте, не пострадал ли обход важных разделов. В большинстве случаев этого достаточно, чтобы навести порядок без риска для сайта.

Как создать мультиязычный сайт на WordPress без плагинов
30.09.2026
Как закрыть страницы вложений изображений в WordPress от индексации
13.10.2026
Как отключить XML-RPC в WordPress через .htaccess и PHP без плагинов
23.09.2026
Как убрать тонкий контент в WordPress: что делать с пустыми и малоценными страницами
16.10.2026
Как настроить robots.txt для WordPress: что закрывать, а что не трогать
19.10.2026