Если в отчётах поисковиков всплывают странные URL вроде /xmlrpc.php, /wp-login.php, архивы автора без контента или внутренний поиск, проблема обычно не в «плохом SEO», а в том, что сайт отдаёт роботам лишние точки входа. Эти страницы не должны конкурировать с нормальными материалами и часто только засоряют индекс.
Ниже — рабочая схема: что именно закрывать, чем это делать и как проверить, что вы не перестарались. Для WordPress это особенно важно, если сайт давно живёт, на нём менялись темы, ставились плагины и остались старые служебные URL.
Какие страницы и запросы стоит проверить в первую очередь
Не все служебные URL одинаково вредны. Одни нужно закрывать от индексации, другие — отдавать с 403 или 404, а третьи вообще не стоит трогать, если ими пользуются плагины или внешние сервисы.
Типичные кандидаты на закрытие
/xmlrpc.php— если вы не используете удалённую публикацию, мобильные клиенты старого типа или интеграции, которым нужен XML-RPC./wp-login.php— страницу входа обычно не индексируют, но полностью блокировать её от роботов через robots.txt не всегда полезно.- Внутренний поиск вида
/?s=...— почти всегда даёт мусорные дубли. - Архивы автора на сайте с одним автором — часто дублируют ленту записей.
- Пагинация архивов, если она создаёт много слабых страниц без ценности.
Диагностика: как понять, что именно попало в индекс
Сначала не меняйте настройки наугад. Посмотрите, какие URL уже индексируются и откуда они взялись. Для этого достаточно трёх проверок: отчёт в панели вебмастера, поиск по сайту через оператор site: и просмотр логов сервера, если они доступны.
Если в индексе есть xmlrpc.php или страницы поиска, это обычно означает одно из двух: либо поисковик увидел ссылку на них, либо они не были явно закрыты и робот решил проверить их сам. Для WordPress это частая история после установки SEO-плагина без ручной настройки.
Что смотреть в логах и в Search Console
- Запросы к
/xmlrpc.phpс частыми повторениями. - Страницы вида
/?s=с параметрами поиска. - Архивы
/author/, если на сайте один автор. - Страницы пагинации архивов, которые не несут самостоятельной ценности.
Пошаговое решение: закрываем лишнее без лишнего риска
Лучший подход — разделить задачи. Одни URL нужно убрать из индекса через noindex, другие — ограничить в robots.txt, а третьи — вообще отключить на уровне сервера или WordPress.
1. Закройте внутренний поиск и архивы автора от индексации
Если у вас есть SEO-плагин, используйте его настройки. Но если нужен кодовый вариант, можно добавить noindex для поисковых страниц и архивов автора через фильтр wp_robots. Это штатный механизм WordPress, он не ломает шаблоны и работает на уровне мета-роботов.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() || is_author() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Такой вариант удобен, если вы не хотите зависеть от конкретного SEO-плагина. Но если архивы автора у вас реально полезны, не закрывайте их автоматически: сначала проверьте, есть ли на них трафик и входящие ссылки.
2. Ограничьте XML-RPC на уровне сервера или WordPress
Если XML-RPC не нужен, его лучше не просто скрывать от индексации, а отключить. Для поисковиков это не «контентная» страница, а технический endpoint. В индексе ему делать нечего.
В WordPress можно вернуть 403 на запросы к xmlrpc.php через xmlrpc_enabled. Это безопаснее, чем пытаться играться только с robots.txt.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если вам нужно именно заблокировать индексирование, а не функциональность, можно дополнительно закрыть URL в robots.txt. Но помните: robots.txt не удаляет уже проиндексированный адрес, он только ограничивает обход.
User-agent: *
Disallow: /xmlrpc.php
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/Для wp-login.php я бы не делал жёсткий запрет без понимания, как у вас настроена авторизация и есть ли внешние сервисы, которые проверяют доступность страницы входа. Обычно достаточно не давать ей индексироваться, а не прятать её полностью.
3. Уберите дубли от пагинации и архивов, если они реально пустые
Пагинация сама по себе не проблема. Проблема начинается, когда на страницах 2, 3, 4 и дальше почти нет уникального контента, а поисковик тратит краулинговый бюджет на мусор. В таком случае можно оставить ссылки для пользователей, но закрыть эти страницы от индексации.
Если используете SEO-плагин, проверьте, не ставит ли он уже noindex на архивы и пагинацию. Дублировать правила вручную не нужно: можно получить конфликт мета-тегов.
Сравнение подходов: плагин, код или сервер
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Нужно быстро закрыть архивы, поиск и служебные URL без кода | Легко получить дубли настроек и забыть, что именно включено |
| Код в теме или mu-plugin | Нужен точечный контроль без лишних зависимостей | Требует аккуратного тестирования после обновлений |
| Серверная блокировка | Нужно жёстко отрезать endpoint, например xmlrpc.php | Можно сломать интеграции, если не проверить зависимости |
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой страницы. Нужно убедиться, что поисковик видит именно тот сигнал, который вы задали.
- Откройте страницу поиска или архив автора и проверьте исходный код на наличие
<meta name="robots" content="noindex,follow">или эквивалентного заголовка. - Проверьте
/xmlrpc.php: если вы отключали XML-RPC, запрос должен возвращать отказ в доступе или пустой ответ в зависимости от реализации. - Посмотрите, не осталось ли в
robots.txtконфликтующих правил. - В панели вебмастера отправьте URL на повторную проверку и убедитесь, что статус меняется не только в кэше браузера.
Для быстрой проверки заголовков удобно использовать curl:
curl -I https://example.com/xmlrpc.php
curl -I https://example.com/?s=testЕсли на поисковой странице вы видите X-Robots-Tag: noindex или мета-робот с noindex, значит сигнал доходит. Если страница всё ещё индексируется, проверьте кэш плагина, CDN и серверный кэш — иногда они отдают старую версию HTML.
Частые ошибки и как их исправить
Закрыли в robots.txt, но URL остался в индексе
Это нормальная ситуация. Robots.txt не удаляет уже известные страницы. Чтобы убрать их из индекса, нужен noindex или статус 404/410, а затем повторный обход поисковиком.
Поставили noindex и одновременно запретили обход в robots.txt
Так делать можно не всегда. Если робот не может зайти на страницу, он не увидит noindex. В итоге URL может дольше висеть в индексе как «запрещённый к обходу». Для удаления уже известных страниц чаще полезнее сначала дать роботу увидеть noindex, а потом при необходимости ужесточать правила.
Отключили XML-RPC, а сломалась внешняя интеграция
Такое бывает с мобильными приложениями, старой публикацией через сторонние сервисы и некоторыми плагинами синхронизации. Перед отключением проверьте, кто реально обращается к endpoint. Если XML-RPC нужен только частично, лучше ограничить доступ на уровне IP или заменить интеграцию на REST API.
Сделали правила в нескольких местах сразу
Если noindex задаётся и плагином, и кодом, и сервером, потом трудно понять, что именно сработало. Оставьте один основной источник правил: либо SEO-плагин, либо код в mu-plugins, либо серверную конфигурацию.
Практические советы по безопасности и производительности
Закрытие служебных страниц — это не только про SEO. Меньше лишних URL в обходе — меньше мусорных запросов к сайту. А отключение XML-RPC снижает поверхность атаки, если он вам не нужен.
- Не закрывайте важные страницы только через robots.txt, если нужно именно удаление из индекса.
- Перед отключением XML-RPC проверьте плагины резервного копирования, мобильные клиенты и интеграции.
- После изменений очистите кэш страницы, объектный кэш и CDN, если он есть.
- Если сайт большой, не меняйте сразу всё: сначала закройте один тип страниц и посмотрите на реакцию поисковика.
Если вам нужен более удобный контроль над дублями, служебными страницами и технической чисткой сайта, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но и там важно не включать всё подряд — сначала проверьте, какие правила уже работают в теме и SEO-плагине.
Главная проверка простая: если в индексе остаются только те URL, которые реально нужны пользователю, а технические страницы перестали всплывать в отчётах, настройка сделана правильно.