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

Если в Search Console всплывают служебные URL, а в логах и сканерах постоянно светятся /wp-admin/, /wp-login.php, /wp-json/, страницы вложений и служебные параметры, проблема часто не в «плохой индексации», а в том, что robots.txt либо отсутствует, либо написан слишком агрессивно. В WordPress это особенно заметно на сайтах с плагинами, которые добавляют свои эндпоинты, и на проектах, где кто-то однажды скопировал чужой robots.txt без понимания последствий.

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

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

Типичные кандидаты на закрытие:

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

Но есть и то, что закрывать опасно: CSS, JS, изображения темы, /wp-content/uploads/ целиком, если сайт зависит от медиа в выдаче, а также публичные страницы, которые должны индексироваться. Если поисковик не сможет нормально отрендерить страницу, вы сами создадите проблемы с видимостью.

Диагностика: что именно сейчас мешает индексации

Прежде чем править robots.txt, проверьте, какие URL реально попадают в обход. Для этого не нужен сложный стек: достаточно Search Console, краулера вроде Screaming Frog и обычного просмотра текущего файла robots.txt.

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

• Есть ли в корне сайта файл /robots.txt и кто его генерирует: WordPress, плагин или сервер.
• Не закрыты ли случайно /wp-content/uploads/, /wp-includes/ или папка темы.
• Нет ли в файле директив Disallow: / или слишком широких масок.
• Не конфликтует ли robots.txt с noindex, canonical и редиректами.
• Не пытается ли сайт закрыть URL, которые уже давно не существуют и отдают 404 — в таком случае robots.txt не решает проблему.

Признаки ошибки в настройке

Если в отчётах Search Console растёт число «Просканировано, но не проиндексировано», а в robots.txt есть только общие запреты без логики, это обычно означает, что файл не помогает. Если же после правки резко падает рендеринг страниц в тесте URL Inspection, значит, вы перекрыли нужные ресурсы или слишком широко запретили каталоги.

Какой подход выбрать: плагин, код или ручная правка

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

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

Пошаговая настройка robots.txt в WordPress

Ниже — безопасный базовый вариант. Он не закрывает ничего лишнего и подходит как отправная точка для большинства обычных сайтов.

1. Создайте или проверьте текущий файл

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

Базовый пример:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Disallow: /search/
Disallow: /?s=
Sitemap: https://example.com/sitemap_index.xml

Здесь admin-ajax.php оставлен открытым, потому что его часто используют фронтенд-скрипты и плагины. Закрывать его целиком — частая ошибка.

2. Добавьте только те правила, которые реально нужны

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

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

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

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

<?php
add_filter( 'robots_txt', function( $output, $public ) {
    $output .= "\nDisallow: /wp-login.php";
    $output .= "\nDisallow: /search/";
    $output .= "\nDisallow: /?s=";
    $output .= "\nAllow: /wp-admin/admin-ajax.php";

    return $output;
}, 10, 2 );

Такой код лучше размещать в мини-плагине или в functions.php дочерней темы. В родительской теме он потеряется при обновлении.

4. Не путайте robots.txt и noindex

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

Проверка результата после внедрения

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

• Откройте https://ваш-домен/robots.txt и убедитесь, что файл отдаёт актуальные правила.
• Проверьте в Search Console инструмент проверки robots.txt, если он доступен в вашем аккаунте.
• Запустите краулер по сайту и посмотрите, не исчезли ли CSS/JS из обхода.
• Откройте несколько важных страниц в режиме инкогнито и проверьте, что они рендерятся без ошибок.
• Сравните отчёты по сканированию через несколько дней: мусорные URL должны встречаться реже, а не исчезнуть «магически» за час.

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

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

Закрыли слишком много

Самая частая проблема — запретить целый каталог, в котором лежат нужные файлы. Например, Disallow: /wp-content/ ломает доступ к изображениям, стилям и скриптам. Исправление простое: уберите широкий запрет и оставьте только точечные правила.

Ожидали, что robots.txt удалит страницы из индекса

Robots.txt не удаляет уже известные URL. Если страница должна исчезнуть из поиска, нужен noindex, 404/410 или редирект на релевантную страницу. Закрытие в robots.txt — это про обход, а не про деиндексацию.

Правили не тот файл

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

Закрыли admin-ajax.php

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

Добавили правила без sitemap

Файл robots.txt без ссылки на sitemap не критичен, но это лишает поисковик удобной подсказки. Если у сайта есть XML-карта, укажите её явно и проверьте, что URL карты действительно открывается.

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

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

Для производительности полезнее не «запретить всё подряд», а убрать из обхода только мусорные URL, которые создают лишние запросы. Это особенно актуально на больших сайтах с фильтрами, поиском и большим количеством архивов. Если у вас уже есть плагин для технической чистки, например Clearfy Pro, он может помочь централизовать часть настроек, но финальную проверку всё равно нужно делать руками.

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

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