В WordPress дубли чаще всего появляются не из-за «плохого SEO», а из-за штатной логики: архивы тегов, страницы автора, вложения медиафайлов, пагинация, параметры сортировки и поиска. Если не разобраться, поисковик начинает тратить обход на мусорные URL, а в отчётах видны страницы с одинаковым или почти одинаковым содержимым.
Ниже — рабочая схема: как найти такие URL, чем их закрывать и как проверить, что вы не сломали индексацию полезных страниц.
Какие дубли в WordPress встречаются чаще всего
Сначала полезно отделить реальные проблемы от ложной тревоги. Не каждый похожий URL нужно закрывать. Например, пагинация архива может быть нормальной частью сайта, а вот страницы вложений изображений почти всегда бесполезны для индексации.
Типовые источники дублей
- страницы вложений вида
/image-name/; - архивы тегов, если они дублируют рубрики или не несут уникальной ценности;
- страницы автора на одиночных сайтах;
- страницы поиска по сайту;
- URL с параметрами
?replytocom=,?utm_, сортировкой и фильтрами; - пагинация архивов, если она индексируется без необходимости;
- версии с и без слеша, http и https, www и без www, если редиректы настроены криво.
Диагностика: где искать проблему
Начинать лучше не с плагина, а с проверки того, что уже попало в индекс и как сайт отдает мета-данные. Это помогает не закрыть лишнее.
Что проверить вручную
- откройте несколько архивов и одиночных записей в браузере;
- посмотрите исходный код страницы и найдите
<meta name="robots"; - проверьте, есть ли
canonicalи совпадает ли он с основной версией URL; - сравните заголовки ответа сервера для дублей и канонических страниц;
- посмотрите отчёты в Google Search Console по страницам, исключённым из индекса.
Если у вас есть доступ к командной строке, быстро проверить заголовки можно так:
curl -I https://example.com/sample-page/В ответе важно увидеть корректный код ответа, редирект на основную версию сайта и отсутствие неожиданных цепочек.
Что закрывать, а что оставлять в индексе
Здесь полезно не идти по принципу «закрыть всё, что похоже на архив». У WordPress есть страницы, которые могут приносить трафик и помогать навигации. Если у архива есть уникальный текст, нормальная структура и поисковый спрос, его можно оставить открытым.
| Тип страницы | Обычно индексировать? | Комментарий |
|---|---|---|
| Одиночные записи | Да | Это основной контент сайта |
| Страницы вложений | Нет | Чаще всего это пустые или слабые страницы |
| Поиск по сайту | Нет | Динамические результаты не должны плодить индекс |
| Теги | Зависит | Если теговые архивы пустые или дублят рубрики, лучше закрыть |
| Авторские архивы | Зависит | На одиночном сайте обычно не нужны |
| Пагинация | Обычно да | Если она нужна для обхода каталога и архива |
Пошаговое решение: как закрыть дубли в WordPress
Самый безопасный путь — комбинировать настройки SEO-плагина, редиректы и точечный код. Если у вас уже стоит плагин для технической чистки, часть задач можно закрыть там. Например, в Clearfy Pro есть инструменты для удаления дублей и технической оптимизации, но даже с плагином полезно понимать, что именно он меняет.
Шаг 1. Закройте страницы вложений
Для вложений лучше не просто ставить noindex, а редиректить их на родительскую запись или сам файл, если это уместно. В WordPress это можно сделать кодом:
add_action('template_redirect', function () {
if (is_attachment()) {
$parent = wp_get_post_parent_id(get_queried_object_id());
if ($parent) {
wp_redirect(get_permalink($parent), 301);
exit;
}
wp_redirect(home_url('/'), 301);
exit;
}
});Такой вариант лучше, чем оставлять отдельную страницу вложения в индексе. Но если у вас медиа-архив используется осознанно, сначала проверьте, не ломает ли редирект внутренние ссылки.
Шаг 2. Уберите из индекса служебные архивы
Для поиска, тегов или авторов можно управлять индексацией через SEO-плагин или через фильтры. Если нужен точечный контроль без лишней магии, можно добавить noindex для определённых типов архивов:
add_filter('wp_robots', function (array $robots) {
if (is_search() || is_attachment()) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
}
if (is_author() && !is_multi_author()) {
$robots['noindex'] = true;
}
return $robots;
});Здесь важно не путать noindex и редирект. noindex оставляет страницу доступной, но просит поисковик не включать её в выдачу. Редирект отправляет пользователя и робота на другой URL.
Шаг 3. Проверьте canonical
Если на странице есть дублирующие параметры, canonical должен указывать на чистую версию URL. В большинстве тем и SEO-плагинов это работает автоматически, но после кастомных шаблонов стоит проверить. В исходнике страницы ищите строку:
<link rel="canonical" href="https://example.com/post/" />Если canonical указывает на URL с параметрами или на несуществующую версию, поисковик может игнорировать ваш noindex или считать страницу отдельной сущностью.
Шаг 4. Закройте мусорные параметры URL
Параметры вроде ?replytocom= и UTM-метки часто создают десятки вариантов одного и того же адреса. Для UTM обычно достаточно корректного canonical на чистый URL. Для replytocom лучше отключить саму генерацию, если она не нужна, или хотя бы убедиться, что такие ссылки не индексируются.
Если у вас есть доступ к серверной конфигурации, редиректы и правила для параметров лучше делать на уровне веб-сервера, а не только в PHP. Но в WordPress-проекте без доступа к nginx/apache можно начать с canonical и robots.
Как проверить, что решение сработало
Проверка нужна не только в Search Console. Сначала убедитесь, что страница отдает то, что вы задумали.
- откройте закрытую страницу и проверьте наличие
noindexв исходнике; - убедитесь, что canonical ведёт на основную версию;
- проверьте HTTP-статус редиректа для вложений и служебных URL;
- посмотрите, не исчезли ли из индекса важные архивы;
- сравните количество страниц в отчёте «Страницы» до и после изменений.
Для быстрой проверки можно использовать и браузер, и curl:
curl -I https://example.com/?replytocom=123
curl -s https://example.com/sample-page/ | grep -i canonicalЕсли canonical не выводится, ищите проблему в теме или SEO-плагине. Если редирект есть, но ведёт не туда, проверьте правила в template_redirect и конфликтующие плагины.
Частые ошибки и как их исправить
Закрыли рубрики, а теги оставили открытыми без смысла
Это частая перекосная настройка. В итоге теги продолжают плодить слабые страницы, а рубрики, которые реально нужны для навигации, исчезают из индекса. Решение простое: оцените каждую таксономию отдельно, а не по названию.
Поставили noindex, но не убрали внутренние ссылки
Если на закрытые архивы ведут меню, блоки и хлебные крошки, они всё равно будут обходиться ботом. Это не критично, но если цель — сократить мусор, уберите лишние ссылки или замените их на более полезные посадочные страницы.
Сделали редирект всех вложений на главную
Это грубая ошибка. Для картинок и файлов, привязанных к конкретной записи, лучше вести пользователя на родительский контент. Массовый редирект на главную ухудшает поведение пользователей и может запутать поисковик.
Отключили индексацию через robots.txt
Robots.txt не решает задачу полностью. Если URL уже в индексе, запрет на обход не гарантирует его удаление. Для дублей обычно нужен noindex, canonical или редирект — в зависимости от сценария.
Безопасность и производительность: что учесть до правок
Любые правки в functions.php лучше сначала тестировать в staging-копии. Ошибка в условии может случайно закрыть весь сайт от индексации или сломать редиректы.
- делайте резервную копию перед изменениями;
- не смешивайте несколько SEO-плагинов с одинаковыми функциями;
- проверяйте, не дублируют ли друг друга правила темы, плагина и сервера;
- после правок очистите кеш страницы и объектный кеш, если он есть;
- не закрывайте страницы, которые уже дают трафик без анализа.
Если нужен более прикладной набор инструментов для технической чистки сайта, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, какие именно URL вы закрываете и почему.
Когда лучше не трогать индексацию вручную
Если сайт маленький, структура простая и в индексе нет явных дублей, не стоит превращать техническую настройку в бесконечную оптимизацию. Сначала исправьте действительно проблемные URL: вложения, поиск, параметры, пустые архивы. Потом уже смотрите на теги, авторов и пагинацию.
Хороший критерий простой: если страница не несёт самостоятельной ценности для пользователя и не нужна для обхода сайта, её можно закрывать. Если страница помогает навигации, собирает тематический спрос или поддерживает структуру контента, решение нужно принимать после проверки в Search Console и на живом трафике.