Как найти и убрать дубли страниц в WordPress после миграции

Автор: Маргарита Ширяева | Опубликовано: 15.08.2026

После миграции WordPress-сайта дубли обычно появляются не из-за одной ошибки, а из-за набора мелочей: старые и новые URL доступны одновременно, архивы индексируются вместе с записями, страницы открываются с www и без него, а иногда ещё и с разными параметрами в адресе. На небольшом сайте это выглядит как «пара лишних страниц», но в поиске такие расхождения быстро превращаются в размывание сигналов и лишнюю нагрузку на обход.

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

Как понять, что у сайта появились дубли

Сначала не трогайте код. Проверьте, какие именно URL отдают одинаковый контент или почти одинаковые страницы. После миграции чаще всего всплывают такие варианты:

одна и та же страница доступна по /page/ и /page;
сайт открывается и на http, и на https;
есть версии с www и без него;
архивы категорий, тегов и авторов дублируют основной контент;
страницы с параметрами ?utm_, ?replytocom, ?amp или сортировками создают отдельные URL;
после переноса остались старые адреса, которые не редиректятся на новые.

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

Откройте несколько подозрительных адресов в браузере и сравните:

финальный URL после загрузки;
код ответа сервера;
есть ли редирект на каноническую версию;
совпадает ли <link rel="canonical"> с итоговым адресом.

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

curl -I https://example.com/page/
curl -I https://www.example.com/page/
curl -I http://example.com/page/

В нормальной схеме лишние варианты должны вести на один основной URL через 301-редирект. Если этого нет, поисковик может держать в индексе несколько версий одной страницы.

Что исправлять в первую очередь после миграции

Не пытайтесь сразу закрыть всё noindex-ом. Сначала нужно привести в порядок базовую адресацию сайта: домен, протокол, слэши, постоянные ссылки и канонические URL. Это фундамент, без которого остальные меры работают нестабильно.

1. Проверьте настройки WordPress и редирект основного домена

В Настройки → Общие адрес WordPress и адрес сайта должны совпадать с той версией, которую вы хотите считать основной. Если сайт должен открываться на https://example.com, не оставляйте там старый http или www-вариант.

Если у вас Apache, базовый редирект можно сделать через .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

Для Nginx логика похожая, но правило пишется в конфиге сервера. Если вы не уверены в синтаксисе, лучше править это на уровне хостинга или через ответственного администратора, а не экспериментировать на боевом сайте.

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

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

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

индексацию архивов тегов и авторов;
наличие canonical на архивных страницах;
исключение технических страниц из sitemap;
правильность robots.txt, но без попытки «лечить» дубли только им.

Если нужен более точный контроль, можно отключить архивы авторов кодом:

add_action('template_redirect', function () {
    if (is_author()) {
        wp_redirect(home_url('/'), 301);
        exit;
    }
});

Такой подход уместен только если авторские архивы вам действительно не нужны. Если на сайте несколько авторов и архивы полезны для навигации, лучше не ломать их редиректом.

3. Проверьте canonical и пагинацию

После миграции часто ломается canonical: страница показывает один адрес, а в canonical указан другой. Для поисковика это сигнал, что версия страницы не определена однозначно.

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

Сравнение подходов: плагин, код или серверный редирект

Подход	Когда подходит	Плюсы	Минусы
SEO-плагин	Нужно быстро закрыть архивы, canonical и sitemap	Меньше ручной работы, проще поддержка	Не лечит ошибки сервера и старые URL после миграции
Код в теме/плагине	Нужно точечно убрать архивы, редиректы или параметры	Точный контроль	Риск сломать логику при обновлении темы
Редиректы на сервере	Нужно привести домен, протокол и слэши к одному виду	Быстро и надёжно	Требует доступа к конфигу и аккуратной проверки

На практике лучше комбинировать: сервером закрыть базовые дубли, SEO-плагином — canonical и sitemap, кодом — только точечные исключения.

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

Выберите один основной URL сайта: один домен, один протокол, один формат со слэшем или без него.
Настройте 301-редиректы со всех альтернативных вариантов на основной адрес.
Проверьте постоянные ссылки в WordPress и обновите правила перезаписи, если переносили сайт между серверами.
Отключите ненужные архивы: теги, авторы, даты, если они не несут ценности.
Проверьте sitemap: в нём должны быть только канонические URL.
Сверьте canonical на типовых страницах: записи, страницы, категории, пагинация.
Уберите параметры, создающие мусорные URL, если они не нужны для работы сайта.

Если дубли создаёт параметр в URL

Иногда после миграции в индекс попадают адреса с параметрами, которые не должны быть отдельными страницами. Например, ?replytocom у комментариев или технические параметры от старой аналитики. В таком случае лучше не плодить отдельные версии и сразу редиректить или игнорировать их на уровне шаблона.

Пример точечного редиректа для параметра replytocom:

add_action('template_redirect', function () {
    if (isset($_GET['replytocom']) && is_singular()) {
        wp_safe_redirect(remove_query_arg('replytocom'), 301);
        exit;
    }
});

Это не универсальное решение для всех параметров, но для конкретного мусорного дубля работает предсказуемо.

Как проверить, что решение сработало

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

Откройте старые и новые адреса: все альтернативы должны отдавать 301 на один URL.
Проверьте canonical в исходном коде страницы.
Сравните sitemap: там не должно быть старых доменных вариантов и параметрических URL.
В Search Console посмотрите, не растёт ли число страниц с пометкой «дубликат, выбранный канонический URL отличается».
Проверьте, не остались ли в индексе старые адреса через оператор site: и выборочную проверку URL.

Если редирект настроен правильно, curl -I покажет 301 на старом адресе и 200 на основном. Если видите 200 на обеих версиях, проблема ещё не решена.

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

Редирект сделан через 302 вместо 301

302 не закрепляет основную версию страницы так надёжно, как 301. После миграции это частая ошибка, особенно если редирект ставили временно и забыли заменить код. Исправление простое: для постоянной смены адреса используйте 301.

Canonical указывает на несуществующий или старый адрес

Такое бывает после смены домена или структуры ссылок. Проверьте настройки SEO-плагина, шаблон темы и кэш страницы. Иногда проблема не в коде, а в том, что старая версия HTML продолжает отдаваться из кэша.

robots.txt пытаются использовать как замену редиректам

Запрет в robots.txt не убирает уже существующие дубли из индекса и не решает проблему одинакового контента на разных URL. Он лишь ограничивает обход. Если адреса уже доступны, сначала нужен редирект или canonical, а не только Disallow.

Отключают архивы без проверки внутренней перелинковки

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

Безопасность и производительность: что не стоит игнорировать

Массовые редиректы и фильтры на template_redirect могут добавить лишнюю нагрузку, если вы проверяете слишком много условий на каждом запросе. Держите правила короткими и не вешайте на фронт тяжёлую логику, которая нужна только для редких URL.

Если сайт большой, полезно:

сначала собрать список дублей из Search Console и логов сервера;
сделать редиректы на уровне веб-сервера, а не только в PHP;
не смешивать несколько SEO-плагинов с одинаковыми функциями;
после правок очистить кэш страницы, объектный кэш и CDN, если он есть.

Для сайтов, где много технических дублей из-за архивов, параметров и служебных страниц, удобно использовать инструменты вроде Clearfy Pro, если нужен набор точечных настроек для удаления дублей и чистки сайта: https://wpshop.ru/plugins/clearfy. Но даже с плагином базовые редиректы и проверка canonical остаются обязательными.

Если вы хотите быстро понять, что именно осталось в индексе после переноса, начните с простого чек-листа:

один основной домен;
один протокол;
один формат слэша;
301 со старых URL;
корректный canonical;
чистый sitemap;
отсутствие мусорных параметров в индексе.

Когда эти пункты закрыты, дубли обычно перестают быть системной проблемой и сводятся к единичным URL, которые уже можно добить точечно.