Если в Google Search Console или аналитике растёт число 404, это обычно не одна проблема, а несколько разных источников: удалённые записи, изменённые URL, битые внутренние ссылки, старые внешние ссылки и ошибки в настройках постоянных ссылок. Хорошая новость в том, что в WordPress почти всегда можно быстро найти источник и закрыть его без полной переделки сайта.
Ниже — практический порядок действий: сначала определить, какие именно URL отдают 404, затем понять, откуда они взялись, и только после этого исправлять ссылки, настраивать редиректы или возвращать страницы.
С чего начать: какие 404 действительно нужно чинить
Не каждая ошибка 404 требует немедленного вмешательства. Если бот случайно запросил несуществующий адрес, это нормально. Исправлять стоит те URL, которые:
- приходят из внутренних ссылок на вашем сайте;
- уже получают переходы из поиска или внешних сайтов;
- были важными страницами и раньше приносили трафик;
- массово появляются в Search Console или логах после переноса сайта, смены структуры URL или удаления контента.
Если 404 много, но они все случайные и не связаны с реальными переходами, задача — не «убрать все 404», а убрать те, что мешают пользователям и поисковым системам.
Как найти источник ошибок 404
Самый удобный путь — смотреть не только саму ошибку, но и реферер, то есть страницу, с которой пользователь или бот пришёл на несуществующий адрес.
Проверьте Search Console и аналитику
В Google Search Console откройте отчёт по страницам с ошибкой 404 и посмотрите список URL. Если рядом видны запросы и страницы, которые раньше были в индексе, это уже подсказка: адрес либо изменился, либо страница была удалена без редиректа.
В аналитике ищите страницы входа с кодом ответа 404. Если у вас настроены события или отдельный отчёт по ошибкам, полезно смотреть:
- какие URL запрашивают чаще всего;
- с каких страниц идёт переход на 404;
- есть ли у этих URL внешний трафик или только внутренние переходы.
Посмотрите логи сервера, если они доступны
Логи полезны, когда 404 появляются массово и непонятно, откуда они берутся. В access log обычно видно запрошенный URL и источник. Это помогает отличить реальные битые ссылки от мусорных запросов ботов, старых скриптов или попыток обратиться к несуществующим файлам.
Если у вас нет доступа к логам, можно обойтись Search Console и инструментами проверки ссылок, но при большом сайте логи экономят много времени.
Проверьте саму страницу 404
Иногда проблема не в отсутствии страницы, а в том, что WordPress не может корректно обработать адрес из-за сбоя в правилах перезаписи, конфликтов плагинов или настроек сервера. Если даже существующие записи открываются с 404, сначала нужно проверить структуру постоянных ссылок и правила перезаписи, а не искать битые ссылки.
Что чаще всего вызывает 404 в WordPress
На практике причины повторяются. Вот самые типичные:
- страница, запись или рубрика удалены, но на них всё ещё ведут ссылки;
- изменён slug у записи, а старый адрес нигде не перенаправлен;
- после импорта или миграции сломались постоянные ссылки;
- в меню, виджетах, блоках или шаблонах остались старые URL;
- внутренние ссылки в контенте прописаны вручную и не обновились после редактирования;
- внешние сайты ссылаются на старый адрес;
- на сервере неправильно работают правила rewrite, особенно после переноса между Apache и Nginx.
Если 404 начались сразу после обновления структуры URL или переноса сайта, сначала проверяйте редиректы и настройки постоянных ссылок. Если проблема появилась постепенно, чаще всего виноваты старые ссылки в контенте и удалённые страницы.
Как исправить 404 без потери трафика
Универсального решения нет: для каждого URL нужно выбрать один из трёх вариантов — вернуть страницу, перенаправить на новый адрес или оставить 404, если адрес больше не нужен и не имеет ценности.
1. Верните страницу, если она должна существовать
Если запись удалили случайно или она по-прежнему нужна пользователям, проще всего восстановить её из корзины или резервной копии. Это лучший вариант, когда старый URL уже в индексе и получает переходы.
После восстановления проверьте, что адрес страницы совпадает с тем, который был раньше. Если slug изменился, старый URL всё равно придётся перенаправить.
2. Настройте 301-редирект на новый адрес
Если страница переехала на другой URL, нужен постоянный редирект 301. Это передаёт пользователя и помогает поисковым системам понять, что адрес изменился.
Редирект можно сделать через плагин или на уровне сервера. Для большинства владельцев сайтов проще использовать плагин, если у них нет доступа к конфигурации Apache или Nginx. Главное — не делать цепочки редиректов и не отправлять все удалённые страницы на главную без разбора: это плохой пользовательский сценарий и слабый сигнал для поиска.
Если у вас есть доступ к файлу .htaccess на Apache, редирект можно задать так:
Redirect 301 /staryy-url/ https://example.com/novyy-url/Для Nginx правило обычно добавляют в конфигурацию сайта на стороне сервера, а не в WordPress. Если вы не уверены, лучше не править конфиг вручную без резервной копии: ошибка может уронить сайт целиком.
3. Уберите или замените битые внутренние ссылки
Если 404 возникает из-за ссылки внутри вашего сайта, редирект — не единственное решение. Саму ссылку лучше исправить в исходном месте: в записи, странице, меню, блоке, шаблоне или виджете.
Это важнее, чем кажется. Если оставить битую внутреннюю ссылку и только поставить редирект, вы сохраните переход для пользователя, но не устраните источник проблемы. Через пару месяцев эта же ссылка может снова всплыть в другом месте.
Как найти битые ссылки на сайте WordPress
Искать битые ссылки вручную на большом сайте неудобно, поэтому лучше использовать сочетание автоматической проверки и точечной ручной проверки там, где ошибка уже видна.
Проверка через плагины и внешние сервисы
Для WordPress обычно используют плагины для поиска битых ссылок или внешние краулеры. Они обходят страницы сайта и показывают, какие URL возвращают 404, 301 или другие коды ответа. Это удобно, если нужно быстро найти проблемные ссылки в контенте.
Но у плагинов есть нюанс: на больших сайтах они могут заметно нагружать хостинг. Если сайт на слабом тарифе, лучше запускать проверку в часы низкой нагрузки или использовать внешний сервис, который сканирует сайт со своей стороны.
Проверка через браузер и редактор WordPress
Если проблема локальная, например одна статья или один блок меню, проще открыть страницу в редакторе и пройтись по ссылкам вручную. Особое внимание стоит уделить:
- меню и подменю;
- ссылкам в тексте старых статей;
- кнопкам в блоках и шаблонах;
- ссылкам в футере и сайдбаре;
- архивам, хлебным крошкам и связанным материалам.
Часто битая ссылка сидит не в самом контенте, а в шаблонном блоке, который повторяется на десятках страниц. Поэтому проверка только одной записи не всегда показывает реальную картину.
Как проверить, что исправление сработало
После правки нужно убедиться, что старый адрес больше не отдаёт 404, а новый открывается корректно.
Проверка простая:
- откройте старый URL в браузере в режиме инкогнито;
- убедитесь, что он ведёт на нужную страницу или показывает корректную 404, если редирект не нужен;
- проверьте HTTP-статус через инструменты разработчика браузера, онлайн-проверку заголовков или серверный лог;
- если был редирект, убедитесь, что он один и ведёт сразу на конечный адрес.
В Search Console изменения не всегда видны сразу. После исправления Google должен заново обойти URL, поэтому отчёт обновляется не мгновенно. Это нормально.
Когда 404 лучше оставить как есть
Не каждый несуществующий адрес нужно перенаправлять. Если страница никогда не существовала, не имела трафика и на неё нет внутренних ссылок, корректная 404 — нормальный ответ сервера. То же самое касается мусорных или случайных запросов ботов.
Пытаться перенаправить всё подряд на главную — плохая практика. Пользователь не находит нужный контент, а поисковая система получает неочевидный сигнал. Лучше чинить только те адреса, которые действительно важны для посетителей и поискового трафика.
Если у вас много старых URL после переезда сайта, сначала соберите список самых ценных страниц из Search Console, аналитики и логов, а потом уже настраивайте редиректы и исправляйте внутренние ссылки. Так вы закроете именно те 404, которые реально влияют на трафик, а не будете тратить время на случайный шум.