404 в WordPress редко появляются «сами по себе». Обычно это следствие смены структуры URL, удаления записей, неверных ссылок в меню, старых адресов из поиска или конфликтов с правилами ЧПУ. Если не разбирать источник, можно бесконечно ставить редиректы и всё равно получать новые ошибки.
Ниже — рабочая схема: сначала находим, откуда приходит 404, потом решаем, что делать с каждым типом адресов, и в конце проверяем, что проблема действительно закрыта, а не просто спрятана в логах.
Как понять, что именно ломается
Перед исправлением важно разделить три сценария. Первый — удалённая страница, на которую ещё ведут внутренние ссылки. Второй — старый адрес после изменения структуры постоянных ссылок. Третий — мусорные запросы от ботов, которые не имеют отношения к контенту сайта. Для каждого случая решение разное.
Где смотреть источник 404
Самый быстрый способ — открыть отчёт сервера или логи в панели хостинга. Если доступа к логам нет, используйте Google Search Console и любой плагин для логирования 404. Важно не просто увидеть адрес, а понять, откуда он пришёл: из меню, из статьи, из внешней ссылки или из индекса поисковика.
Если 404 появляются после миграции сайта, проверьте:
- структуру постоянных ссылок в
Настройки → Постоянные ссылки; - наличие старых URL в меню и виджетах;
- внутренние ссылки в записях и страницах;
- редиректы на уровне сервера или плагина;
- не менялись ли slug у рубрик и записей.
Диагностика: что делать в первую очередь
Не начинайте с массовой установки редиректов. Сначала соберите список адресов, которые реально дают 404. Если ошибок десятки, а не тысячи, их проще закрыть точечно. Если 404 идут пачкой по одному шаблону, например /category/ или старый префикс рубрик, значит проблема в структуре URL, а не в отдельных страницах.
Полезно проверить и саму страницу ошибки. Иногда тема или плагин подменяют стандартный ответ 404 на страницу с кодом 200. Визуально это выглядит как «страница не найдена», но для поисковика это уже не ошибка, а дублирующий контент. Такой случай нужно исправлять отдельно.
Пошаговое решение
1. Верните корректные правила ЧПУ
Если после переноса сайта или правки .htaccess начали сыпаться 404 на все красивые ссылки, сначала сбросьте правила постоянных ссылок. В админке откройте настройки и просто сохраните их заново. Это пересоздаст rewrite rules без ручного редактирования базы.
Если нужно сделать это программно, можно временно сбросить правила при активации темы или плагина:
<?php
register_activation_hook(__FILE__, function () {
flush_rewrite_rules();
});
Но так делать нужно только на активации, а не на каждом запросе. Постоянный вызов flush_rewrite_rules() бьёт по производительности.
2. Закройте удалённые страницы редиректом 301
Если страница удалена, но на неё есть внешние ссылки или она уже в индексе, лучше настроить 301 на ближайший релевантный адрес. Не отправляйте всё на главную: это плохой пользовательский сценарий и слабый сигнал для поисковика.
Простой вариант на уровне WordPress — редирект через template_redirect для конкретных URL:
<?php
add_action('template_redirect', function () {
if (is_404()) {
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
if ($request_uri === '/staryi-article/') {
wp_redirect(home_url('/novyi-article/'), 301);
exit;
}
}
});
Для нескольких адресов удобнее хранить карту редиректов в отдельном массиве или использовать серверные правила, если их много. В WordPress-слое такой код уместен только для небольшого числа точечных случаев.
3. Исправьте внутренние ссылки
Если 404 создаются самим сайтом, редирект не решает корень проблемы. Найдите записи, страницы, меню и блоки, где остались старые URL, и замените их на актуальные. Особенно часто ломаются:
- ссылки в произвольных HTML-блоках;
- ссылки в старых шаблонах темы;
- ссылки в ACF-полях или кастомных метаполях;
- ссылки в меню, если менялся slug рубрики;
- ссылки в хлебных крошках и блоках похожих материалов.
Если у вас есть доступ к базе и нужно быстро найти старый адрес, можно использовать поиск по контенту через WP-CLI или SQL, но с осторожностью. Для массовой замены лучше сначала сделать резервную копию.
4. Проверьте шаблон 404.php
Иногда проблема не в URL, а в том, как тема отдаёт ошибку. Страница должна возвращать именно HTTP 404, а не 200. В шаблоне 404.php не должно быть ручной подмены статуса на успешный ответ.
Минимальный корректный шаблон выглядит так:
<?php
get_header();
status_header(404);
nocache_headers();
?>
<main class="site-main">
<h1>Страница не найдена</h1>
<p>Проверьте адрес или вернитесь на главную.</p>
</main>
<?php get_footer();
Если тема использует кастомный шаблон, проверьте, что он не вызывает wp_redirect() на главную без причины и не скрывает ошибку за страницей с кодом 200.
Что выбрать: плагин, код или серверные правила
Для разных объёмов проблемы подходят разные инструменты. Если редиректов немного и они меняются редко, можно обойтись кодом. Если адресов много и ими управляет редакция, удобнее плагин. Если сайт большой и нагрузка заметная, часть правил лучше вынести на сервер.
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| Код в теме/плагине | 1–20 точечных редиректов | Контроль, без лишних зависимостей | Нужно сопровождать вручную |
| Плагин редиректов | Редиректами управляет редактор или SEO-специалист | Удобная админка, журнал 404 | Дополнительная нагрузка и риск конфликтов |
| .htaccess / nginx | Много однотипных правил | Быстрее на уровне сервера | Ошибки в правилах могут сломать сайт |
Если нужен не только редирект, но и общая чистка сайта от дублей, лишних архивов и технического мусора, иногда удобнее подключить плагин уровня Clearfy Pro: он закрывает часть SEO-технических задач в одном месте. Но даже в этом случае логику редиректов и карту проблемных URL лучше держать отдельно и проверять вручную.
Проверка результата после внедрения
После исправлений не ограничивайтесь открытием страницы в браузере. Проверьте три вещи: код ответа, отсутствие цепочек редиректов и отсутствие новых 404 по тем же адресам.
- Откройте старый URL через
curl -Iи убедитесь, что он отдаёт301или404в зависимости от сценария. - Проверьте, что конечный адрес отдаёт
200. - Посмотрите, нет ли цепочки
301 → 301 → 200. - Обновите отчёт 404 в Search Console и сравните список через несколько дней.
Пример проверки из консоли:
curl -I https://example.com/staryi-article/
curl -I https://example.com/novyi-article/
Если на старом адресе вы видите 301 Moved Permanently, а на новом 200 OK, базовая часть решения работает. Если вместо этого приходит 200 OK на старый адрес, значит редирект не сработал или его перебивает другой слой.
Частые ошибки и как их исправить
Редирект на главную вместо релевантной страницы
Это самая частая ошибка. Она кажется удобной, но пользователю не помогает и поисковику не объясняет, куда делся контент. Если аналогичной страницы нет, лучше оставить честный 404 или 410, чем отправлять всё на главную.
Сброс правил постоянных ссылок на каждом запросе
Так иногда делают в коде «для надёжности». На деле это лишняя нагрузка и риск нестабильности. flush_rewrite_rules() должен вызываться только при активации или после изменения структуры URL, а не в обычном фронтенд-запросе.
Скрытая 404-страница с кодом 200
Если тема выводит красивую страницу ошибки, но не меняет HTTP-статус, поисковик может индексировать её как обычную страницу. Проверяйте статус ответом сервера, а не только визуально.
Массовая замена без бэкапа
При правке ссылок в базе легко задеть не только контент, но и сериализованные данные. Если используете поиск и замену, убедитесь, что инструмент умеет работать с сериализацией. Иначе можно повредить настройки виджетов, блоков и плагинов.
Практические советы по безопасности и производительности
Редиректы и логирование 404 — это не только SEO, но и вопрос нагрузки. На больших сайтах журнал ошибок быстро разрастается, а некоторые боты специально перебирают тысячи несуществующих URL. Не храните бесконечный лог в базе без ротации и не ставьте тяжёлые плагины ради одной задачи.
- ограничьте срок хранения логов 404;
- не логируйте каждый мусорный запрос, если их слишком много;
- закрывайте старые URL точечно, а не через универсальные правила «всё на главную»;
- проверяйте редиректы после обновления темы и плагинов;
- если редиректов много, выносите их на серверный уровень.
Если на сайте регулярно меняется структура контента, полезно заранее вести таблицу старых и новых URL. Это экономит время при миграциях и снижает риск накопления 404 после очередного редизайна.