Дубли в WordPress обычно появляются не из-за одной ошибки, а из-за набора мелких настроек: архивы тегов и авторов, страницы пагинации, версии с параметрами, вложения медиафайлов, HTTP/HTTPS, www/без www, а иногда и из-за темы или SEO-плагина, который одновременно генерирует несколько вариантов одной и той же страницы. Если это не разрулить, поисковик начинает индексировать лишние URL, а вес страниц размазывается по дублям.
Ниже — рабочая схема, которая помогает сначала понять источник дублей, а потом убрать их без хаотичных редиректов и потери нужных страниц.
Как понять, что проблема именно в дублях
Симптомы обычно видны в Search Console, логах сервера и в самом поиске. Но важно не путать дубли с обычной пагинацией или с похожими страницами каталога. Для WordPress типичный признак — одна и та же страница доступна по нескольким адресам, а в индексе оказываются не те версии, которые вы считали основными.
Что проверить в первую очередь
- в Search Console откройте отчет по страницам и посмотрите, какие URL помечены как дубли или как страницы с выбранной пользователем канонической версией;
- проверьте, не индексируются ли архивы
/tag/,/author/, страницы вложений и результаты внутреннего поиска; - сравните ответы сервера для
httpиhttps, а также дляwwwи безwww; - посмотрите, не появляются ли в индексе URL с параметрами вроде
?replytocom=,?amp,?utm_...или служебными query string; - проверьте, не создает ли тема отдельные шаблоны для одного и того же контента, например карточку записи и страницу автора с тем же текстом.
Если у вас есть доступ к серверным логам, полезно посмотреть, какие URL реально чаще всего запрашивают боты. Иногда проблема не в том, что страница уже в индексе, а в том, что бот постоянно ходит по мусорным адресам и тратит краулинговый бюджет.
Какие дубли в WordPress встречаются чаще всего
Чтобы не лечить симптомы, полезно разделить дубли по источнику. У каждого источника свой способ исправления: где-то нужен редирект, где-то каноникал, а где-то достаточно закрыть страницу от индексации.
| Источник дубля | Что делать | Компромисс |
|---|---|---|
| HTTP/HTTPS, www/без www | Сделать один канонический вариант и редирект 301 | Нужна аккуратная настройка сервера или плагина |
| Архивы тегов, авторов, дат | Закрыть от индексации или ограничить каноникал | Часть страниц перестанет участвовать в поиске |
| Вложения медиафайлов | Редиректить attachment pages на сам файл или родительскую запись | Нужно проверить старые ссылки |
| Параметры URL | Нормализовать адреса и убрать лишние параметры | Не все параметры можно закрыть без побочных эффектов |
| Пагинация и фильтры | Оставить нужные страницы, лишние закрыть от индексации | Нельзя бездумно закрывать все страницы 2+ |
Пошаговое решение: от аудита до исправления
1. Зафиксируйте канонический вариант сайта
Сначала выберите один основной формат домена и протокол. Если сайт должен жить на https://example.ru, не оставляйте параллельно доступными http://example.ru, https://www.example.ru и http://www.example.ru без 301-редиректа. Это базовая нормализация, без которой дальше бессмысленно разбирать более тонкие дубли.
На уровне WordPress проверьте значения siteurl и home в wp_options. Если они расходятся с реальным адресом сайта, WordPress может генерировать ссылки в неправильном формате.
wp option get home
wp option get siteurlЕсли используете WP-CLI и значения неверные, исправляйте их только после проверки, что веб-сервер уже отдает нужный канонический адрес через 301.
2. Уберите лишние архивы из индекса
Для большинства контентных сайтов архивы тегов и авторов не должны конкурировать с основными статьями. Если архивы не несут самостоятельной ценности, их лучше закрыть от индексации через SEO-плагин или через фильтры темы. Это не значит, что их нужно удалять: страницы могут оставаться доступными для навигации, но не попадать в поиск.
Если вы используете плагин уровня Clearfy Pro, там удобно отключать лишние архивы и служебные страницы без правки кода темы. Это особенно полезно, когда в проекте уже есть несколько источников генерации мета-тегов и каноникалов.
3. Настройте canonical для страниц, где есть вариации URL
Канонический URL нужен там, где одна и та же сущность доступна по нескольким адресам, но редирект делать нельзя или нежелательно. Например, для страниц с параметрами сортировки, фильтрации или для некоторых архивов. В WordPress canonical обычно выводится через rel=canonical в <head>, и важно, чтобы его не перезаписывали одновременно тема и SEO-плагин.
Если вы пишете код сами, можно добавить каноникал для конкретного типа страниц через хук wp_head. Но не делайте это поверх уже работающего SEO-плагина без проверки — получите два канонических URL на одной странице.
add_action('wp_head', function () {
if (is_search() || is_404()) {
return;
}
if (is_singular()) {
echo '<link rel="canonical" href="' . esc_url(get_permalink()) . '" />' . "\n";
}
}, 1);Этот пример уместен только если вы точно знаете, что тема или SEO-плагин не выводят canonical сами. Иначе лучше управлять настройкой в одном месте.
4. Закройте или перенаправьте вложения медиафайлов
Страницы вложений — частый источник мусора в индексе. WordPress создает отдельную страницу attachment для изображения, и если ее не обработать, поисковик может индексировать пустую или почти пустую страницу вместо полезного контента.
Практичнее всего сделать редирект со страницы вложения на родительскую запись, а если родителя нет — на сам файл или на главную медиатеку, в зависимости от структуры сайта. Для этого можно использовать стандартный фильтр template_redirect.
add_action('template_redirect', function () {
if (!is_attachment()) {
return;
}
$parent_id = get_post_field('post_parent', get_queried_object_id());
if ($parent_id) {
wp_redirect(get_permalink($parent_id), 301);
exit;
}
$file_url = wp_get_attachment_url(get_queried_object_id());
if ($file_url) {
wp_redirect($file_url, 301);
exit;
}
});После этого проверьте, что старые attachment URL отдают 301, а не 200. Если они продолжают открываться как обычные страницы, значит редирект не сработал или его перебивает другой плагин.
Диагностика через код и инструменты
Когда дублей много, вручную их не собрать. Удобнее пройтись по сайту списком и посмотреть, какие типы страниц реально доступны. Для этого можно использовать WP-CLI и базовые запросы к базе данных.
Проверка архивов и служебных страниц
wp post list --post_type=post --fields=ID પોસ્ટ_titleКоманда выше сама по себе не ищет дубли, но помогает быстро понять, сколько у вас контента и есть ли смысл держать открытыми архивы авторов, дат и тегов. Для более точной проверки полезно смотреть, какие таксономии реально используются, а какие только создают шум.
Если нужен быстрый аудит URL, можно выгрузить список опубликованных записей и сравнить его с тем, что видит поисковик. Для этого часто хватает sitemap.xml и отчета Search Console. Если sitemap содержит страницы, которые вы не хотите индексировать, проблема не в поиске, а в генерации карты сайта.
Проверка ответа сервера
Перед тем как править редиректы, убедитесь, что сервер не отдает разные коды для разных вариантов URL. Это можно проверить curl’ом:
curl -I https://example.ru
curl -I http://example.ru
curl -I https://www.example.ru
curl -I https://example.ru/sample-post/В нормальной схеме только один вариант должен отдавать 200, а остальные — 301 на канонический адрес. Если видите цепочку из нескольких редиректов, ее стоит сократить: лишние переходы замедляют обход и усложняют диагностику.
Как проверить, что решение сработало
После правок не ограничивайтесь визуальной проверкой в браузере. Нужны минимум три проверки: HTTP-ответ, canonical и индексация.
- проверьте, что неканонические версии URL отдают
301на основной адрес; - откройте страницу и посмотрите исходный код: canonical должен быть один и вести на правильный URL;
- убедитесь, что в sitemap остались только нужные типы страниц;
- в Search Console отправьте на переобход важные страницы и проверьте, не появились ли новые сообщения о дублях;
- через несколько дней сравните количество мусорных URL в отчете по страницам и в поиске по сайту.
Если вы закрывали архивы тегов или авторов, не ждите мгновенного исчезновения страниц из индекса. Поисковик может держать их какое-то время, пока не переобойдет сайт. Важно, чтобы новые сигналы были однозначными: canonical, noindex или редирект.
Частые ошибки и как их исправить
Делают редирект на все подряд
Самая частая ошибка — отправить все похожие URL на главную. Так теряются полезные страницы, а поисковик получает слишком грубый сигнал. Редирект нужен только там, где есть очевидный дубль: attachment pages, http на https, www на non-www, старые URL после смены структуры.
Ставят noindex и оставляют страницу в sitemap
Это конфликтующий сигнал. Если страница закрыта от индексации, но продолжает попадать в sitemap, вы сами сообщаете поисковику, что она важна. Для служебных архивов лучше убрать их и из индекса, и из карты сайта.
Каноникал выводят дважды
Так бывает, когда canonical добавляет и тема, и SEO-плагин, или когда его вручную вставили в wp_head без проверки. В результате поисковик может проигнорировать оба сигнала. Оставьте один источник правды.
Закрывают пагинацию без разбора
Страницы 2, 3 и дальше не всегда дубль. Если у вас большой архив записей или категория с реальным трафиком, пагинация может быть полезной. Закрывать ее стоит только после анализа, а не по принципу «все, что не главная, лишнее».
Не проверяют вложения после миграции
После переноса сайта attachment pages часто остаются доступными, даже если раньше их закрывали. Это особенно заметно после смены темы или SEO-плагина. После миграции обязательно прогоните список старых медиа-URL и проверьте, что они ведут туда, куда нужно.
Что помогает держать дубли под контролем дальше
Если сайт регулярно растет, лучше сразу зафиксировать правила генерации URL и мета-тегов. Не смешивайте несколько SEO-решений, не плодите кастомные шаблоны архивов без необходимости и не включайте служебные страницы в индекс «на всякий случай».
Для проектов, где много технического мусора из коробки WordPress, удобно использовать единый инструмент для чистки дублей и служебных страниц, чтобы не разносить настройки по теме и нескольким плагинам. Но даже в этом случае базовая проверка остается той же: один канонический адрес, один ответ сервера, один источник мета-данных.
Если после всех правок дубли продолжают появляться, обычно причина не в поиске, а в генерации URL на стороне темы, плагина кеша или фильтров. Тогда уже имеет смысл смотреть шаблоны archive.php, single.php, настройки хлебных крошек и то, как именно формируется canonical в <head>.
