Soft 404 возникает при расхождении протокола и содержания. Сервер сообщает 200 OK, то есть обещает полноценный ресурс, однако в HTML находится ошибка, пустой шаблон или страница, не соответствующая запрошенному адресу. Поисковая система может классифицировать такой URL как отсутствующий, хотя технически код 404 не получен. В DevTools отдельного статуса soft 404 нет: это вывод системы по совокупности признаков.
Почему успешный код становится ошибочным сигналом
Типичная причина — универсальный шаблон CMS. Роутер не нашёл запись в базе, но всё равно отрисовал шапку, футер и фразу «Ничего не найдено». На уровне приложения исключение было обработано, поэтому веб-сервер отправил 200. Для пользователя это страница ошибки; для протокола — успешный документ.
Другой сценарий связан с каталогами. Товар снят, фильтр не дал результатов, город не обслуживается, профиль удалён. Шаблон остаётся доступным, но уникального основного блока нет. Бывает и обратное: полезная короткая страница ошибочно определяется как soft 404 из-за очень малого объёма или сходства с сообщением об ошибке.
Google рекомендует возвращать 404 для действительно отсутствующих страниц и проверять отрисованный результат через live-тест в Search Console; это отражено в официальной справке об отчёте индексирования. Задача владельца сайта — привести код и смысл ответа в соответствие. Скрытие уведомления консоли проблему не решит.
Сначала определите класс URL
Не начинайте с массовой замены статусов. Разделите отмеченные адреса хотя бы на четыре группы:
| Состояние ресурса | Правильная реакция |
|---|---|
| Ресурс никогда не существовал или удалён без замены | 404 либо 410 |
| Есть точный новый эквивалент | постоянный редирект на эквивалент |
| Страница временно пуста, но сохраняет полезную функцию | 200 с содержательным состоянием |
| Полезный документ ошибочно распознан как пустой | сохранить 200, устранить признаки ошибки |
Список URL дополните источником: внутренние ссылки, sitemap, старый импорт, параметры фильтра, внешние переходы. Если soft 404 массово появляется по одному шаблону, исследуйте генератор: поштучная правка адресов оставит общую причину. Если затронута одна важная посадочная страница, сравните её с нормальной страницей того же типа.
Статья об обычных ошибках 404 полезна для выбора между восстановлением, удалением и редиректом, но soft 404 требует ещё проверки содержимого успешного ответа.
Посмотрите фактический ответ на каждом уровне
Получите код без автоматического перехода по редиректам, затем — итоговую цепочку. Сохраните исходный HTML. После этого откройте страницу с отключённым JavaScript и с обычным выполнением скриптов. Если исходник содержит нормальный товар, а интерфейс после запроса к API заменяет его сообщением «не найдено», причина находится в данных или клиентском приложении. Если исходник пуст, но браузер получает контент позже, нужно проверить доступность API для роботов.
Сопоставьте четыре элемента: HTTP-код, <title>, H1 и основной текст. Комбинация 200, «Страница не найдена» в title, общего H1 и почти пустого main ясно показывает ошибочный шаблон. Проверьте также canonical: страница ошибки не должна канонизироваться на главную в попытке сохранить сигналы.
Для динамического сайта полезно изучить сетевые запросы и серверные логи по одному URL. Код 200 внешнего документа может скрывать 404 или 500 внутреннего API. В этом случае исправлять нужно обработку данных; мета-тег не изменит ошибочный ответ API.
Выберите ответ по состоянию ресурса
Возвращайте 404, если запрошенного объекта нет и релевантной замены не существует. Код 410 Gone точнее сообщает о намеренном окончательном удалении, но для большинства CMS корректного 404 достаточно. Оба ответа могут показывать оформленную страницу с поиском, категориями и навигацией; полезность интерфейса не требует кода 200.
Постоянный редирект оправдан, когда есть близкий преемник: карточка того же товара по новому URL, объединённая статья, изменившийся адрес услуги. Перенаправлять все удалённые карточки на главную или родительскую категорию нельзя считать универсальным исправлением. Пользователь ожидал конкретный объект, а получил другой; такой переход сам может быть воспринят как soft 404. Правила построения цепочек разобраны в материале о проверке редиректов.
Уберите удалённый URL из sitemap и внутренних ссылок. Внешние ссылки невозможно обновить полностью, поэтому качественная 404-страница остаётся нужна. Не закрывайте адрес в robots.txt: роботу требуется увидеть корректный статус и обновить состояние.
Когда следует оставить 200
Пустой результат не всегда означает отсутствующий ресурс. Страница категории «Вакансии» может временно не содержать объявлений, но сохранять описание компании, подписку на новые позиции и контакты. Категория товаров может быть важна как постоянная сущность, даже если остатки закончились. Тогда 200 логичен, если основной блок объясняет состояние и продолжает выполнять задачу пользователя.
Уберите лексику системной ошибки из title и H1. Дайте уникальный контекст: что это за раздел, почему сейчас нет элементов, какие действия доступны, когда информация обновляется, есть ли соседние категории. Не заполняйте шаблон случайным SEO-текстом. По содержанию должно быть понятно, какую устойчивую сущность представляет URL. Маскировка отсутствующих данных создаст тот же сигнал soft 404.
Для товарных страниц бизнес-решение зависит от модели каталога. Временно недоступный товар обычно сохраняют с характеристиками и статусом поставки. Окончательно удалённый без аналога — отдают с 404 или 410. Если есть точная модель-преемник, делают редирект после проверки смыслового соответствия.
Как исправить массовую причину в шаблоне
Найдите слой, который первым узнаёт об отсутствии объекта: маршрутизатор, контроллер, серверный компонент или API. Именно там должен формироваться статус ответа. Если приложение сначала отправляет 200, а затем клиентский JavaScript показывает ошибку, изменить HTTP-код уже поздно. Для SSR-фреймворков используйте предусмотренный механизм not found до отправки заголовков; в традиционной CMS задайте статус до вывода шаблона.
Отдельно обработайте неверные параметры. Несуществующая страница пагинации, комбинация фильтров и мусорный идентификатор не обязаны становиться индексируемыми пустыми посадочными. Определите допустимые значения, нормализуйте URL, закройте генерацию бесконечных комбинаций и оставьте в sitemap только выбранные канонические страницы. Связь подобных адресов с обходом раскрыта в статье о краулинговом бюджете.
Тесты должны покрывать существующий объект, удалённый объект, неверный идентификатор, временно пустой список и ошибку источника данных. Последняя не равна отсутствию: при сбое базы или API корректнее вернуть 5xx, чтобы не сообщать поиску об удалении реальных страниц.
Перепроверьте ложное срабатывание
Если страница полезна, сравните то, что видит робот, с браузером. Проверьте мобильный вариант, отрисованный HTML, скриншот Search Console, доступность ресурсов и содержимое для незалогиненного посетителя. Короткая страница может быть самостоятельной, но шаблонные title, одинаковый H1 и отсутствие основного текста усиливают сходство с заглушкой.
Не пытайтесь решить ложное срабатывание только увеличением количества слов. Сделайте явной сущность страницы: точное название, факты, навигационный контекст, корректные структурированные данные, собственный canonical. Убедитесь, что важная часть не скрыта до пользовательского действия. После изменения запросите live-проверку и сохраните полученный HTML как контрольный образец.
Контроль после публикации исправления
Сначала выборочно проверьте несколько URL каждого класса, затем запустите обход всего затронутого шаблона. Критерии приёмки: отсутствующие объекты отдают выбранный код; рабочие страницы отвечают 200 и содержат основной блок; редиректы ведут на релевантный конечный адрес; sitemap и внутренние ссылки очищены; ошибки источника данных не превращаются в 404.
После выборочной проверки полный аудит сайта reChecker может собрать страницы из sitemap и внутренних ссылок, показать их ответы и повторяющиеся технические признаки. Логи и поисковые консоли остаются источником истории, а владелец сайта задаёт бизнес-класс каждого URL.
Изменения в отчёте поисковой системы появятся после повторного обхода, поэтому проверка через несколько минут покажет только состояние сайта. Сохраните дату выкладки, новый ответ и запись о выбранном классе URL. Когда робот снова посетит адрес, по этим данным будет видно, получил ли он обновлённую версию и соответствует ли статус жизненному циклу ресурса.