Служебные страницы WordPress часто попадают в индекс не потому, что сайт «плохой», а потому что поисковик видит лишние URL: страницы авторов, архивы дат, вложения медиафайлов, результаты поиска по сайту, служебные таксономии, пагинацию с дублями. Если закрыть всё подряд через noindex или robots.txt без проверки, можно случайно убрать из индекса нужные страницы или сломать обход важных разделов.
Ниже — рабочая схема: как понять, что именно нужно закрывать, чем лучше управлять через код, а где достаточно настроек плагина или SEO-модуля.
Когда проблема действительно в индексации служебных страниц
Признаки обычно видны в поисковой консоли и в логике URL сайта. Не нужно гадать: сначала проверьте, какие адреса уже попали в индекс и почему.
Что смотреть в первую очередь
- в отчётах поисковой системы есть страницы вида
/author/,/date/,/page/2/,?s=,/attachment/; - в выдаче находятся страницы вложений с пустым или почти пустым контентом;
- один и тот же материал доступен по нескольким URL, например с параметрами, пагинацией или архивами;
- в индексе много страниц, которые не несут самостоятельной ценности для пользователя.
Если проблема только в одном типе страниц, не стоит включать глобальные запреты на весь сайт. Для WordPress это особенно важно: часть URL создаётся ядром, часть — темой или плагинами, и универсальный запрет часто даёт побочный эффект.
Диагностика: какие страницы закрывать, а какие оставить
Перед изменениями составьте короткий список типов URL. Это помогает не смешивать SEO-настройки и реальные бизнес-страницы.
| Тип URL | Обычно закрывают? | Комментарий |
|---|---|---|
| Архивы автора | Да, если авторских страниц не используют как посадочные | Часто дублируют списки записей |
| Архивы дат | Чаще да | Редко дают ценность, если сайт не новостной |
| Страницы вложений | Да | Лучше редиректить на файл или родительскую запись |
| Поиск по сайту | Обычно да | Результаты поиска не должны конкурировать с контентом |
| Пагинация архивов | Зависит от структуры | Не всегда нужно закрывать, но важно убрать дубли title/description |
Если у вас уже стоит SEO-плагин, сначала проверьте его настройки. Многие задачи решаются без кода. Но если нужен точечный контроль, лучше сделать это через фильтры WordPress, а не через правку шаблонов.
Пошаговое решение через код
Ниже — безопасный базовый вариант: отключить индексацию для служебных типов страниц и добавить корректный noindex там, где это уместно. Код можно разместить в дочерней теме или в небольшом mu-plugin.
1. Закрываем архивы автора и даты
<?php
add_action('wp_head', function () {
if (is_author() || is_date() || is_search()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Этот вариант простой, но не идеальный, если у вас уже есть SEO-плагин, который тоже выводит robots meta. В таком случае лучше использовать его настройки или фильтры, чтобы не получить два одинаковых тега.
2. Отключаем индексацию вложений и редиректим их на родительскую запись
<?php
add_action('template_redirect', function () {
if (is_attachment()) {
$parent = get_post_field('post_parent', get_queried_object_id());
if ($parent) {
wp_safe_redirect(get_permalink($parent), 301);
exit;
}
}
});Это полезнее, чем просто ставить noindex на attachment-страницы. Если у вложения есть родительская запись, поисковику и пользователю лучше сразу показать основной контент.
3. Убираем лишние архивы из карты сайта
Если архивы не нужны в поиске, их не должно быть и в sitemap. В WordPress это обычно делается через SEO-плагин. Если карта сайта генерируется вручную, исключите служебные URL на уровне генератора, а не постфактум через robots.txt.
Пример логики для собственных списков URL:
<?php
$urls = array_filter($urls, function ($url) {
return !preg_match('#/(author|date|attachment)/#', $url);
});Фильтрация URL на этапе генерации карты сайта надёжнее, чем попытка «спрятать» уже опубликованные адреса.
Когда лучше использовать плагин, а когда код
Если задача типовая, плагин экономит время. Если нужны точечные правила — код даёт меньше сюрпризов. Ниже короткое сравнение.
| Подход | Плюсы | Минусы |
|---|---|---|
| SEO-плагин | Быстро, без разработки, есть UI | Не всегда удобно для нестандартных правил |
| Код в теме или mu-plugin | Точный контроль, легко версионировать | Нужно следить за совместимостью и обновлениями |
| robots.txt | Просто закрыть обход | Не решает проблему индексации уже известных URL |
Важно: robots.txt не равен noindex. Если страница уже в индексе, запрет обхода не гарантирует её исчезновение. Для удаления из поиска обычно нужен либо корректный noindex, либо редирект, либо удаление страницы с отдачей 404/410 в зависимости от сценария.
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой в браузере. Нужно убедиться, что поисковый робот видит именно то, что вы задумали.
- откройте служебную страницу и проверьте исходный код на наличие
<meta name="robots" content="noindex,follow" />; - проверьте, что attachment-страницы редиректят на родительскую запись с кодом 301;
- посмотрите, не появились ли дубли robots meta от нескольких плагинов;
- проверьте sitemap: служебные URL не должны туда попадать;
- в поисковой консоли отправьте страницу на повторную проверку после изменений.
Если используете кэш, очистите не только фронтенд-кэш, но и серверный кэш, а также CDN, если он есть. Иначе вы можете проверять старую версию страницы и сделать ложный вывод, что правило не сработало.
Частые ошибки и как их исправить
Закрыли URL в robots.txt и ждёте удаления из индекса
Это самая частая ошибка. Если страница уже известна поисковику, одного запрета на обход мало. Добавьте noindex или сделайте редирект/удаление в зависимости от задачи.
Поставили noindex через несколько плагинов сразу
В результате можно получить конфликтующие мета-теги или нестабильную генерацию head. Оставьте один источник правды: SEO-плагин или собственный код.
Закрыли архивы, которые реально приводят трафик
Такое бывает с авторскими страницами в медиа-проектах или с архивами рубрик, если они хорошо проработаны. Перед отключением проверьте статистику и поисковый спрос по этим URL.
Удалили страницы вложений, но не настроили редирект
Тогда старые URL начинают отдавать 404, хотя могли бы передавать вес на родительский материал. Для медиафайлов редирект обычно практичнее.
Практические советы по безопасности и производительности
Если вы вносите код, не правьте его в активной теме напрямую. Используйте дочернюю тему или mu-plugin, чтобы обновление темы не затёрло изменения. Для небольших SEO-правил mu-plugin часто удобнее: он грузится стабильно и не зависит от темы.
Ещё один момент — не плодите тяжёлые проверки в wp_head. Для простых условий это не критично, но если логика разрастается, лучше вынести её в отдельную функцию и тестировать на staging-копии.
Если нужен более широкий технический аудит дублей, служебных страниц и мусорных архивов, в экосистеме WPShop есть Clearfy Pro: он закрывает часть типовых задач по чистке WordPress и удалению дублей. Но даже с плагином полезно понимать, какие URL вы реально отключаете и зачем: автоматическая настройка без проверки часто даёт лишние ограничения.
Мини-чек-лист перед публикацией изменений
- определили конкретные типы служебных URL;
- проверили, нет ли у них поискового трафика;
- выбрали один способ управления: плагин или код;
- убрали лишние URL из sitemap;
- проверили редиректы для вложений;
- очистили кэш и CDN;
- перепроверили исходный код и ответ сервера.
Если после внедрения служебные страницы всё ещё появляются в индексе, обычно проблема не в одном теге, а в сочетании факторов: карта сайта, внутренние ссылки, кэш, дубли title и отсутствие явного сигнала для поисковика. В таких случаях проще идти от конкретного URL к источнику его появления, чем пытаться «закрыть WordPress целиком».