Сервер, который отдаёт по несуществующему адресу страницу с надписью "ничего не найдено" и кодом 200, врёт вежливо и убедительно. Для посетителя выглядит правдоподобно, для поисковика - как страница без содержания: алгоритмы распознают обман и помечают адрес мягкой ошибкой 404, после чего страница уходит из выдачи. Проблема коварнее обычной битой ссылки, потому что код ответа формально успешен и стандартные мониторы молчат. Search Console умеет находить такие страницы и честно показывает их в отчёте об индексировании. Ниже - как читать этот отчёт, отличать настоящую причину от мнимой и чинить адреса правильными кодами ответа, не сломав при этом живые страницы.
Что такое мягкая ошибка 404 и чем она опаснее честного кода ответа
Мягкая ошибка 404 - ситуация, описанная в документации Google без обиняков: адрес возвращает пользователю сообщение об отсутствии страницы и одновременно код 200. Сюда же относятся страницы без основного контента - пустые, с оборванным шаблоном или единственной строчкой извинений. Поисковик смотрит не на надпись, а на содержимое: если страница по сути пустышка, она исключается из поиска, какой бы код ни стоял в заголовке ответа.
Чем это хуже честной ошибки 404? Честный код сразу закрывает вопрос: адреса не существует, сигнал однозначен, робот со временем перестаёт приходить. Мягкая ошибка оставляет неразбериху. Посетитель думает, что страница рабочая, и расстраивается. Робот тратит обход на адрес, который не несёт ценности. Владелец сайта не видит проблему в мониторинге кодов ответа, потому что формально всё в порядке. Ирония в том, что в ловушку попадают и живые страницы: слишком лаконичный контент или оборванная загрузка порой дают алгоритму повод принять полезный адрес за пустышку.
Скорость реакции - второй довод в пользу честных кодов. На настоящий 404 поисковик отвечает предсказуемо: адрес постепенно теряет частоту обхода, и через пару месяцев робот заглядывает туда редко. Мягкая ошибка держит адрес в подвешенном состоянии: робот возвращается снова и снова, потому что формально страница существует, и каждый визит съедает слот обхода, который мог достаться свежей статье.
Есть и хозяйственный смысл: мягкие ошибки засоряют внутреннюю аналитику. Адреса с кодом 200 считаются рабочими страницами в отчётах обхода и логах, и вычисление реальной доли мусора требует ручных поправок. Честные коды ответа делают статистику честной бесплатно.
Отдельная тонкость - JavaScript-приложения. Маршрут "страница не найдена" в одностраничном приложении рисуется на клиенте, а сервер на любой запрос отвечает 200. Для пользователя разница есть, для поисковика - нет: он видит пустой каркас с сообщением об ошибке и исправно заносит адрес в список мягких ошибок.
Распознать подвох можно и без консоли: адрес открывается в браузере, показывает аккуратное сообщение об отсутствии, но вкладка сети в инструментах разработчика подсвечивает статус 200. Логика кодов на сервере - единственный надёжный фундамент, интерфейсными заглушками поисковик не обманешь.
Где Search Console показывает soft 404 и как читать отчёт об индексировании
Мягкие ошибки живут в отчёте об индексировании страниц: раздел индексации, отчёт о страницах, список причин исключения. Статус так и называется - "Мягкая ошибка 404", рядом лежат отдельные статусы "Не найдено (404)" и "Ошибка сервера (5xx)", и смешивать их не стоит: у каждого своя механика и своё лечение. По статусу доступны примеры адресов, но список ограничен тысячей записей, поэтому на крупном сайте он показывает выборку, а не полный реестр.
Для полномасштабного аудита выборку дополняют собственным краулингом: SEO-паук обходит сайт и выписывает все адреса с кодом 200, а нехитрый скрипт ищет среди них короткие страницы - по количеству символов, по типовым фразам отсутствия, по пустым блокам основного контента. Пересечение с отчётом консоли даёт рабочий список кандидатов на исправление, не ограниченный тысячей записей.
Отчёт не показывает проблему мгновенно: между сбоем страницы и появлением статуса в консоли проходят дни, иногда недели. Кнопка "Проверить исправление" запускает живую перепроверку выборки адресов, а инструмент проверки URL по конкретному адресу даёт самый быстрый ответ - живой тест показывает текущий код ответа и скриншот отрисованной страницы. Каждый адрес из выборки кликабелен и открывает карточку с историей: последние обходы, выбранный канонический адрес, статус индексации. Оттуда же запускается проверка страницы и отправка на переобход после исправления - путь от находки до исправления укладывается в один экран. Скриншот - главное орудие: он показывает, что именно видит Google, а не то, что видит браузер с куки и грузным подключением. Динамика статуса ускоряет разбор: если число адресов с мягкой ошибкой подскочило на графике, совпадение с датой релиза подсказывает причину быстрее любого дебага.
Каждую найденную страницу стоит фиксировать в списке с датой обнаружения: часть проблем всплывает волнами после релизов, и история превращает разбор из гадания в рутину.
С мягкой ошибкой соседствует статус "Обойдено, но не проиндексировано": он не про пустышки, а про слабый спрос и очереди обхода. Смешение статусов порождает неверные действия, поэтому перед исправлением стоит прочитать описание статуса в самой консоли - для мягкой ошибки оно прямо называет код 200 при отсутствии контента.
Типичные причины мягких ошибок на реальных сайтах
Документация Google перечисляет четыре классические причины: отсутствующий server-side include, оборванное соединение с базой, страница пустых результатов внутреннего поиска и незагрузившийся файл JavaScript. На практике список шире, и каждая причина имеет почерк.
Убитые карточки товаров и удалённые материалы, которые CMS продолжает собирать шаблоном: заголовок есть, контента нет, ответ 200. Экспиренные акции и рассписания, которые система показывает "пустыми", когда событие прошло. Редиректы на главную без контента по смыслу. Пагинация и фильтры, выдавшие ноль результатов по редким сочетаниям. Наконец, reverse-ошибка: живая страница с тяжёлой загрузкой или заблокированными в robots.txt критичными ресурсами отрисовывается как пустая и получает метку незаслуженно.
Частый сценарий - переезды и чистки каталога. Старые адреса после массового удаления товаров начинают возвращать шаблон с сообщением об отсутствии, техническая команда считает задачу закрытой, а поисковик неделю за неделей пересматривает тысячи мягких ошибок вместо полезных страниц.
Заметный подвид - страницы поиска по сайту. Внутренний поиск отвечает по любому запросу, и на пустую выдачу робот способен наткнуться бесконечным числом способов: адреса с параметром запроса размножаются по ссылкам, опечаткам и старым фразам. Пустая выдача с кодом 200 - готовая мягкая ошибка в промышленных масштабах.
Диагностика отдельного адреса через curl и живой тест в Search Console
Диагноз ставится за минуту. Сначала смотрят фактический код ответа:
curl -I "https://example.com/catalog/old-product"Потом повторяют запрос со строкой User-Agent робота - так проверяется клокинг, когда сервер отдаёт людям одно, а роботам другое:
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
-I "https://example.com/catalog/old-product"Если коды расходятся, ищут правила для роботов в настройках сервера или в коде. Если код одинаковый и равен 200, смотрят на тело ответа: пустое, с сообщением об ошибке, с недогруженным шаблоном. Живой тест в Search Console добавляет взгляд робота - он запрашивает страницу прямо сейчас и показывает скриншот отрисовки. Расхождение скриншота с браузером почти всегда указывает на заблокированные ресурсы: стили и скрипты, закрытые в robots.txt, ломят страницу по-тихому.
Полезно проверить и время ответа: страница, которая отдаётся десять секунд, для робота и для живого теста может не дожить до полной отрисовки. Канонический адрес из того же теста подскажет, не считает ли Google страницу дублем другой, а это уже другая ветка разбора.
Практичная деталь: заголовок Content-Type и размер тела ответа подсказывают, что отдал сервер - полноценную страницу или заглушку в два килобайта. Сравнение с эталонной страницей раздела показывает, где теряется контент. Если тело ответа полное, а скриншот в консоли пуст, подозрение падает на отрисовку: заблокированные скрипты, ошибки в JavaScript, зависший ответ backend-а.
Исправление через корректные коды 404 и 410 с настройкой сервера
Логика исправления сводится к трём сценариям, и в документации Google она описана именно так:
- страница удалена навсегда и равноценной замены нет, сервер возвращает 404 или 410;
- контент переехал или у него есть очевидная замена, адрес отдаёт 301 на новое место;
- страница должна работать, значит чинят загрузку и отрисовку для робота.
Для удалённых адресов код настраивается на уровне сервера. В nginx несуществующее отдают честно, а шаблон ошибки подключают отдельной директивой:
location /catalog/old-product {
return 404;
}
error_page 404 /404.html;В Apache то же самое делают через ErrorDocument, а для навсегда удалённых адресов есть лаконичная директива gone, отдающая 410:
ErrorDocument 404 /404.html
Redirect gone /catalog/old-productВ PHP код выставляют до любого вывода, иначе заголовки не уйдут:
http_response_code(404);
include __DIR__ . '/templates/404.php';
exit;Разница между 404 и 410 - в категоричности. Код 410 означает "удалено навсегда", и адреса с ним покидают индекс быстрее, чем с обычным 404. Красивая страница-ошибка - забота о людях: навигация, ссылки на популярные разделы, поиск. Поисковику всё равно на дизайн, ему нужен правильный код, поэтому кастомный шаблон обязан отдавать 404, а не 200.
Чтобы исправление не разъезжалось снова, контроль встраивают в релизный процесс. Простейший регламент: после каждого деплоя скрипт проверяет выборку заведомо несуществующих адресов и ждёт от них кода 404 или 410, а по выборке живых страниц ждёт 200. Пара строк в пайплайне предупреждает о регрессе раньше, чем отчёт консоли пополнится новыми мягкими ошибками.
Когда вместо ошибки нужен редирект 301 и оживление полезных страниц
Не каждая мягкая ошибка заслуживает код ошибки. Если у удалённого адреса есть живой преемник, ставят 301: на аналогичный товар, на категорию, на страницу замены. Пользователь не упирается в тупик, ссылочный вес переезжает, робот обновляет адрес в индексе. Бездумно сводить все удалённые адреса на главную не стоит - это раздражает людей и путает поисковик; редирект должен вести на осмысленную замену.
Про массовые удаления стоит сказать отдельно. Тысяча удалённых карточек не требует тысячи редиректов на карточки: разумнее вести старые адреса на ближайшие категории и оформлять это правилами, а не руками. Правило "удалённый товар ведёт на свою категорию" закрывает большинство ситуаций, а адреса без осмысленной замены честно отдают 410.
Ветка "страница должна работать" требует не кодов, а починки. Типичные работы: открыть роботу ресурсы в robots.txt, починить маршрутизацию в JavaScript-приложении так, чтобы несуществующий адрес получал реальный код ошибки на сервере, залатать оборванные инклуды и соединения с базой, ускорить медленные шаблоны. Во фреймворках для этого есть штатные механизмы отдачи ошибок, но они работают только когда серверная логика действительно возвращает ошибку, а не рендерит заглушку со статусом 200. Слишком лаконичную, но полезную страницу разумнее дополнить содержанием, чем бороться с меткой.
После исправлений запускают живой тест по паре адресов, убеждаются в правильном коде ответа, жмут "Запросить переобход" для приоритетных страниц и кнопку проверки исправления по статусу. Дальше остаётся наблюдение: пересмотр адресов занимает от нескольких дней до недель, и поспешные выводы на второй день после правок ничего не стоят. Мягкие ошибки в отчёте - не приговор сайту, а список конкретных адресов, где сервер обязан перестать врать: либо честным кодом, либо рабочей страницей, либо осмысленным редиректом.