Удалить страницу в WordPress — это только половина задачи. Если URL уже индексировался, на него есть внутренние ссылки или внешние упоминания, простой статус 404 часто приводит к потере трафика и накоплению ошибок в отчётах поисковых систем. В таких случаях нужен понятный сценарий: куда именно перенаправлять старый адрес, как не сломать каноникализацию и как проверить, что редирект работает без цепочек и лишних переходов.
Ниже — рабочая схема для типичного сайта на WordPress: когда страница удалена, но у неё есть замена, близкая по смыслу категория или родительский раздел. Если замены нет, редирект всё равно можно настроить, но решение должно быть осознанным, а не автоматическим.
Когда 301 нужен, а когда лучше оставить 404 или 410
Не каждая удалённая страница должна вести на главную. Это частая ошибка: так делают «на всякий случай», а потом получают нерелевантные переходы и плохие сигналы для поисковых систем. Сначала нужно понять сценарий.
Подходит 301, если
- у удалённой страницы есть точный аналог или новая версия;
- контент перенесён на другой URL;
- страница собирала внешние ссылки или стабильный органический трафик;
- нужно сохранить пользователей из старых закладок и ссылок.
Лучше не редиректить наугад, если
- страница была технической, временной или мусорной;
- нет близкой замены по смыслу;
- редирект ведёт на нерелевантный раздел только ради «сохранения веса»;
- URL уже давно не нужен и не имеет ценности для пользователей.
Если страницы больше не существует и замены нет, иногда корректнее вернуть 410 Gone или обычный 404 с нормальной страницей ошибки. Это честнее для поисковиков и проще для поддержки сайта.
Диагностика: что проверить до настройки редиректа
Перед изменениями посмотрите, как URL используется сейчас. Это помогает избежать цепочек вида /old-page/ → /new-page/ → /final-page/, которые замедляют переход и усложняют индексацию.
- Есть ли страница в индексе поисковиков.
- Есть ли на неё внутренние ссылки в меню, записях, хлебных крошках.
- Есть ли внешние ссылки из других сайтов.
- Не совпадает ли новый URL с уже существующим редиректом.
- Не используется ли адрес в sitemap.xml.
Если у вас установлен плагин для SEO или редиректов, сначала проверьте, не создаёт ли он уже правила автоматически. Дублирующие настройки в плагине и в .htaccess — типичная причина конфликтов.
Пошаговое решение: как настроить 301 в WordPress
Есть три практических подхода: через плагин, через серверную конфигурацию и через код темы или небольшого плагина. Выбор зависит от того, сколько редиректов нужно поддерживать и кто будет ими управлять.
| Способ | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| Плагин | Несколько редиректов, нужен интерфейс | Проще для редактора, не требует правки сервера | Дополнительная нагрузка и риск дублей правил |
| .htaccess / nginx | Много правил, нужен быстрый ответ сервера | Работает до загрузки WordPress | Нужен доступ к конфигам и аккуратность |
| Код в WordPress | Небольшой набор точечных правил | Можно хранить рядом с логикой сайта | Не лучший вариант для большого числа редиректов |
Вариант 1: редирект через код
Если нужно перенаправить один или несколько конкретных URL, можно сделать это в небольшом плагине или в functions.php дочерней темы. Для точечных случаев это рабочий вариант, но лучше не перегружать им сайт.
<?php
add_action('template_redirect', function () {
if (is_admin()) {
return;
}
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
$map = [
'/old-page/' => '/new-page/',
'/category/old-section/' => '/category/new-section/',
];
foreach ($map as $from => $to) {
if (strpos($request_uri, $from) === 0) {
wp_redirect(home_url($to), 301);
exit;
}
}
});Здесь важно, что сравнение идёт по началу URI. Если вам нужен точный матч, лучше сравнивать без параметров и без хвоста, чтобы не задеть похожие адреса.
Вариант 2: редирект на уровне сервера
Если сайт на Apache, правило можно добавить в .htaccess. Это быстрее, чем обработка через WordPress, и не зависит от темы.
Redirect 301 /old-page/ https://example.com/new-page/Для nginx логика похожая, но правило пишется в конфиге сервера. Формат зависит от вашей схемы размещения, поэтому копировать чужой блок без проверки не стоит.
Вариант 3: плагин редиректов
Если редиректов много и ими управляет редактор, удобнее использовать отдельный плагин. Важно только не смешивать один и тот же набор правил в нескольких местах. Если правило уже есть в серверной конфигурации, в плагин его дублировать не нужно.
Для сайтов, где параллельно приходится чистить дубли, закрывать служебные страницы и управлять индексированием, часто удобнее держать SEO-логику в одном месте. Например, Clearfy Pro закрывает часть типовых технических задач по дублям и мусорным страницам, но редиректы всё равно нужно настраивать осознанно, а не автоматически.
Как не сломать редирект при удалении страницы
Самая частая проблема — удалить запись в админке раньше, чем подготовить правило. В результате URL начинает отдавать 404, а потом его уже приходится искать по логам и отчётам. Правильнее сначала определить целевой адрес, затем добавить редирект и только после этого удалять или переводить страницу в архив.
- Сначала создайте новую страницу или проверьте существующую замену.
- Добавьте 301 на старый URL.
- Проверьте, что новый адрес отвечает 200 OK.
- Убедитесь, что старый URL не участвует в цепочке редиректов.
- Только потом удаляйте исходную запись или снимайте её с публикации.
Проверка результата после внедрения
После настройки нужно проверить не только факт перехода, но и его качество. Откройте старый URL в браузере и посмотрите, куда он ведёт. Лучше дополнительно проверить заголовки ответа.
curl -I https://example.com/old-page/В ответе должен быть статус 301 Moved Permanently и заголовок Location с целевым адресом. Если вы видите 302, значит редирект временный, а для удалённой страницы это обычно не то, что нужно.
Что ещё проверить вручную:
- старый URL не открывается по нескольким промежуточным адресам;
- новая страница не редиректит дальше без необходимости;
- внутренние ссылки уже обновлены на новый адрес;
- в sitemap остались только актуальные URL;
- в отчётах сканирования больше не растёт число 404 по этому адресу.
Частые ошибки и как их исправить
Редирект ведёт на главную
Это удобно только на первый взгляд. Если страница была про конкретную тему, главная не является полноценной заменой. Исправление простое: подберите ближайший по смыслу URL или оставьте 404/410, если замены нет.
Получается цепочка редиректов
Например, старый адрес сначала ведёт на промежуточную страницу, а та — ещё дальше. Такое часто возникает после нескольких миграций сайта. Решение: сократить цепочку до одного перехода и обновить все внутренние ссылки на финальный URL.
Правило конфликтует с плагином SEO
Если один и тот же URL обрабатывается и в плагине, и в серверной конфигурации, результат может быть непредсказуемым. Оставьте только один источник правды для каждого правила.
Редирект не срабатывает на URL с параметрами
Иногда старые ссылки содержат ?utm= или другие параметры. В таком случае нужно проверять не только путь, но и нормализованный адрес без query string, если это соответствует вашей задаче.
Безопасность и производительность: что учесть на живом сайте
Если редиректов немного, кодовый вариант не создаст заметной нагрузки. Но когда правил много, лучше не держать их в functions.php. Для большого количества перенаправлений серверная конфигурация обычно надёжнее и быстрее.
Ещё один практический момент — доступ к редактированию редиректов. Не давайте эту возможность всем подряд. Ошибка в одном правиле может увести трафик на чужую страницу или создать петлю. Если редиректы управляются через админку, ограничьте роли и проверяйте изменения перед публикацией.
Короткий чек-лист перед удалением страницы
- Проверен текущий трафик и наличие внешних ссылок.
- Определён целевой URL или принято решение оставить 404/410.
- Редирект добавлен в одном месте, без дублей.
- Старый адрес отвечает 301, новый — 200.
- Нет цепочек и циклов перенаправления.
- Внутренние ссылки и sitemap обновлены.
Если задача не ограничивается одной страницей, а вы регулярно чистите дубли, служебные URL и технический мусор, имеет смысл выстроить единый процесс: сначала карта редиректов, потом обновление ссылок, затем проверка ответов сервера. В WordPress это экономит время лучше, чем разовые ручные правки после каждого удаления записи.