404 в WordPress редко появляются «сами по себе». Обычно это следствие старых URL после редизайна, неверных ссылок в контенте, конфликтов с правилами ЧПУ, удаления файлов темы или плагина, а иногда — кривой миграции с другого сайта. Если просто поставить редирект на главную, проблема не исчезает: поисковики продолжают видеть мусорные URL, а пользователи ловят битые страницы.
Ниже — рабочая схема: как найти источник 404, чем закрыть проблему на уровне контента, а где нужен редирект или правка кода.
Как понять, откуда берутся 404
Сначала нужно не «чинить», а зафиксировать источник. В WordPress 404 обычно видно в трех местах: в логах сервера, в Search Console и в аналитике. Если сайт небольшой, достаточно открыть самые частые URL из отчета об ошибках и посмотреть, что именно запрашивается: страница записи, изображение, файл темы, REST-эндпоинт или старый адрес рубрики.
Что проверить в первую очередь
- есть ли 404 на старых URL после смены структуры постоянных ссылок;
- не удаляли ли вы изображения, PDF или другие файлы из
/wp-content/uploads/; - не менялись ли слаги записей, рубрик, страниц;
- не конфликтует ли плагин кеша или редиректов с правилами
.htaccess; - не ломает ли тему вывод ссылок в меню, хлебных крошках или блоках.
Если 404 массовые и однотипные, почти всегда причина в шаблоне или плагине. Если ошибки точечные, чаще всего это старые внешние ссылки или удаленный контент.
Диагностика проблемы без догадок
Самый быстрый способ — открыть проблемный URL и посмотреть, что именно возвращает сервер. Для этого удобно использовать curl или любой HTTP-клиент. Так вы сразу увидите код ответа, а не только страницу темы с сообщением «ничего не найдено».
curl -I https://example.com/staryy-url/Если в ответе действительно 404 Not Found, дальше смотрите, существует ли такой объект в админке WordPress. Иногда запись есть, но у нее другой slug. Иногда файл физически удален, а ссылка осталась в контенте или в медиатеке.
Для поиска внутренних ссылок по базе данных можно использовать SQL-запрос к таблице wp_posts. Он помогает найти старый адрес в тексте записей, страниц и кастомных типов записей.
SELECT ID, post_title, post_type
FROM wp_posts
WHERE post_content LIKE '%/staryy-url/%'
OR post_excerpt LIKE '%/staryy-url/%';Если у вас префикс таблиц не wp_, подставьте свой. Запрос не исправляет проблему, но быстро показывает, где ссылка живет в контенте.
Пошаговое решение: что делать с каждой группой 404
1. Исправить внутренние ссылки
Если URL встречается внутри записей, страниц, виджетов или блоков, лучше заменить его на актуальный. Это надежнее, чем держать редирект на старый адрес бесконечно. Для массовой замены подойдет поиск по базе через WP-CLI, если он у вас есть, или через инструмент поиска и замены в админке, но только с предварительным бэкапом.
Пример безопасной замены через WP-CLI:
wp search-replace 'https://example.com/staryy-url/' 'https://example.com/novyy-url/' --skip-columns=guidПараметр --skip-columns=guid нужен, чтобы не трогать GUID записей. Это стандартная практика для WordPress, и ее не стоит игнорировать.
2. Настроить редирект там, где URL уже внешне закреплен
Если на старый адрес ведут внешние ссылки, закладки пользователей или поисковый индекс, редирект оправдан. Для единичных случаев можно добавить правило в .htaccess или конфигурацию Nginx. Для массовых — использовать плагин редиректов, но не плодить цепочки из нескольких переходов.
Пример правила для Apache:
Redirect 301 /staryy-url/ https://example.com/novyy-url/Если у вас Nginx, правило будет другим, и его лучше добавлять в конфиг сервера, а не пытаться имитировать через PHP. Важно: не редиректите все 404 на главную. Это ухудшает поведение сайта и мешает поисковикам понимать, что страница действительно исчезла.
3. Восстановить удаленный файл или заменить ссылку на медиа
Если 404 отдает картинка, PDF или архив, сначала проверьте, есть ли файл в /uploads/. Иногда проблема в том, что файл удалили вручную по FTP, а ссылка осталась в контенте. В таком случае правильнее либо вернуть файл, либо обновить ссылку в записи. Для медиа лучше не полагаться на ручной поиск по страницам, если файлов много.
4. Проверить правила ЧПУ и слагов
После переноса сайта или массовой правки записей иногда сбиваются правила пермалинков. В админке это выглядит как случайные 404 на существующие страницы. В таком случае помогает сброс правил: зайдите в Настройки → Постоянные ссылки и просто сохраните настройки без изменений. Это пересобирает rewrite rules.
Если проблема не ушла, проверьте, не конфликтует ли кастомный post type с одинаковым slug у страницы и типа записи. В WordPress это частая причина странных 404.
Когда нужен код: ловим и логируем 404 на стороне темы или плагина
Если вы разрабатываете тему или плагин, полезно логировать 404, чтобы понять, какие URL ломаются после релиза. WordPress дает для этого хук template_redirect и условный тег is_404(). Ниже пример, который пишет проблемный URL в error log только для администраторов сайта, чтобы не шуметь в продакшене.
add_action('template_redirect', function () {
if (is_404() && current_user_can('manage_options')) {
error_log('404 URL: ' . esc_url_raw(home_url(add_query_arg(array(), $_SERVER['REQUEST_URI']))));
}
});Этот код не чинит 404, но помогает быстро собрать список проблемных адресов после обновления темы или плагина. Для боевого сайта лучше ограничить логирование по времени или включать его только на короткий период диагностики.
Если нужно отдать кастомную 404-страницу с полезными ссылками, не делайте это через жесткий редирект. Лучше доработать шаблон 404.php: добавить поиск по сайту, ссылки на популярные разделы и форму обратной связи.
<?php get_header(); ?>
<main class="site-main">
<h1>Страница не найдена</h1>
<p>Проверьте адрес или воспользуйтесь поиском по сайту.</p>
<?php get_search_form(); ?>
</main>
<?php get_footer(); ?>Сравнение подходов: плагин, код или ручная правка
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин редиректов | Много старых URL, нужен интерфейс для менеджера | Быстро настраивать, удобно вести список | Легко получить цепочки и лишние правила |
| Код в теме/плагине | Нужна точечная логика или логирование | Контроль, минимум лишнего | Требует разработки и тестирования |
| Ручная правка ссылок | Проблема сидит в контенте | Убирает причину, а не симптом | Долго на большом сайте |
Проверка результата после внедрения
После исправлений не ограничивайтесь открытием одной страницы в браузере. Проверьте несколько уровней:
- проблемный URL должен отдавать
200, если страница восстановлена; - старый адрес должен отдавать
301на новый URL, если вы сделали редирект; - внутренние ссылки в контенте должны вести сразу на актуальный адрес;
- в Search Console количество 404 по этому шаблону должно перестать расти;
- в логах сервера не должно быть повторяющихся запросов к одному и тому же несуществующему URL.
Проверить код ответа можно так:
curl -I https://example.com/novyy-url/
curl -I https://example.com/staryy-url/Если редирект настроен правильно, первый запрос вернет 200, второй — 301 с заголовком Location на новый адрес. Если вместо этого видите цепочку из нескольких переходов, сократите ее до одного шага.
Частые ошибки и как их исправить
Редирект на главную вместо точечного URL
Это самая вредная «быстрая починка». Пользователь не получает нужную страницу, а поисковик видит нерелевантную подмену. Исправление простое: редирект должен вести на ближайший по смыслу адрес или на аналогичный материал, а не на корень сайта.
Смена slug без обновления внутренних ссылок
Страница открывается, но половина сайта продолжает ссылаться на старый адрес. Решение — массовая замена ссылок в контенте и меню, а не только редирект.
Удаление файлов из uploads вручную
Если удалить картинку по FTP, WordPress не всегда успевает корректно почистить ссылки в контенте. Лучше удалять медиа через медиатеку или сразу искать все вхождения файла в записи.
Конфликт правил у плагина кеша или SEO-плагина
Иногда 404 появляются после обновления плагина, который переписывает правила или вмешивается в canonical/redirect logic. В таком случае временно отключите подозрительный плагин, проверьте URL и включайте обратно по одному, чтобы найти источник конфликта.
Что стоит держать под контролем дальше
Если сайт регулярно обновляется, 404 лучше не ловить вручную раз в месяц. Практичнее держать короткий процесс: раз в неделю смотреть отчет Search Console, разбирать новые битые URL, обновлять внутренние ссылки и удалять устаревшие редиректы. На больших проектах помогает отдельный список старых адресов после редизайна или миграции.
Если у вас много технических задач по чистке сайта, дублирующимся URL и лишним служебным страницам, часть рутины можно закрыть плагином вроде Clearfy Pro, но только как инструмент для ускорения работы, а не как замену нормальной диагностики. Сначала найдите источник 404, потом уже автоматизируйте повторяющиеся действия.