Ошибка 404 Not Found: что значит и как исправить

Ошибка 404 Not Found означает, что сервер получил HTTP-запрос, но не нашёл ресурс по указанному адресу или не хочет подтверждать его существование. Посетителю стоит проверить URL и перейти с навигации сайта. Владельцу — проследить маршрут от ссылки и правил роутинга до файлов текущей выкладки и фактического статуса ответа.

Сам по себе код не объясняет причину. Страница могла быть удалена, перемещена, опубликована под другим регистром, потеряна при сборке или не попасть в маршрут приложения. Правильное исправление зависит от судьбы конкретного адреса: вернуть ресурс, починить ссылку, настроить точный редирект либо честно оставить отсутствие.

404 появляется после DNS, соединения и TLS

Браузер получает HTTP-статус только после того, как нашёл адрес сервера, установил соединение и при HTTPS согласовал защищённый сеанс. Поэтому сообщение о неизвестном домене, отказе соединения, тайм-ауте или сертификате — не разновидность 404. До HTTP-запроса дело ещё не дошло.

Не начинайте с DNS, если в инструментах браузера уже виден ответ 404 от нужного хоста. Это подтверждает, что имя разрешилось и сервер ответил. Теперь расследование находится между запрошенным путём и тем, что реально опубликовано.

Что безопасно сделать посетителю

Сначала сохраните полный адрес без приватных токенов. Проверьте опечатку, лишний символ, регистр букв в пути и окончание со слешем. Имя хоста обычно не зависит от регистра, но путь может зависеть. На одном окружении Page и page совпадут, а после переноса на другое — станут разными адресами.

Затем откройте главную страницу и найдите материал через меню, поиск или категорию. Если нужная страница доступна по другому адресу, сообщите владельцу обе ссылки: неработающую и актуальную. Два точных адреса полезнее снимка экрана без URL.

Посетителю не стоит очищать DNS-кэш, отключать антивирус или менять системные сетевые настройки ради одной 404. Если страница могла содержать оплату, заказ или личные данные, не подбирайте похожие адреса вручную. Вернитесь через официальную навигацию сайта.

Владельцу нужен один точный запрос

Зафиксируйте URL целиком, время с часовым поясом, метод запроса, источник перехода и окружение. Откройте заголовки ответа и запись в access log. Важно доказать, какой виртуальный хост обработал запрос и какой статус ушёл клиенту, а не ориентироваться только на красивую страницу в браузере.

Короткий порядок локализации выглядит так:

• повторите точный адрес без изменения регистра и слеша;
• найдите запрос в журнале доступа нужного виртуального хоста;
• сопоставьте путь с маршрутом приложения или опубликованным файлом;
• проверьте, присутствует ли ресурс в текущем артефакте выкладки;
• сравните результат на боевом адресе и в окружении, где страница считалась рабочей.

Если запись отсутствует, запрос мог попасть на другой балансировщик, домен или старый узел. Если запись есть, продолжайте от фактического обработчика. Один подтверждённый запрос полезнее общего списка возможных причин.

Проверьте URL: регистр, слеш и кодирование

Сравнивайте путь посимвольно. Частые расхождения — прописная буква после миграции, пробел или кириллица в неправильной кодировке, старое расширение файла, лишний сегмент локали и относительная ссылка, рассчитанная от другого базового адреса.

Окончательный слеш тоже может менять маршрут. Одни системы нормализуют адрес редиректом, другие различают файл и каталог, третьи ожидают строгий шаблон. Выберите канонический вариант и обеспечьте его одинаково в генераторе ссылок, маршрутизаторе, веб-сервере и карте сайта. Не добавляйте слеш вслепую ко всем адресам.

Отдельно проверьте параметры и якорь. Якорь не отправляется серверу и обычно не способен вызвать 404. Параметры запроса доходят до приложения и могут влиять на выбор сущности, но исправлять их нужно в месте генерации ссылки, а не универсальным правилом переписывания.

Маршрут приложения должен знать об отсутствии

В серверном приложении запрос сначала сопоставляется с маршрутом, затем с конкретной сущностью. Маршрут может существовать, а запись товара — отсутствовать. В этом случае обработчик должен вернуть честный 404, а не пустую страницу с успешным статусом.

Для клиентского приложения есть дополнительная ловушка. Веб-сервер может отдавать оболочку приложения для любого пути, после чего JavaScript рисует сообщение «не найдено». Если исходный ответ остаётся 200, получается soft 404. Поисковая система видит успешный документ, содержание которого говорит об обратном.

Проверяйте две вещи отдельно: что видит человек и какой статус вернул сервер. Если архитектура не позволяет сразу отдать корректный статус, для поисковых роботов нужна предусмотренная официальными рекомендациями стратегия, но предпочтительнее устранять несоответствие на серверной границе.

Проверьте артефакт и порядок выкладки

Страница может существовать в исходниках и отсутствовать на сервере. Для статического сайта убедитесь, что генератор действительно создал ожидаемый файл и что каталог попал в публикацию. Для CMS проверьте статус записи, постоянный адрес, локаль и правила формирования ссылок. Для приложения — таблицу маршрутов и наличие сущности в используемой базе.

Сравните текущую выкладку с предыдущей: что удалили, переименовали или исключили фильтром. Особое внимание — сборке с будущими датами, черновым статусам CMS, регистру имён файлов и правилам копирования каталогов. Фраза «локально открывается» ничего не доказывает, пока не сравнен тот же URL и тот же артефакт.

Если 404 начались сразу после выпуска, сначала подтвердите состав релиза и конфигурацию маршрута. Массовая перезагрузка сервисов не возвращает файл, которого нет в сборке. Исправляйте расхождение между ожидаемым и опубликованным состоянием.

NGINX, Apache и CMS: сохраняйте исходный статус

В NGINX директива try_files последовательно проверяет кандидатов и может завершить поиск ответом 404. Ошибка часто появляется, когда root или alias указывает не туда, порядок кандидатов не соответствует структуре, а запрос не передаётся нужному front controller. Сопоставьте конфигурацию с реальным деревом файлов.

Пользовательскую страницу ошибки можно подключить через error_page. Важно не менять код на 200 ради дизайна. В Apache локальный ErrorDocument сохраняет смысл ошибки, тогда как внешний адрес создаёт перенаправление. Динамический обработчик обязан вернуть перехваченный статус, а не успешный документ.

В WordPress и других CMS проверьте отдельный шаблон 404, правила постоянных ссылок и опубликованность записи. Красивая тема не заменяет корректный ответ. Тестируйте заведомо несуществующий адрес через заголовки ответа, а не по наличию крупной надписи «страница не найдена».

404, soft 404 и 410 — разные сигналы

Обычный 404 говорит, что текущего представления по адресу нет или сервер не раскрывает его наличие. Он не обещает, временно это или навсегда. Код 410 Gone точнее сообщает, что ресурс удалён намеренно и его отсутствие, вероятно, постоянно.

Soft 404 — не отдельный HTTP-код. Так называют ситуацию, когда сервер возвращает 200 или отправляет посетителя на нерелевантную страницу, хотя содержимое сообщает об отсутствии. Это сбивает пользователя и поисковую систему. Пользовательская страница ошибки может быть полезной и при этом обязана сохранять настоящий 404.

Не превращайте каждый удалённый адрес в 410 автоматически. Если неизвестно, окончательно ли исчез ресурс, стандарт допускает 404. Выбор должен отражать реальное решение редакции или продукта, а не желание быстрее убрать отчёт из Search Console.

Редирект нужен только при ясной замене

Если материал переехал без смены назначения, настройте постоянный редирект на новый канонический URL. Если замена временная, используйте временное перенаправление. Проверяйте всю цепочку: старый адрес должен вести прямо к конечному, без петли и серии промежуточных шагов.

Не отправляйте все неизвестные адреса на главную. Главная страница редко отвечает намерению старого URL, поэтому такой маршрут выглядит как soft 404 и не помогает человеку найти материал. Для удалённого товара возможна замена на действительно эквивалентную модель или категорию, но только если она решает тот же запрос.

Редиректы не исправляют внутреннюю ссылку в источнике. После настройки перехода обновите меню, карточки, шаблоны, рекламные объявления и письма. Иначе сайт продолжает генерировать лишний запрос и скрывает дефект за перенаправлением.

Внутренние ссылки и sitemap должны отражать канон

Составьте список 404 из журналов, отчётов обхода, Search Console и собственной проверки ссылок. Разделите внешние старые URL, внутренние ошибки и случайный шум. Приоритет выше у адресов с реальными переходами, внутренних ссылок и страниц, которые недавно перемещались.

Исправьте источник каждой внутренней ссылки. Из sitemap удалите исчезнувшие URL и оставьте только полные канонические адреса, предназначенные для поиска. Карта сайта не создаёт страницу и не заменяет навигацию; она лишь сообщает поисковой системе о выбранных URL.

После исправления повторите запросы и проверьте статус, конечный адрес и содержимое. Для перемещённой страницы убедитесь, что новый URL доступен и сам не перенаправляет дальше. Для удалённой — что пользовательская 404 предлагает поиск, категории или популярные материалы, но не выдаёт себя за найденный документ.

Итог

Исправление 404 начинается не с редиректа, а с ответа на вопрос, что должно находиться по конкретному адресу. Проследите запрос через URL, маршрут и выкладку, затем восстановите ресурс или сообщите о его судьбе корректным статусом. Так пользователь получает понятный выход, а поисковая система — непротиворечивый сигнал.