Как найти и убрать дубли страниц в WordPress на VDS

Автор: Виктория Ковалева | Опубликовано: 11.09.2026

На VDS у WordPress дубли страниц обычно появляются не из-за одной ошибки, а из-за набора мелких настроек: доступны версии с www и без него, HTTP и HTTPS, страницы с параметрами, архивы тегов и авторов, а иногда еще и дубли от темы или SEO-плагина. В результате поисковик видит несколько адресов с одинаковым контентом и начинает выбирать канонический URL сам. Это почти всегда хуже, чем явно задать правила на стороне сайта.

Ниже — рабочая схема: как быстро найти источник дублей, что править в WordPress и на сервере, и как проверить, что проблема действительно закрыта.

Когда дубли уже есть: как это заметить без догадок

Первый признак — в индексе появляются одинаковые страницы с разными адресами. Например, одна и та же запись открывается как https://site.ru/post/, https://www.site.ru/post/, http://site.ru/post/ или https://site.ru/post/?utm_source=.... Второй признак — в Search Console растет число страниц, которые «дублируются, Google выбрал другой канонический URL».

Проверять нужно не только главную и записи, но и типовые источники дублей:

архивы тегов и рубрик;
страницы автора;
страницы вложений медиафайлов;
поиск по сайту;
страницы с параметрами сортировки, фильтрации или UTM;
версии сайта с разным протоколом и поддоменом.

Быстрая диагностика через сервер и браузер

Сначала проверьте, что один и тот же контент не отдается с разными кодами ответа и без редиректа. Для этого удобно использовать curl:

curl -I https://site.ru/post-name/

curl -I http://site.ru/post-name/

curl -I https://www.site.ru/post-name/

В норме все варианты должны вести к одному финальному URL с 301. Если один из вариантов отдает 200 OK без перенаправления, это уже источник дубля.

Еще один полезный тест — посмотреть канонический тег в HTML:

curl -s https://site.ru/post-name/ | grep -i canonical

Если canonical указывает не на тот адрес, который вы считаете основным, поисковик может индексировать не ту версию.

Откуда дубли берутся в WordPress

На практике чаще всего проблема сидит в трех местах: настройках WordPress, SEO-плагине и серверных редиректах. Если чинить только одно место, дубли могут вернуться после обновления темы или плагина.

Источник	Как проявляется	Что делать
WordPress Address / Site Address	Сайт открывается и с `www`, и без него	Выбрать один вариант и закрепить редиректом
SEO-плагин	Дубли архивов, тегов, авторов, страниц вложений	Закрыть лишние типы архивов или поставить noindex
Сервер	HTTP и HTTPS, www и non-www доступны как отдельные версии	Настроить 301 на уровне Nginx/Apache
Тема/кастомный код	Появляются страницы с параметрами и одинаковыми заголовками	Проверить шаблоны, query vars, фильтры и canonical

Пошаговое решение: закрываем основные дубли

1. Зафиксируйте один основной URL

В админке WordPress проверьте Настройки → Общие. Адрес WordPress и адрес сайта должны совпадать по протоколу и домену. Если основной вариант — https://site.ru, не оставляйте в настройках http://www.site.ru или другой вариант.

После этого на сервере настройте принудительный редирект на один канонический адрес. Для Nginx это может выглядеть так:

server {
    listen 80;
    server_name site.ru www.site.ru;
    return 301 https://site.ru$request_uri;
}

server {
    listen 443 ssl http2;
    server_name www.site.ru;
    return 301 https://site.ru$request_uri;
}

Если у вас Apache, логика та же: все варианты должны сводиться к одному URL через 301, а не через мета-теги или JavaScript.

2. Уберите дубли архивов и служебных страниц

Если сайт не нуждается в индексировании тегов, авторов или страниц вложений, их лучше закрыть на уровне SEO-плагина. Это не «магическая оптимизация», а способ не плодить однотипные страницы, которые не дают поисковому трафику.

Для вложений особенно важен редирект на сам файл или на родительскую запись. Иначе медиа-страницы часто становятся тонкими дублями без смысла для пользователя.

Если используете SEO-плагин, проверьте:

noindex для архивов тегов, если они не несут ценности;
noindex для архивов авторов на одиночных проектах;
отключение страниц вложений или редирект на файл/родителя;
канонический URL на страницах с пагинацией и параметрами.

3. Нормализуйте параметры в URL

Параметры ?utm_, ?replytocom=, сортировка и фильтры часто создают технические дубли. Не всегда нужно их полностью блокировать, но нужно исключить их из индекса и не давать им становиться отдельными страницами.

Для комментариев WordPress иногда генерирует адреса вида ?replytocom=1. Если они индексируются, проверьте настройки темы и плагинов комментариев, а также каноникал на странице записи. Для UTM-параметров обычно достаточно корректного canonical на чистый URL.

4. Проверьте canonical и robots meta

На каждой индексируемой странице должен быть один понятный canonical. Если SEO-плагин и тема одновременно выводят canonical, можно получить конфликт. В исходнике страницы должен быть только один тег:

<link rel="canonical" href="https://site.ru/post-name/" />

Если canonical отсутствует или указывает на URL с параметрами, это нужно исправить в теме или SEO-плагине. Для технических страниц, которые не должны попадать в индекс, используйте noindex,follow, а не просто удаляйте ссылки.

Если дубли создает тема или плагин: где искать в коде

Иногда проблема не в настройках, а в шаблоне. Например, тема может выводить отдельные страницы для одного и того же контента через кастомные query vars, а плагин — создавать дополнительные архивы или фильтры.

Если вы правите тему, проверьте, не генерируются ли ссылки вручную без home_url() и trailingslashit(). Жестко прописанные адреса часто ломают каноникал при смене домена или протокола.

Для принудительного canonical на отдельных типах страниц можно использовать фильтр wpseo_canonical, если у вас Yoast SEO, или аналогичный механизм вашего SEO-плагина. Пример ниже показывает общий подход: для страниц с параметром replytocom возвращаем чистый URL записи.

add_filter('wpseo_canonical', function ($canonical) {
    if (isset($_GET['replytocom']) && is_singular()) {
        return get_permalink();
    }

    return $canonical;
});

Если у вас не Yoast, не пытайтесь слепо переносить этот код. Сначала проверьте, какой SEO-плагин установлен и какие у него есть фильтры. Логика важнее конкретного хука.

Проверка результата после внедрения

После правок не ограничивайтесь открытием страницы в браузере. Нужно проверить три вещи: редирект, canonical и индексируемость.

все варианты URL отдают 301 на один адрес;
в HTML есть один canonical без параметров;
служебные страницы не отдают 200 OK там, где должен быть noindex или редирект;
в Search Console уменьшается число дублей и страниц с выбранным Google каноническим URL.

Полезно прогнать несколько адресов через curl -I и сравнить ответы. Если редирект есть, но canonical остался старым, поисковик может продолжать видеть несогласованность. Если canonical верный, но сервер отдает две версии с 200, проблема тоже не решена.

Мини-чек-лист перед повторной индексацией

один домен и один протокол;
редирект с www или без него на основной вариант;
отключены или закрыты лишние архивы;
вложенные страницы не индексируются без необходимости;
canonical совпадает с основным URL;
параметры не создают отдельные индексируемые страницы.

Частые ошибки и как их исправить

Редирект настроили только в WordPress

Если редирект делает только плагин, а сервер по-прежнему отдает обе версии, дубли могут появляться до загрузки WordPress. Правильнее закрывать канонизацию на уровне Nginx или Apache, а WordPress использовать как дополнительный слой.

Закрыли все архивы подряд

Это частая перегибка. Не все архивы бесполезны. Иногда рубрики дают трафик и помогают структуре сайта. Закрывать нужно не «всё подряд», а только то, что реально создает мусор или не несет ценности.

Удалили страницы вложений без проверки ссылок

Если на вложения уже есть внутренние ссылки, массовое удаление может дать 404. Безопаснее сначала настроить редирект вложений на родительскую запись или сам файл, а потом уже чистить остатки.

Не проверили тему после обновления

После обновления темы или SEO-плагина canonical, robots meta и архивы могут измениться. Если у вас кастомная тема, держите под контролем шаблоны header.php, functions.php и вывод мета-тегов.

Что делать, если нужен аккуратный технический контроль без ручной возни

Если на сайте много дублей из-за служебных страниц, параметров и лишних архивов, часть работы можно упростить плагином, который закрывает типовые SEO- и технические хвосты. Но даже в этом случае серверный редирект и проверка canonical остаются обязательными.

Из практики удобнее сначала убрать серверные дубли, потом пройтись по архивам и параметрам, и только после этого смотреть в Search Console. Иначе вы будете чинить симптомы, а не источник проблемы.

Если нужен инструмент для чистки дублей, служебных страниц и SEO-настроек, можно посмотреть Clearfy Pro. Но его стоит воспринимать как помощника в настройках, а не замену нормальной серверной канонизации.

После внедрения еще раз проверьте основные URL через curl, затем откройте исходник страницы и убедитесь, что canonical и robots meta совпадают с вашей логикой индексации. Если эти три уровня согласованы — сервер, WordPress и SEO-плагин — дубли обычно перестают возвращаться после очередного обновления.

⭐⭐⭐⭐⭐