В WordPress дубли чаще всего появляются не из-за «плохого SEO», а из-за стандартной логики CMS: архивы категорий, теги, страницы авторов, пагинация, параметры сортировки, версии для печати, служебные URL. Если это не контролировать, поисковик тратит обход на мусорные страницы, а в индексе остаются варианты, которые не должны конкурировать с основными посадочными.
Ниже — рабочая схема: как найти источник дублей, чем закрывать их от индексации и как проверить, что после правок сайт не потерял важные страницы.
Как понять, что у вас именно проблема дублей
Симптомы обычно видны в Search Console и в логах обхода. Часто в отчётах всплывают страницы с одинаковыми title и description, а в индексе оказываются URL с ?replytocom=, ?amp, /page/2/, архивы тегов и авторов, которые не несут самостоятельной ценности.
Что проверить в первую очередь
- есть ли в индексе страницы тегов и авторов, если они не нужны для поиска;
- дублируются ли записи через пагинацию архивов;
- появляются ли URL с параметрами в отчёте «Страницы»;
- совпадают ли title у архивов категорий и тегов;
- не открываются ли служебные страницы, которые не должны ранжироваться.
Если сайт настраивали давно, часто проблема не в одном источнике, а в комбинации: например, теги открыты, архивы автора доступны, а пагинация ещё и индексируется отдельно. В таком случае точечное закрытие одного типа страниц не даст эффекта.
Какие типы дублей в WordPress встречаются чаще всего
Удобнее сначала разложить проблему по типам. Тогда проще выбрать способ: где-то достаточно noindex, где-то лучше убрать страницу из генерации, а где-то — настроить канонический URL.
| Источник дубля | Что делать | Компромисс |
|---|---|---|
| Теги и авторы | Закрыть от индексации или отключить архивы | Потеря дополнительного входного трафика |
| Пагинация архивов | Оставить доступной, но не плодить лишние мета-теги | Не всегда нужно закрывать полностью |
| Параметры URL | Настроить canonical и исключить генерацию мусора | Не все параметры можно убрать без потери функционала |
| Служебные страницы | Закрыть от индексации и убрать из sitemap | Нужно проверить, не используются ли они в навигации |
Пошаговое решение: как закрыть дубли без лишнего риска
Шаг 1. Определите, что должно остаться в индексе
Не закрывайте всё подряд. Сначала решите, какие типы страниц реально полезны для поиска. Обычно в индексе оставляют записи, категории и важные посадочные страницы. Теги, авторы, архивы по датам и служебные страницы часто закрывают, но это зависит от структуры сайта.
Если у вас контентный проект с сильной рубрикацией, категории могут быть важнее тегов. Если же теги используются как навигационный мусор, их лучше убрать из индекса и из карты сайта.
Шаг 2. Закройте архивы через SEO-плагин или код
Самый безопасный путь для большинства сайтов — управлять индексированием через SEO-плагин. Если нужен ручной контроль, можно добавить noindex,follow для архивов тегов и авторов. Важно: не путайте закрытие от индексации с запретом обхода. Обычно поисковику нужно дать пройти по ссылкам, но не показывать саму страницу в выдаче.
Пример для темы или мини-плагина, если вы хотите добавить мета-тег только на архивы тегов и авторов:
<?php
add_action('wp_head', function () {
if (is_tag() || is_author()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Этот способ рабочий, но его лучше использовать только если вы понимаете, что SEO-плагин не управляет этими страницами уже сейчас. Два источника мета-тегов могут конфликтовать.
Шаг 3. Уберите архивы из sitemap, если они не нужны
Если страница закрыта от индексации, но остаётся в sitemap, вы создаёте лишний шум. Поисковик видит URL в карте сайта и всё равно тратит на него обход. Для архивов тегов, авторов и дат это особенно заметно на больших сайтах.
В большинстве SEO-плагинов это настраивается в интерфейсе. Если вы пишете кодом, логика должна быть простой: в sitemap попадают только те типы страниц, которые вы реально хотите индексировать.
Шаг 4. Настройте canonical для параметров и пагинации
Если дубли возникают из-за параметров URL, canonical помогает указать основную версию страницы. Но canonical не лечит плохую архитектуру сам по себе: если на сайте есть десятки бесполезных вариантов одной и той же страницы, лучше ещё и сократить их генерацию.
Для страниц пагинации архивов canonical обычно должен указывать на саму страницу пагинации, а не на первую страницу архива. Иначе можно сломать обход и ухудшить доступность старых материалов.
Когда лучше использовать плагин, а когда код
Если задача типовая, проще и безопаснее настроить её в SEO-плагине. Код нужен там, где требуется точечная логика: закрыть только часть архивов, исключить конкретные шаблоны или добавить правила для нестандартных URL.
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Типовые архивы, sitemap, robots | Меньше гибкости |
| Код в теме | Небольшой сайт, точечные правила | Риск потерять изменения при обновлении темы |
| Мини-плагин | Нужна переносимость и контроль | Нужно поддерживать свой код |
Если вы используете Clearfy Pro, у него как раз есть инструменты для чистки сайта, удаления дублей и управления SEO-настройками. Это не обязательное условие, но для типовых задач он закрывает часть ручной работы. Ссылка: Clearfy Pro.
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковик видит именно ту версию, которую вы задумали.
Что проверить вручную
- открывается ли страница и отдает ли она ожидаемый
meta robots; - нет ли лишних URL в sitemap;
- не остались ли закрытые страницы в меню и внутренних ссылках;
- не появились ли ошибки 404 после отключения архивов;
- не изменился ли canonical на важных посадочных страницах.
Как быстро проверить через код ответа и HTML
Для проверки можно посмотреть исходный код страницы или запросить заголовки. Если у вас есть доступ к серверу, полезно проверить, что страницы не отдают неожиданный редирект или ошибку.
curl -I https://example.com/tag/novosti/
curl -s https://example.com/tag/novosti/ | grep -i robotsЕсли страница должна быть закрыта, в HTML должен присутствовать noindex. Если она должна остаться доступной, но не конфликтовать с другими версиями, проверьте canonical и отсутствие дублей title.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt вместо noindex
Это частая ошибка. Если запретить обход через robots.txt, поисковик может не увидеть мета-тег noindex и страница останется в индексе как URL без содержимого. Для уже проиндексированных страниц это плохой сценарий.
Убрали архивы, но оставили их в sitemap
Такой конфликт встречается после частичной настройки SEO-плагина. В результате поисковик продолжает обходить URL, которые вы сами объявили ненужными. Исправление простое: синхронизируйте sitemap с правилами индексации.
Поставили noindex на всё подряд
Иногда закрывают и категории, и записи, и пагинацию, а потом удивляются падению видимости. Проверьте, какие страницы реально должны ранжироваться. Если сомневаетесь, сначала закрывайте только теги, авторов и служебные страницы.
Сломали canonical на пагинации
Если canonical всех страниц архива указывает на первую страницу, поисковик может игнорировать остальные страницы архива. Для многостраничных архивов это часто ошибка. Проверьте шаблон вывода canonical в SEO-плагине или теме.
Практические советы по безопасности и производительности
Чем меньше лишних архивов и параметров генерирует WordPress, тем проще поддерживать сайт. Это не только про SEO, но и про нагрузку: меньше страниц в sitemap, меньше обхода, меньше мусора в логах.
- не создавайте теги для каждого случайного слова в записи;
- не плодите архивы авторов, если на сайте один автор и они не несут смысла;
- не добавляйте параметры в URL без необходимости;
- проверяйте, что закрытые страницы не используются в рекламных кампаниях и внешних ссылках;
- после правок обновляйте sitemap и отправляйте его в Search Console.
Если нужна более широкая чистка SEO-структуры, можно посмотреть и на другие инструменты WPShop, но только если они реально закрывают вашу задачу, а не добавляют ещё один слой настроек.
Главная проверка простая: в индексе остаются только те страницы, которые вы готовы показывать пользователю и поисковику как самостоятельные. Всё остальное должно быть либо закрыто от индексации, либо вообще не генерироваться без причины.