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

Автор: Кирилл Карпов | Опубликовано: 06.09.2026

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

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

Когда robots.txt действительно нужен

Файл полезен не для «запрета индексации вообще», а для ограничения обхода. Это разные вещи. Если страница уже попала в индекс, robots.txt сам по себе не уберёт её из выдачи. Для этого нужен noindex, canonical или удаление страницы с корректным статусом ответа.

В WordPress robots.txt обычно настраивают, когда нужно:

закрыть служебные URL вроде /wp-admin/ и /wp-includes/;
снизить обход архивов, которые не несут ценности;
не пускать роботов в технические каталоги или временные файлы;
убрать из обхода параметры и внутренние поисковые страницы, если они создают мусор.

Диагностика: что сейчас отдается и где проблема

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

Что смотреть в первую очередь

Откройте /robots.txt в браузере и проверьте содержимое.
Убедитесь, что сайт не отдает 404 на этот адрес.
Посмотрите, нет ли там правил, которые закрывают важные разделы: CSS, JS, изображения, публичные рубрики.
Проверьте, не дублируется ли robots.txt физическим файлом и настройками плагина SEO — иногда они конфликтуют.

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

Что обычно закрывают в WordPress

Ниже не универсальный шаблон, а базовая логика. Закрывать стоит только то, что не должно расходовать crawl budget и не несет пользы в поиске.

Раздел	Обычно закрывают?	Комментарий
`/wp-admin/`	Да	Админка не нужна в обходе, но не путайте с доступом для авторизованных пользователей.
`/wp-includes/`	Чаще да	Служебные файлы не должны индексироваться как контент.
`/wp-content/plugins/`	Обычно да	Если там нет публичных файлов, которые вы хотите показывать в поиске.
Медиафайлы	Обычно нет	Изображения и PDF часто полезны в поиске.
Архивы тегов/авторов	Зависит	Если они пустые или дублируют контент, лучше решать через `noindex`, а не robots.txt.

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

Пошаговое решение без плагина

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

Шаг 1. Создайте файл в корне

В корне WordPress рядом с wp-config.php создайте robots.txt. Пример базового файла:

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

Sitemap: https://example.com/sitemap.xml

Замените домен и путь к карте сайта на свой. Если sitemap генерируется плагином или ядром, укажите именно реальный URL.

Шаг 2. Не закрывайте лишнее

Не стоит бездумно запрещать /wp-content/uploads/. Для большинства сайтов это ошибка: поисковики должны видеть изображения, если они участвуют в трафике. Если есть отдельные приватные файлы, их лучше хранить вне публичного каталога или закрывать на уровне сервера.

Шаг 3. Если нужен динамический robots.txt

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

<?php
add_filter( 'robots_txt', function( $output, $public ) {
    $lines = array(
        'User-agent: *',
        'Disallow: /wp-admin/',
        'Disallow: /wp-includes/',
        'Allow: /wp-admin/admin-ajax.php',
        'Sitemap: ' . home_url( '/sitemap.xml' ),
    );

    return implode( "\n", $lines ) . "\n";
}, 10, 2 );

Этот вариант подходит, если вы добавляете правила из темы или небольшого mu-plugin. Но если у вас уже есть SEO-плагин, проверьте, не перезаписывает ли он вывод.

Как понять, что настройка сработала

Проверка нужна не только на уровне браузера. Важно убедиться, что файл отдается корректно и не блокирует нужные разделы.

Откройте https://ваш-домен/robots.txt и убедитесь, что видите актуальный текст.
Проверьте HTTP-статус: должен быть 200 OK, а не 404 или редирект на HTML-страницу.
Посмотрите исходный файл на наличие опечаток в директивах User-agent, Disallow, Allow.
Проверьте, что sitemap указан корректно и открывается в браузере.
Если используете Google Search Console, отправьте robots.txt на повторную проверку через инструменты тестирования URL, если они доступны в вашем аккаунте.

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

Частые ошибки и как их исправить

Закрыли страницы от обхода, но они остались в индексе

Это ожидаемо. Robots.txt не удаляет URL из индекса. Если нужно убрать страницу из выдачи, используйте noindex на самой странице или отдайте корректный 404/410, если контент удалён окончательно.

Запретили слишком много и сломали рендеринг

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

Оставили конфликт с SEO-плагином

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

Использовали robots.txt для приватности

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

Практический чек-лист перед публикацией

robots.txt открывается по прямому URL и отдает 200 OK;
в файле нет запрета на публичные CSS, JS и изображения;
админка и служебные каталоги закрыты;
ссылка на sitemap актуальна;
нет дублирующих правил из плагина и физического файла;
страницы, которые нужно убрать из индекса, закрываются не robots.txt, а noindex или удалением.

Безопасность и производительность

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

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

Если вы хотите держать техническую часть сайта в порядке, удобно совмещать ручную настройку robots.txt с инструментами очистки дублей и служебных страниц. Например, в Clearfy Pro есть функции, которые помогают убрать часть технического шума и не держать это в голове вручную: https://wpshop.ru/plugins/clearfy.

Когда лучше не трогать robots.txt вручную

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

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