Создание полезных сайтов

Страница «не найдена» возвращает 200: как проверить настоящий HTTP-статус

Страница может сообщать «не найдено», пока сервер отвечает «успешно». Проверяйте запрошенный URL, статус ответа и содержимое вместе: каждый из них отвечает на свой вопрос.

Автор coru · Опубликовано 2026-10-21 · Обновлено 2026-10-21

Начните с трёх URL, а не с изменения всего сайта

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

Например, на сайте ремонтной мастерской могут быть /guides/mend-a-seam/, несуществующий /guides/missing-check-7q9/ и старый адрес /sewing-help/. Это вымышленные примеры. Проверка одного случайного пути может не обнаружить ошибку правила, действующего только в определённом разделе.

Google может распознать ответ с признаками ошибки как soft 404, даже если сервер передал успешный статус. Ответ 200 не гарантирует индексацию. Описанные ниже действия проверяют ваш ответ, но не воспроизводят классификацию Google.

Посмотрите ответ HTML-документа в браузере

Браузер может отобразить документ с ошибкой как обычную страницу. По дизайну, заголовку и снимку экрана HTTP-статус не определить. Если ответ предоставляет service worker, результат браузера может отличаться от прямой сетевой проверки ниже; зафиксируйте это отличие до изменения сервера.

Откройте инструменты разработчика → Network до загрузки адреса. Включите Preserve log и Disable cache на время работы с открытыми инструментами. Перейдите непосредственно по полному проверяемому URL.
Выберите запрос документа (Doc), а не картинки, стилей или favicon. Во вкладке Headers запишите Request URL и Status Code. Если есть перенаправление, проверьте его строку и заголовок Location, а затем конечный документ.
Прочитайте страницу. На ней нужная статья, полезное объяснение отсутствия страницы, форма входа или общая главная страница? Отдельно сохраните конечный адрес.
Повторите проверку для заведомо рабочей страницы и известного переезда. Красный 404 у отсутствующей картинки не доказывает, что сам HTML-документ вернул 404.

Проверьте GET-ответ через curl

В терминале macOS или Linux замените URL в этой команде своим адресом. Она запрашивает страницу методом GET, выводит заголовки ответа и отбрасывает тело:

curl -sS --max-time 15 -D - -o /dev/null "https://example.com/guides/missing-check-7q9/"

Посмотрите строку HTTP-статуса и заголовок Location, если он есть. Эта команда не следует перенаправлениям. В Windows используйте curl.exe и замените /dev/null на NUL. Не заменяйте эту проверку на curl -I: тогда будет отправлен HEAD, то есть вы проверите другой метод.

Чтобы пройти известное перенаправление и увидеть его назначение, выполните:

curl -sS -L --max-redirs 5 --max-time 15 -o /dev/null -w "%{http_code} %{url_effective}\n" "https://example.com/sewing-help/"

Вторая команда показывает конечный статус. Сохраните и первоначальный ответ: за конечным 200 само перенаправление не видно. Откройте назначение в браузере и убедитесь, что там обещанная замена.

По умолчанию curl может завершиться успешно после получения HTTP 404. Его код завершения описывает передачу данных, а не наличие вашей статьи. С --fail HTTP-ошибка обычно приводит к коду завершения curl 22; при диагностике конкретного URL всё равно смотрите сам HTTP-статус.

Наш опыт: одинаковая страница, разные статусы

21 октября 2026 года мы отдали один и тот же 96-байтный документ с ошибкой по двум локальным тестовым URL. В Chrome 155.0.8059.12 оба показывали «Page not found» и «Try the article index.». Хеши тел ответов совпали. Различался только статус ответа маршрута.

Чтобы повторить сравнение в своей тестовой среде, настройте два маршрута с одним шаблоном ошибки: первый возвращает 200, второй — 404. Сравните запросы документов и видимый текст. Добавьте перенаправление на рабочую страницу и сравните первоначальный и конечный статусы. После опыта удалите намеренно неправильный маршрут.

Это локальная техническая демонстрация, а не проверка индексации Google или поведения реальных читателей. Она показывает, почему снимка экрана и успешного завершения curl недостаточно для приёмки.

/soft-missing: HTTP 200; код завершения curl 8.5.0 — 0; на экране сообщение об отсутствии страницы.
/fixed-missing: HTTP 404; код завершения curl — 0 без --fail и 22 с ним; на экране то же сообщение.
/moved: HTTP 301 с Location: /index; проверка с переходом по перенаправлению показала HTTP 200 по адресу /index.

Выберите исправление по ожидаемому результату

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

Страница должна существовать, но показывает ошибку или пустое содержимое: восстановите маршрут, контент или источник данных. Проверьте отображаемую страницу, прежде чем считать 200 успехом.
Адрес никогда не существовал либо материал удалён без подходящей замены: верните настоящий 404, либо 410 для намеренно удалённого содержимого, и покажите полезное объяснение со ссылками. Заголовок «404» сам по себе не меняет статус ответа.
Есть очевидная постоянная замена: перенаправьте старый URL именно на неё, затем проверьте содержимое и конечный статус. Отправка всех отсутствующих адресов на главную делает назначение менее полезным и всё ещё может привести к диагнозу soft 404.
Рабочая статья начала возвращать 404 после изменения маршрутизации: исправьте правило. Не назначайте 404 всем адресам, которые обрабатывает оболочка приложения.

После установки проверьте публичный маршрут

После изменения повторите три проверки на публичном домене. Проверяйте настоящий путь, а не только файл шаблона ошибки: при прямом открытии шаблон может возвращать 200, хотя отсутствующий маршрут правильно отвечает 404. Если раньше влияли кеш или service worker, помимо curl проверьте и новый сеанс браузера.

Используйте запись приёмки: «URL → ожидаемый результат → первоначальный статус → конечный URL/статус → видимое содержимое → время проверки». Сохраняйте заведомо рабочий URL как контроль от регрессии. Если Search Console раньше показывал soft 404, сравните дату обхода с датой изменения: успешная повторная проверка у вас не доказывает, что Google уже повторно обошёл или проиндексировал страницу.