Как убрать дубли страниц в WordPress от пагинации, фильтров и архивов

Если в Search Console растут страницы с одинаковыми заголовками и описаниями, а в индексе появляются архивы, пагинация и URL с параметрами, проблема обычно не в «плохом SEO», а в структуре сайта. WordPress сам по себе генерирует много похожих страниц: архивы рубрик, теги, авторов, даты, страницы пагинации, результаты поиска, а иногда еще и URL с ?orderby=, ?filter= или другими параметрами.

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

Как понять, что у вас именно дубли, а не нормальная индексация

Сначала стоит проверить, какие типы URL реально попали в индекс. Самый быстрый способ — посмотреть отчеты в Google Search Console и выгрузить список страниц с одинаковыми title или canonical. Если у вас нет доступа к GSC, можно пройтись по сайту краулером вроде Screaming Frog и сравнить:

• одинаковые title на разных URL;
• страницы с параметрами в адресе;
• архивы, которые повторяют содержимое рубрик;
• страницы пагинации, где текст и мета почти не меняются;
• служебные страницы поиска и автора, которые не несут ценности для поиска.

Типичный симптом — в индексе есть и основная рубрика, и ее пагинация, и теги, которые дублируют одни и те же записи. Еще один частый случай — фильтры и сортировки в URL, которые создают десятки почти одинаковых страниц.

Что можно считать нормой

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

Пошаговое решение: что закрывать, а что оставлять

Удобнее идти от источника дублей к способу обработки. Сначала определите, откуда они появляются, потом выберите: noindex, canonical, редирект или полное отключение генерации URL.

1. Архивы, которые не нужны в поиске

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

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

<?php
add_action('wp_head', function () {
    if (is_tag() || is_author() || is_date()) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }
});

Это не убирает страницу с сайта, но сигнализирует поисковику не индексировать ее как отдельный результат. Для уже проиндексированных URL этого может быть недостаточно: иногда нужен еще и canonical на основную страницу или удаление внутренних ссылок на дубль.

2. Пагинация архивов

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

Если нужно убрать пагинацию из индекса для конкретных архивов, можно ориентироваться на is_paged():

<?php
add_action('wp_head', function () {
    if (is_archive() && is_paged()) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }
});

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

3. Параметры в URL: сортировки, фильтры, поиск

Параметры вроде ?s=, ?orderby=, ?filter= и похожих часто создают мусорные URL. Если они не нужны для SEO, их лучше не индексировать и по возможности не генерировать внутренними ссылками.

Для поисковых результатов WordPress обычно лучше оставить их вне индекса. Поиск по сайту редко должен конкурировать с основными страницами:

<?php
add_action('wp_head', function () {
    if (is_search()) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }
});

Для параметров фильтрации лучше решать на уровне шаблона или плагина фильтров: либо не создавать индексируемые ссылки, либо ставить canonical на основную категорию, либо закрывать такие URL от индексации через правила SEO-плагина.

4. Canonical вместо жесткого запрета

Если страница нужна пользователю, но не должна конкурировать с основной, canonical часто безопаснее, чем noindex. Например, для сортировок и некоторых вариантов фильтрации можно указывать canonical на чистый URL без параметров. Это помогает поисковику понять, какая версия главная.

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

Сравнение подходов: плагин, код или редирект

Если дубль — это просто альтернативная версия той же страницы, canonical или noindex обычно безопаснее. Если же URL вообще не должен существовать, тогда уместен редирект на основную версию.

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

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

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

Если вы используете командную строку на сервере, полезно проверить заголовки ответов и редиректы. Например, curl -I https://example.com/category/news/ покажет код ответа, а curl -I https://example.com/category/news/page/2/ поможет увидеть, не отдает ли пагинация неожиданный canonical или редирект.

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

Ставят noindex на всё подряд

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

Закрывают URL, но оставляют на них внутренние ссылки

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

Используют canonical на нерелевантную страницу

Иногда canonical ставят на главную или на первую страницу рубрики, хотя контент страницы с параметром отличается. Это может привести к потере нужной страницы из индекса. Canonical должен указывать только на действительно основную версию.

Путают индексацию и обход

noindex не означает, что бот перестанет заходить на страницу. Если URL массово генерируется и не нужен вообще, лучше убрать причину его появления, а не только прятать от индекса.

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

Чем меньше мусорных URL генерирует сайт, тем проще ему жить. Это не только SEO-вопрос, но и вопрос нагрузки. Фильтры, поиск и бесконечные архивы могут создавать лишние запросы к базе и увеличивать число обходов ботом.

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

Если нужен более системный подход к чистке дублей и технических страниц, удобно собрать это через один SEO-инструмент, а не держать настройки в нескольких плагинах и кусках кода. Но даже с плагином все равно стоит проверить исходный HTML и поведение в Search Console — именно там видно, сработало ли решение на практике.