В WordPress технические страницы часто попадают в индекс не из-за одной ошибки, а из-за набора мелочей: архивы авторов без контента, страницы поиска, вложения медиафайлов, служебные URL плагинов, результаты фильтров, пагинация с пустыми листингами. На небольшом сайте это выглядит как «мусор в индексе», на крупном — как размывание краулингового бюджета и лишние дубли в отчётах Search Console.
Задача здесь не в том, чтобы закрыть всё подряд. Нужен список страниц, которые не несут самостоятельной ценности для поиска, и понятный способ убрать их из индекса без поломки навигации и без случайного закрытия полезных разделов.
Какие страницы WordPress обычно стоит закрывать
Сначала полезно разделить URL на две группы: те, что должны индексироваться, и служебные страницы, которые нужны пользователю или движку сайта, но не должны ранжироваться сами по себе. Ошибка многих администраторов в том, что они пытаются решить вопрос только через robots.txt. Это не всегда достаточно: если URL уже известен поисковику, запрет на обход не равен удалению из индекса.
Типовые кандидаты на закрытие
- страницы внутреннего поиска вида
?s=; - архивы авторов, если на сайте один автор и архив не несёт пользы;
- страницы вложений медиафайлов, если они пустые или дублируют сам файл;
- служебные страницы плагинов, которые не должны попадать в поиск;
- пустые или почти пустые архивы рубрик и меток;
- страницы пагинации, если они создают технический шум, а не полезную структуру.
При этом не стоит автоматически закрывать рубрики, теги или пагинацию на контентных проектах. Если эти страницы реально помогают пользователю и содержат уникальные сниппеты, они могут быть полезны для индексации.
Диагностика: как понять, что именно лишнее в индексе
Перед правками откройте отчёт Search Console по страницам и посмотрите, какие URL Google уже сканирует или держит в индексе. Дополнительно проверьте сайт через site:example.com и выгрузите список URL из карты сайта. Сравнение этих трёх источников обычно быстро показывает, где проблема: в sitemap, во внутренних ссылках или в генерации служебных адресов.
Если на сайте стоит кэш или SEO-плагин, проверьте, не добавляет ли он автоматические архивы, страницы автора, attachment pages и служебные таксономии. Иногда проблема не в WordPress как таковом, а в настройках темы или плагина, которые создают индексируемые страницы без контента.
Чек-лист диагностики
- проверить, есть ли URL в индексе через Search Console;
- сравнить индексируемые страницы с sitemap.xml;
- посмотреть, не ведут ли внутренние ссылки на служебные URL;
- проверить заголовки ответа и наличие
noindex; - убедиться, что нужные страницы не закрыты случайно.
Пошаговое решение: как закрыть технические страницы правильно
Надёжнее всего использовать связку из двух уровней: noindex для страниц, которые уже известны поисковику, и ограничение обхода там, где это действительно нужно. Для WordPress это обычно делается через SEO-плагин или кодом в теме/мини-плагине.
Вариант 1. Через SEO-плагин
Если на сайте уже используется SEO-плагин, проверьте его настройки архивов и таксономий. В большинстве случаев можно отключить индексацию страниц автора, меток, форматов записей, attachment pages и результатов поиска. Это самый безопасный путь, если вы не хотите поддерживать собственный код.
Плюс такого подхода в том, что плагин обычно сам ставит noindex и корректно убирает URL из карты сайта. Минус — настройки могут отличаться от темы к теме, поэтому после изменения всё равно нужна ручная проверка.
Вариант 2. Через код в WordPress
Если нужно точечно закрыть конкретные типы страниц, можно добавить noindex, follow в <head>. Ниже пример для страниц поиска, архивов автора и attachment pages. Код лучше размещать в дочерней теме или в небольшом mu-plugin.
<?php
add_action('wp_head', function () {
if (is_search() || is_author() || is_attachment()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);Этот вариант не закрывает обход страницы полностью, но сообщает поисковику, что страницу не нужно держать в индексе. Для большинства служебных URL этого достаточно.
Если нужно убрать attachment pages с медиафайлов
У WordPress вложения часто создают отдельные страницы, которые почти всегда бесполезны для поиска. Если на сайте они не нужны, можно перенаправлять их на сам файл или на родительскую запись.
<?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);
} else {
wp_safe_redirect(home_url('/'), 301);
}
exit;
}
});Это уже не про noindex, а про нормализацию URL. Такой подход полезен, если attachment pages успели накопиться в индексе и создают дубли.
Сравнение подходов: плагин, код и robots.txt
| Подход | Когда подходит | Плюсы | Ограничения |
|---|---|---|---|
| SEO-плагин | Нужно быстро закрыть типовые архивы и таксономии | Меньше ручного кода, часто есть управление sitemap | Не всегда хватает точности для нестандартных URL |
| Код в теме или mu-plugin | Нужно закрыть конкретные шаблоны и служебные страницы | Точный контроль, легко расширять | Требует проверки после обновлений темы |
robots.txt | Нужно ограничить обход отдельных разделов | Просто добавить правила | Не удаляет URL из индекса, если он уже известен |
На практике чаще всего используют комбинацию: noindex для страниц, которые уже могут быть в индексе, и robots.txt только для явного ограничения обхода, если это действительно нужно. Полагаться только на robots.txt для удаления страниц из поиска — частая ошибка.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой в браузере. Откройте исходный код страницы и убедитесь, что мета-тег robots реально выводится. Для attachment pages и архивов проверьте HTTP-ответ и конечный URL после редиректа.
Дальше отправьте страницу на повторное сканирование в Search Console и посмотрите, как меняется статус в отчёте по индексированию. Если URL был в sitemap, удалите его оттуда или исключите через настройки плагина, иначе поисковик будет снова и снова находить тот же адрес.
Что именно проверить
- в исходнике есть
<meta name="robots" content="noindex,follow" />; - служебный URL не попадает в sitemap.xml;
- редирект с attachment page ведёт на нужную страницу;
- внутренние ссылки больше не ведут на закрытый URL;
- в Search Console URL постепенно уходит из индекса.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но она осталась в индексе
Это нормальная ситуация. Если URL уже известен поисковику, одного запрета на обход недостаточно. Добавьте noindex или настройте редирект, если страница вообще не должна существовать.
Случайно закрыли полезные архивы
Такое часто происходит, когда отключают индексацию всех архивов подряд. Проверьте, не потеряли ли трафик рубрики, теги или пагинация, которые реально отвечают на запрос пользователя. Если архив полезен, верните индексирование и доработайте контент на странице.
Оставили URL в sitemap
Если страница закрыта от индексации, но продолжает попадать в карту сайта, поисковик будет тратить на неё лишние обходы. Исключите её из sitemap на уровне плагина или фильтра генерации карты сайта.
Поставили noindex только в шаблоне, но забыли про кэш
После изменения шаблона или хука очистите кэш страницы, объектный кэш и, если есть, CDN. Иначе вы будете проверять старую версию HTML и думать, что правка не сработала.
Безопасность и производительность: что учесть перед правками
Если вы добавляете код вручную, не правьте functions.php на боевом сайте без копии. Лучше использовать дочернюю тему или mu-plugin, чтобы не потерять изменения при обновлении. Перед редиректами проверьте, что не создаёте цепочки и петли: attachment page должна вести сразу на конечный адрес.
Для сайтов с большим количеством медиафайлов и архивов полезно периодически пересматривать список закрытых URL. То, что было техническим мусором год назад, иногда становится рабочей страницей после изменения структуры сайта. Поэтому схема должна быть не «поставил и забыл», а «настроил и проверяю по отчётам».
Если нужен более широкий аудит дублей, архивов и служебных страниц, удобно сначала привести в порядок индексацию и только потом чистить сайт глубже. В таких задачах часто помогает Clearfy Pro, если нужен именно набор инструментов для технической чистки и управления дублями: https://wpshop.ru/plugins/clearfy.