Старые версии страниц в WordPress обычно всплывают после редизайна, переноса контента, смены структуры URL или когда редактор оставил в индексе черновую копию с другим адресом. Проблема не всегда в самих страницах: чаще поисковик продолжает видеть дубли, потому что старый URL отвечает 200 OK, есть внутренняя ссылка, либо страница попала в sitemap и не была снята с обхода.
Если задача именно техническая, сначала нужно понять, какой тип старой версии у вас остался: архивная копия, дубликат по параметрам, страница из staging-сайта, старый slug после переезда или версия с UTM/фильтрами. От этого зависит, что делать: ставить 301, отдавать 410, закрывать robots.txt или убирать URL из внутренних ссылок и sitemap.
Как диагностировать проблему
Не начинайте с массовых правок в robots.txt. Сначала проверьте, как именно старый URL ведет себя сейчас. Важны три вещи: код ответа, наличие канонического адреса и то, есть ли URL в карте сайта или внутренних ссылках.
Что проверить вручную
- Открывается ли старый URL в браузере без редиректа.
- Какой код ответа возвращает сервер:
200,301,404или410. - Есть ли на странице тег
rel="canonical"и куда он указывает. - Не осталась ли старая версия в XML sitemap.
- Не ссылаются ли на нее меню, хлебные крошки, блоки похожих материалов или старые статьи.
Для быстрой проверки удобно использовать curl:
curl -I https://example.com/staryy-url/Если видите 200 OK, а страница уже не нужна, это почти всегда источник дубля. Если 301 Moved Permanently ведет на актуальный адрес, это нормальный сценарий. Если страница удалена навсегда и замены нет, часто лучше отдать 410 Gone, чем держать пустой 200 или бесконечную цепочку редиректов.
Когда проблема не в индексации, а в дубле
Иногда старый URL не нужно закрывать от индексации отдельно — его достаточно перенаправить на новый адрес. Это касается переименованных страниц, смены структуры рубрик, переноса материалов между разделами. Если же у страницы есть несколько рабочих адресов с одинаковым контентом, сначала убирают причину дубля, а не маскируют ее запретом в robots.txt.
| Сценарий | Что делать | Компромисс |
|---|---|---|
| Старый slug после редизайна | 301 на новый URL | Передача сигналов занимает время |
| Удаленная страница без замены | 410 Gone | Пользователь увидит ошибку, но индекс очистится быстрее |
| Технический дубль с параметрами | Canonical + очистка ссылок | Нужно проверить все источники параметров |
| Черновая копия на staging | Закрыть сайт целиком от индексации | Нельзя забыть снять запрет перед запуском |
Пошаговое решение: что делать со старыми версиями страниц
Ниже рабочая схема, которая подходит для большинства сайтов на WordPress. Она не завязана на один плагин и позволяет закрыть проблему без лишних экспериментов.
1. Уберите старый URL из внутренних ссылок
Если старая версия страницы все еще где-то упоминается, поисковик будет продолжать ее обходить. Проверьте меню, виджеты, блоки в редакторе, шаблоны темы и автосгенерированные списки. Иногда старый адрес сидит в контенте старой статьи или в произвольном HTML-блоке, и именно он поддерживает индексацию.
2. Настройте 301 редирект для переехавших страниц
Если страница просто сменила адрес, не закрывайте ее от индексации через robots.txt. Правильнее сделать 301 на новый URL. Это сохраняет переходы и помогает поисковику быстрее понять, что адрес изменился окончательно.
add_action('template_redirect', function () {
if (is_page('staryy-slug')) {
wp_redirect(home_url('/novyy-slug/'), 301);
exit;
}
});Такой вариант подходит для точечного переноса. Если редиректов много, лучше сделать их на уровне сервера или через плагин редиректов, чтобы не плодить логику в теме.
3. Для удаленных страниц используйте 410, если замены нет
Когда контент удален окончательно и перенаправлять некуда, ответ 410 Gone обычно честнее, чем 404. Он прямо сообщает поисковику, что адрес больше не должен участвовать в индексации.
add_action('template_redirect', function () {
if (is_page('udalennaya-stranica')) {
status_header(410);
nocache_headers();
echo 'Страница удалена';
exit;
}
});Этот код стоит применять аккуратно: только для конкретных URL, которые действительно больше не нужны. Не вешайте 410 на страницы, которые могут вернуться после доработки.
4. Уберите URL из sitemap
Если старый адрес остался в XML sitemap, поисковик будет продолжать его обходить даже при наличии редиректа. Важно, чтобы в карте сайта были только актуальные URL. Если вы используете SEO-плагин, проверьте его настройки исключения записей и таксономий. Если sitemap генерируется кодом темы или кастомным плагином, исключение нужно делать там же.
Для случаев, когда нужно убрать конкретную страницу из выдачи sitemap, но оставить ее на сайте, можно использовать фильтр wp_sitemaps_posts_query_args:
add_filter('wp_sitemaps_posts_query_args', function ($args, $post_type) {
if ($post_type === 'page') {
$args['post__not_in'] = array(123, 456); // ID страниц, которые не должны попадать в sitemap
}
return $args;
}, 10, 2);Это не закрывает страницу от индексации само по себе. Оно лишь убирает ее из карты сайта, что полезно как часть общей чистки.
5. Если нужен запрет на обход, используйте robots.txt только для технических дублей
robots.txt подходит не для всех случаев. Если URL уже в индексе, запрет на обход не гарантирует его исчезновение. Для старых страниц с уже накопленной историей чаще нужен редирект или код ответа 410. robots.txt полезен для технических разделов, параметров и служебных путей, которые не должны тратить crawl budget.
Пример для служебных URL:
User-agent: *
Disallow: /wp-admin/
Disallow: /?s=
Disallow: /*?replytocom=
Disallow: /staging/Но если речь именно о старой версии важной страницы, не прячьте ее только в robots.txt. Это частая ошибка.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой в браузере. Нужно убедиться, что поисковик видит нужный код ответа и что старый URL больше не участвует в обходе как полноценная страница.
- Проверьте старый URL через
curl -Iили любой HTTP checker. - Убедитесь, что редирект ведет на правильный новый адрес без цепочки из нескольких шагов.
- Откройте исходный код новой страницы и проверьте canonical.
- Посмотрите XML sitemap и убедитесь, что старого URL там нет.
- В Google Search Console проверьте статус URL через проверку страницы и запросите переобход, если это уместно.
Если старый адрес был удален, а не перенесен, нормальный результат — 410 или 404 без индексации. Если он перенаправляется, убедитесь, что конечный URL действительно отвечает 200 и содержит актуальный контент.
Частые ошибки и как их исправить
Закрывают старую страницу только в robots.txt
Это не удаляет URL из индекса, если он уже там есть. Исправление: ставьте 301 на новую страницу или отдавайте 410, если замены нет.
Делают редирект на главную
Такой подход часто выглядит как «быстрое решение», но для SEO это слабый вариант. Пользователь и поисковик теряют контекст. Исправление: перенаправляйте на максимально близкий релевантный адрес, а не на домашнюю страницу.
Оставляют старый URL в sitemap
Даже при редиректе это создает лишний обход и задерживает переоценку структуры сайта. Исправление: уберите адрес из карты сайта и проверьте генерацию на уровне плагина или кода.
Путают canonical и редирект
Canonical помогает подсказать предпочтительный URL, но не заменяет редирект. Если старая версия страницы больше не нужна, canonical сам по себе проблему не решит. Исправление: для окончательного переноса используйте 301.
Ставят 410 на страницу, которая еще нужна пользователям
Это ломает доступ и может создать лишние обращения в поддержку. Исправление: если материал должен остаться доступным, не удаляйте его кодом ответа; лучше обновите контент и адрес или оставьте 301.
Безопасность и производительность: что важно не сломать
Редиректы и фильтры на уровне темы удобны, но при большом количестве правил они становятся хрупкими. Если у вас десятки старых URL, лучше вынести логику в отдельный мини-плагин или настроить серверные редиректы. Так проще сопровождать изменения после обновления темы.
Еще один практический момент: не делайте тяжелые проверки в template_redirect для каждого запроса, если можно решить задачу на уровне маршрутизации или веб-сервера. Для единичных страниц это нормально, но для больших списков лучше использовать более предсказуемый слой.
Если на сайте уже есть SEO-плагин, сначала проверьте его возможности: иногда достаточно исключить записи из sitemap и настроить редирект, не добавляя новый код. Например, в Clearfy Pro есть инструменты для чистки сайта и управления SEO-настройками, но использовать их стоит только там, где это действительно упрощает поддержку. Не дублируйте одну и ту же логику в плагине, теме и functions.php одновременно.
Когда нужен не код, а пересборка структуры
Если старые версии страниц появляются постоянно, проблема обычно глубже, чем один забытый URL. Часто это следствие хаотичной структуры: меняются slug, рубрики, шаблоны архивов, а редиректы не ведутся системно. В такой ситуации полезно сначала описать правила: какие типы страниц можно удалять, какие должны редиректиться, а какие нельзя трогать без согласования.
Для редакции и разработчика это удобнее, чем разбирать каждый случай вручную. Тогда старые версии страниц не копятся в индексе, а переезды становятся предсказуемыми и проверяемыми.