Вот как я разбираюсь с 404 — как со стороны посетителя, так и со стороны владельца сайта. Ошибка «404 Not Found» означает, что веб-сервер доступен, но запрошенный путь он найти не смог.

Если вы просто пытаетесь открыть страницу

Проверьте адрес
— Опечатки, лишние/отсутствующие дефисы, регистр букв (на Unix-хостингах /About и /about — разные пути).
— Хвост слеша: иногда нужен /catalog/, а не /catalog.
— Наличие расширения: /file.pdf vs /file.
— Кодировку и пробелы (проценты в URL вроде %20).
Обновите/очистите
— Обновить страницу и очистить кэш/куки для домена.
— Откройте в приватном режиме или другом браузере.
— Попробуйте без/с www, без/с https. Иногда страницы есть только по одному варианту.
Проверьте перенаправления
— Если вас кидает на 404 после клика, возможно, старая ссылка. Попробуйте найти страницу через поиск по сайту или через корень сайта, убирая части пути слева направо, пока не найдёте живой раздел.
DNS/провайдер
— Если сайт только что переезжал, подождите распространения DNS или попробуйте мобильный интернет/VPN.

Если после этого 404 остаётся — проблема на стороне сайта.

Если вы владелец/разработчик и хотите устранить 404

1) Убедитесь, что ресурс реально существует

Проверьте, что файл/роут присутствует в нужной директории/конфигурации окружения (prod ≠ dev).
Проверьте регистр имён файлов и расширений (на Linux Image.jpg и image.jpg — разные).
Ссылки из CMS: нет ли «битых» записей/удалённых страниц.

2) Проверьте веб-сервер и корневой каталог

Nginx

nginx
server {
    root /var/www/site/public;
    index index.html index.htm index.php;
    location / {
        try_files $uri $uri/ =404;  # для статического сайта
        # для SPA (React/Vue/Angular): try_files $uri $uri/ /index.html;
    }    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }
}

Типичные ошибки: неверный root, путаница root vs alias, забытый index, лишний =404 для SPA.

Apache (.htaccess)

apache
# Чистые URL для PHP-приложения
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [L]# Кастомная 404
ErrorDocument 404 /404.html

Убедитесь, что включён AllowOverride All и файл действительно читается.

IIS (web.config, кратко)

Добавьте с statusCode="404" path="/404.html".
Для SPA — правило переписывания на /index.html.

3) Маршрутизация фреймворков

Django: проверьте urls.py, имена путей, включён ли нужный app_name, нет ли конфликтов path()/re_path().
Laravel: routes/web.php, кеш маршрутов (php artisan route:cache), права на public/.
Express (Node): порядок middleware, app.use(express.static(...)) до/после роутов, обработчик 404 в самом конце.
Next.js/Nuxt/SvelteKit: проверьте динамические маршруты и экспорт/билд; для статического экспорта нужен fallback.
React Router/Vue Router/Angular (SPA): на сервере должен быть fallback на index.html, иначе прямой заход на /some/route даст 404.

4) Перенаправления и «битые» ссылки

Настройте 301-редиректы со старых URL на новые (после редизайна/смены структуры).
Избегайте цепочек: A→B→C. Делайте A→C.
Для массовых изменений заведите карту сопоставлений и прогоните через переписывание правил.

5) Права доступа и симлинки

Убедитесь, что файлы читаются пользователем веб-сервера (644 для файлов, 755 для каталогов).
Симлинки должны указывать в доступные директории; для Apache включите Options +FollowSymLinks.

6) Индексные файлы и директории

Добавьте index.html/index.php или включите листинг директорий (лучше не надо в проде).
Проверьте DirectoryIndex (Apache) и index (Nginx).

7) Кодировка URL и необычные символы

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

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

Сделайте полезную, лёгкую страницу:

Объяснение простыми словами, поиск по сайту, популярные разделы.
Логирование реального запроса (путь, реферер, user-agent).
Возвращайте статус 404, а не 200 — иначе получится «soft 404».

9) Кэш и CDN

Очистите кэш CDN (Cloudflare и др.) и кэш приложения после правок маршрутов/файлов.
Проверьте правила edge-redirect’ов — они могут вести на несуществующий путь.

10) DNS и инфраструктура

Если меняли хостинг/поддомен — проверьте A/AAAA/CNAME и прокси. Несовпадение окружений легко даёт 404 на одном из бэкендов за балансировщиком.

11) Диагностика (быстро и по делу)

curl -I https://example.com/path — смотрите статус и цепочку редиректов.
Логи: Nginx (access.log, error.log с кодом 404 и реальным путём), Apache (access_log, error_log).
Снимите HAR в браузере (DevTools → Network) — видно, кто именно вернул 404 (CDN, прокси, бэкенд).
Проверьте, совпадает ли запрошенный путь с фактическим путём на диске/в роутере приложения.

Короткие «рецепты» под частые случаи

SPA на GitHub Pages/статическом хостинге: включите fallback на index.html (например, сервить 404.html, который делает JS-редирект на index.html), либо настройте серверный try_files ... /index.html.
WordPress 404 после смены постоянных ссылок: пересохраните структуру пермалинков, проверьте .htaccess, отключите конфликтующие плагины маршрутизации.
S3/статический сайт: укажите документ ошибок 404.html и документ индекса; для роутинга — правила перенаправления.
Многоязычие: проверьте префиксы /ru/ /en/ и auto-redirect по языку — часто ломают ссылки.

Когда 404 — это норма

Страница удалена осознанно: оставьте 404 или 410 (Gone) и настройте полезную «Not Found»; редиректите только когда есть явный эквивалент.
Для поисковиков это сигнал «страницы больше нет» — важно возвращать корректный код.

Следуя этому чек-листу, я обычно нахожу и устраняю первопричину: либо исправляю URL/редиректы, либо настраиваю серверный fallback/маршруты и обновляю кэш.

Как исправить ошибку 404?

Ответы на вопрос