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

Страница 404 должна объяснять отсутствие материала, помогать продолжить путь и сохранять код ответа 404. Проверьте оформление и ответ сервера отдельно.

Что должно получиться

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

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

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

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

Из чего это складывается

Почему одной надписи недостаточно

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

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

Как это сделать по шагам

1. Определите, кто обрабатывает адреса. Узнайте, формирует ли ответ CMS, приложение или сам веб-сервер. На сайте с маршрутизацией приложения создание отдельного статического файла ещё не заставит систему использовать его для неизвестных материалов.
2. Подготовьте содержание ошибки. Напишите короткое сообщение о том, что страница не найдена. Добавьте понятный путь в раздел, поиск или основную навигацию. Используйте существующие ссылки и проверьте их до подключения шаблона.
3. Подключите обработчик в нужном месте. Для CMS используйте предусмотренный механизм шаблона ошибки и формирования ответа. Для статического сайта настройте обработку на сервере. Сохраняйте прежнюю конфигурацию, чтобы можно было вернуться к рабочему варианту.
4. Сохраните код 404. Убедитесь, что обработчик не подменяет его успешным ответом и не отправляет посетителя автоматически на главную. Для известного перенесённого материала отдельно настройте соответствующее перенаправление, не смешивая эти случаи.
5. Проверьте неизвестный адрес. На своей тестовой площадке откройте заведомо отсутствующий путь и посмотрите ответ основного документа в панели сетевой активности браузера. Сопоставьте код, конечный адрес и отображаемое сообщение.
6. Проверьте вложенность и ресурсы. Повторите проверку для отсутствующего адреса внутри раздела. Убедитесь, что стили, картинки и навигация не зависят от случайной глубины пути. Проверьте обычный существующий материал, чтобы правило не перехватывало всё подряд.
7. Исправьте источники ошибочных переходов. Найдите внутренние ссылки на отсутствующие материалы и обновите их по смыслу. Затем повторите проверку после публикации изменений и сохраните несколько контрольных адресов для будущих обновлений.

Пример для Apache

Для статического сайта Apache использует директиву ErrorDocument. Учебная строка с локальным обработчиком может выглядеть так: ErrorDocument 404 /errors/not_found.html. Файл должен существовать в соответствующем расположении сайта. Это пример настройки, а не команда для любого хостинга.

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

Локальный путь и внешний адрес в ErrorDocument обрабатываются по-разному. Для своей страницы ошибки не подставляйте без проверки полный адрес другого сайта: вместо нужного ответа можно получить внешнее перенаправление. После изменения смотрите реальный ответ для исходного отсутствующего пути.

Пример для nginx

В nginx для локальной страницы ошибки используется error_page. Учебная строка: error_page 404 /404.html;. В конфигурации должен быть настроен доступ к соответствующему файлу. Директива делает внутренний переход, поэтому важно учитывать остальные правила обработки этого пути.

В документации также показан вариант с отдельным внутренним location для файла: location = /404.html { internal; }. Это ограничивает прямое внешнее обращение к обработчику. Конкретное размещение файла и взаимодействие с CMS зависят от вашей конфигурации, поэтому пример не заменяет проверку работающего сайта.

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

Частые ошибки

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

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

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

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

Менять код вместо исправления ссылки. Если ссылка внутри сайта ведёт не туда, обновите её. Хорошая страница ошибки снижает неудобство, но не делает сломанную навигацию правильной. Особенно внимательно проверьте меню, подборки и повторяющиеся блоки.

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

Как проверить

• Несуществующий адрес показывает понятное сообщение и сохраняет исходный путь без ненужного перенаправления.
• Основной документ отвечает кодом 404, что подтверждено просмотром ответа, а не только надписью.
• Существующие материалы продолжают открываться с ожидаемым содержимым.
• Оформление работает на вложенных неизвестных адресах.
• Навигация и поиск на странице ошибки ведут в действующие места.
• Для известных перенесённых материалов проверены отдельные точные перенаправления.
• Во внутренних ссылках исправлены найденные ошибочные адреса.
• Результат проверен в обычном режиме посетителя, без зависимости от входа администратора.

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

Смысл ответа описан в справочнике MDN. Настройка обработчиков есть в документации Apache и nginx. Отличие успешного ответа от ошибки содержимого поясняет документация Google о HTTP-кодах.

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

Вопросы и ответы

Достаточно ли написать на странице «404»?

Нет. Надпись находится в содержимом, а код — в техническом ответе сервера. Проверьте их отдельно для реально отсутствующего адреса. Человек должен понять ситуацию, а сервер — правильно сообщить об отсутствии ресурса.

Почему страница ошибки отвечает 200?

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

Нужно ли отправлять всех с ошибки на главную?

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

Почему на странице ошибки пропадают картинки?

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

Можно ли сделать красивую страницу 404 в CMS?

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

Правильная 404 устраняет битые ссылки?

Нет. Она помогает при неудачном переходе, но источник проблемы остаётся. Исправьте внутренние ссылки на актуальные адреса или удалите неуместные переходы, а для перенесённых материалов рассмотрите точные перенаправления.