404 в WordPress редко появляются «сами по себе». Обычно это следствие смены постоянных ссылок, удаления записей, старых внутренних ссылок, кривых редиректов или мусора от плагинов. Проблема в том, что одна и та же ошибка может быть и нормальной, и вредной: часть URL уже давно не нужна, а часть всё ещё приносит трафик или используется во внутренних ссылках.
Ниже — рабочий сценарий: как быстро найти источник 404, чем закрывать проблему в зависимости от причины и как проверить, что вы не сломали живые страницы.
Когда 404 — это действительно проблема
Не каждый 404 нужно срочно чинить. Если бот или пользователь зашёл на случайный старый адрес без внешних ссылок и без внутренних переходов, это обычная ситуация. Но есть признаки, что 404 уже мешают:
- в отчётах Search Console растёт число несуществующих URL;
- на 404 ведут внутренние ссылки из меню, контента или виджетов;
- старый адрес имеет внешние ссылки и должен отдавать редирект;
- после миграции сайта сломались категории, записи или вложения;
- 404 появляются на страницах с параметрами, которые генерирует тема или плагин.
Диагностика: откуда берутся битые URL
Сначала нужно понять источник. Без этого легко поставить редирект не туда или замаскировать проблему вместо исправления.
Проверьте отчёты поиска и логи сервера
Если у вас подключена Google Search Console, откройте раздел с ошибками сканирования и посмотрите конкретные URL. Важно не только наличие 404, но и тип адреса: это старая запись, файл, категория, параметр или что-то с опечаткой.
Если есть доступ к логам веб-сервера, ищите повторяющиеся запросы к одному и тому же пути. Это помогает отличить случайный мусор от реально популярного старого адреса.
Посмотрите, не ведут ли на 404 внутренние ссылки
Частая причина — ссылка в контенте, меню, хлебных крошках или блоке «похожие записи». Если 404 генерируется внутри сайта, редирект не решит первопричину: ссылка всё равно будет ломаться при каждом обходе.
Удобный способ — пройтись по сайту краулером или хотя бы проверить проблемный URL через поиск по базе/контенту, если вы знаете, где он мог быть вставлен.
Сравните старый и новый адрес
После смены структуры постоянных ссылок WordPress старые URL часто перестают совпадать с новыми. Например, запись раньше открывалась по /2023/09/post-name/, а теперь — по /post-name/. В таком случае нужен не «ремонт 404», а нормальный 301-редирект.
Пошаговое решение: что делать в зависимости от причины
1. Если страница должна существовать — восстановите или перенесите её
Если URL был удалён случайно, проще вернуть запись, страницу или файл. Это лучше, чем редиректить всё подряд на главную. Редирект на нерелевантную страницу ухудшает поведение пользователя и часто выглядит как мягкая ошибка для поисковиков.
2. Если адрес изменился — поставьте 301-редирект
Для единичных случаев можно использовать плагин редиректов, но если вы работаете с кодом или настраиваете сайт после миграции, удобнее добавить правило на уровне сервера или через WordPress. Для небольшого количества URL подойдёт template_redirect:
<?php
add_action( 'template_redirect', function () {
$request_uri = $_SERVER['REQUEST_URI'] ?? '';
if ( $request_uri === '/old-page/' ) {
wp_redirect( home_url( '/new-page/' ), 301 );
exit;
}
if ( $request_uri === '/category/old-slug/' ) {
wp_redirect( home_url( '/category/new-slug/' ), 301 );
exit;
}
} );Такой вариант годится для точечных редиректов. Если адресов много, лучше использовать серверные правила или специализированный плагин, чтобы не раздувать тему или mu-plugin.
3. Если 404 идёт из внутренней ссылки — исправьте источник
Это самый важный шаг. Найдите место, где ссылка хранится: запись, блок, меню, виджет, шаблон темы, ACF-поле или настройка плагина. После этого замените URL на актуальный. Редирект можно оставить как страховку, но он не должен быть единственным решением.
4. Если это мусорные URL от параметров или старых шаблонов — ограничьте генерацию
Иногда 404 создаёт тема или плагин, который генерирует ссылки на несуществующие фильтры, архивы или вложения. Тогда нужно не только закрыть адрес, но и убрать источник генерации. Иначе бот будет снова и снова находить новые варианты того же мусора.
Если проблема связана с вложениями, проверьте, не создаёт ли тема отдельные страницы для медиафайлов, которые вам не нужны. В ряде проектов это лучше отключить на уровне логики сайта, а не лечить редиректами.
Сравнение подходов: плагин, код, сервер
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин редиректов | Много URL, нужен интерфейс | Быстро настраивать, удобно для контент-менеджера | Дополнительная нагрузка, риск накопить хаос |
| Код в теме или mu-plugin | Несколько стабильных правил | Прозрачно, без лишнего интерфейса | Нужно аккуратно сопровождать при изменении темы |
| Правила сервера | Большой объём редиректов, важна скорость | Быстрее на уровне веб-сервера | Сложнее поддержка, выше риск ошибки в конфиге |
Пример: как отдать 410 для удалённого контента
Если страница удалена окончательно и не имеет замены, иногда лучше вернуть 410 Gone, а не редиректить её на нерелевантный адрес. Это честнее для поисковиков и быстрее очищает индекс от мусора.
<?php
add_action( 'template_redirect', function () {
$path = trim( parse_url( $_SERVER['REQUEST_URI'] ?? '', PHP_URL_PATH ), '/' );
if ( $path === 'old-promo-page' ) {
status_header( 410 );
nocache_headers();
include get_query_template( '404' );
exit;
}
} );Используйте это только для действительно удалённых страниц. Если есть релевантная замена, 301 обычно лучше.
Чек-лист перед публикацией правок
- Проверил, что URL действительно не существует или должен вести на новый адрес.
- Нашёл источник ссылки: контент, меню, шаблон, плагин или внешний сайт.
- Выбрал правильный ответ сервера: 301, 410 или обычный 404.
- Не редиректнул всё на главную без причины.
- Проверил, что новый URL открывается без цепочки редиректов.
- Очистил кэш страницы, объекта и CDN, если они используются.
Как проверить, что решение сработало
После правок проверьте не только открытие страницы в браузере. Нужна проверка статуса ответа и конечного адреса.
- Откройте старый URL в браузере и убедитесь, что он ведёт на нужную страницу или отдаёт 410.
- Проверьте заголовки через
curl:
curl -I https://example.com/old-page/В ответе смотрите на HTTP/1.1 301 или 410 Gone, а также на заголовок Location при редиректе.
- Пройдитесь по внутренним ссылкам и убедитесь, что они больше не ведут на 404.
- Если есть Search Console, отправьте страницу на повторную проверку после исправления.
Частые ошибки и как их исправить
Редирект на главную вместо нужной страницы
Это самая распространённая ошибка. Она скрывает проблему, но не решает её. Если у старого URL есть замена, ведите сразу на неё. Если замены нет — оставьте 404 или отдайте 410.
Цепочка из нескольких редиректов
Например, /old/ ведёт на /new/, а потом ещё на /new-2/. Такие цепочки замедляют обход и усложняют индексацию. Сведите редирект к одному шагу.
Редирект через плагин и через сервер одновременно
Если правило есть и в плагине, и в .htaccess или конфиге nginx, можно получить непредсказуемое поведение. Оставьте один источник истины.
Кэш мешает увидеть результат
После правок старый ответ может продолжать отдаваться из кэша. Очистите кэш плагина, серверный кэш и CDN, иначе проверка будет ложной.
Игнорирование внутренних ссылок
Если 404 остаётся в меню или контенте, поисковый робот всё равно будет на неё попадать. Редирект не заменяет исправление ссылки в исходном месте.
Что делать после массовой чистки 404
Если вы убрали много старых URL, не останавливайтесь на редиректах. Проверьте карту сайта, обновите внутренние ссылки и убедитесь, что в шаблонах не осталось старых путей. Для больших сайтов полезно периодически прогонять краулер по всему домену и смотреть, не вернулись ли битые адреса после обновлений темы или плагинов.
Если 404 появляются после каждого релиза, стоит вынести список редиректов и удалённых адресов в отдельный процесс сопровождения. Тогда проблема не будет возвращаться при следующей правке структуры сайта.