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

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

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

Что должен делать robots.txt на WordPress

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

Для WordPress обычно имеет смысл ограничить:

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

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

Базовый robots.txt для WordPress

Для обычного сайта на WordPress можно начать с такого варианта:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml

Здесь есть только то, что действительно полезно в большинстве случаев.

• User-agent: * — правило для всех роботов.
• Disallow: /wp-admin/ — закрывает административный раздел от обхода.
• Allow: /wp-admin/admin-ajax.php — оставляет доступ к AJAX-обработчику, который часто нужен теме и плагинам на публичной части сайта.
• Sitemap: — указывает адрес карты сайта, если она у вас есть.

Адрес карты сайта нужно подставить свой. В WordPress он зависит от того, чем вы его генерируете. Если используете встроенную карту сайта WordPress, адрес обычно выглядит как https://example.com/wp-sitemap.xml. Если карта создается SEO-плагином, путь может быть другим.

Какие директории обычно закрывают, а какие нет

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

Обычно можно закрывать только то, что действительно служебное и не должно обходиться поисковиками:

• /wp-admin/ — стандартный административный раздел;
• /cgi-bin/ — если такой каталог вообще есть на хостинге и не используется для публичного контента;
• временные или технические каталоги, которые созданы конкретным плагином и не должны индексироваться.

А вот такие пути закрывать без понимания последствий не стоит:

• /wp-content/ целиком — внутри часто лежат изображения, стили и скрипты, которые нужны для корректного обхода;
• /wp-includes/ целиком — это системные файлы WordPress, но запрет всего каталога может мешать роботам разбирать ресурсы темы и плагинов;
• публичные разделы сайта, если они должны попадать в поиск.

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

Как добавить карту сайта в robots.txt

Карта сайта в robots.txt не обязательна, но это полезная практика. Роботам проще найти актуальный sitemap, если его адрес указан явно. Главное — не писать выдуманный путь и не оставлять старую ссылку после смены SEO-плагина.

Если у вас одна карта сайта, достаточно одной строки Sitemap:. Если карт несколько, можно перечислить все актуальные адреса. Это допустимо и для WordPress, и для большинства поисковых роботов.

Проверьте, что адрес карты сайта открывается в браузере и отдает XML, а не 404 или редирект на несуществующую страницу. Если sitemap генерируется плагином, после его отключения или смены может измениться и адрес карты, и тогда robots.txt нужно обновить вручную.

Как создать или изменить robots.txt в WordPress

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

Через корень сайта по FTP или файловому менеджеру

Если у вас есть доступ к файлам сайта, самый надежный способ — создать или отредактировать файл robots.txt в корне установки WordPress, рядом с wp-config.php и папками wp-admin, wp-content, wp-includes.

Перед изменением сделайте копию текущего файла, если он уже есть. Это простая мера, но она спасает, если после правки сайт начнет отдавать не тот robots.txt или вы случайно удалите нужную директиву.

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

Через SEO-плагин или настройки темы

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

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

Частые ошибки, которые мешают индексации

У robots.txt есть несколько типичных проблем, которые встречаются чаще остальных.

• Закрывают весь сайт. Строка вроде Disallow: / для всех роботов полностью запрещает обход сайта. Это допустимо только на тестовом стенде, но не на рабочем проекте.
• Запрещают слишком широкий каталог. Например, Disallow: /wp-content/ может задеть изображения и ресурсы темы.
• Путают robots.txt и noindex. Запрет в robots.txt не равен удалению страницы из индекса. Если URL уже известен поисковику, он может оставаться в выдаче без содержимого.
• Оставляют старый sitemap. После смены плагина карта сайта меняется, а в robots.txt остается прежний адрес.
• Пишут правила с ошибками в путях. Лишний слэш, неверный регистр или опечатка делают директиву бесполезной.

Еще одна практическая проблема — конфликт между robots.txt и внутренними ссылками сайта. Если страница закрыта от обхода, но на нее активно ведут ссылки, поисковик может видеть URL, но не понимать содержимое. В результате получается неочевидная и часто бесполезная для SEO ситуация.

Как проверить, что robots.txt настроен правильно

После правки не стоит полагаться только на то, что файл «сохранился». Нужно проверить три вещи: доступность файла, корректность правил и наличие карты сайта.

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

1. Откройте https://ваш-домен/robots.txt в браузере.
2. Убедитесь, что файл отдается без ошибки 404 или редиректа на другую страницу.
3. Проверьте, что в нем нет лишних запретов на публичные разделы.
4. Откройте указанный sitemap и убедитесь, что он существует.

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

Когда robots.txt лучше не усложнять

Для большинства WordPress-сайтов достаточно короткого файла с запретом /wp-admin/ и ссылкой на sitemap. Не стоит добавлять десятки правил «на всякий случай». Чем длиннее и сложнее robots.txt, тем выше шанс ошибиться и перекрыть нужный раздел.

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

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