Если на сайте уже накопились старые URL, сменились слаги записей или после переноса остались битые ссылки, проблема обычно не в «SEO вообще», а в двух конкретных вещах: сервер отдаёт 404 там, где должен быть редирект, и поисковик продолжает видеть устаревшие адреса. В WordPress это лечится не одним плагином, а нормальной схемой: сначала находим источник битых URL, потом ставим 301 только там, где есть замена, и отдельно решаем, что делать с настоящими 404.
Ниже — рабочий сценарий для обычного сайта на WordPress: без выдуманных хуков, без магии и без попытки закрыть все проблемы одним правилом в .htaccess.
Когда 404 — это ошибка, а когда нормальное поведение
Не каждая страница с кодом 404 требует редиректа. Если адрес никогда не существовал, а на него просто пришёл бот или кто-то ошибся в ссылке, 404 — нормальный ответ. Редирект нужен только тогда, когда у старого URL есть понятная новая цель: вы поменяли структуру постоянных ссылок, переименовали запись, перенесли раздел или удалили страницу, но у неё есть прямой аналог.
Плохая практика — отправлять все несуществующие URL на главную. Для пользователя это выглядит как мягкая ошибка, а для поисковика часто как попытка скрыть проблему. В итоге теряется сигнал о том, что страница действительно исчезла, и растёт количество «мусорных» переходов.
Диагностика: откуда берутся битые URL
Сначала нужно понять, какие именно адреса ломаются и кто на них ссылается. Иначе можно поставить редирект наугад и только замаскировать проблему.
Что проверить в первую очередь
- Журнал 404 в плагине аналитики или в логах сервера.
- Внутренние ссылки в меню, виджетах, хлебных крошках и старых записях.
- Старые URL после смены структуры постоянных ссылок.
- Ссылки из внешних источников: старые статьи, каталоги, соцсети, email-рассылки.
Если у вас есть доступ к серверным логам, полезно посмотреть не только сам путь, но и реферер. Это помогает понять, проблема внутри сайта или снаружи. Для WordPress-проектов это особенно важно после миграции с другого движка или после редизайна.
Быстрая проверка через браузер и curl
Перед настройкой редиректа проверьте, что именно отдаёт сервер. Иногда плагин уже создаёт правило, но оно конфликтует с кэшем или с правилами Nginx/Apache.
curl -I https://example.com/staryi-url/В ответе смотрите на три вещи: код ответа, заголовок Location и цепочку переходов. Для 301 должен быть один понятный переход на новый адрес, без петли и без промежуточных прыжков через главную.
Пошаговое решение: как настроить 301 редиректы в WordPress
Есть три рабочих подхода: плагин, серверные правила и код в теме или мини-плагине. Выбор зависит от объёма задач и от того, кто будет поддерживать сайт дальше.
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| Плагин редиректов | Нужно быстро закрыть несколько URL и вести журнал 404 | Удобно, есть интерфейс | Дополнительная нагрузка, риск конфликтов |
| .htaccess / Nginx | Много постоянных правил, нужен минимальный оверхед | Быстро и прозрачно | Нужен доступ к серверу, легко ошибиться |
| Код в мини-плагине | Нужна точечная логика и контроль в репозитории | Версионирование, можно тестировать | Нужно писать и поддерживать код |
Вариант 1: редирект через плагин
Если у вас нет доступа к конфигам сервера, проще всего использовать плагин для редиректов. Важно не плодить десятки правил без системы: сначала составьте список старых и новых URL, потом добавляйте их пачкой и проверяйте по одному.
При настройке обращайте внимание на тип редиректа. Для постоянной замены нужен именно 301, а не 302. Временный редирект оставляет поисковику сигнал, что старый адрес ещё может вернуться.
Вариант 2: правила в .htaccess для Apache
Если сайт работает на Apache, точечные редиректы можно задать прямо в .htaccess. Это удобно для старых URL, которые не зависят от логики WordPress.
Redirect 301 /staryi-url/ https://example.com/novyi-url/Для более сложных случаев иногда используют mod_rewrite, но без необходимости лучше не усложнять. Чем короче правило, тем проще потом понять, почему оно сработало или не сработало.
Вариант 3: мини-плагин с хуком template_redirect
Если редиректов немного, но они завязаны на логику WordPress, безопаснее вынести их в мини-плагин, а не в functions.php темы. Так правило не исчезнет после смены темы.
<?php
/**
* Plugin Name: Custom Redirects
*/
add_action('template_redirect', function () {
if (is_admin()) {
return;
}
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
if ($request_uri === '/staryi-url/' || $request_uri === '/staryi-url') {
wp_redirect(home_url('/novyi-url/'), 301);
exit;
}
});Такой вариант подходит для одного-двух адресов. Если редиректов становится много, лучше перейти на таблицу соответствий или на серверные правила, иначе код быстро превратится в список исключений без структуры.
Как правильно обработать настоящие 404
Не все битые адреса нужно перенаправлять. Если страница удалена без замены, оставляйте 404 или 410, но не делайте вид, что контент существует. Для поисковика это честнее и понятнее.
Если удалённый материал был важным и у него есть близкая замена, редиректите на наиболее релевантную страницу, а не на категорию «на всякий случай». Если замены нет, лучше оставить 404 и убрать внутренние ссылки на этот адрес.
Что делать с массовыми 404 после переноса сайта
- Соберите список старых URL из логов и Search Console.
- Сопоставьте каждый адрес с новой страницей или разделом.
- Добавьте 301 только там, где есть смысловая замена.
- Удалите или обновите внутренние ссылки в контенте.
- Проверьте, не создаёт ли тема или плагин лишние ссылки на старый путь.
Проверка результата после внедрения
После настройки не ограничивайтесь визуальной проверкой в браузере. Нужно убедиться, что сервер отдаёт нужный код, редирект не зациклен и конечная страница открывается без промежуточных переходов.
curl -I https://example.com/staryi-url/Ожидаемый результат для постоянного редиректа: HTTP/1.1 301 Moved Permanently и заголовок Location с новым адресом. Затем проверьте конечный URL отдельно:
curl -I https://example.com/novyi-url/Там должен быть 200 OK, если страница существует. Если вместо этого снова идёт редирект, значит, в цепочке есть лишнее правило или конфликт со слэшем в конце URL.
Ещё один практический тест — открыть старый адрес в режиме инкогнито и посмотреть, не вмешивается ли кэш. Иногда браузер или CDN держит старый ответ, и кажется, что правило не работает, хотя на сервере всё уже исправлено.
Частые ошибки и как их исправить
Редирект на главную вместо релевантной страницы
Это самая частая ошибка. Она маскирует проблему, но не решает её. Исправление простое: ищите ближайший аналог по теме старой страницы, а если аналога нет — оставляйте 404.
Смешивание 301 и 302
Если старый URL должен исчезнуть окончательно, нужен 301. 302 оставляет поисковику сигнал, что адрес временный, и это мешает нормальной переиндексации.
Петля редиректов
Петля появляется, когда старый URL редиректит на новый, а новый из-за другого правила возвращается обратно или снова переписывается. Обычно это случается при одновременной настройке в плагине, в .htaccess и в кэширующем плагине. Решение — оставить одно место, где управляются правила, и удалить дубли.
Редирект без учёта слэша и регистра
На некоторых сайтах /page и /page/ ведут себя по-разному. То же самое касается регистра в URL, если сервер или плагин не нормализует путь. Перед массовым добавлением правил проверьте, как именно WordPress формирует постоянные ссылки на вашем сайте.
Безопасность и производительность
Редиректы — это не только SEO, но и нагрузка. Если правила написаны неаккуратно, каждый запрос может проходить через лишнюю логику. На небольшом сайте это незаметно, но на проекте с большим трафиком и кэшем лишние проверки лучше не плодить.
С точки зрения безопасности не стоит ставить сомнительные плагины редиректов без поддержки и обновлений. Если нужен дополнительный функционал вокруг технической чистки сайта, имеет смысл смотреть в сторону проверенных решений вроде Clearfy Pro: он помогает закрывать часть типовых SEO-задач и уменьшать количество ручных правок. Подробности есть на странице плагина.
Если редиректов много и они критичны для проекта, держите список правил в репозитории или хотя бы в отдельном файле с комментариями. Через полгода никто не вспомнит, почему конкретный URL уводили именно туда, а не в другой раздел.
Что проверить после публикации изменений
- Старый URL отдаёт 301, а не 302.
- Новый URL открывается с кодом 200.
- Нет цепочки из нескольких редиректов.
- Внутренние ссылки в контенте обновлены.
- 404-страница остаётся доступной для реально несуществующих адресов.
- В Search Console постепенно уменьшается число старых URL, которые получают переходы.
Если после внедрения редиректов в логах всё ещё появляются старые адреса, это не всегда ошибка. Иногда внешние сайты продолжают ссылаться на старый путь, и тогда задача не в том, чтобы убрать сам запрос, а в том, чтобы направить его в правильное место без лишних промежуточных шагов.