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

После редизайна, смены шаблона или переноса контента в WordPress часто остаются старые URL: версии с параметрами, дубли после смены структуры, архивы старых разделов, страницы с устаревшими slug. Если такие адреса продолжают отдавать 200 OK и доступны из внутренних ссылок, поисковик может держать их в индексе дольше, чем нужно. В итоге в выдаче всплывают неактуальные страницы, а вес распыляется между дублями.

Задача здесь не в том, чтобы «спрятать всё подряд», а в том, чтобы аккуратно убрать из индексации именно устаревшие версии и при этом не сломать доступ к нужным страницам, редиректам и истории сайта.

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

Сначала стоит убедиться, что речь именно о старых версиях страниц, а не о нормальных рабочих URL. Типичные признаки:

• в Google Search Console в индексе остаются адреса со старой структурой;
• поиск по сайту или внутренние ссылки ведут на устаревшие URL;
• страницы с новым адресом уже есть, но старые продолжают открываться без редиректа;
• в выдаче видны версии с параметрами, например ?replytocom=, ?amp, ?utm_ или технические копии после миграции;
• в отчётах краулинга много дублей с одинаковым контентом и разными адресами.

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

• HTTP-статус старого URL: должен быть либо 301 на новый адрес, либо 404/410, если страницы больше не существует.
• Наличие канонического адреса через rel="canonical".
• Нет ли внутренних ссылок на старую версию в меню, хлебных крошках, блоках похожих записей и в контенте.
• Не закрыта ли страница только через noindex без редиректа — это часто оставляет мусор в обходе.

Что делать: рабочая схема по шагам

1. Для старого URL выберите правильную реакцию

Если у страницы есть новый эквивалент, старый адрес нужно редиректить на актуальный. Если эквивалента нет и контент удалён окончательно, лучше отдавать 410 Gone или хотя бы 404. Закрытие через noindex полезно как дополнительная мера, но не как единственный способ убрать устаревший адрес из индекса.

Практически это выглядит так:

• 301 — когда есть замена;
• 410 — когда страница удалена навсегда;
• noindex — когда страница нужна пользователю, но не должна ранжироваться;
• canonical — когда есть основная версия и несколько технических дублей.

2. Настройте редиректы для старых адресов

Если старые URL известны заранее, проще всего прописать их на уровне сервера или через плагин редиректов. Для WordPress это безопаснее, чем пытаться ловить всё PHP-логикой на каждом запросе.

Пример для .htaccess на Apache:

Redirect 301 /staryy-razdel/ https://example.com/novyy-razdel/

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

3. Для удалённых страниц отдавайте 410

Если контент удалён без замены, 410 Gone обычно быстрее сигнализирует поисковым системам, что адрес больше не нужен. В WordPress это можно сделать через шаблонную логику, но только для конкретных случаев, а не для всего сайта.

add_action('template_redirect', function () {
    if (is_page('staryy-razdel')) {
        status_header(410);
        nocache_headers();
        echo 'Страница удалена';
        exit;
    }
});

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

4. Уберите старые URL из внутренних ссылок

Даже идеальный редирект не решает проблему полностью, если старые адреса продолжают жить в меню, блоках, виджетах и контенте. Поисковый робот всё равно будет тратить обход на лишние переходы.

Проверьте:

• главное меню и футер;
• хлебные крошки;
• ссылки в старых статьях;
• похожие записи и блоки рекомендаций;
• XML-карту сайта, если туда попали устаревшие URL.

5. Обновите canonical и мета-robots там, где нужен noindex

Если страница остаётся доступной для пользователя, но не должна индексироваться, добавьте noindex, follow. При этом canonical должен указывать на основную версию, а не на саму техническую страницу.

Пример для шаблона WordPress:

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

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

Сравнение подходов

Диагностика после внедрения

Проверять нужно не только код ответа, но и то, как страница ведёт себя в обходе и индексации.

1. Откройте старый URL в браузере и проверьте, куда он ведёт.
2. Проверьте заголовки ответа через curl -I https://example.com/staryy-url/.
3. Убедитесь, что новый URL отдаёт 200 OK, а старый — 301 или 410.
4. Посмотрите исходный код страницы: нет ли лишнего noindex на рабочем адресе.
5. В Search Console отправьте на переобход важные страницы и проверьте отчёт об индексировании через несколько дней.

Пример проверки через командную строку:

curl -I https://example.com/staryy-razdel/
curl -I https://example.com/novyy-razdel/

Если старый адрес всё ещё отдаёт 200, значит редирект не сработал или правило перекрывается другим правилом сервера, плагина кэша или WordPress-роутинга.

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

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

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

Редиректят всё на главную

Такой подход ломает релевантность. Пользователь и робот попадают на нерелевантную страницу, а поисковик может воспринимать это как soft 404. Редирект должен вести на наиболее близкий по смыслу адрес.

Оставляют старые ссылки в контенте

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

Забывают про кэш

После изменения правил редиректа или мета-тегов старые ответы могут продолжать отдаваться из кэша. Очистите серверный кэш, кэш плагина и, если используется CDN, его копию.

Смешивают canonical и redirect без логики

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

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

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

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

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

Мини-чек-лист перед публикацией изменений

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

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