Ошибка 404 Not Found: причины появления и правильная обработка

HTTP 404 Not Found означает, что origin-сервер не нашёл текущего представления запрошенного ресурса либо не хочет раскрывать, что такой ресурс существует. Сам по себе код 404 не сообщает, временно или постоянно отсутствует страница.

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

Что означает HTTP 404

RFC 9110 определяет 404 как отсутствие текущего представления целевого ресурса либо нежелание origin-сервера раскрывать его существование.

Если сервер знает, что ресурс намеренно удалён и это состояние, вероятно, постоянно, HTTP предусматривает отдельный код 410 Gone.

Практическая схема:

• URL никогда не существовал — 404 обычно нормален;
• URL существовал и переехал — нужен redirect на реальный эквивалент;
• URL намеренно удалён без замены — 404 или, при осознанном постоянном удалении, 410;
• URL должен существовать, но пропал — это дефект.

Откуда берутся 404

Опечатка в адресе

/products/monitoring
/products/monitroing

Второй URL не обязан куда-либо перенаправлять. Корректный 404 явно сообщает, что ресурса нет.

Изменился slug

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

Страница удалена

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

Сломана внутренняя ссылка

Сайт сам может ссылаться на несуществующий путь. Такой 404 нужно исправлять в источнике ссылки.

Ошибка маршрутизации после релиза

Причины:

• route переименован;
• неверный base path;
• rewrite направляет не туда;
• нужный статический файл не попал в build;
• production config отличается от staging;
• dynamic route перестал принимать старый slug.

CDN или origin routing

CDN может корректно передать 404 от origin, но причина будет в origin routing. В другом случае edge-правило само вернёт 404, не доходя до приложения.

Как убедиться, что это настоящий 404

curl -i https://example.com/missing-page

Ищите в первой строке реальный HTTP status. Смотрите также Cache-Control, Age, CDN-заголовки, Location и тело ответа.

Сайт может показывать текст «Страница не найдена», но ошибочно вернуть 200 OK.

Для человека страницы могут выглядеть одинаково, но для браузеров, роботов и мониторинга семантика различается.

Шаг 1. Проверьте точный URL

curl -sS -o /dev/null -w '%{http_code}\n' \
  https://example.com/path

Проверьте домен, протокол, регистр, завершающий /, URL encoding и query string, если он влияет на route.

На Linux Image.webp и image.webp могут быть разными файлами.

Шаг 2. Определите историю ресурса

Никогда не существовал

Оставить 404 обычно нормально.

Переехал

Настройте постоянный redirect на наиболее близкую по смыслу страницу.

Удалён навсегда без замены

Можно оставить 404 либо использовать 410, если удаление действительно постоянное и это осознанное решение.

Пропал случайно

Восстановите route или данные. Redirect на главную лишь маскирует проблему.

Почему нельзя перенаправлять все 404 на главную

Такой подход:

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

Redirect должен отвечать на вопрос «куда переехал именно этот ресурс».

Шаг 3. Найдите источник битой ссылки

Проверьте:

• меню;
• footer;
• breadcrumbs;
• карточки;
• Markdown-ссылки;
• sitemap;
• canonical;
• изображения;
• JavaScript/CSS chunks.

Для одной страницы можно посмотреть HTML через curl. Для большого сайта лучше использовать crawler или проверку ссылок в CI.

Шаг 4. Посмотрите access log

В типовом Nginx:

sudo grep ' 404 ' /var/log/nginx/access.log | tail -n 100

Формат логов может отличаться, поэтому в production лучше фильтровать структурированное поле статуса.

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

Шаг 5. Проверьте routing приложения

Если 404 появился после deployment:

1. убедитесь, что route существует;
2. проверьте build artifact;
3. проверьте rewrite;
4. сравните staging и production;
5. проверьте application logs;
6. определите, дошёл ли запрос до приложения.

404 на /assets/app.js может вернуть Nginx, а приложение вообще не увидит запрос.

404 и 410 — когда какой код

Это не автоматическое SEO-правило. Сначала определите фактический жизненный цикл ресурса.

404 в REST API

Запрос GET /api/users/123 может вернуть 404, если route существует, но пользователя нет. А GET /api/usres/123 вероятно содержит ошибочный путь.

Код одинаковый, но причины разные. Для API полезно возвращать безопасное структурированное тело ошибки, не раскрывая внутренние данные.

404 статических ресурсов

HTML может отвечать 200, но страница быть сломанной:

/app.js       → 404
/styles.css   → 404
/hero.webp    → 404
/api/config   → 404

Открывайте Network в DevTools и фильтруйте запросы по статусу.

Особенно опасны 404 на JS chunks после deployment.

404 и кеш/CDN

404 может кешироваться. После исправления origin проверьте, не остался ли старый ответ на CDN, корректны ли cache headers и требуется ли точечный purge.

Не очищайте весь CDN-cache без необходимости.

Как должна выглядеть пользовательская страница 404

Она должна:

• возвращать настоящий 404;
• ясно сообщать, что ресурс не найден;
• давать путь назад;
• предлагать полезную навигацию;
• не раскрывать stack trace и внутренние пути.

UX страницы и HTTP-код решают разные задачи.

Нужно ли мониторить 404

Не каждый 404 является инцидентом.

Разделяйте:

• критичные URL, которые обязаны существовать;
• всплеск 404 после релиза;
• случайный шум сканеров.

UpWatch можно использовать для контроля заранее известных критичных URL. Для поиска всех неизвестных битых ссылок нужен crawler или анализ server logs.

Как предотвратить 404 при изменении URL

Перед миграцией:

1. выгрузите старые публичные URL;
2. сопоставьте их с новыми;
3. создайте redirect map;
4. проверьте внутренние ссылки;
5. проверьте sitemap;
6. протестируйте старые URL после deployment.

Не меняйте опубликованные URL без необходимости.

Типичные ошибки

Возвращать 200 для страницы «Не найдено»

Машинный клиент считает запрос успешным.

Redirect всех отсутствующих URL на /

Теряется смысл исходного ресурса.

Удалять URL без карты перенаправлений

Старые ссылки начинают вести в тупик.

Считать любой 404 аварией

Неизвестный URL должен возвращать 404. Инцидент — когда пропал ресурс, который обязан существовать.

Практический чек-лист

1. Подтвердить настоящий HTTP-код.
2. Определить происхождение URL.
3. Установить, существовал ли ресурс раньше.
4. Найти внутренние ссылки на него.
5. Проверить access log и routing.
6. Если ресурс переехал — настроить релевантный redirect.
7. Если удалён намеренно — оставить 404 или осознанно использовать 410.
8. Не перенаправлять всё на главную.
9. Проверить статические ресурсы и API.
10. Контролировать критичные URL автоматически.

Источники и спецификации

• RFC 9110: 404 Not Found
• RFC 9110: 410 Gone