Soft 404: почему страница отвечает 200, но поисковик считает ее пустой

Код 200 подтверждает ответ сервера, а не ценность страницы

HTTP-код отвечает на узкий вопрос: как сервер обработал запрос. Он не объясняет, удалось ли загрузить главный контент, соответствует ли URL ожиданию пользователя и есть ли на странице самостоятельная польза. Поэтому проверка soft 404 всегда начинается с просмотра реальной страницы, а не с автоматической замены статуса.

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

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

Сначала определите судьбу URL

У soft 404 есть три базовых сценария. Контент исчез окончательно. Контент переехал на релевантную замену. Контент по-прежнему должен существовать, но его не видит пользователь или робот. Эти сценарии нельзя смешивать, потому что одинаковая техническая правка в каждом из них будет означать разное.

Я бы начинал не со статуса, а с вопроса «какую задачу этот URL должен решать через месяц». Ответ сразу убирает половину спора. Если задачи нет, не нужно искусственно поддерживать страницу. Если она есть, недостаточно спрятать проблему редиректом.

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

Проверьте, где именно исчезает содержание

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

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

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

Не путайте пустой результат с полезной посадочной страницей

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

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

Для JavaScript-сайта проверьте не только браузер

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

Google рекомендует для клиентских приложений направлять человека на URL, который сервер отдает с 404, либо добавлять noindex на страницу ошибки, если корректный серверный статус получить невозможно. Руководство по JavaScript SEO описывает эти варианты для предотвращения soft 404 в SPA.

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

Выберите одно исправление для каждого сценария

У soft 404 нет универсальной кнопки «исправить». Ошибка появляется, когда технический ответ расходится с фактическим состоянием URL. Поэтому исправление должно вернуть соответствие между ними.

Исправление должно вернуть соответствие между URL, его статусом и реальным содержанием. Тогда задача решает причину, а не только убирает строку из отчета.

Одно решение должно устранять причину конкретного сценария, а не просто убирать предупреждение из отчета.

После выбора действия зафиксируйте URL, причину, владельца и критерий приемки. Это особенно важно, если над страницей работают редакция, разработка и SEO одновременно. Иначе каждый может закрыть свою часть работы, а итоговый URL продолжит отдавать тот же противоречивый сигнал.

Проверьте исправление в два этапа

Первый этап - техническая приемка. Команда убеждается, что нужный URL отдает ожидаемый статус, редирект ведет на точную замену, а живая страница содержит основной материал. Второй этап - проверка со стороны поиска. В Search Console для конкретного URL можно использовать инструмент проверки, чтобы увидеть доступность и обработку страницы Google. Справка по проверке URL описывает, какие сведения дает такая диагностика.

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

Превратите soft 404 из аварии в правило проекта

Самые неприятные soft 404 возникают не из-за одной удаленной страницы, а из-за отсутствия договоренности: что происходит с URL при снятии товара, кто отвечает за связь старой и новой статьи, как должен вести себя пустой фильтр, кто проверяет рендеринг после релиза. Эти правила не требуют тяжелого регламента. Достаточно сделать их частью обычного процесса публикации и изменений.

Для более широкой диагностики индексации используйте проверку проблем индексации. А в работе с soft 404 держитесь простого правила: сначала определить реальную судьбу страницы, затем привести статус и содержание в соответствие, а после проверить, что это увидел не только браузер команды.