Ситуация типовая: сайт уже живёт, структура менялась, часть страниц переехала, а в поиске всё ещё всплывают старые адреса. Это не всегда дубли в классическом смысле. Чаще проблема в том, что WordPress, тема или плагин продолжают отдавать доступные для обхода URL с устаревшими параметрами, архивами, вложениями или альтернативными путями к тому же контенту.
Если просто начать ставить noindex на всё подряд, можно случайно закрыть нужные страницы и ухудшить внутреннюю перелинковку. Поэтому задача здесь не «спрятать сайт», а аккуратно оставить в индексе только канонические URL, а старые версии — убрать из обхода или перевести на редирект.
Когда это действительно проблема
Проверять нужно не по ощущениям, а по фактам. Откройте несколько старых адресов и посмотрите, что именно с ними происходит: отдают ли они 200 OK, редиректят ли на новый URL, есть ли у них канонический адрес, не попадают ли они в sitemap. Если старый URL открывается как полноценная страница и отличается от новой только параметрами, поисковик вполне может считать это отдельной сущностью.
Признаки, что старые версии уже мешают
- в Google Search Console видны URL с параметрами, архивами или устаревшими путями;
- в выдаче появляются старые адреса вместо новых;
- на сайте есть несколько маршрутов к одному и тому же материалу;
- после смены темы или плагина остались старые шаблоны архивов и вложений;
- в sitemap попадают URL, которые вы не хотите индексировать.
Если речь о страницах, которые должны существовать только в новой версии, обычно правильный путь — 301-редирект. Если же старый URL нужен для пользователей, но не должен индексироваться, тогда уместны noindex и/или каноникал, но только после проверки, что страница не является точкой входа из поиска.
Что именно закрывать: редирект, canonical или noindex
У этих инструментов разная задача. Редирект говорит: «этот адрес больше не нужен, иди на новый». Canonical говорит: «контент здесь похож, но основной адрес вот этот». Noindex говорит: «страницу можно открыть, но в индекс её не добавлять».
| Подход | Когда использовать | Минус |
|---|---|---|
| 301 redirect | Старый URL окончательно заменён новым | Нужно аккуратно сопоставить старые и новые адреса |
| rel=canonical | Есть похожие версии одной страницы | Не всегда убирает URL из обхода быстро |
| noindex | Страница нужна пользователю, но не для поиска | Если закрыть важную страницу, она выпадет из поиска |
На практике для старых версий страниц чаще всего работает связка: редирект для окончательно устаревших адресов, canonical для близких дублей и noindex для служебных страниц, которые не должны ранжироваться, но должны оставаться доступными.
Диагностика: где искать старые URL в WordPress
Начните с простых мест. Смена структуры постоянных ссылок, архивы автора, архивы дат, вложения медиа, страницы с параметрами фильтрации, версии с ?amp, ?replytocom и похожие варианты — это частые источники мусора. Если сайт давно живёт, проверьте ещё и старые записи в базе, которые могли остаться после миграции.
Что проверить вручную
/page/2/и другие пагинированные страницы архивов;- страницы вложений вида
/attachment/...или отдельные URL медиафайлов; - архивы по датам, если они не нужны;
- страницы с параметрами сортировки и фильтров;
- старые адреса после изменения структуры рубрик или слагов;
- URL, которые уже редиректят, но всё ещё попадают в sitemap или внутренние ссылки.
Если у вас есть доступ к консоли, полезно быстро посмотреть, какие адреса отдают 200, а какие уже редиректят.
curl -I https://example.com/staryy-url/В ответе важно увидеть либо 301/302 с новым адресом в заголовке Location, либо 200, если страница ещё живая. Если старый URL отдаёт 200 и там тот же контент, это кандидат на canonical или редирект.
Пошаговое решение без лишнего риска
Шаг 1. Составьте список старых адресов
Не пытайтесь закрыть всё через один глобальный фильтр. Сначала соберите конкретные URL или шаблоны URL. Для небольшого сайта хватит выгрузки из Search Console, логов сервера и ручной проверки внутренних ссылок. Для большого — лучше пройтись по краулеру и посмотреть, какие адреса реально доступны.
Шаг 2. Для окончательно устаревших URL поставьте 301
Если страница переехала на новый адрес, редирект — самый чистый вариант. В WordPress это можно сделать на уровне сервера или через код. Для точечных случаев в теме или мини-плагине можно использовать template_redirect.
<?php
add_action('template_redirect', function () {
if (is_page('staryy-slug')) {
wp_redirect(home_url('/novyy-slug/'), 301);
exit;
}
});Такой вариант подходит только для небольшого числа адресов. Если старых URL много, лучше перенести правила в .htaccess или конфигурацию nginx, чтобы не нагружать PHP на каждом запросе.
Шаг 3. Для похожих версий укажите canonical
Если у страницы есть альтернативная версия, но она нужна по техническим причинам, задайте канонический адрес. В WordPress это можно сделать через фильтр wpseo_canonical в Yoast SEO или аналогичный механизм в вашем SEO-плагине. Если плагина нет, можно вывести тег вручную в wp_head, но только если вы уверены, что он не конфликтует с темой и другими плагинами.
<?php
add_action('wp_head', function () {
if (is_page('staryy-variant')) {
echo '<link rel="canonical" href="' . esc_url(home_url('/osnovnoy-variant/')) . '" />' . "\n";
}
}, 1);Этот способ полезен, когда старый URL нельзя удалить сразу, но нужно подсказать поисковику основной адрес. Однако canonical не заменяет редирект, если страница уже не должна существовать.
Шаг 4. Закройте служебные страницы от индексации
Для страниц, которые нужны пользователю, но не должны попадать в поиск, используйте noindex. Это может быть отдельный шаблон, страница с внутренним поиском, технический архив или результат фильтрации. Важно не закрывать таким способом важные посадочные страницы, которые собирают трафик.
<?php
add_action('wp_head', function () {
if (is_page('sluzhebnaya-stranica')) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Если используете SEO-плагин, лучше настраивать это в его интерфейсе или через его фильтры, а не дублировать мета-теги вручную. Два разных robots-тега на одной странице — частая причина путаницы.
Проверка результата после внедрения
После правок не ограничивайтесь открытием страницы в браузере. Нужна проверка на уровне ответа сервера и индексации. Сначала убедитесь, что старый URL отдаёт нужный статус: 301 для переезда, 200 для живой страницы с canonical или 200 + noindex для служебной страницы.
- проверьте заголовки через
curl -Iили DevTools; - посмотрите исходный код страницы и убедитесь, что canonical указывает на правильный URL;
- проверьте, не попал ли старый адрес в sitemap;
- в Search Console отправьте проверку URL и запросите переобход;
- через несколько дней сравните, исчез ли старый URL из отчётов и выдачи.
Если редирект настроен, но старый адрес всё ещё индексируется, обычно причина в том, что на него ведут внутренние ссылки, он остался в sitemap или редирект цепочкой уходит через несколько шагов. Для поисковика это уже не «чистое» решение.
Частые ошибки и как их исправить
Ставят noindex вместо редиректа
Это работает не всегда. Если страница уже заменена новой, noindex только оставит старый URL доступным для обхода. В итоге он может ещё долго висеть в индексе. Для окончательно устаревших адресов нужен 301.
Закрывают в robots.txt то, что должно редиректить
Если URL закрыт в robots.txt, поисковик может не увидеть редирект и продолжить держать адрес в индексе как «запрещённый к обходу». Для старых страниц сначала настраивают редирект, а не блокировку обхода.
Оставляют старые ссылки внутри сайта
Даже идеальный canonical не спасёт, если меню, хлебные крошки, блоки похожих материалов и старые статьи продолжают ссылаться на устаревший адрес. После миграции нужно пройтись по внутренним ссылкам и заменить их на новые.
Дублируют правила в плагине и на сервере
Когда редирект одновременно задан в плагине и в .htaccess, легко получить цепочку или петлю. Лучше выбрать один уровень управления и документировать, где лежит правило.
Практические советы по безопасности и производительности
Если старых URL много, не вешайте десятки проверок на template_redirect. Это лишняя нагрузка на PHP. Для массовых редиректов используйте серверный уровень. Для точечных исключений — код в мини-плагине, а не в functions.php темы, чтобы не потерять правила при обновлении шаблона.
Ещё один полезный момент: после чистки старых адресов проверьте кэш. Если у вас стоит кэш-плагин или серверный кэш, старые версии страниц могут продолжать отдаваться из кэша даже после правок. Очистите кэш страниц, объектный кэш и CDN, если он есть.
Если нужно быстро убрать технические дубли и мусорные страницы без ручной возни с каждым шаблоном, иногда удобнее использовать инструменты вроде Clearfy Pro от WPShop: у него есть настройки для части SEO- и технических мелочей, которые обычно приходится собирать вручную. Но даже в этом случае базовую логику — что редиректить, что закрывать, а что оставлять — лучше определить самостоятельно. Ссылка: Clearfy Pro.
В итоге рабочая схема всегда одна и та же: сначала находите конкретные старые URL, потом решаете для каждого из них — редирект, canonical или noindex, и только после этого проверяете ответ сервера, исходный код и отчёты поисковой консоли. Без этой последовательности легко получить ещё больше дублей вместо чистки.
