Как закрыть лишние URL в robots.txt и не сломать XML-карту сайта WordPress

Автор: Вера Тихонова | Опубликовано: 12.09.2026

Ситуация типичная: сайт уже работает, карта сайта есть, но в Search Console всплывают служебные адреса, параметры, страницы поиска, архивы или внутренние endpoint’ы. Рука тянется просто добавить всё в robots.txt, но именно здесь чаще всего и ломают индексацию: закрывают не то, дублируют правила плагина или случайно мешают обходу страниц, которые должны оставаться в выдаче.

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

Когда проблема действительно в robots.txt

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

Признаки, что нужен именно robots.txt

в индекс попадают технические URL, которые не должны обходиться вообще;
поисковик активно тратит crawl budget на служебные разделы;
в логах видно много запросов к /wp-json/, /search/, параметрам сортировки или внутренним страницам предпросмотра;
XML-карта сайта корректна, но рядом есть мусорные URL, которые туда не должны попадать.

Когда robots.txt не поможет

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

Диагностика: что именно индексируется лишнего

Перед правкой откройте Search Console и посмотрите разделы с проблемными URL. Полезно сверить их с тем, что реально генерирует сайт:

архивы тегов и авторов;
страницы поиска вида ?s=;
параметры сортировки и фильтров;
/wp-json/ и другие REST-эндпоинты;
/feed/, если фиды не нужны в поиске;
служебные страницы плагинов и предпросмотры.

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

Как правильно закрывать лишние URL

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

Способ	Когда подходит	Минус
SEO-плагин	если правила редактирует контент-менеджер	зависимость от интерфейса плагина
Код через фильтр	если нужен контроль в теме или мини-плагине	нужно следить за обновлениями и деплоем
Физический robots.txt	для простых статичных правил	легко перетереть при миграции или настройке CDN

Вариант 1: добавить правила через фильтр WordPress

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

<?php
add_filter('robots_txt', function ($output, $public) {
    $rules = [];

    // Блокируем служебный поиск и параметры.
    $rules[] = 'Disallow: /?s=';
    $rules[] = 'Disallow: /search/';

    // REST API и фиды — только если они действительно не нужны в поиске.
    $rules[] = 'Disallow: /wp-json/';
    $rules[] = 'Disallow: /feed/';

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

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

Вариант 2: физический robots.txt

Если сайт простой и правила не меняются, достаточно файла в корне. Пример аккуратного набора без лишней агрессии:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-json/
Disallow: /search/
Disallow: /*?s=
Disallow: /feed/

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

Обратите внимание на строку Allow: /wp-admin/admin-ajax.php. Её часто забывают, а потом ломают фронтенд-скрипты и AJAX-запросы, если внешний бот или сервис пытается следовать robots-ограничениям буквально.

Вариант 3: не закрывать, а убрать источник дублей

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

Пошаговая настройка без поломки sitemap

Определите список URL, которые не должны обходиться. Не добавляйте всё подряд.
Проверьте, не отдает ли SEO-плагин свой robots.txt или sitemap.
Сначала внесите одно-два правила и протестируйте ответ сервера.
Убедитесь, что XML-карта сайта по-прежнему доступна по своему адресу.
Проверьте, что важные страницы не попали под слишком широкий шаблон вроде Disallow: /*?.
После публикации отправьте sitemap на повторную проверку в Search Console.

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

Проверка должна быть не на глаз, а по факту ответа сервера и поведению поисковика.

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

откройте /robots.txt в браузере и убедитесь, что там именно те правила, которые вы ожидали;
проверьте, что sitemap_index.xml или другой адрес карты сайта доступен без редиректов и 404;
в Search Console используйте проверку URL для нескольких проблемных адресов;
посмотрите, исчезли ли новые обходы служебных URL в логах сервера;
убедитесь, что важные страницы не стали выпадать из обхода вместе с мусором.

Быстрая проверка через curl

curl -I https://example.com/robots.txt
curl -I https://example.com/sitemap_index.xml
curl -I https://example.com/wp-json/

Если robots.txt отдается с кодом 200, а sitemap — без ошибок, базовая часть настроена правильно. Дальше смотрите уже не на файл, а на статистику обхода и статус проблемных URL в Search Console.

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

Закрывают страницу, которую нужно удалить

Если URL уже в индексе, Disallow не решает задачу удаления. Для удаления используйте noindex, редирект на релевантную страницу или 410, если страница больше не нужна вообще.

Ставят слишком широкое правило

Правило вроде Disallow: /?* или Disallow: /*? может задеть полезные страницы с параметрами, которые реально нужны. Сначала проверьте, какие параметры используются на сайте, и только потом закрывайте конкретные шаблоны.

Редактируют не тот robots.txt

На WordPress часто работает виртуальный robots через плагин или кэш/CDN. Если правите файл на сервере, а в браузере видите другое содержимое, ищите источник генерации в SEO-плагине и настройках прокси.

Путают robots.txt и noindex

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

Практические советы по безопасности и производительности

Не закрывайте в robots.txt всё подряд ради «чистоты». Иногда это ухудшает диагностику: поисковик перестает видеть полезные сигналы, а вы теряете контроль над тем, что реально происходит на сайте.

держите правила минимальными и понятными;
не блокируйте CSS и JS без необходимости;
не закрывайте admin-ajax.php полностью, если фронтенд его использует;
если у сайта много дублей, лучше сначала убрать источник генерации, а не наращивать список запретов;
после изменений проверьте кэш страницы и CDN, если они есть.

Если вам нужно регулярно чистить сайт от дублей, служебных URL и лишних архивов, удобнее вынести это в отдельный набор настроек или плагин, а не держать правила в нескольких местах. В таких задачах часто помогает Clearfy Pro от WPShop, если нужен именно набор для SEO-гигиены и удаления дублей: https://wpshop.ru/plugins/clearfy.

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