Страница 404 и soft 404: как проверить статус, содержимое и маршрут пользователя

Сначала решите, должен ли URL существовать

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

По RFC 9110 404 Not Found означает, что у целевого ресурса нет текущего представления либо сервер не раскрывает его наличие; этот код сам по себе не говорит, временно это или навсегда. 410 Gone сообщает, что отсутствие, вероятно, постоянно. Эти значения не заменяют решение владельца о том, есть ли подходящая замена. Не выбирайте 410 ради обещания более быстрого удаления из поиска: сначала подтвердите судьбу материала.

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

Google Search Central рекомендует 404 или 410, когда удалённый документ не имеет подходящей замены, и постоянный редирект, когда содержимое действительно переехало. Не отправляйте все старые адреса на главную: посетитель теряет контекст, а поисковик может рассматривать такой переход как проблему. Внутренние ссылки и sitemap затем приводят к выбранным актуальным адресам, но это отдельный шаг после установления правильного исхода.

Разведите код ответа и видимое содержимое

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

Кандидат на soft 404 — адрес, который отвечает 200 OK, но сообщает, что страницы нет, либо почти не содержит основного материала. Это не новый HTTP-код: Google описывает soft 404 как результат своей оценки содержимого успешного ответа. Локальная проверка может найти очевидную несогласованность, но не воспроизведёт классификатор Google. Если Search Console показывает soft 404 для на вид нормальной страницы, дополнительно проверьте её загруженную роботом версию и необходимые ресурсы.

Распространённая причина расхождения — общий fallback: сервер отдаёт HTML приложения с кодом 200 для любого пути, а JavaScript уже после загрузки рисует сообщение об отсутствии. Другой случай — реальная страница существует, но не загрузился API-запрос, и посетитель увидел пустой основной блок. В первом случае нужно согласовать поведение неизвестного маршрута; во втором — восстановить рабочее содержимое и разобраться со сбоем. Одинаковая пустота на экране не означает одинаковое исправление.

Рисунок ниже разделяет два слоя: табличка 200 относится к серверу, а сообщение «не найдено» — к содержимому. Они должны описывать один и тот же исход. Обратное тоже верно: HTTP 404 с полезным текстом и ссылками остаётся ошибкой отсутствующего адреса. Дизайн страницы ошибки нужен человеку; поисковый сигнал задаёт ответ сервера.

Не записывайте любую страницу без результатов в soft 404 автоматически. Внутренний поиск может честно отвечать 200: форма, исходный запрос, объяснение отсутствия совпадений и путь к новой попытке составляют самостоятельный сценарий. Но пустая категория без товара, текста и действия или оболочка приложения без основного содержимого требуют отдельной проверки. Решение зависит от назначения URL, а не от одного слова «ничего» в интерфейсе.

Проверяйте точный URL через GET, а не только глазами

Сохраните полный адрес вместе с протоколом, путём, слешем и параметрами. Сначала отправьте GET без автоматического следования редиректам, чтобы увидеть первый ответ: curl -sS -D headers.txt -o body.html 'https://example.com/nesushchestvuyushchij-put/'. В headers.txt посмотрите статус и Location, а в body.html — заголовок, основной текст и ссылки. Это диагностический пример для своего сайта; адрес example.com здесь условный. Опция -I отправляет HEAD и не сохраняет тело, поэтому для проверки пары «код + содержимое» одного HEAD недостаточно.

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

Проверяйте и промежуточные ответы, а не только финальный экран после -L: цепочка может пройти через временный адрес, повторно вернуться на исходный URL или незаметно потерять параметр. Для отчёта достаточно сохранить начальный статус, каждый Location, конечный статус и конечный URL. Если ошибка возникает только у части адресов, сравните правила для файлов, каталогов и динамических страниц: разные слои сервера могут обрабатывать их независимо.

Запишите время проверки, устройство или профиль браузера, наличие авторизации, ответ CDN и фактический адрес после переадресации. Сервер может отдавать разные варианты по cookie, региону или защите от ботов. Локальный GET обычного клиента — важное доказательство текущего состояния, но он не показывает, что именно получил Googlebot или робот Яндекса при последнем обходе. Если статус меняется нерегулярно, сопоставьте момент теста с логами хостинга и действиями в CMS.

Для JavaScript-сайта проверьте сырой ответ отдельно от состояния после выполнения кода. Рекомендации Google для JavaScript подчёркивают смысловые HTTP-статусы; для полностью клиентского маршрута описаны запасные подходы, когда отдать статус на исходном URL технически трудно. Это не повод оставить везде 200 и считать проблему закрытой одним текстом «404» в интерфейсе.

Пройдите четыре вида отсутствующих и спорных адресов

Одного случайного /asdf/ мало. Такой тест найдёт общий fallback, но пропустит устаревший редирект конкретной статьи или пустую категорию. Составьте небольшой набор из собственных URL и для каждого заранее укажите ожидаемый исход. Ниже — матрица для приёмки; в ней нет адресов реального клиента.

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

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

В протоколе держите два столбца: expected до теста и actual после GET. Если фактическое значение не совпало, укажите ответственного за правило маршрута — CMS, веб-сервер, CDN или клиентское приложение. Исправление в шаблоне не помогает, когда nginx уже перенаправил запрос; изменение .htaccess не помогает, когда ошибочный 200 создан выше по цепочке. Конкретный слой определяйте по журналам и конфигурации своего проекта, а не по виду экрана.

Оставьте посетителю полезный путь после ошибки

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

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

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

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

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

Сверьте локальный ответ с данными поисковых систем

После исправления сохраните новый ответ и проверьте точный URL в Search Console и инструменте Яндекс Вебмастера «Проверка ответа сервера». В поисковой панели различайте сведения о последнем обходе и проверку опубликованной версии: старый отчёт может отражать прежнее состояние. Робот может столкнуться с блокировкой, ошибкой ресурса или другим вариантом ответа, которого не было в вашем браузере.

Сама запись 404 в отчёте не всегда означает задачу на исправление. Справка Search Console допускает корректный 404 для несуществующего или удалённого без замены адреса. Приоритет имеют URL, которые должны работать: важные внутренние ссылки, документы из sitemap, актуальные услуги и страницы, на которые ведёт навигация. Не перенаправляйте каждый неизвестный адрес на главную ради исчезновения числа ошибок из отчёта.

Разделяйте код и директивы для индексации. robots.txt управляет возможностью обхода, noindex — включением полученного документа в индекс поддерживающей системы; ни то ни другое не превращает 200 с сообщением «не найдено» в HTTP 404. Google прямо указывает, что закрытый в robots.txt URL может не дать роботу увидеть noindex. При локальной диагностике смотрите действующие правила отдельно, не снимайте защиту всего сайта ради одной проверки и не заявляйте, что одно изменение гарантирует исчезновение soft 404 из отчёта.

Рабочий пример: двенадцать проверок локального HTTP

Подготовлен учебный ZIP с сервером на 127.0.0.1, матрицей ожидаемых результатов и Python-скриптом. Все адреса и тексты синтетические; после запуска временный сервер закрывается. Команда python3 -B test_routes.py выполняет реальные GET-запросы только к выбранному локальному порту и выдаёт JSON с PASS и двенадцатью именованными сценариями. Исходники, результат и инструкция лежат внутри архива, поэтому проверку можно повторить после распаковки.

Пять сценариев должны пройти без замечаний: существующая страница 200, случайный путь 404, удалённый материал 410, эквивалентный перенос 301 на страницу 200 и содержательная пустая выдача поиска 200. Семь специально неисправны: надпись «не найдена» при 200, пустой <main> при 200, редирект не туда, редирект на отсутствующую страницу, 404 без ссылок, 404 со ссылкой на другой 404 и 404 с обычным содержимым действующей статьи. Проверка сопоставляет ожидаемый код с фактическим, читает Location независимо от регистра имени заголовка, основной текст и ссылки, а затем запрашивает адрес назначения редиректа и ссылки со страницы ошибки.

Результат скрипта — локальная приёмка учебного контракта, а не вердикт Google о soft 404, аудит живого сайта или подтверждение индексации. Простая текстовая эвристика намеренно распознаёт лишь очевидные признаки, в том числе русские слова об отсутствии при 404/410; для других языков и формулировок её нужно менять. Реальная CMS, авторизация, CDN, разные ответы роботам и время обхода не входят в модель. Для собственного сайта сначала составьте список URL и ожидаемые состояния с владельцем, затем адаптируйте проверки к реальному окружению без отправки приватных адресов в публичный пример.

Чек-лист приёмки страницы 404

1. Для каждого тестового URL назначены состояние, владелец решения и ожидаемый HTTP-код.
2. Случайный неизвестный путь отвечает настоящим 404, а не успешным шаблоном с надписью об ошибке.
3. Удалённый без замены материал даёт согласованный 404 или 410; старые внутренние ссылки исправлены.
4. Старый адрес с равнозначной заменой ведёт на точный новый URL; конечный документ отвечает 200 и решает ту же задачу.
5. У страницы ошибки есть ясное сообщение и рабочие ссылки на актуальные разделы.
6. Пустой поиск, пустая категория и несуществующая запись проверены как разные сценарии.
7. GET сохранил статус, Location, тело, время и точный URL; браузерный вид сверён отдельно.
8. При расхождении определён слой исправления: сервер, CMS, CDN или клиентский маршрут.
9. Данные Search Console и Яндекс Вебмастера сопоставлены с датой обхода, но не выданы за текущий локальный ответ.
10. После изменения проведён повторный запрос; опубликованную версию проверяют отдельно от учебной модели.

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