Удалили страницу, поменяли структуру URL или вычистили старый контент — а в индексе и логах всё ещё живут старые адреса. Если оставить их как есть, поисковик будет тратить краулинговый бюджет на мусор, а пользователи — попадать в тупик. В WordPress это обычно решается связкой из корректной 404-страницы, точечных 301-редиректов и проверки, что старые URL не ведут в цепочки.
Ниже — практический сценарий: как понять, какие адреса надо перенаправить, как сделать это без конфликтов с плагинами и как проверить, что всё работает именно так, как задумано.
Когда проблема уже видна в логах и Search Console
Сначала стоит отделить нормальные 404 от тех, которые надо закрыть редиректом. Не каждый удалённый URL должен вести на главную или на ближайшую категорию. Если страница была заменена на новую версию с тем же смыслом, нужен 301. Если контент исчез без замены, 404 или 410 часто честнее и безопаснее для структуры сайта.
Типичные признаки
- в Search Console растут ошибки «Не найдено (404)» по старым URL;
- в логах много запросов к адресам с опечатками, устаревшими слагами или параметрами;
- после смены структуры записей старые ссылки из меню, sitemap или внешних сайтов ведут в пустоту;
- редиректы уже есть, но браузер показывает несколько переходов подряд.
Если у вас уже настроены canonical и закрытие дублей, это не отменяет задачу редиректов. Canonical помогает поисковику понять предпочтительный URL, но не спасает пользователя, который открывает старую ссылку из закладок или из внешнего сайта.
Диагностика: какие URL реально нужно перенаправить
Перед правкой правил полезно собрать список адресов. Для небольшого сайта достаточно отчёта из Search Console и логов веб-сервера. Для более крупного — выгрузки из старой sitemap, базы внешних ссылок и результатов краулинга.
Минимальный чек-лист перед внедрением
- проверьте, есть ли новая релевантная страница для старого URL;
- убедитесь, что старый адрес не используется внутри сайта в меню, хлебных крошках и контенте;
- посмотрите, не создаёт ли редирект цепочку через промежуточный URL;
- отдельно отметьте URL с параметрами, которые не должны индексироваться;
- сохраните список изменений, чтобы потом быстро откатить правило.
Если удалённая страница не имеет замены, не перенаправляйте её на случайную категорию. Это частая ошибка: пользователь попадает не туда, а поисковик видит нерелевантный редирект. Лучше оставить 404 или, если удаление окончательное и осознанное, вернуть 410.
Как настроить 301 редирект в WordPress без лишних конфликтов
Есть три рабочих подхода: плагин, серверный редирект и код в теме или мини-плагине. Для точечных задач удобнее плагин, для большого объёма и высокой нагрузки — конфигурация сервера. Код в WordPress уместен, если редиректов немного и вы хотите держать логику в репозитории.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин редиректов | Нужно быстро править URL без доступа к серверу | Удобно для редактора, есть журнал переходов | Дополнительная нагрузка на WordPress |
| .htaccess / nginx | Много постоянных правил, важна производительность | Срабатывает до загрузки WordPress | Нужен доступ к серверу и аккуратность |
| Код в мини-плагине | Нужны несколько точечных правил под версионирование | Контроль в Git, без лишнего UI | Нужно следить за порядком хуков и тестами |
Пример: редирект старого URL через template_redirect
Если нужно перенаправить несколько конкретных адресов, можно сделать это в мини-плагине. Так правило не потеряется при смене темы.
<?php
/**
* Plugin Name: Site Redirects
*/
add_action('template_redirect', function () {
if (is_admin() || wp_doing_ajax()) {
return;
}
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
$map = [
'/staryj-url/' => '/novyj-url/',
'/blog/old-post/' => '/blog/new-post/',
];
foreach ($map as $from => $to) {
if (untrailingslashit($request_uri) === untrailingslashit($from)) {
wp_redirect(home_url($to), 301);
exit;
}
}
});Такой вариант годится для небольшого набора правил. Если URL много, лучше хранить их в серверной конфигурации или использовать специализированный плагин, чтобы не раздувать логику в PHP.
Пример: редирект на уровне Apache
Если сайт работает на Apache, правило можно добавить в .htaccess. Это быстрее, чем прогонять запрос через WordPress.
Redirect 301 /staryj-url/ https://example.com/novyj-url/
Redirect 301 /blog/old-post/ https://example.com/blog/new-post/Для nginx логика будет другой, но принцип тот же: редирект должен отрабатывать до загрузки WordPress. Это особенно важно, если старых URL много и они часто запрашиваются ботами.
Как правильно отдавать 404, если замены нет
Не все удалённые страницы нужно перенаправлять. Если контент больше не актуален и новой страницы нет, корректная 404-страница лучше, чем фиктивный редирект. В WordPress это обычно уже настроено темой, но важно проверить, что сервер действительно отдаёт статус 404, а не 200 с текстом «ничего не найдено».
Что проверить в шаблоне 404
- вызов
status_header(404)или корректная логика WordPress-шаблона; - отсутствие редиректа на главную вместо ошибки;
- понятный текст для пользователя и ссылки на полезные разделы;
- нет ли на странице 404 индексируемого мусора, который создаёт новые дубли.
Если вы правите шаблон вручную, не ломайте стандартный цикл WordPress. Частая ошибка — выводить «страница не найдена» в контенте, но оставлять HTTP-статус 200. Для поисковика это уже не ошибка, а обычная страница.
Пошаговое решение: от списка URL до проверки
- Соберите список старых адресов из Search Console, логов и старых sitemap.
- Разделите их на три группы: есть новая страница, нет замены, нужен временный редирект.
- Для первой группы настройте 301 на релевантный URL.
- Для второй группы оставьте 404 или отдайте 410, если удаление окончательное.
- Проверьте, что редирект не создаёт цепочку и не уводит на URL с параметрами.
- Обновите внутренние ссылки, чтобы старые адреса не продолжали жить в контенте.
Как проверить, что решение сработало
После внедрения не ограничивайтесь открытием страницы в браузере. Визуально всё может выглядеть нормально, но статус ответа окажется неверным.
Проверка через curl
curl -I https://example.com/staryj-url/В ответе для редиректа должен быть статус 301 и заголовок Location с новым адресом. Для удалённой страницы без замены — 404 или 410, в зависимости от выбранной логики.
Проверка в браузере и Search Console
- откройте старый URL в режиме инкогнито и убедитесь, что адрес меняется ровно один раз;
- проверьте, что конечная страница отдаёт
200; - посмотрите, исчез ли старый URL из отчёта о проблемах после повторного обхода;
- если редиректов много, прогоните сайт краулером и найдите цепочки и петли.
Частые ошибки и как их исправить
Редирект на главную вместо релевантной страницы
Так делают, когда «некуда вести». Но для поисковика и пользователя это слабый сигнал. Если замены нет, лучше 404. Если замена есть, ведите на неё, а не на общую страницу.
Цепочка из нескольких 301
Например, /old/ ведёт на /new/, а потом ещё на /new-2/. Это лишняя задержка и лишний риск ошибок. Сведите все старые адреса сразу к финальному URL.
Конфликт плагина и серверных правил
Если один и тот же URL редиректится и в .htaccess, и в плагине, поведение становится трудно предсказуемым. Оставьте один источник истины: либо сервер, либо WordPress, либо отдельный плагин с журналом.
Редирект по шаблону ломает служебные страницы
Иногда правило слишком широкое и начинает цеплять /wp-json/, /feed/ или страницы с параметрами. Перед выкладкой проверьте, что исключения не нужны только на бумаге, а реально работают.
Производительность и безопасность: что важно не упустить
Если редиректов немного, разница между плагином и сервером не критична. Но когда правил становится много, лучше не заставлять WordPress обрабатывать каждый старый URL. Это лишняя нагрузка на PHP и базу, особенно на посещаемых сайтах.
С точки зрения безопасности не стоит принимать произвольный URL из параметра и отправлять пользователя туда без проверки. Открытые редиректы часто используют в фишинге. Если строите логику сами, жёстко ограничивайте список допустимых адресов.
Для сайтов, где нужно регулярно чистить дубли, служебные URL и старые адреса, полезно держать под рукой инструменты для технической оптимизации. Например, Clearfy Pro закрывает часть типовых задач по чистке и SEO-настройкам, но даже с ним логику редиректов всё равно нужно проверять вручную: автоматизация не отменяет контроль статусов и цепочек.
Что должно получиться в итоге
После настройки старые URL либо корректно ведут на новые страницы с кодом 301, либо честно отдают 404/410. Внутренние ссылки обновлены, цепочек редиректов нет, а в отчётах поисковой системы остаются только те ошибки, которые действительно требуют внимания.
Если хотите, следующий шаг — пройтись по sitemap и внутренним ссылкам, чтобы старые адреса не возвращались в индекс через новые публикации и архивы.