Soft 404 — расхождение между тем, что говорит сервер, и тем, что решает индексатор. Сервер отвечает 200 OK, страница открывается в браузере, а конвейер индексирования Google читает содержимое, находит там сообщение об ошибке или пустоту и записывает URL в ложные ошибки 404. В индекс такая страница не попадает; если она там была, её убирают.
У расхождения три источника: неверный код ответа, сломанный рендеринг и нерелевантный редирект. Первый лечится настройкой сервера, второй — доставкой контента до робота, третий — переносом перенаправления на подходящую страницу. Попытка «просто дописать текст» закрывает один сценарий из трёх, поэтому порядок работы начинается с диагностики, а не с редактора.
Search Console собирает такие URL в отчёте «Индексирование страниц» под причиной «Ложная ошибка 404». Яндекс термином soft 404 не пользуется: похожие страницы уходят в исключённые с формулировкой «Малоценная или маловостребованная страница». Названия расходятся, механика совпадает — поисковая система оценивает не код ответа, а то, что осталось от страницы после загрузки и обработки.
Что Search Console называет ложной ошибкой 404
Статус живёт в разделе «Индексирование» → «Страницы», в таблице «Почему эти страницы не индексируются», с общим состоянием «Не проиндексировано». Английский интерфейс называет ту же причину Soft 404 — отсюда жаргон, прижившийся в русскоязычной среде.
Механику Google описывает в таблице кодов статуса HTTP: при ответе 2xx робот передаёт полученное дальше, в конвейер индексирования, а если содержимое похоже на ошибку или пустую страницу, Search Console регистрирует ошибку soft 404. Там же стоит отдельная оговорка: код 2xx индексирование не гарантирует. Документ в 2026 году переехал в раздел Crawling infrastructure → «Устранение неполадок» (русская версия обновлена 5 марта 2026 года), а старые адреса справки о ложных ошибках 404 перенаправляют туда же.
«Код статуса HTTP 2xx (success) не гарантирует успешное индексирование в Google Поиске». — Google Search Central, «Как коды статуса HTTP влияют на сканирование», обновление от 5 марта 2026 года.
Справка отчёта об индексировании страниц формулирует симптом с точки зрения человека: пользователь видит сообщение «не найдено», а сервер при этом не отдаёт код 404. Рекомендация там же — возвращать настоящий код 404 и снабжать страницу ошибки дополнительной информацией, чтобы робот отличал реальную 404 от ложной.
Три соседних статуса путают с ложной 404 чаще всего. «Не найдено (404)» — сервер отвечает честно, страницы нет, робот постепенно снижает частоту обращений к URL; это не поломка. «Страница с переадресацией» — неканонический URL ведёт на другой адрес, и в индекс попадает цель перенаправления, а не сам URL. «Страница проиндексирована без контента» — предупреждение из другой таблицы: страница в индексе, но робот не сумел обработать её содержимое.
Термин старше, чем кажется. Google попрощался с soft 404 в блоге для вебмастеров в августе 2008 года, а отдельный отчёт об этих ошибках появился в Webmaster Tools в июне 2010-го.
Шесть причин, по которым код 200 не спасает страницу
Причины делятся на группы, и каждая оставляет свой след в диагностике.
Шаблон ошибки с успешным кодом. CMS или хостинг показывает «Страница не найдена», но отдаёт 200. Признак: в исходном HTML лежит текст об ошибке, а первая строка ответа сервера сообщает об успехе.
Пустой рендеринг. HTML приходит роботу как контейнер, содержимое рисует JavaScript. Запрос к API отвалился, роутер отработал не так — робот получил каркас без текста. Признак: HTML короткий, скриншот в живой проверке пустой.
Страницы с нулевым результатом. Внутренний поиск, комбинации фильтров, пустые категории, теги и архивы без записей. Признак: массовость и параметрические URL в списке.
Нерелевантный редирект. Удалённые адреса перенаправляют на главную или на общую категорию. Джон Мюллер из Google в видеовстрече для вебмастеров 7 октября 2016 года (по пересказу Search Engine Roundtable) назвал массовый 301 всех страниц на главную тем, что Google видит как soft 404: такие редиректы игнорируются, и сигналы через них не идут.
Тонкий контент. Карточка товара без описания, страница со строчкой «нет в наличии», сгенерированная заглушка. Признак: точечные URL одного шаблона, а не весь раздел.
Заблокированные ресурсы. JS и CSS закрыты в robots.txt, рендер разваливается. Признак: в живой проверке URL раздел ресурсов страницы показывает ошибки загрузки.
Масштаб последствий виден на больших сайтах. Разбор миграции в Search Engine Land (12 мая 2026 года, автор Mikael Araújo, данные Search Console за 2022 год) показывает: вместе с накоплением ложных 404 на одном из доменов суточное число запросов на обход упало с 60–70 тысяч до 20–30 тысяч, а всего на 13 доменах организации скопилось около 120 тысяч soft 404. Робот тратит бюджет обхода на адреса, которые ничего не отдают, и реже возвращается к тем, что отдают.
Порядок разбора: восемь шагов от выгрузки до переобхода
Шаг 1. Выгрузить список. В Search Console открыть «Индексирование» → «Страницы», найти строку «Ложная ошибка 404», нажать «Экспорт». На экране появится таблица примеров; справка предупреждает, что она содержит не больше 1000 URL. Смотреть сразу. Успех: файл с адресами и датой последнего сканирования по каждому. Провал: URL в отчёте заметно меньше, чем ожидается по структуре сайта — переключить фильтр над таблицей с «Все отправленные страницы» на «Все обработанные страницы» и выгрузить снова.
Шаг 2. Сгруппировать по шаблонам. В таблице разложить адреса по маске пути и параметрам: /search?, /tag/, /catalog/*/filter/, карточки товаров. Инструмент — любой табличный редактор, фильтр по подстроке. Смотреть сразу. Успех: три-шесть групп, каждая из которых объясняется одним шаблоном страницы. Провал: группы не собираются, адреса разрозненные — проблема точечная, дальше идти по датам сканирования и по одному URL.
Шаг 3. Проверить дату последнего сканирования. Для трёх-пяти представителей каждой группы открыть инструмент проверки URL и посмотреть поле «Последнее сканирование». Смотреть сразу после выгрузки. Успех: дата свежее последних правок шаблона — статус отражает текущее состояние, диагностика имеет смысл. Провал: дата старше правок — исправление уже могло сработать; дождаться переобхода или запросить его вместо новых изменений.
Шаг 4. Снять код ответа и объём исходного HTML. В терминале:
bash
curl -sI https://example.ru/page/ | head -n 1
curl -s https://example.ru/page/ | wc -c
curl -s https://example.ru/page/ | grep -i -c "не найден\|not found\|ничего не найдено"Смотреть сразу, по одному URL из каждой группы. Успех для честной страницы: HTTP/2 200, объём в десятки килобайт, ноль совпадений с маркерами ошибки. Провал первого типа: 200 и ненулевое число совпадений — чинить код ответа сервера. Провал второго типа: 200 и объём в единицы килобайт без текста — вопрос к рендерингу. 301/302 в первой строке — это не «почти 200»: проверять нужно конечный адрес, а сам URL уйдёт в «Страница с переадресацией». Оговорка: CDN и защита от ботов иногда отвечают роботу иначе, чем внешнему curl, поэтому итоговая сверка — по логам сервера.
Шаг 5. Посмотреть скриншот рендера. В инструменте проверки URL нажать «Проверить страницу на сайте», затем «Посмотреть проверенную страницу». Вкладка «Скриншот» показывает, что увидел робот после обработки, вкладка «Дополнительная информация» — код ответа и ресурсы, которые не загрузились. Смотреть после шага 4. Успех: на скриншоте основной блок с текстом, ресурсы загружены. Провал: пустой экран или шаблон ошибки при нормальном HTML из шага 4 — рендеринг или заблокированные в robots.txt ресурсы. Три замера сводятся в матрицу:
| Код | Исходный HTML | Скриншот рендера | Что чинить |
|---|---|---|---|
200 | текст ошибки внутри | страница ошибки | код ответа сервера |
200 | пустой каркас | пустой экран | рендеринг и доставку данных |
200 | нормальный контент | нормальная страница | контент, дубли, спрос |
301 | редирект на главную | главная страница | цель перенаправления |
Четвёртая строка самая коварная: технически всё работает, а Google засчитывает URL как несуществующий, потому что цель редиректа не связана с исходной страницей.
Шаг 6. Проверить коды ответа массово. Ручной curl не масштабируется на тысячи адресов. Список из шага 1 прогоняется через краулер с экспортом кодов или через бесплатный чекер ошибок 404 по списку URL. Смотреть сразу после выгрузки. Успех: список делится на «код честный» (404/410) и «код 200 при содержимом ошибки». Провал: массово 200 на явно удалённых страницах — значит, шаблон ошибки CMS отдаёт успех, и чинить нужно на уровне сервера, а не по одному URL.
Шаг 7. Применить сценарий починки и запустить проверку. Одна группа — одно решение из таблицы ниже, без смешивания. После правки в отчёте нажать «Проверить исправление». Смотреть через две недели: справка называет срок «около двух недель, иногда дольше». Успех: статус проверки «Пройдено», число URL в строке падает. Провал: проверка не пройдена — открыть список оставшихся URL, повторить шаги 3–5 для них; чаще всего это вторая группа с другой причиной, которую починили тем же способом, что и первую.
Шаг 8. Проконтролировать переобход. Через 7–14 дней после правок: для контрольных URL — поле «Последнее сканирование» в инструменте проверки, в логах сервера — заходы Googlebot Smartphone на эти адреса, в отчёте — движение числа URL. Успех: свежая дата, строка «Ложная ошибка 404» уменьшается. Провал: дата не обновилась — робот не вернулся; добавить URL в sitemap и поставить внутренние ссылки с индексируемых страниц. Проблема числится в отчёте до 90 дней после того, как последняя страница помечена исправленной, — пустая таблица появится не сразу.
Какой способ починки выбрать под конкретный случай
| Метод | Кому подходит | Ожидаемая скорость | Риск | Когда НЕ использовать |
|---|---|---|---|---|
Код 404 | Удалённые страницы без замены | Выпадение из индекса за недели | Потеря ссылочного веса удалённого URL | Если у страницы есть точный аналог |
Код 410 | Осознанно удалённый раздел, снятые товары | Как правило, быстрее 404 | Возврат страницы потребует переиндексации | При временном отключении раздела |
301 на близкую страницу | Переезд URL, слияние карточек | Дни — недели | При нерелевантной цели превращается в soft 404 | Для массового сноса адресов на главную |
noindex или X-Robots-Tag | Внутренний поиск, служебные фильтры | Недели | Робот продолжит обходить URL | Если страница нужна в поиске |
| Доработка контента | Тонкие карточки, пустые категории | От недели до месяца | Не помогает при поломке рендера | При честном отсутствии страницы |
| Серверный рендеринг или prerender | SPA, каталоги на JS | Недели после релиза | Кэш отдаёт устаревший HTML | Когда HTML и так содержит контент |
Disallow в robots.txt | Бесконечные параметрические выдачи | Сразу для обхода | Закрытый URL остаётся в индексе без контента | Для страниц, которые нужно убрать из индекса |
Оговорка к последней строке: robots.txt управляет обходом, а не индексированием. Чтобы убрать страницу из результатов, роботу оставляют доступ и ставят noindex.
Что стоит за soft 404 в Яндексе
Статуса с таким названием в Яндекс Вебмастере нет. Ближайшая по смыслу метка — «Малоценная или маловостребованная страница» в разделе «Индексирование» → «Страницы в поиске», вкладка «Исключённые». Справка Вебмастера описывает её как алгоритмическую оценку, а не санкцию: малоценная — дубль или страница без видимого роботу текста, маловостребованная — та, на которую нет запросов. Среди причин прямо названы «отсутствие видимого текста» и «контент недоступен роботу» — те же пустой рендер и шаблон ошибки под другим именем.
Коды ответа Яндекс проверяет двумя инструментами. «Проверка ответа сервера» показывает код и отдельным сообщением предупреждает, что «Документ не содержит текст», например при заголовке Content-length: 0; справка оговаривает, что инструмент обращается с другого IP-адреса, поэтому ответ может отличаться от реального, и последняя инстанция — логи. «Проверка страницы» в разделе «Индексирование» показывает код ответа, статус URL в поиске и то, как выглядит содержимое для робота.
Вывод для двух систем сразу: страница с кодом 200 и текстом ошибки одинаково бесполезна и там, и там. Google назовёт её ложной 404, Яндекс — малоценной, а пользователь просто уйдёт.
Частые вопросы
В: Чем отличается soft 404 от обычной ошибки 404? О: Обычная 404 — честный ответ сервера о том, что страницы нет. Ложная ошибка 404 возникает, когда сервер отвечает успешным кодом, а содержимое сообщает об ошибке или пустое; решение принимает индексатор, а не сервер.
В: Влияет ли ложная ошибка 404 на позиции всего сайта? О: Статус относится к конкретным URL и не переносится на остальные страницы как санкция. Косвенный вред другой: робот тратит бюджет обхода на бесполезные адреса, и в разборе Search Engine Land это выражалось в кратном падении запросов на обход.
В: Можно ли редиректить удалённые страницы на главную? О: Массовое перенаправление на главную Google обрабатывает как ложные 404, и сигналы через такие редиректы не передаются. Перенаправлять нужно на ближайшую по смыслу страницу или отдавать честный 404/410.
В: Что делать, если страница с нормальным контентом помечена как soft 404? О: Проверить дату последнего сканирования и посмотреть скриншот в живой проверке URL. Чаще всего робот получил версию без содержимого из-за рендеринга или заблокированных ресурсов — это вторая строка матрицы, а не третья.
В: Сколько ждать после исправления ошибки soft 404? О: Проверка исправления в Search Console занимает около двух недель, иногда дольше. Сама проблема остаётся в отчёте до 90 дней после того, как последний URL помечен исправленным, поэтому пустая таблица — не критерий.
В: Как найти ложные 404 без Search Console? О: Краулером или чекером кодов по списку URL — сравнивать код ответа с наличием текста об ошибке и объёмом основного блока. Дополнительно помогают логи: адреса, к которым робот возвращается, но которые не появляются в поиске.
В: Нужно ли закрывать страницы внутреннего поиска от индексации? О: Да, это типовой источник пустых выдач с кодом 200. Рабочая связка — noindex на страницах результатов и ограничение обхода параметрических URL; один Disallow из индекса не выводит.
Куда движется диагностика и что проверить за десять минут
Граница между «страница есть» и «страницы нет» уходит с уровня веб-сервера на уровень рендеринга. Чем больше интерфейсов собирается на клиенте, тем чаще вердикт зависит от того, доехали ли данные до робота, а не от строки в конфиге nginx. Переезд документации Google о кодах ответа в раздел о сканировании — сигнал того же порядка: коды, рендеринг и отчётность сходятся в одну картину, и в 2026–2028 годах это направление, по оценке практиков, только усилится.
Десять минут на ближайшую проверку: открыть отчёт «Индексирование страниц», найти строку «Ложная ошибка 404», взять три URL из разных шаблонов, посмотреть дату последнего сканирования и запустить живую проверку со скриншотом. В Яндекс Вебмастере параллельно прогнать те же адреса через «Проверку ответа сервера». Дальше решение принимает матрица из трёх замеров, а не догадки; таблица кодов из справки Google о кодах статуса HTTP — опора для спора с разработчиком.
