После редизайна или переноса контента в WordPress часто остаются старые URL: черновые версии страниц, дубли с другим слагом, архивы старых посадочных, тестовые копии разделов. Если такие адреса уже попали в поиск, простого удаления из меню недостаточно — поисковик продолжит обходить их по внешним ссылкам, истории индекса и внутренним переходам.
Задача здесь не в том, чтобы «спрятать всё подряд», а в том, чтобы аккуратно убрать из индекса именно устаревшие версии и не сломать рабочие страницы, редиректы и аналитику.
Когда это действительно проблема
Сценарий обычно выглядит одинаково: основная страница уже живёт по новому адресу, а старая версия всё ещё доступна по прямой ссылке. Иногда она отдаёт 200 OK, иногда дублируется через архивы, иногда остаётся копией в теме или в конструкторе. В результате в индексе появляются:
- старые URL после смены структуры сайта;
- дубли страниц с другим слагом или в другой рубрике;
- тестовые версии лендингов, которые забыли удалить;
- страницы, которые должны работать только как технический промежуточный адрес.
Что проверить в первую очередь
До любых правок нужно понять, как именно URL сейчас отвечает серверу. Это можно сделать вручную или через инструменты разработчика. Важно не гадать по виду страницы, а посмотреть реальный код ответа и канонический адрес.
curl -I https://example.com/staryy-url/Если видите 200, страница доступна для индексации. Если 301 или 308 — уже лучше, но надо проверить, куда ведёт редирект. Если 404 или 410, поисковику проще убрать адрес из индекса, но только если он не подхватывается снова из sitemap, внутренних ссылок или каноникала.
Какие варианты решения есть на практике
Для старых версий страниц обычно используют три подхода: редирект, noindex или удаление с возвратом 410 Gone. Выбор зависит от того, есть ли у страницы замена и нужен ли переход пользователя на новый адрес.
| Подход | Когда применять | Плюс | Минус |
|---|---|---|---|
| 301 редирект | Есть новая актуальная страница | Передаёт пользователей и часть сигналов на новый URL | Нужно следить за цепочками редиректов |
noindex | Страница нужна для доступа, но не для поиска | Не ломает доступ по прямой ссылке | Страница должна оставаться доступной для обхода |
410 Gone | Страница окончательно удалена | Быстрее сигнализирует о удалении | Нельзя использовать, если есть замена или трафик |
Пошаговое решение для старых URL
1. Если есть новая страница — ставим 301 редирект
Это самый безопасный вариант для пользователя и обычно самый понятный для поисковика. В WordPress редирект лучше делать на уровне сервера или через плагин редиректов, если у вас нет доступа к конфигурации веб-сервера.
Пример для .htaccess на Apache:
Redirect 301 /staryy-url/ https://example.com/novyy-url/Если редиректов несколько, проверьте, чтобы не было цепочки вида старый URL → промежуточный URL → новый URL. Чем короче путь, тем лучше.
2. Если страница нужна, но не должна индексироваться — ставим noindex
Такой вариант подходит для служебных страниц, временных лендингов, внутренних версий контента. В WordPress проще всего добавить noindex через SEO-плагин, если он умеет управлять мета-тегами и каноникалом. Если нужен точечный код, можно вывести мета-тег в wp_head только для конкретного URL.
add_action('wp_head', function () {
if (is_page('staryy-url')) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});Важно: noindex не должен конфликтовать с robots.txt. Если закрыть страницу в robots.txt, поисковик может не увидеть мета-тег и дольше держать URL в индексе. Для уже проиндексированных страниц это частая ошибка.
3. Если страница удалена окончательно — отдаём 410
Когда замены нет и контент больше не нужен, корректнее вернуть 410 Gone. Это честнее, чем оставлять пустую страницу или маскировать её под 200-й ответ. Для WordPress можно сделать это через шаблон или отдельную проверку в template_redirect.
add_action('template_redirect', function () {
if (is_page('staryy-url')) {
status_header(410);
nocache_headers();
include get_query_template('404');
exit;
}
});Если используете этот вариант, убедитесь, что страница не попадает в sitemap и на неё не ведут внутренние ссылки.
Диагностика: почему старый URL всё ещё в индексе
Даже после редиректа или удаления адрес может висеть в поиске неделями. Обычно причина не в «плохой индексации», а в одном из технических хвостов:
- URL остался в XML-sitemap;
- на него ведут внутренние ссылки из меню, хлебных крошек или блоков;
- канонический тег указывает на старую версию;
- страница доступна по нескольким адресам без редиректа;
- сервер отдаёт
200вместо301или410.
Проверять лучше в таком порядке: ответ сервера, каноникал, sitemap, внутренние ссылки. Если начать с robots.txt, можно потратить время и не решить корень проблемы.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой в браузере. Нужны три проверки: код ответа, наличие в sitemap и поведение в поисковой консоли.
- Откройте старый URL и убедитесь, что он отдаёт нужный код:
301,410или страницу сnoindex. - Проверьте, что новый URL доступен без цепочек редиректов.
- Посмотрите, исчез ли старый адрес из XML-sitemap.
- В Search Console отправьте проверку URL или запросите переобход, если страница уже была в индексе.
Если старый адрес всё ещё показывается в поиске, но уже ведёт на новый URL, это нормальная задержка обновления. Если же он продолжает открываться как полноценная страница, значит где-то осталась копия шаблона, редирект не сработал или кэш отдаёт старый ответ.
Частые ошибки и как их исправить
Закрыли URL в robots.txt вместо удаления
Это частая попытка «быстро спрятать» страницу. Проблема в том, что поисковик может не увидеть мета-тег noindex и дольше держать адрес в индексе. Если страница уже доступна, сначала решайте вопрос через редирект, noindex или 410.
Оставили страницу в sitemap
Даже если на странице стоит noindex, её наличие в sitemap посылает противоречивый сигнал. Уберите старый URL из карты сайта и проверьте, что она пересобирается после очистки кэша.
Сделали редирект на нерелевантную страницу
Редирект на главную — плохая замена, если у старой страницы была конкретная тема. Лучше вести на ближайший аналог по смыслу. Иначе пользователь получает лишний шаг, а поисковик — слабый сигнал о замене.
Получили цепочку редиректов
Если старый URL сначала ведёт на промежуточный адрес, а потом на новый, это ухудшает обход и усложняет диагностику. Сведите всё к одному переходу.
Чек-лист перед публикацией изменений
- старый URL отвечает нужным кодом, а не
200 OK; - новый URL открывается без лишних редиректов;
- старый адрес удалён из sitemap;
- внутренние ссылки ведут только на актуальную страницу;
- канонический тег указывает на правильный URL;
- кэш страницы и кэш CDN очищены после правок;
- в Search Console отправлена проверка обновлённого адреса.
Что делать, если старых страниц много
Когда речь не об одной странице, а о десятках старых URL после миграции, ручная правка быстро превращается в хаос. В таком случае удобнее собрать таблицу соответствий: старый адрес, новый адрес, тип действия, статус проверки. Это помогает не забыть про редиректы и не закрыть случайно рабочие страницы.
Если у вас уже есть SEO-плагин с управлением дублями и техническими страницами, часть задач можно закрыть через него. Например, в Clearfy Pro есть инструменты для чистки сайта и удаления типовых дублей, но перед массовыми изменениями всё равно стоит проверить конкретные URL вручную и не полагаться только на автоматические настройки.
Главный принцип простой: сначала определите судьбу каждой старой страницы, потом выберите способ удаления из индекса. Для живого контента это редирект, для служебного — noindex, для окончательно удалённого — 410. Тогда WordPress не будет держать в поиске мусорные версии страниц и не создаст лишних конфликтов в индексации.