В WordPress старые версии страниц обычно появляются не из-за одной ошибки, а из-за набора мелких причин: смена URL после редизайна, дубли с параметрами, архивы пагинации, тестовые страницы, версии для предпросмотра и служебные URL от плагинов. Если такие адреса начинают попадать в индекс, поисковик тратит обход на мусор, а в отчётах Search Console растёт число «Просканировано, но не проиндексировано» и похожих статусов.
Задача здесь не в том, чтобы закрыть всё подряд. Важно убрать из индекса именно старые и бесполезные версии, при этом оставить доступными канонические страницы, которые должны собирать трафик. Ниже — рабочая схема: как диагностировать проблему, что именно закрывать, чем лучше управлять через код, а где достаточно настроек плагина.
Когда старые версии страниц действительно мешают
Сначала стоит понять, что именно вы считаете «старой версией». В WordPress это могут быть разные сущности:
- страницы с изменённым slug после редактирования;
- дубли с параметрами вроде
?replytocom=,?utm_или служебных query string; - страницы предпросмотра и черновики;
- архивы пагинации, которые не несут самостоятельной ценности;
- страницы вложений, если они открываются как отдельные URL без контента;
- старые адреса после переноса сайта или смены структуры постоянных ссылок.
Если такие URL уже в индексе, просто поставить noindex на все подряд — плохая идея. Поисковик может продолжить тратить ресурсы на обход, а часть старых адресов будет висеть в отчётах ещё долго. Лучше сначала разделить сценарии: что нужно удалить из индекса, что нужно редиректить, а что вообще не должно существовать как отдельная страница.
Диагностика: какие URL уже попали в индекс
Начните с проверки в Search Console и в логике самого сайта. Важно не угадывать, а увидеть конкретные адреса. Для этого обычно хватает трёх источников:
- отчёт по страницам в Google Search Console;
- поиск по сайту через
site:example.comс точными масками URL; - список URL из sitemap и внутренних ссылок.
Если у вас есть доступ к серверу, полезно посмотреть, не отдают ли старые адреса код 200 OK вместо редиректа или 404. Это частая причина индексации мусора: страница уже не нужна, но сервер продолжает считать её живой.
Что проверить вручную
- открывается ли старый URL в браузере;
- есть ли на нём канонический адрес через
rel=canonical; - не дублируется ли контент на новой и старой версии;
- не попадает ли URL в XML sitemap;
- не ссылаются ли на него внутренние ссылки из меню, хлебных крошек или блоков похожих записей.
Если старый URL всё ещё отдаёт контент, но уже не должен ранжироваться, чаще всего нужен редирект. Если URL технический и контента там быть не должно, тогда уместнее noindex или вообще запрет на генерацию страницы.
Что выбрать: редирект, noindex или удаление URL
У этих вариантов разная задача. Смешивать их без понимания последствий не стоит.
| Подход | Когда использовать | Плюс | Минус |
|---|---|---|---|
| 301 редирект | Старая страница заменилась новой | Передаёт сигнал и трафик на актуальный URL | Нужно корректно сопоставить старый и новый адрес |
noindex | Страница нужна пользователю, но не должна быть в поиске | Не требует удаления URL | Поисковик может ещё какое-то время обходить страницу |
| 404/410 | Страница больше не существует и не должна заменяться | Чёткий сигнал на удаление | Нельзя использовать, если есть релевантная замена |
Для старых версий контентных страниц обычно лучший вариант — 301 редирект на актуальный адрес. Для служебных страниц, которые не должны индексироваться, но нужны внутри сайта, чаще подходит noindex, follow. Для совсем ненужных URL — 404 или 410, если вы уверены, что замены нет.
Пошаговое решение: как убрать старые версии страниц в WordPress
1. Настройте редиректы для устаревших URL
Если страница переехала на новый адрес, не оставляйте старый URL с тем же контентом. Самый надёжный путь — 301 редирект. На уровне сервера это обычно быстрее и чище, чем через PHP.
Пример для .htaccess на Apache:
Redirect 301 /staryj-url/ https://example.com/novyj-url/Если у вас Nginx, правило будет другим, но смысл тот же: старый адрес должен вести на новый, а не жить отдельной страницей. Для большого числа адресов удобнее использовать плагин редиректов или собственную таблицу соответствий, чтобы не плодить ручные правила в конфиге.
2. Закройте технические страницы через noindex
Если это архивы, страницы поиска, вложения или другие технические URL, которые не должны попадать в поиск, добавьте noindex на уровне шаблона или через SEO-плагин. Для страниц вложений, например, часто достаточно перенаправлять их на файл или родительскую запись, если отдельная страница вложения не нужна.
Пример для WordPress: добавить noindex на вложения и страницы поиска через wp_head:
add_action('wp_head', function () {
if (is_attachment() || is_search()) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});Это рабочий вариант, если у вас нет SEO-плагина или нужно точечно переопределить поведение. Но если SEO-логика уже управляется плагином, не дублируйте мета-теги из двух мест — иначе получите конфликт.
3. Уберите старые URL из внутренних ссылок
Даже если старый адрес закрыт от индексации, поисковик всё равно будет находить его по внутренним ссылкам. Поэтому проверьте:
- меню;
- хлебные крошки;
- виджеты и блоки «похожие записи»;
- ссылки в контенте после редизайна;
- автоматические ссылки из плагинов.
Если старый URL продолжает активно ссылаться внутри сайта, редирект будет работать, но вы создаёте лишнюю цепочку обхода. Лучше заменить ссылки на актуальные сразу в базе или через редактор контента.
4. Проверьте, не попадает ли URL в sitemap
Если старые страницы всё ещё есть в XML sitemap, поисковик получает противоречивый сигнал: вы вроде бы закрываете URL, но одновременно предлагаете его как важный. Это особенно часто случается после миграции сайта или смены SEO-плагина.
Проверьте sitemap вручную и убедитесь, что там нет:
- старых страниц после смены slug;
- вложений;
- служебных архивов;
- страниц с параметрами.
Если sitemap генерирует SEO-плагин, настройку лучше делать в нём, а не через костыли в шаблоне. Если же проблема в кастомном коде, проверьте фильтры, которые добавляют лишние URL в карту сайта.
Пример точечной логики в коде
Иногда нужен не общий запрет, а логика для конкретного сценария. Например, вы хотите закрыть от индексации старые страницы, если они помечены меткой или имеют определённый шаблон. В этом случае можно добавить noindex только для нужных записей.
add_action('wp_head', function () {
if (!is_singular('page')) {
return;
}
$template = get_page_template_slug();
if ($template === 'templates/old-landing.php') {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});Такой подход полезен, когда старые посадочные страницы ещё доступны по прямой ссылке, но вы не хотите, чтобы они конкурировали с новой версией. Главное — не забыть, что шаблон должен быть действительно назначен только нужным страницам.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой. Нужны конкретные признаки:
- старый URL отдаёт 301 на новый адрес или 404/410, если удалён без замены;
- в исходном коде нет лишних мета-тегов robots;
- старый адрес исчез из sitemap;
- внутренние ссылки больше не ведут на устаревшую страницу;
- в Search Console статус URL меняется в сторону исключения или замены, а не продолжает болтаться как отдельная страница.
Проверить код ответа можно через curl:
curl -I https://example.com/staryj-url/Если всё настроено правильно, вы увидите либо 301 Moved Permanently с новым Location, либо 404 Not Found/410 Gone, либо страницу с noindex в HTML, если это именно тот сценарий, который вам нужен.
Частые ошибки и как их исправить
- Ставят
noindexна страницу, которая должна передавать вес новой версии. В этом случае нужен 301, а не мета-роботс. - Оставляют старый URL с кодом 200. Поисковик видит живую страницу и продолжает её обход.
- Закрывают URL в robots.txt и считают задачу решённой. Если страница уже в индексе, один robots.txt не уберёт её быстро и предсказуемо.
- Дублируют robots-метки из плагина и темы. Получается конфликт, а иногда и некорректная разметка в head.
- Не убирают старые ссылки из контента. Тогда поисковик снова и снова находит устаревший адрес.
- Оставляют старые URL в sitemap. Это ломает логику индексации и мешает переобходу.
Практические советы по безопасности и производительности
Если вы правите редиректы и мета-теги кодом, не вносите изменения прямо в тему, которую потом обновляете. Для точечных правок лучше использовать дочернюю тему или небольшой mu-plugin. Так вы не потеряете настройки после обновления.
Если на сайте много старых URL, не пытайтесь закрыть их через тяжёлые PHP-обработчики на каждом запросе. Для массовых редиректов лучше серверный уровень или специализированный плагин редиректов. Для массовой чистки дублей и технических SEO-настроек иногда удобнее использовать Clearfy Pro, если он уже вписывается в ваш стек и не конфликтует с текущим SEO-плагином.
Ещё один практический момент: после смены структуры URL не удаляйте старые адреса сразу без проверки логов. Иногда на них ещё идут внешние ссылки или трафик из закладок. В таких случаях 301 редирект безопаснее, чем жёсткое удаление.
Если нужна короткая рабочая схема, то она выглядит так: старые контентные URL — через 301, служебные страницы — через noindex, ненужные адреса без замены — через 404/410, а внутренние ссылки и sitemap — обязательно привести к актуальному состоянию. Именно эта последовательность обычно убирает проблему без лишнего шума в индексации.