В WordPress дубли чаще всего появляются не из-за «плохого SEO», а из-за штатной логики: архивы по датам, теги, авторы, страницы пагинации, параметры сортировки, версии с ?replytocom, а иногда и дубли главной через разные URL. Если это не контролировать, поисковик тратит краулинговый бюджет на мусорные страницы, а в индексе остаются не те URL, которые вы хотите продвигать.
Ниже — рабочая схема: как найти источник дублей, что закрывать через noindex, что лучше отдавать с canonical, а что вообще убрать из генерации. Без магии и без советов в стиле «поставьте SEO-плагин и забудьте».
Какие дубли в WordPress встречаются чаще всего
Сначала полезно разделить проблему на два типа: дубли контента и дубли URL. Это не одно и то же. Один и тот же пост может открываться по нескольким адресам, а одна и та же страница архива — иметь десятки комбинаций параметров. Для поисковика это разные URL, даже если HTML почти одинаковый.
Типовые источники дублей
- архивы категорий, тегов, авторов и дат;
- страницы пагинации архивов;
- страницы вложений медиафайлов;
- служебные URL с параметрами вроде
?replytocomили UTM; - дубли главной страницы с
/page/2/,/feed/и вариациями слэша; - страницы поиска по сайту, если они индексируются без нужды;
- дубли из-за неправильного
canonicalв теме или плагине.
Диагностика: где именно у вас появляются дубли
Не начинайте с массового закрытия всего подряд. Сначала проверьте, какие URL реально попали в индекс и какие из них несут одинаковый или почти одинаковый контент. Для этого достаточно нескольких источников.
Что смотреть в первую очередь
- Google Search Console — отчеты по страницам, исключенным из индекса, и по дублированным URL;
- site: запросы в поиске — чтобы увидеть, какие служебные страницы уже индексируются;
- краулер вроде Screaming Frog — чтобы найти одинаковые title, description и canonical;
- логи сервера — если подозреваете, что бот активно ходит по мусорным параметрам;
- исходный код страниц — проверьте, какой
canonicalреально отдает тема.
Если у вас уже стоит SEO-плагин, не полагайтесь на его интерфейс вслепую. Откройте HTML страницы и убедитесь, что в <head> нет конфликтующих canonical-меток от темы и плагина одновременно.
Быстрая проверка через поиск и curl
curl -I https://example.com/category/news/page/2/Смотрите на код ответа, заголовки и редиректы. Если страница должна быть закрыта от индексации, но отдает 200 и полноценный контент, это уже повод для правки.
curl -s https://example.com/post-name/ | grep -i canonicalТак вы быстро увидите, какой URL указан как основной. Если canonical указывает не туда, поисковик может склеивать страницы неправильно.
Что закрывать через noindex, а что — через canonical
Это ключевой момент. Не все дубли нужно запрещать одинаково. Если страница полезна пользователю, но не должна ранжироваться отдельно, обычно достаточно noindex, follow. Если же это техническая копия основного URL, лучше настроить canonical на основную страницу или сделать редирект.
| Сценарий | Что делать | Комментарий |
|---|---|---|
| Теги без ценности | noindex | Оставить для навигации, но не тащить в индекс |
| Пагинация архивов | canonical на саму страницу | Не склеивать все страницы в первую, если контент реально разный |
| Вложения изображений | редирект на файл или запись | Часто лучше убрать из индекса полностью |
| Параметры сортировки | canonical на чистый URL | Если это не отдельные посадочные |
| Поиск по сайту | noindex | Почти всегда техническая страница |
Пошаговое решение: как закрыть дубли в WordPress
Шаг 1. Отключите индексацию служебных архивов
Если у вас нет редакционной задачи продвигать архивы авторов, даты или теги, их можно закрыть от индексации. Важно: не удалять их из сайта, а именно убрать из поиска.
add_action('wp_head', function () {
if (is_tag() || is_author() || is_date() || is_search()) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
}, 1);Это рабочий пример, но в реальном проекте лучше не лепить его в functions.php темы, а вынести в мини-плагин или mu-plugin. Так вы не потеряете настройку при обновлении темы.
Шаг 2. Настройте canonical для пагинации и параметров
Если у вас есть страницы с параметрами, которые не меняют смысл контента, canonical должен указывать на чистый URL без параметров. Для стандартных архивов WordPress это часто делает SEO-плагин, но после кастомизации темы лучше перепроверить.
add_filter('get_canonical_url', function ($canonical, $post) {
if (is_string($canonical) && strpos($canonical, '?') !== false) {
$canonical = strtok($canonical, '?');
}
return $canonical;
}, 10, 2);Этот пример не универсален для всех сайтов. Он полезен только там, где параметры действительно не должны создавать отдельные страницы. Если у вас есть фильтры каталога или поисковые посадочные, такой подход может навредить.
Шаг 3. Уберите страницы вложений из индекса
Страницы attachment часто индексируются автоматически, хотя полезной нагрузки в них почти нет. Обычно лучше редиректить их на файл или на родительскую запись.
add_action('template_redirect', function () {
if (is_attachment()) {
$parent = wp_get_post_parent_id(get_the_ID());
if ($parent) {
wp_redirect(get_permalink($parent), 301);
exit;
}
}
});Если у вложения нет родителя, можно редиректить на медиафайл или на главную, но это уже зависит от структуры сайта. Главное — не оставлять пустые attachment-страницы в индексе.
Шаг 4. Закройте мусорные параметры URL на уровне сервера или плагина
Если бот активно ходит по ?replytocom, UTM или другим параметрам, лучше не надеяться только на canonical. Для некоторых параметров уместен редирект на чистый URL. Для других — достаточно noindex, если они нужны аналитике.
Например, для replytocom можно убрать генерацию ссылок в комментариях через фильтрацию, но это уже зависит от темы и версии WordPress. Если параметр появляется из-за старого шаблона, сначала проверьте, не решается ли проблема обновлением темы или отключением устаревшего комментарного скрипта.
Когда лучше использовать плагин, а когда код
Если задача типовая и у вас нет сложной логики, удобнее закрыть дубли через SEO-плагин или через плагин для технической чистки сайта. Но если тема уже переопределяет canonical, а архивы и так кастомные, код даст больше контроля.
| Подход | Плюсы | Минусы |
|---|---|---|
| SEO-плагин | Быстро, без кода, удобно для редакторов | Может конфликтовать с темой и другими плагинами |
| Код в mu-plugin | Контроль и предсказуемость | Нужна проверка после обновлений |
| Редиректы на сервере | Быстро и надежно для тех. URL | Сложнее поддерживать без доступа к конфигу |
Если нужен именно инструмент для чистки дублей и лишнего мусора в WordPress, имеет смысл посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с ним полезно понимать, что именно вы закрываете и почему.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковик видит именно то, что вы задумали.
- откройте проблемный URL и проверьте
<meta name="robots">; - посмотрите, что canonical указывает на нужную страницу;
- проверьте, что attachment-страницы дают 301 или не индексируются;
- снова прогоните сайт краулером и сравните число дублей title и canonical;
- в Search Console отправьте на переобход важные страницы и дождитесь обновления статуса.
Если после правок в индексе все еще остаются старые URL, это нормально: поисковику нужно время на переобход. Но если через несколько обходов canonical и robots остаются прежними, значит, где-то есть конфликт между темой, плагином и кастомным кодом.
Частые ошибки и как их исправить
Закрыли от индексации слишком много
Частая ошибка — поставить noindex на все архивы подряд, а потом удивляться падению внутренней перелинковки и трафика по низкочастотным запросам. Если архив категории реально полезен, не убирайте его без анализа.
Canonical указывает на главную страницу
Это ломает смысл пагинации и архивов. Если у страницы есть уникальный контент, canonical должен быть либо на саму себя, либо на действительно основную версию, а не на главную «на всякий случай».
Тема и SEO-плагин пишут разные canonical
В исходнике должен быть один canonical. Если их два, поисковик может проигнорировать оба или выбрать не тот. Обычно нужно отключить генерацию canonical в теме или убрать лишний хук.
Редирект на вложения сделан без проверки родителя
Если у attachment нет родительской записи, редирект на несуществующий URL или на главную может создать цепочку ошибок. Всегда проверяйте, что именно возвращает wp_get_post_parent_id().
Практические советы по безопасности и производительности
Чем меньше лишних URL генерирует сайт, тем меньше нагрузка на обход и тем проще поддерживать структуру. Но не стоит превращать это в бесконечный набор исключений.
- не храните SEO-логику только в теме — используйте mu-plugin или отдельный мини-плагин;
- после правок очищайте кеш страницы и объектный кеш, если он есть;
- не закрывайте в
robots.txtто, что уже нужно убрать из индекса черезnoindex— это разные задачи; - не удаляйте архивы физически, если на них есть внутренняя навигация или ссылки из меню;
- проверяйте изменения на staging-копии, особенно если тема переопределяет шаблоны архивов.
Если нужен более широкий набор технических настроек — от удаления дублей до чистки служебных элементов WordPress — можно использовать Clearfy Pro как базовый слой, а точечные правила оставить в коде. Так проще не потерять контроль над тем, что именно закрыто и почему.
В рабочем проекте хороший результат выглядит просто: в индексе остаются только нужные URL, canonical совпадает с реальным основным адресом, а служебные страницы не конкурируют с контентными. Это проверяется не догадками, а исходным кодом, краулером и отчетами Search Console.