Как закрыть дубли архивов WordPress от индексации без потери нужных страниц

Автор: Юлия Журавлева | Опубликовано: 20.08.2026

Если в Search Console всплывают дубли страниц, а в индексе оказываются теги, архивы дат, авторские страницы и пагинация, проблема обычно не в одном «плохом» URL. Чаще всего WordPress просто слишком щедро отдаёт архивы, которые не несут самостоятельной ценности. Задача не в том, чтобы всё подряд спрятать, а в том, чтобы оставить в индексе полезные страницы и убрать технический шум.

Ниже — рабочая схема: как диагностировать, что именно дублируется, чем закрывать архивы, как не сломать canonical и как проверить результат после внедрения.

Что именно считать дублями в WordPress

В типовой установке WordPress дубли чаще всего появляются в архивных разделах. Это не всегда «ошибка» в строгом смысле, но для поиска такие страницы часто лишние.

Архивы тегов — если теги используются формально и у них нет собственной редакционной ценности.
Архивы дат — почти всегда технический шум для блога без новостной модели.
Архивы авторов — особенно на сайтах с одним автором, где страница автора повторяет ленту.
Пагинация архивов — сама по себе не проблема, но иногда её индексируют вместо основных материалов.
Страницы поиска — обычно не должны попадать в индекс.

Если у вас есть рубрики, которые реально работают как посадочные страницы и собирают трафик, их закрывать не нужно. Сначала смотрим на фактическую пользу, а не на тип архива.

Диагностика проблемы: где искать дубли

Начните с простого списка URL, которые уже попали в индекс или были обнаружены как дубли. Полезно смотреть не только Search Console, но и сам сайт: как формируются заголовки, canonical и robots.

Что проверить вручную

Откройте архив тега, рубрики, автора и даты.
Посмотрите исходный код: есть ли <meta name="robots" content="noindex,follow">.
Проверьте canonical: указывает ли он на саму страницу или на другую, более полезную.
Сравните title и H1 с основными страницами сайта — если они почти одинаковые, это кандидат на дубль.

Если на сайте стоит SEO-плагин, он может уже управлять индексированием архивов. Важно не накладывать несколько решений сразу: например, не ставить noindex в плагине и одновременно не закрывать тот же URL в robots.txt. Это разные механизмы, и вместе они часто мешают диагностике.

Быстрая проверка через браузер и консоль

Для любой проблемной страницы откройте исходник и найдите robots/canonical. Если нужен быстрый чек через командную строку, можно посмотреть заголовки и HTML без лишних инструментов:

curl -I https://example.com/tag/wordpress/

curl -s https://example.com/tag/wordpress/ | grep -iE 'robots|canonical'

Если canonical указывает на сам архив, а страница не несёт ценности, это не решает проблему индексации. Тогда нужен noindex или отключение архива на уровне темы/плагина.

Как закрыть архивы от индексации: три рабочих подхода

Выбор зависит от того, чем вы управляете сайтом: SEO-плагином, кодом темы или серверными правилами. Для большинства проектов безопаснее начинать с SEO-настроек, а код использовать только там, где нужен точечный контроль.

Подход	Когда подходит	Плюс	Минус
SEO-плагин	Нужно быстро закрыть теги, даты, авторов	Просто и прозрачно	Меньше гибкости для нестандартных архивов
Код в теме/плагине	Нужен точечный контроль над конкретными архивами	Точно и без лишних настроек	Требует аккуратности при обновлениях
robots.txt	Нужно ограничить обход, а не индекс	Легко добавить	Не заменяет `noindex`

Вариант 1: закрыть архивы через SEO-плагин

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

Плюс этого подхода в том, что плагин сам добавит корректный meta robots и не потребует ручной правки шаблонов. Минус — если на сайте есть нестандартные таксономии, их придётся настраивать отдельно.

Вариант 2: точечный noindex через код

Если нужен контроль без тяжёлого SEO-плагина, можно добавить фильтр в functions.php дочерней темы или в небольшой mu-plugin. Ниже пример для архивов тегов, дат и авторов.

add_filter('wp_robots', function (array $robots) {
    if (is_tag() || is_date() || is_author()) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    return $robots;
});

Это рабочий вариант для современных версий WordPress, где используется фильтр wp_robots. Он не трогает остальные страницы и не требует правки шаблонов.

Если нужно закрыть ещё и страницы поиска, добавьте отдельную проверку:

add_filter('wp_robots', function (array $robots) {
    if (is_search()) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    return $robots;
});

Вариант 3: ограничить обход через robots.txt

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

User-agent: *
Disallow: /search/
Disallow: /tag/
Disallow: /author/
Disallow: /date/

Такой файл может уменьшить нагрузку на обход, но не стоит считать его полноценной заменой мета-роботам. Если страница уже в индексе, поисковик может продолжать показывать её по внешним сигналам.

Когда архив лучше не закрывать

Не все архивы — мусор. Иногда тег или рубрика собирают релевантный трафик и помогают пользователю быстро найти материалы. В таких случаях закрывать страницу от индексации не нужно, но стоит улучшить её содержимое.

Добавьте уникальный текст в рубрику или тег, если он реально нужен.
Проверьте, есть ли у архива нормальный H1 и понятный title.
Уберите пустые или почти пустые архивы.
Сведите к минимуму теги, которые дублируют рубрики.

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

Пошаговое решение без лишнего риска

Составьте список архивов, которые реально не нужны в поиске: теги, даты, авторы, поиск.
Проверьте, нет ли у них входящего трафика и внешних ссылок.
Выберите один способ управления: SEO-плагин или код, но не оба сразу.
Добавьте noindex,follow для выбранных архивов.
Убедитесь, что canonical не указывает на случайную страницу.
Проверьте robots.txt только как дополнительный слой, а не как основное решение.

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

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

Откройте страницу и проверьте meta robots в исходном коде.
Убедитесь, что canonical остался корректным.
В Search Console отправьте URL на повторную проверку.
Посмотрите, не исчезли ли из индекса нужные рубрики или важные посадочные страницы.

Если у вас есть доступ к серверным логам или инструментам обхода, полезно проверить, как поисковый бот ходит по архивам после изменений. Иногда проблема не в индексации, а в том, что бот тратит слишком много обхода на бесполезные страницы.

Что должно измениться

После корректной настройки архивы с noindex должны перестать конкурировать с основными материалами. В индексе останутся только те страницы, которые вы сознательно оставили открытыми. Если этого не произошло, значит, где-то остался второй источник управления robots или canonical.

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

Ставят Disallow в robots.txt и ждут удаления из индекса. Исправление: для уже известных страниц используйте noindex.
Закрывают все архивы подряд. Исправление: сначала проверьте, какие из них реально дают трафик и полезны пользователю.
Одновременно настраивают SEO-плагин и вручную правят шаблон. Исправление: оставьте один источник правды для meta robots.
Ломают canonical при кастомизации темы. Исправление: проверьте исходный код после каждого изменения шаблона archive.php или header.php.
Закрывают страницу поиска, но забывают про пагинацию архивов. Исправление: проверьте не только первый URL, но и страницы /page/2/, /page/3/.

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

Если вы вносите изменения кодом, лучше не редактировать родительскую тему напрямую. Используйте дочернюю тему или маленький mu-plugin, чтобы настройка не слетела после обновления. Это особенно важно, если сайт поддерживается несколькими разработчиками.

Для проектов, где нужно не только закрыть дубли, но и почистить лишние SEO-настройки, иногда удобнее использовать специализированный плагин вроде Clearfy Pro: он помогает убрать часть технического шума и централизовать SEO-правила. Но даже в этом случае проверка исходного кода и Search Console остаётся обязательной.

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

Мини-чек-лист перед публикацией изменений

Проверен список архивов, которые реально не нужны в индексе.
Выбран один способ управления robots: плагин или код.
На страницах есть noindex,follow, где это нужно.
Canonical не сломан и указывает на ожидаемый URL.
Пагинация и поиск тоже проверены.
В Search Console отправлены проблемные URL на повторную проверку.

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