Дубли в WordPress обычно появляются не из-за одной ошибки, а из-за набора мелких настроек: архивы тегов, страницы автора, пагинация, параметры в URL, версии с www и без, HTTP и HTTPS, а иногда и одинаковые записи, доступные по нескольким адресам. Если это не привести в порядок, поисковик начинает индексировать лишние URL, а релевантность основной страницы размазывается.
Ниже — рабочая схема, как найти источник дублей, что закрывать от индексации, где ставить canonical и когда нужен редирект, а не noindex.
Как понять, что у сайта есть проблема с дублями
Первый признак — в поиске появляются страницы, которые вы не считали посадочными: архивы тегов, страницы пагинации, URL с параметрами, версии одного и того же материала с разными адресами. Второй признак — в Google Search Console растёт число проиндексированных страниц, а полезных переходов больше не становится.
Что проверить в первую очередь
- открывается ли один и тот же материал по нескольким адресам;
- есть ли в индексе страницы тегов, авторов, дат и внутренних поисков;
- не создаёт ли тема или плагин параметры сортировки, фильтров или UTM-версии страниц;
- совпадает ли основной адрес сайта с
wwwили без него, и не живут ли обе версии одновременно; - есть ли у пагинации корректный canonical на саму страницу, а не на первую страницу архива.
Если сайт небольшой, это можно увидеть вручную через поиск по оператору site:. На более крупном проекте удобнее смотреть отчёты Search Console и выгрузку URL из краулера вроде Screaming Frog или Sitebulb.
Какие дубли WordPress создаёт чаще всего
У WordPress есть несколько типовых сценариев, которые почти всегда всплывают на аудите. Они не всегда критичны сами по себе, но в сумме создают шум для индексации.
| Источник дубля | Что происходит | Что делать |
|---|---|---|
| Архивы тегов и рубрик | Один и тот же контент доступен через несколько таксономий | Оставить только полезные архивы, лишние закрыть от индексации |
| Пагинация архивов | Страницы /page/2/, /page/3/ индексируются как отдельные URL | Проверить canonical и мета-robots |
| Параметры URL | Один материал доступен с параметрами сортировки, поиска или трекинга | Нормализовать URL и при необходимости ставить canonical |
| www / non-www, http / https | Один и тот же сайт доступен по нескольким версиям | Сделать 301-редирект на одну основную версию |
| Страницы автора и даты | Архивы повторяют список записей без дополнительной ценности | Закрыть от индексации или доработать контент архивов |
Пошаговое решение: от диагностики к исправлению
Шаг 1. Выберите основную версию URL
Сначала нужно зафиксировать, какой адрес считается главным: с www или без, с https, со слешем на конце или без него. Для WordPress это важно, потому что тема, плагин кеша и сервер могут по-разному собирать ссылки.
Проверьте в админке раздел Настройки → Общие: Адрес WordPress (URL) и Адрес сайта (URL) должны совпадать с выбранной схемой. После этого настройте 301-редирект на уровне сервера или через плагин редиректов, если нет доступа к конфигу веб-сервера.
# Пример для .htaccess: принудительный HTTPS и non-www
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]Этот фрагмент нужно адаптировать под вашу схему домена. Если сайт уже работает на Nginx, правило пишется в конфиге сервера, а не в .htaccess.
Шаг 2. Закройте от индексации служебные архивы
Если архивы тегов, авторов или дат не несут самостоятельной ценности, их лучше не тащить в индекс. Это не означает удалять страницы физически — достаточно выставить noindex,follow и убрать их из XML-карты сайта, если плагин SEO это поддерживает.
В Yoast SEO, Rank Math и похожих плагинах это обычно делается в настройках таксономий и архивов. Если нужен точечный контроль кодом, можно использовать фильтр wp_robots для конкретных шаблонов:
add_filter('wp_robots', function ($robots) {
if (is_tag() || is_author() || is_date()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Такой подход полезен, когда нужно закрыть только часть архивов, а не весь сайт целиком.
Шаг 3. Проверьте canonical на страницах архива и записей
Canonical нужен, чтобы поисковик понял, какой URL считать основным. На обычной записи canonical должен указывать на саму запись. На страницах пагинации — на текущую страницу пагинации, а не на первую страницу архива, если вы не хотите ломать логику обхода.
Если canonical генерирует SEO-плагин, не дублируйте его вручную в теме. Двойной canonical — частая ошибка, из-за которой поисковик игнорирует оба варианта.
Проверить canonical можно в исходном коде страницы или через инструменты разработчика. На странице должен быть один тег вида:
<link rel="canonical" href="https://example.com/category/news/page/2/" />Шаг 4. Уберите лишние параметры из индекса
Если на сайте есть поиск по сайту, фильтры, сортировки или UTM-метки, не все такие URL должны попадать в индекс. Для UTM и других трекинговых параметров canonical обычно должен указывать на чистый URL без параметров. Для внутренних фильтров лучше вообще не допускать индексирования, если они не создают полезные посадочные страницы.
Если параметры генерируются плагином, проверьте его настройки. Если параметры добавляются вручную в шаблонах, лучше пересмотреть логику формирования ссылок.
Когда нужен редирект, а когда достаточно noindex
Это ключевой момент. Редирект нужен там, где есть один очевидный основной адрес и все альтернативы должны вести на него. Noindex нужен там, где страница полезна пользователю, но не должна конкурировать в поиске.
- 301-редирект — для дублей домена, http/https, www/non-www, старых URL после смены структуры;
- noindex — для служебных архивов, страниц поиска, некоторых пагинаций и фильтров;
- canonical — когда страница должна существовать, но есть риск появления альтернативных URL с тем же содержимым.
Если поставить noindex вместо редиректа на старый URL, поисковик может ещё долго держать в индексе обе версии. Если поставить редирект на страницу, которая должна оставаться доступной для пользователя, можно сломать навигацию и внутреннюю перелинковку.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковый робот видит именно то, что вы задумали.
- Откройте несколько проблемных URL и проверьте HTTP-статус: старые адреса должны отдавать
301, а не200. - Посмотрите исходный код страниц и убедитесь, что canonical один и указывает на правильный адрес.
- Проверьте мета-robots: у закрытых архивов должен быть
noindex. - Сравните XML-карту сайта до и после настройки: лишние архивы не должны туда попадать.
- В Search Console отправьте на повторную проверку несколько URL и отследите, как меняется статус индексации.
Для быстрой проверки редиректа удобно использовать curl:
curl -I https://example.com/old-page/В ответе должен быть 301 и заголовок Location с новым адресом.
Частые ошибки и как их исправить
Два canonical на одной странице
Такое бывает, когда canonical выводит SEO-плагин, а тема добавляет свой тег вручную. В итоге поисковик получает противоречивые сигналы. Решение простое: canonical должен генерироваться только одним источником.
Закрыли страницу noindex, но оставили её в sitemap
Это не фатально, но создаёт лишний шум. Если URL не должен индексироваться, уберите его из карты сайта. Иначе робот будет снова и снова заходить на страницу, которую вы сами просите не индексировать.
Редирект ведёт на нерелевантную страницу
Например, старый материал перенаправили не на обновлённую версию, а на главную. Для поисковика это слабый сигнал, а для пользователя — потеря контекста. Лучше вести на максимально близкий по смыслу URL.
Пагинация закрыта полностью
Иногда в попытке «почистить индекс» закрывают все страницы архива, включая нужные. Если архив реально помогает находить контент, не убирайте его целиком. Сначала оцените, есть ли у него поисковая ценность и трафик.
Практические советы по безопасности и производительности
Когда правите дубли, легко случайно перегрузить сайт лишними проверками и правилами. Не стоит вешать тяжёлую логику на каждый запрос, если задачу можно решить настройками SEO-плагина или серверным редиректом.
- не дублируйте редиректы в
.htaccess, Nginx и плагине одновременно; - не добавляйте собственные SQL-запросы на каждом хите ради проверки canonical;
- после изменений очистите кеш страницы и объектный кеш, если он есть;
- если используете плагин для SEO и чистки дублей, проверьте, не конфликтует ли он с темой по выводу canonical и robots.
Если нужен инструмент для чистки дублей, управления мета-тегами и отключения лишних архивов, имеет смысл смотреть в сторону решений вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином базовая логика остаётся той же: сначала определить источник дубля, потом выбрать правильный способ устранения.
Мини-чек-лист перед публикацией правок
- основная версия домена выбрана и принудительно редиректится;
- служебные архивы закрыты или удалены из sitemap;
- canonical на страницах один и корректный;
- старые URL отдают 301 на релевантную страницу;
- в Search Console нет массового роста дублей после обновления;
- кеш очищен, а изменения видны не только в админке, но и в публичной версии.
Если после правок дубли всё ещё остаются, обычно проблема не в SEO-плагине, а в теме, которая генерирует альтернативные шаблоны URL, или в плагине фильтров/поиска, который создаёт новые адреса без контроля индексации. В таких случаях проще сначала найти источник URL, а уже потом решать, закрывать его, канонизировать или перенаправлять.
