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

404 Not Found означает: сервер получил запрос, но не нашёл страницу, файл или маршрут по указанному адресу. Сам сервер при этом доступен — иначе браузер показал бы ошибку соединения или DNS.

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

Почему один и тот же код 404 возникает по разным причинам

Адрес https://example.com/docs/install/ проходит несколько проверок. DNS приводит запрос на сервер, веб-сервер выбирает сайт по домену, затем сопоставляет путь /docs/install/ с файлом или маршрутом приложения. Код 404 появляется на последнем этапе.

На практике причина обычно одна из следующих:

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

RFC допускает ещё один случай: сервер может вернуть 404, если не хочет подтверждать существование закрытого ресурса. Поэтому по одному коду нельзя заключить, что файла физически нет.

Убедитесь, что сервер действительно отвечает 404

Внешний вид страницы недостаточен. Сайт может показать надпись «не найдено», но по ошибке вернуть 200 OK. Такой ответ называют soft 404: человеку видна ошибка, а поисковый робот получает сигнал об обычной странице.

На своём компьютере запросите только заголовки. Замените адрес на проблемный URL:

curl -I https://example.com/docs/install/

Первая строка должна содержать реальный статус, например HTTP/2 404. Если видите 301 или 302, посмотрите конечный ответ вместе с переходами:

curl -I -L https://example.com/docs/install/

Ключ -I запрашивает заголовки без тела страницы, а -L следует редиректам. Если конечный статус 200, проверьте, не перенаправляет ли сервер любой неизвестный адрес на главную.

Определите, какой адрес должен работать

Скопируйте URL из адресной строки и сравните его с источником ссылки. Обратите внимание на:

• дефис и подчёркивание;
• окончание /;
• расширение файла;
• регистр букв в пути — в Linux Photo.webp и photo.webp являются разными именами;
• закодированные пробелы и кириллицу;
• домен и поддомен.

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

Проверьте файл в корне сайта

Для статического сайта сначала узнайте активный root Nginx. На VPS выполните команду с правами sudo; она читает собранную конфигурацию и ничего не меняет:

sudo nginx -T 2>/dev/null | grep -E 'server_name|root|try_files'

Если для example.com указан root /var/www/example/current;, то запрос /docs/install/index.html должен соответствовать файлу /var/www/example/current/docs/install/index.html. Проверьте весь путь:

namei -l /var/www/example/current/docs/install/index.html

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

Сверьте правила Nginx с типом сайта

Для обычного статического сайта типичная логика ищет точный файл, каталог с index.html, а затем возвращает 404:

location / {
    try_files $uri $uri/ =404;
}

$uri — запрошенный путь, а =404 — явный ответ, если ни файл, ни каталог не найдены. После изменения конфигурации сначала проверьте синтаксис и только затем примените её без остановки сервера:

sudo nginx -t
sudo systemctl reload nginx

Reload допустим только после сообщения об успешной проверке. Если nginx -t показывает ошибку, верните предыдущую версию файла или исправьте указанную строку и повторите проверку.

Одностраничное приложение может направлять неизвестные маршруты в index.html, чтобы маршрутизацией занялся JavaScript. Не переносите такое правило на обычный сайт: сервер начнёт отвечать 200 даже на несуществующие адреса.

Если 404 возвращает приложение или CMS

Когда Nginx передаёт запрос приложению, файл на диске может вообще не соответствовать URL. Тогда маршрут определяет код программы или CMS. Сначала отделите ответ Nginx от ответа приложения:

1. Найдите запрос в access log Nginx.
2. Проверьте error log за то же время.
3. Посмотрите журнал приложения или PHP-FPM.
4. Сравните проблемный путь со списком маршрутов приложения.

В WordPress массовые 404 после переноса часто связаны с правилами постоянных ссылок или конфигурацией веб-сервера. Не переустанавливайте сайт и не удаляйте плагины вслепую. Сохраните текущую конфигурацию, пересохраните структуру постоянных ссылок в панели и проверьте один материал, одну рубрику и главную страницу.

Выберите между восстановлением, редиректом и удалением

Решение зависит от судьбы страницы:

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

Пример точечного редиректа Nginx для действительно переехавшей страницы:

location = /old-guide/ {
    return 301 /new-guide/;
}

Знак = требует точного совпадения пути, поэтому правило не затронет соседние страницы. Перед правкой сделайте копию конфигурационного файла; после неё снова выполните nginx -t и reload.

Как проверить исправление

Запросите старый и новый адреса непосредственно с локального компьютера. Так вы увидите статусы и цепочку переходов независимо от оформления страницы в браузере:

curl -I https://example.com/old-guide/
curl -I -L https://example.com/old-guide/
curl -I https://example.com/new-guide/

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

Затем проверьте несколько соседних URL и журнал сервера. Это защищает от слишком широкого правила, которое исправило один адрес ценой других страниц. Для контроля после публикации пригодится чек-лист домена и HTTPS, а устройство root, location и try_files подробнее разобрано в руководстве по маршрутам Nginx.

Источники

• RFC 9110: 404 Not Found
• Nginx: директива try_files
• Google Search Central: ошибки 404 и soft 404