Как закрыть старые версии страниц в WordPress и убрать дубли из индекса

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

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

Когда проблема уже есть: как понять, что в индексе остались старые страницы

Первый признак — в поиске по site:example.com всплывают адреса, которых на сайте уже нет или которые ведут на тот же контент, но по другому пути. Второй признак — в Google Search Console у страницы есть несколько URL с одинаковым содержимым, а в отчетах по индексированию появляются «дубликат, выбран другой канонический URL» или «страница с перенаправлением».

Проверять нужно не только саму страницу, но и все ее варианты:

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

Что смотреть в первую очередь

Если у вас есть доступ к Search Console, откройте проверку URL и посмотрите, какой адрес считается каноническим. Если канонический не совпадает с тем, который вы хотите видеть в индексе, сначала нужно исправлять источник дублирования, а не просто закрывать что-то в robots.txt.

На самом сайте проверьте заголовки ответа и редиректы. Для этого удобно использовать:

curl -I https://example.com/staryy-url/

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

Что именно закрывать: 3 рабочих варианта

В WordPress для старых версий страниц обычно используют один из трех подходов: 301-редирект на актуальный адрес, noindex для технической копии или полное удаление с 410 Gone. Выбор зависит от того, есть ли у старой страницы ценность для пользователя и внешние ссылки.

Пошаговое решение через код: редирект старого URL на новый

Если вы меняли адрес страницы, самый надежный вариант — 301-редирект. В WordPress это можно сделать на уровне template_redirect, если речь о единичном кейсе и вы точно знаете старый и новый адрес.

add_action( 'template_redirect', function () {
	if ( is_page( 'staryy-url' ) ) {
		wp_redirect( home_url( '/novyy-url/' ), 301 );
		exit;
	}
} );

Такой код лучше добавлять в дочернюю тему или в небольшой mu-plugin, а не в произвольный файл темы. Если старых адресов несколько, список лучше хранить в массиве:

add_action( 'template_redirect', function () {
	$map = array(
		'/staryy-url/'   => '/novyy-url/',
		'/old-about/'    => '/about-us/',
		'/old-contact/'  => '/contact/',
	);

	$request_uri = strtok( $_SERVER['REQUEST_URI'], '?' );

	if ( isset( $map[ $request_uri ] ) ) {
		wp_redirect( home_url( $map[ $request_uri ] ), 301 );
		exit;
	}
} );

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

Если копия нужна, но в индекс ее пускать нельзя

Иногда старый URL остается рабочим по техническим причинам: например, его использует внешний сервис, форма, виджет или старый email-шаблон. В таком случае редирект может ломать сценарий, и тогда лучше поставить noindex на конкретный шаблон или тип страницы.

Для одиночной страницы можно добавить мета-тег через wp_head:

add_action( 'wp_head', function () {
	if ( is_page( 'staryy-url' ) ) {
		echo '<meta name="robots" content="noindex,follow">' . "\n";
	}
} );

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

add_action( 'wp_head', function () {
	if ( is_page_template( 'templates/legacy-page.php' ) ) {
		echo '<meta name="robots" content="noindex,follow">' . "\n";
	}
} );

Важно: noindex не заменяет редирект, если страница уже устарела и у нее есть очевидная новая версия. Для переехавших страниц редирект почти всегда лучше.

Как убрать старые версии из индекса через заголовки и каноникал

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

Проверка простая: откройте исходный код страницы и найдите строку вида <link rel="canonical" href="...">. Если там старый адрес, значит поисковик получает противоречивый сигнал. Исправлять нужно либо настройку плагина SEO, либо фильтр, который меняет canonical.

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

Диагностика после внедрения: как проверить, что решение сработало

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

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

Для быстрой проверки редиректа удобно смотреть заголовки:

curl -I https://example.com/staryy-url/

Если у вас несколько промежуточных редиректов, это тоже видно в ответе. Цепочка http -> www -> https -> новый URL уже не катастрофа, но лучше сократить ее до одного шага.

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

Ставят noindex вместо редиректа

Это частая ошибка после переноса страницы. noindex говорит поисковику не показывать страницу, но не передает ее вес новой версии. Если есть новый адрес, нужен 301.

Закрывают старый URL в robots.txt

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

Делают редирект на главную

Это плохая замена удаленной страницы. Для поисковика это выглядит как soft 404, а для пользователя — как потеря контекста. Если есть релевантная новая страница, редирект должен вести именно на нее.

Забывают про параметры и альтернативные адреса

Одна и та же страница может открываться с параметрами, через архив рубрики или по старому пути после смены структуры ссылок. Если закрыт только «красивый» URL, дубли все равно останутся.

Ломают редиректы в кэше

После внедрения правил очистите кэш плагина, серверный кэш и CDN, если он есть. Иначе вы будете проверять уже не тот ответ, который реально отдает сайт.

Чек-лист перед публикацией правок

• Старый URL и новый URL выписаны явно, без догадок.
• Понятно, нужен ли 301, noindex или 410.
• Нет цепочки из нескольких редиректов.
• Canonical на новой странице указывает на нее саму.
• Кэш и CDN очищены после изменений.
• Проверка URL в Search Console показывает нужный адрес.
• В индексе не осталось технических копий с параметрами.

Практические советы по безопасности и производительности

Если вы добавляете редиректы кодом, не раздувайте functions.php десятками условий. Для большого списка старых адресов лучше вынести правила в отдельный mu-plugin или использовать серверные редиректы, если у вас есть доступ к конфигурации веб-сервера. Это быстрее и надежнее, чем прогонять каждый запрос через PHP.

Для единичных страниц код в WordPress нормален, но следите за тем, чтобы логика была предсказуемой: без обращения к базе на каждом хите и без сложных регулярных выражений там, где достаточно точного совпадения пути.

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

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