Если вы хотите управлять обходом сайта поисковыми роботами, robots.txt в WordPress — это не место для экспериментов. Этот файл не ускоряет индексацию сам по себе и не «прячет» страницы от поиска гарантированно, но помогает подсказать роботам, куда ходить не нужно. Ошибка здесь обычно одна: закрывают слишком много, а потом удивляются, почему поисковики хуже обходят сайт или не видят важные разделы.
Для WordPress рабочая схема простая: в robots.txt имеет смысл ограничить технические и служебные URL, а всё, что может быть полезно поиску, лучше не трогать. Ниже — практический вариант настройки, который подходит большинству обычных сайтов на WordPress.
Что robots.txt делает в WordPress на самом деле
Файл robots.txt лежит в корне сайта и читается роботами до обхода страниц. Он задаёт правила для конкретных user-agent, чаще всего для всех сразу через директиву User-agent: *. Самая полезная директива — Disallow: она говорит роботу не заходить в указанный путь.
Важно понимать ограничение: robots.txt не удаляет URL из индекса, если они уже известны поисковику. Если страница уже попала в поиск, закрытие её в robots.txt не всегда решит задачу. Для удаления из индекса нужны другие механизмы: корректный статус ответа, мета-тег robots или настройка самого контента. Но для управления обходом robots.txt остаётся полезным инструментом.
Что обычно закрывают в WordPress
В WordPress есть несколько типов URL, которые поисковым роботам обычно не нужны. Их и закрывают в первую очередь.
/wp-admin/— административная часть сайта./wp-login.php— страница входа./wp-includes/— служебные файлы ядра./cgi-bin/— если такой каталог есть на хостинге и он не нужен сайту.
Для большинства сайтов этого уже достаточно. Если у вас есть отдельные технические каталоги, тестовые папки или служебные поддомены, их тоже можно закрыть, но только если вы точно понимаете, что они не должны попадать в обход.
Ещё один частый случай — параметры поиска по сайту. В WordPress внутренняя строка поиска обычно выглядит как URL с параметром ?s=. Такие страницы часто создают много мусорных результатов, но закрывать их через robots.txt не всегда лучший ход. Если поисковая выдача по сайту не нужна, лучше решить вопрос на уровне шаблона, мета-тегов или логики генерации страниц, а не просто запрещать обход.
Что не стоит закрывать без причины
Самая распространённая ошибка — закрыть в robots.txt то, что поисковик должен видеть. В WordPress к таким разделам обычно относятся:
- публичные записи и страницы;
- категории и рубрики, если они нужны в поиске;
- теги, если вы реально используете их как полезные архивы;
- медиафайлы, если изображения должны находиться в поиске;
- CSS и JS-файлы, которые нужны для рендеринга страницы.
Особенно осторожно нужно быть с папками темы и плагинов. Если закрыть доступ к стилям или скриптам, поисковый робот может хуже отрисовать страницу и неверно оценить её содержимое. Для современных поисковых систем это уже не мелочь.
Не стоит добавлять в robots.txt директивы «на всякий случай» для всего подряд. Если вы не понимаете, зачем закрываете путь, лучше не закрывать его вообще. В WordPress часто достаточно убрать лишние архивы из индекса другими способами, а не запрещать обход целых директорий.
Практический шаблон robots.txt для обычного сайта
Ниже — базовый вариант, с которого можно начать. Он не универсален для всех проектов, но подходит для большинства стандартных сайтов на WordPress без сложной архитектуры.
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /wp-includes/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap.xmlЗдесь есть несколько важных моментов. Disallow: /wp-admin/ закрывает админку, но строка Allow: /wp-admin/admin-ajax.php оставляет доступ к AJAX-обработчику, который нужен многим темам и плагинам. Если его закрыть, часть фронтенд-функций может работать нестабильно.
Строку с картой сайта указывают только если у вас она реально есть и доступна по этому адресу. В WordPress sitemap часто генерируется ядром и открывается по адресу вида /wp-sitemap.xml, но на некоторых сайтах используется карта от SEO-плагина. Указывайте именно тот URL, который у вас фактически работает.
Как настроить robots.txt в WordPress: два рабочих способа
В WordPress robots.txt можно настроить двумя основными способами: через виртуальный файл, который отдаёт сам WordPress, или через реальный файл в корне сайта. На практике чаще удобнее второй вариант, если хостинг позволяет редактировать файлы сайта.
| Способ | Когда подходит | Что учесть |
|---|---|---|
| Редактирование файла в корне сайта | Есть доступ к файловому менеджеру или FTP/SFTP | Нужно следить, чтобы файл назывался именно robots.txt и лежал в корне домена |
| Виртуальный robots.txt WordPress | Файла в корне нет, а сайт отдаёт стандартный вариант | Удобно для базовой настройки, но не всегда подходит, если нужен полный контроль |
Если вы редактируете файл вручную, делайте это осторожно. Перед изменениями лучше сохранить текущую версию. Одна лишняя строка может закрыть важный раздел или, наоборот, открыть лишнее.
Если на сайте уже есть SEO-плагин, проверьте, не управляет ли он robots.txt сам. Некоторые плагины позволяют редактировать его из админки. В таком случае не стоит одновременно менять и файл на сервере, и настройки плагина: потом сложно понять, какая версия реально отдаётся поисковикам.
Как проверить, что robots.txt работает правильно
После правки откройте файл в браузере по адресу https://ваш-домен/robots.txt. Если вы видите нужные директивы, значит файл доступен. Но этого мало: важно проверить, что он не конфликтует с остальной конфигурацией сайта.
Проверьте три вещи:
- открывается ли сам файл без редиректов и ошибок;
- нет ли в нём случайного запрета на важные публичные разделы;
- указана ли корректная карта сайта, если она нужна.
Если у вас есть доступ к инструментам для вебмастеров поисковых систем, там обычно можно проверить, как робот видит robots.txt и не блокирует ли он нужные URL. Это особенно полезно после переноса сайта, смены темы или установки нового SEO-плагина.
Типичные ошибки, которые потом приходится исправлять
На практике чаще всего встречаются не сложные технические проблемы, а простые ошибки в содержимом файла.
- Закрывают весь сайт одной строкой вроде
Disallow: /и потом забывают убрать её. - Добавляют несколько противоречивых правил для одного и того же пути.
- Закрывают папки темы или плагинов, после чего ломается рендеринг страниц.
- Указывают несуществующую карту сайта.
- Путают robots.txt и мета-тег robots, ожидая, что файл удалит страницы из индекса.
Ещё одна частая ситуация — старый robots.txt остаётся после смены структуры сайта. Например, раньше были закрыты каталоги, которые теперь уже не используются, а новые служебные пути никто не добавил. После крупных изменений в WordPress файл стоит пересмотреть заново, а не оставлять его «как было» годами.
Когда robots.txt лучше не трогать вручную
Если сайт маленький, структура простая и у вас нет технических разделов, которые нужно скрывать от обхода, минимальный robots.txt может быть даже лучше сложного. Чем меньше правил, тем ниже шанс ошибиться.
Не стоит вносить правки, если вы не понимаете, зачем нужен конкретный запрет. Для WordPress это особенно актуально: многие проблемы с обходом появляются не из-за отсутствия robots.txt, а из-за слишком агрессивной настройки. В таких случаях лучше оставить только базовые правила для админки и служебных файлов, а остальное решать точечно.
Если вам нужно не просто закрыть технические разделы, а аккуратно убрать дубли, служебные страницы и лишние архивы из SEO-настроек сайта, иногда удобнее делать это через специализированные инструменты. Например, в Clearfy Pro есть функции для чистки WordPress и управления SEO-дублями, но использовать такие решения имеет смысл только тогда, когда они реально закрывают вашу задачу, а не вместо понимания самого robots.txt.
В итоге рабочая схема для WordPress выглядит так: закрыть админку и служебные пути, не трогать публичные страницы без причины, не блокировать ресурсы темы и плагинов, а после правки обязательно проверить файл в браузере и в инструментах для вебмастеров. Для большинства сайтов этого достаточно, чтобы управлять обходом без лишнего риска.