Дубли в WordPress редко выглядят как одна и та же страница с одинаковым адресом. Чаще это набор похожих URL: версии с и без слэша, архивы тегов, пагинация, страницы автора, параметры сортировки, а иногда и служебные страницы темы или плагина. Для поисковика это не «мелочь», а лишние варианты одной сущности, из-за которых размывается вес, а в отчётах Search Console появляются странные исключения.
Если задача не в том, чтобы «закрыть всё подряд», а в том, чтобы оставить в индексе нужные страницы и убрать мусор, сначала надо понять источник дублей. В WordPress это обычно не один плагин, а комбинация настроек ядра, темы и SEO-логики.
Что именно считать дублем в WordPress
Перед правками полезно разделить проблему на несколько типов. Это экономит время и помогает не сломать индексацию случайным noindex на нужной странице.
Технические дубли URL
Сюда попадают адреса, которые ведут на один и тот же контент: /page и /page/, http и https, www и без www, а также параметры вроде ?utm_source= или ?replytocom=. Если сервер и WordPress не приводят их к одному каноническому виду, поисковик может видеть несколько версий одной страницы.
Контентные дубли
Это архивы рубрик, тегов, авторов, дат, страниц пагинации и поиск по сайту. Они не всегда вредны сами по себе, но часто создают много тонких страниц с одинаковыми заголовками и фрагментами текста. Для небольшого сайта это особенно заметно: индекс забивается страницами, которые не несут самостоятельной ценности.
Дубли, созданные темой или плагином
Некоторые темы выводят отдельные шаблоны для AMP-версий, мобильных страниц, блоков «похожие записи» или собственных архивов. Плагины могут добавлять страницы фильтров, параметров и сортировки. Если не проверить, что именно создаёт URL, можно долго лечить не ту причину.
Диагностика: где искать источник дублей
Начинать лучше не с удаления, а с фиксации фактов. Список URL можно собрать вручную, через Search Console и через краулер вроде Screaming Frog или Sitebulb. Но даже без платных инструментов уже видно многое.
- Откройте несколько страниц сайта в браузере и сравните адреса с разными вариантами слэша, www и http/https.
- Проверьте исходный код страницы: есть ли тег
link rel="canonical"и совпадает ли он с основным URL. - Посмотрите в Search Console разделы «Страницы» и «Исключено» — там часто видны дубли по параметрам, каноникализации и альтернативным версиям.
- Проверьте архивы тегов, авторов и дат: если они пустые или почти пустые, это кандидаты на закрытие от индексации.
- Если есть плагин кеша или SEO-плагин, временно посмотрите, не генерирует ли он отдельные версии для AMP, RSS, печати или предпросмотра.
Если нужен быстрый способ увидеть каноникализацию, можно проверить заголовки и HTML через curl:
curl -I https://example.com/page/
curl -s https://example.com/page/ | grep -i canonicalЕсли у страницы нет канонического адреса или он указывает не туда, это уже конкретная точка для исправления.
Пошаговое решение: что править в первую очередь
Логика простая: сначала приводим к одному виду адреса, потом убираем лишние архивы, затем чистим параметры и служебные страницы. Не наоборот.
1. Настройте единый основной URL
В Настройки → Общие проверьте, что адрес WordPress и адрес сайта совпадают по протоколу и домену. Если сайт должен жить на https://www., а в настройках указан вариант без www, вы получите лишние редиректы и путаницу в каноникализации.
На уровне сервера тоже должен быть один главный вариант. Для Apache это обычно делается через .htaccess, для Nginx — в конфигурации виртуального хоста. Пример для редиректа на HTTPS и без www:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]Это не решает все дубли, но убирает базовую путаницу между версиями домена.
2. Проверьте canonical на страницах и архивах
Если SEO-плагин установлен, он обычно сам выводит canonical. Проблема возникает, когда тема или другой плагин добавляет второй canonical, либо canonical указывает на страницу с параметрами. В таком случае поисковик может игнорировать сигнал.
В шаблонах темы не стоит вручную печатать canonical, если это уже делает SEO-плагин. Если же вы пишете кастомный шаблон и хотите проверить, что canonical есть только один, смотрите исходный код страницы и ищите дублирующиеся теги.
3. Закройте от индексации пустые архивы
Если на сайте много тегов, но почти все они пустые или содержат по одной записи, это типичный источник тонких дублей. В таких случаях лучше не плодить архивы ради архива. В SEO-плагине можно отключить индексацию тегов, дат и авторов, если они не несут ценности.
Если нужен более гибкий подход, можно задать noindex для конкретных типов архивов через wp_head:
add_action('wp_head', function () {
if (is_tag() || is_date() || is_author()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Такой код имеет смысл только если вы понимаете, какие архивы реально нужны. Для новостного или экспертного сайта авторские страницы могут быть полезны, а для небольшого корпоративного блога — нет.
4. Уберите параметры, которые создают мусорные URL
Частая проблема — параметры сортировки, фильтров, UTM-метки и внутренние служебные параметры. Для внешних меток обычно достаточно canonical на чистую страницу. Для внутренних параметров лучше не допускать их индексации и, по возможности, не генерировать лишние ссылки.
Если у вас есть собственный код, который строит ссылки с параметрами, проверьте, не попадают ли они в меню, хлебные крошки и блоки «похожие записи». Иногда дубль создаёт не SEO-плагин, а обычная функция add_query_arg(), которой злоупотребили в теме.
Когда лучше править кодом, а когда плагином
Не все дубли стоит лечить вручную. Если проблема типовая, плагин SEO или чистки сайта экономит время. Если же дубль создаёт конкретный шаблон или кастомный тип записи, код даёт более точный контроль.
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Архивы, canonical, robots, базовая индексация | Меньше контроля над нестандартной логикой |
| Код в теме/плагине | Кастомные архивы, особые условия noindex, служебные страницы | Нужно тестировать после обновлений |
| Серверный редирект | www/без www, http/https, слэш в конце | Не решает контентные дубли |
Если на сайте уже есть лишние архивы, а вы не хотите вручную ковырять шаблоны, можно использовать инструменты для чистки SEO-обвязки. Например, у Clearfy Pro есть функции для отключения дублей и служебных элементов, но применять их стоит только после проверки, какие именно архивы и мета-теги реально нужны сайту: https://wpshop.ru/plugins/clearfy.
Проверка результата после внедрения
После изменений не ограничивайтесь открытием главной страницы. Нужно проверить, что поисковик видит именно ту структуру, которую вы задумали.
- Откройте несколько старых вариантов URL и убедитесь, что они 301-редиректятся на основной адрес.
- Проверьте исходный код: canonical должен быть один и вести на чистый URL.
- Посмотрите, не появились ли
noindexна важных страницах записей и страницах услуг. - В Search Console отправьте на переобход несколько ключевых URL и проверьте, как они классифицируются.
- Если использовали изменения в коде, очистите кеш страницы и объектный кеш, иначе вы будете проверять старую версию.
Для быстрой локальной проверки редиректов удобно смотреть заголовки ответа:
curl -I https://example.com/tag/test/
curl -I https://example.com/?utm_source=testЕсли редиректов нет, а canonical есть, это не всегда ошибка. Но если в индексе остаются обе версии, значит поисковик не получил достаточно сильный сигнал о предпочтительном URL.
Частые ошибки и как их исправить
Ставят noindex на всё подряд
Это самая частая реакция на проблему дублей. В итоге из индекса исчезают не только теги и даты, но и полезные страницы рубрик, которые приводили трафик. Исправление простое: сначала составьте список архивов, потом решайте по каждому типу отдельно.
Оставляют два canonical одновременно
Так бывает, когда canonical выводит SEO-плагин, а разработчик добавляет свой код в header.php. Поисковик может проигнорировать оба сигнала. Решение — оставить один источник canonical и убрать ручную вставку.
Редиректят всё на главную
Это грубая ошибка. Если страница была удалена, лучше вернуть 410 Gone или сделать релевантный 301 на ближайший аналог, а не отправлять любой битый URL на главную. Массовый редирект на главную ухудшает качество сигналов и путает пользователей.
Не чистят кеш после правок
Из-за кеша кажется, что код не работает. На практике вы просто видите старый HTML. После изменения canonical, robots или редиректов очищайте page cache, object cache и, если есть, CDN.
Практические советы по безопасности и производительности
Чем меньше лишней логики в шаблоне, тем проще сопровождать сайт. Не стоит держать в теме самописный код для SEO, если его можно вынести в отдельный мини-плагин или в mu-plugin. Тогда он не пропадёт при смене темы и не смешается с версткой.
Если на сайте много архивов и фильтров, следите за количеством запросов к базе. Иногда проблема дублей идёт рядом с проблемой производительности: каждый новый архив — это ещё один запрос, ещё один шаблон и ещё одна страница для кеша. В таких случаях полезно отключить неиспользуемые таксономии, убрать лишние виджеты и проверить, не создаёт ли тема отдельные страницы для каждого мелкого тега.
Для контентных проектов полезно периодически пересматривать структуру рубрик и тегов. Если тегов стало слишком много, а часть из них не имеет самостоятельного смысла, лучше объединить их или закрыть от индексации, чем держать десятки пустых архивов ради формального порядка.
Если нужна более широкая чистка сайта вместе с дублями, служебными страницами и лишними SEO-элементами, удобнее делать это в одном месте, а не разносить по нескольким плагинам. Но любое такое решение всё равно требует ручной проверки: автоматическое отключение не знает, какие архивы важны именно для вашего проекта.