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

Что такое ошибка 404 Not Found

Ошибка 404 Not Found («не найдено») — HTTP-код, которым сервер отвечает, когда не может найти ресурс по запрошенному URL. Ключевое отличие от других клиентских ошибок: проблема не в авторизации (401) и не в правах (403), а в том, что по этому адресу ничего нет — либо никогда не было, либо уже нет.

Важно понимать разницу между 404 и 410: 404 говорит «здесь сейчас пусто», а 410 — «это удалили намеренно и навсегда, не возвращайтесь». Про 410 и про правильную обработку удалённых страниц подробнее — в отдельном разделе ниже.

Что видит пользователь

В браузере это обычно страница «404 Not Found», «Страница не найдена» или кастомная страница, которую настроил владелец сайта. С точки зрения технической сути, 404 означает одно: маршрут не сматчился ни с одним файлом или обработчиком.

Основные причины появления 404

Ошибка 404 почти всегда возникает на стыке трёх вещей: ссылок, URL и файлов. Разберём причины по источникам.

1. Неверная ссылка (опечатка в URL)

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

2. Удалённая или перемещённая страница

Контент удалили или перенесли на новый адрес без настройки редиректа. Внешние ссылки и закладки продолжают вести на старый URL и получают 404.

3. Изменение структуры URL или CMS

После смены движка, структуры ЧПУ (например, переход с ?p=123 на /articles/123) старые адреса перестают существовать. Если не настроены редиректы — все старые ссылки бьют в 404.

4. Ошибка регистра или слеша

На Linux-серверах Page.html и page.html — разные файлы, а /news и /news/ могут обрабатываться по-разному. Отсюда 404, которых «не должно быть».

5. Файл не загружен или лежит не в том каталоге

Изображение, документ или страница не попали на сервер при публикации, либо лежат в другой папке. Ссылка ведёт в пустоту.

6. Проблемы с DNS или настройкой домена

Запрос уходит на другой сервер или поддомен, где такого пути нет. Внешне — 404, по сути — «не туда пришли».

Сводка причин и решений:

Как диагностировать 404: самопроверка через curl

Как и с 403, первым делом фиксируйте точный код ответа — внешний вид страницы может обманывать (например, «мягкая 404», о которой ниже).

Шаг 1. Точный код и заголовки

curl -I https://example.com/nonexistent-page

Пример вывода:

HTTP/1.1 404 Not Found
Server: nginx/1.24.0
Content-Type: text/html

HTTP/1.1 404 Not Found — сервер подтвердил, что ресурса нет. Запомните: ответ пришёл от сервера, то есть сам сайт и хостинг работают, отсутствует именно маршрут.

Шаг 2. Проверка, существует ли файл на сервере

Если 404 отдаётся на файл, проверьте, есть ли он физически:

ls -la /var/www/example.com/path/to/file.html

Если файла нет — это честный 404 по причине отсутствия. Если файл есть, а сервер всё равно отдаёт 404 — проблема в конфигурации маршрутов (например, в location блоке nginx или в правилах обработки запросов CMS).

Шаг 3. Проверка цепочки редиректов

curl -IL https://example.com/old-page

Флаг -L заставляет curl следовать редиректам, а повторённый -I показывает заголовки на каждом шаге. Если на old-page стоит 301 на новый адрес, но конечный URL возвращает 404 — значит, редирект ведёт в пустоту, и нужно править целевой адрес.

Шаг 4. Проверка DNS

dig example.com +short

Если домен резолвится на другой IP, чем ожидалось (например, на старый сервер или на заглушку хостинга), запросы уходят не туда, и сайт отдаёт 404 на все пути. Сверьте IP с тем, что указан в панели хостинга.

Шаг 5. Обнаружение «мягкой 404» через тело ответа

Мягкая 404 — это когда сервер возвращает код 200 OK, но по сути показывает страницу «ничего не найдено». С точки зрения HTTP ресурс «существует», поэтому браузеры и поисковики не понимают, что это ошибка. Проверяется сравнением: если curl -I даёт 200, а тело страницы — заглушка «не найдено», перед вами мягкая 404.

curl -s https://example.com/nonexistent-page | head -20

Если в выводе HTML виден текст «не найдено» или «404», а заголовок ответа был 200 OK — это мягкая 404, и её нужно чинить на уровне приложения (см. следующий раздел).

Правильная обработка 404: редиректы, мягкая 404 и 410 Gone

Тут — самая важная часть статьи. Правильно обработать 404 важнее, чем «красиво оформить» страницу ошибки, потому что от этого зависит поведение поисковых систем и сохранение трафика.

Мягкая 404: почему это вредно

Мягкая 404 возникает, когда приложение отдаёт код 200 на несуществующий контент. Типичные случаи:

• CMS выводит «заглушку» с кодом 200, если статья не найдена.
• SPA-приложение отдаёт index.html на любой URL, и рендер-страница пустая.
• Поиск возвращает «ничего не найдено» без смены кода ответа.

Чем это плохо:

1. Поисковик считает страницу живой и может держать её в индексе, тратя краулинговый бюджет на мусор.
2. Такие страницы могут попадать в выдачу и показывать пользователю пустоту вместо ответа.
3. Метрики доступности врут: страница «отвечает 200», хотя по факту ничего не показывает.

Правильный подход — отдавать честный код 404 (или 410) с полезной страницей. В этом случае страница-заглушка должна сопровождаться кодом 404, а не 200.

404 против 410 Gone: когда что использовать

Разница принципиальная и простая:

410 уместен, когда вы осознанно убрали страницу (товар снят с производства, старый тариф закрыт, контент удалён по решению). Он ускоряет вывод URL из индекса по сравнению с 404. Ошибочно отдавать 410 на всё подряд: если страница может вернуться, честнее 404.

Редиректы: 301 против 302

Когда страница переехала, правильное решение — редирект со старого адреса на новый, а не 404:

Для постоянной смены адреса используйте 301 — он передаёт «вес» старой страницы новому адресу. Пример настройки на nginx:

location /old-page {
    return 301 https://example.com/new-page;
}

И на Apache через .htaccess:

Redirect 301 /old-page https://example.com/new-page

Проверка, что редирект работает и ведёт куда нужно:

curl -IL https://example.com/old-page

В выводе вы должны увидеть сначала 301 Moved Permanently со строкой Location: ...new-page, а затем 200 OK на конечном адресе. Если конечный адрес даёт 404 — цепочка редиректа сломана, и её нужно поправить.

Кастомная страница 404

Полезная страница ошибки снижает отток: на ней стоит дать ссылку на главную, поиск по сайту и популярные разделы. Но помните: кастомная страница — это оформление, а не решение. Главное — чтобы она отдавалась с правильным кодом 404, а не с 200.

Как находить 404 на своём сайте

Ошибки 404 не видны, пока кто-то не наткнётся на битую ссылку. Поэтому их нужно искать целенаправленно.

1. Логи веб-сервера

В access-логе 404 виден сразу:

grep " 404 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

Команда выводит список URL, по которым чаще всего отдаётся 404, с количеством обращений. Это прямой список битых ссылок, по которым реально ходят пользователи и боты.

2. Сканирование собственных ссылок

Внутренние битые ссылки (страница ссылается на несуществующий URL) находятся сканером сайта. Внешние — через панели вебмастеров поисковых систем, где видно, откуда приходят ссылки на 404-страницы.

3. Регулярный мониторинг ключевых страниц

Для ключевых URL (главная, формы, важные статьи) стоит настроить регулярную проверку, которая уведомит, если код ответа сменился с 200 на 404. Это ловит случайные поломки после деплоя или обновления CMS.

Быстро проверить, что возвращает конкретный URL прямо сейчас, можно через инструмент проверки доступности UptimeChecker — он покажет код ответа и цепочку редиректов со стороны внешней сети. А если нужно проверить именно настройку редиректов на сайте, пригодится отдельная проверка редиректов UptimeChecker.

Мягкая 404 в SPA и API: технические детали

Отдельно стоит разобрать два сценария, где мягкая 404 возникает чаще всего и где её сложнее всего заметить.

SPA-приложения (React, Vue и подобные)

Одностраничные приложения отдают один и тот же index.html на любой URL, потому что маршрутизация происходит на клиенте. Если настроить сервер на try_files ... /index.html без ограничений, то даже https://site.ru/мусор-в-url вернёт код 200 с пустым приложением — классическая мягкая 404.

Правильная настройка nginx для SPA — отдавать index.html только для реальных маршрутов приложения, а на всё остальное отвечать честным 404. На практике это означает: список известных путей приложения должен быть ограничен, а fallback на index.html — не безусловный. Проверить, что fallback не «съедает» 404, можно так:

curl -s -o /dev/null -w "%{http_code}\n" https://site.ru/definitely-not-a-page

Если команда выводит 200, а страницы такой нет — fallback слишком широкий, и это мягкая 404.

API и JSON-ответы

У API своя ловушка: некоторые бэкенды отдают на несуществующий эндпоинт HTTP 200 с JSON вида {"error": "not found"}. Для HTTP-клиентов и мониторинга это выглядит как успешный ответ, хотя по факту ресурса нет. Правильно — возвращать код 404 (или 410) в статусе HTTP, а не только в теле. Это важно и для внешних интеграций, и для вашего же мониторинга: код ответа — единственный надёжный признак, который можно проверять автоматически.

Отличие 404 от 403

Путаница между «страница не найдена» и «доступ запрещён» — частая ошибка при диагностике:

Снимайте точный код через curl -I, а не по внешнему виду страницы, — и не чините редиректами то, что на самом деле запрещено правилами доступа. Подробный разбор причин и решений для 403 — в соседней статье: «Ошибка 403 Forbidden: причины и решение».

Чек-лист: что делать при 404

1. Снимите точный код: curl -I https://ваш-сайт/путь.
2. Проверьте, есть ли файл на сервере (ls -la) и куда резолвится домен (dig).
3. Если страница переехала — настройте 301-редирект на новый адрес.
4. Если страница удалена навсегда — отдавайте 410 Gone, а не 404.
5. Если контента нет, а сервер отдаёт 200 — чините мягкую 404, верните честный код.
6. Оформите кастомную страницу 404 с полезными ссылками.
7. Регулярно проверяйте логи на битые ссылки и мониторьте ключевые URL.

Ошибка 404 сама по себе не ломает сайт: сервер и хостинг работают, отсутствует конкретный маршрут. Но неуправляемые 404 — это потеря трафика, ушедшие внешние ссылки и мусор в индексе. Поэтому ключевое — не «красивая страница ошибки», а честные коды, правильные редиректы и регулярная проверка доступности ключевых страниц, чтобы замечать поломки до того, как их заметят посетители.