На WordPress часто индексируются не только записи и страницы, но и служебные URL: архивы автора, вложения, страницы поиска, а иногда даже прямые ссылки на PHP-файлы темы или плагинов, если сервер настроен неаккуратно. Это не всегда критично, но почти всегда лишнее: поисковик тратит краулинговый бюджет на мусор, а в выдаче могут всплывать технические страницы без ценности для пользователя.
Ниже — рабочий сценарий: что именно закрывать, чем это делать в WordPress, как не сломать сайт и как проверить, что индексация действительно остановилась.
Какие URL обычно нужно закрывать
Сначала полезно разделить проблему на две части. Первая — страницы, которые WordPress генерирует сам: поиск, архивы, вложения, служебные таксономии. Вторая — файлы и точки входа, которые не должны попадать в индекс вообще: .php-файлы внутри темы, тестовые шаблоны, старые копии плагинов, служебные скрипты.
Для SEO обычно закрывают:
- страницы поиска вида
/?s=...; - архивы автора на сайтах с одним автором;
- вложения медиафайлов, если они не нужны как отдельные страницы;
- служебные таксономии и пустые архивы;
- тестовые или временные страницы, которые остались после разработки;
- прямой доступ к PHP-файлам, если они не должны открываться в браузере.
Диагностика: что именно уже индексируется
Перед правками не стоит закрывать всё подряд. Сначала проверьте, какие URL уже попали в индекс и откуда они берутся. Это можно сделать через поиск по сайту в Google, Яндекс.Вебмастер и логи краулера, если он у вас есть.
Что смотреть в первую очередь
- запрос
site:example.comи поиск по типовым шаблонам URL; - разделы «Исключённые страницы» и «Страницы с тегом noindex» в Search Console;
- отчёты по страницам поиска и архивам в панели вебмастера;
- ответ сервера на проблемный URL: код
200,301,404или403.
Если страница отдает 200 OK и содержит мало полезного контента, поисковик может продолжать её обходить. Если это служебный URL, лучше не надеяться только на robots.txt: он ограничивает обход, но не всегда убирает URL из индекса, если на него уже есть внешние или внутренние ссылки.
Пошаговое решение: закрываем служебные страницы в WordPress
Самый безопасный вариант — сочетать noindex для HTML-страниц и запрет на доступ там, где это уместно. Для PHP-файлов и старых служебных скриптов лучше вообще не оставлять публичный доступ, если они не нужны.
1. Добавьте noindex для архивов поиска, автора и вложений
Если вы не используете эти страницы как полноценные посадочные, их лучше пометить как неиндексируемые. Это можно сделать через SEO-плагин или кодом. Код ниже ставит noindex, follow для поиска, архивов автора и страниц вложений.
<?php
add_action('wp_head', function () {
if (is_search() || is_author() || is_attachment()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);Этот вариант подходит, если у вас нет SEO-плагина, который уже управляет robots meta. Если плагин есть, не дублируйте теги: два разных meta robots могут дать неоднозначный сигнал.
2. Закройте индексацию через robots.txt только для обхода, а не как единственную меру
robots.txt полезен, когда нужно снизить нагрузку на обход. Но если URL уже в индексе, одного запрета в robots.txt может быть недостаточно. Используйте его как дополнение, а не как единственный инструмент.
User-agent: *
Disallow: /?s=
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpВажно: строка Disallow: /?s= не всегда отрабатывает одинаково у всех ботов и не заменяет noindex. Для поиска лучше именно мета-тег или заголовок X-Robots-Tag.
3. Запретите индексацию конкретных PHP-файлов на уровне сервера
Если у вас есть служебные PHP-файлы, которые не должны открываться напрямую, правильнее ограничить доступ через серверную конфигурацию. Для Apache можно закрыть файл или каталог через .htaccess.
<Files "debug-template.php">
Require all denied
</Files>Для Nginx логика будет другой: доступ ограничивается в конфиге виртуального хоста. Если файл нужен только внутри темы через include или get_template_part(), прямой публичный доступ ему обычно не нужен.
4. Уберите лишние архивы и вложения из выдачи, если они не несут ценности
На многих сайтах страницы вложений создают отдельные URL с почти пустым содержимым. Если они не используются как самостоятельные страницы, лучше перенаправить их на сам файл или на родительскую запись. Это уменьшает количество мусорных страниц в индексе.
Пример: редирект вложений на родительскую запись, если она есть.
<?php
add_action('template_redirect', function () {
if (is_attachment()) {
$parent = wp_get_post_parent_id(get_queried_object_id());
if ($parent) {
wp_safe_redirect(get_permalink($parent), 301);
exit;
}
}
});Если родительской записи нет, можно отправлять на главную или на страницу архива медиа, но это уже зависит от структуры сайта.
Сравнение подходов: плагин, код или сервер
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| SEO-плагин | Нужно быстро закрыть архивы и отдельные типы страниц | Удобно, без правки темы | Легко получить дубли настроек, если уже есть свой код |
| Код в теме или плагине | Нужна точечная логика под конкретный сайт | Гибко и прозрачно | Требует аккуратности при обновлениях |
| Серверная настройка | Нужно закрыть прямой доступ к PHP или служебным файлам | Надёжнее для файлов | Нужен доступ к конфигу хостинга |
Если у вас уже стоит SEO-плагин, не дублируйте правила в нескольких местах. Например, если плагин ставит noindex на архивы, а в теме вы вручную добавите другой robots meta, результат может стать непредсказуемым.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Нужно убедиться, что URL действительно отдают нужный ответ и что поисковик видит именно тот сигнал, который вы задумали.
Что проверить вручную
- откройте проблемный URL в браузере и посмотрите исходный код страницы;
- убедитесь, что в
<head>естьnoindex,followтам, где это нужно; - проверьте код ответа сервера через DevTools или
curl -I; - посмотрите, не осталось ли внутренних ссылок на закрытые страницы;
- отправьте URL на повторную проверку в Search Console или Яндекс.Вебмастер.
Пример проверки заголовков через командную строку:
curl -I https://example.com/?s=testЕсли вы закрывали файл на уровне сервера, ожидаемый результат — 403 Forbidden или 404 Not Found, в зависимости от выбранной политики. Если ставили noindex, страница может оставаться доступной для обхода, но не должна попадать в индекс.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но она всё равно в индексе
Это типичная ситуация. Robots.txt не удаляет URL из индекса автоматически. Если страница уже известна поисковику, добавьте noindex или отдайте 404/410, если страница больше не нужна.
Поставили noindex в теме, а SEO-плагин перезаписал тег
Так бывает, когда разные части сайта управляют мета-тегами одновременно. Оставьте только один источник правды: либо SEO-плагин, либо собственный код. Иначе вы будете ловить конфликт настроек после каждого обновления.
Закрыли вложения, но потеряли трафик из поиска по картинкам
Если медиафайлы реально приводят трафик, не стоит бездумно закрывать все attachment pages. Сначала посмотрите, есть ли у них входящие переходы и используется ли отдельная страница вложения как часть контентной стратегии.
Запретили доступ к PHP-файлу, а сломали шаблон
Если файл подключается через include внутри темы, его нельзя просто удалить или закрыть без проверки зависимостей. Сначала найдите, где он используется, и только потом ограничивайте прямой доступ.
Чек-лист перед публикацией правок
- проверены URL, которые реально попадают в индекс;
- понятно, что закрываем: страницу, архив или файл;
- для HTML-страниц выбран
noindex, а не только robots.txt; - для служебных PHP-файлов ограничен прямой доступ;
- нет дублей robots meta от плагина и темы;
- внутренние ссылки на закрытые страницы удалены или заменены;
- после правок выполнена повторная проверка в Search Console.
Практические советы по безопасности и производительности
Если на сайте много технических страниц, полезно держать под контролем не только индексацию, но и количество публичных URL. Чем меньше мусорных страниц, тем проще обход сайта и тем меньше риск случайно открыть лишний файл в выдаче.
Для сайтов на WordPress удобно вынести такие правила в небольшой must-use плагин, а не в functions.php темы. Тогда логика не пропадёт при смене темы и её проще сопровождать.
Если вам нужен более широкий набор инструментов для чистки дублей, управления мета-тегами и технической оптимизации, имеет смысл смотреть в сторону решений уровня Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином важно понимать, какие URL вы закрываете и почему — иначе легко скрыть от индексации полезные страницы вместе с мусорными.
Когда всё настроено правильно, в индексе остаются только те страницы, которые действительно нужны пользователю и поисковику. Это не косметическая правка, а нормальная техническая гигиена сайта.