Код 404 при живом контенте: сайт виден людям, но не поисковикам
Аудит показал, что страницы отдают код 404, хотя они открываются и контент на месте? Для посетителя сайт работает, а для поисковика этих страниц не существует: Google и Яндекс смотрят на HTTP-код ответа, а не на то, что видно на экране. Разберём, откуда это берётся и как вернуть страницы в индекс.
- Браузер показывает страницу по содержимому, поисковик — по коду ответа
- Код 404 при живом контенте = «страница есть для людей, но не существует для поиска»
- Проверяется одной командой — curl -I: смотрите первую строку ответа
- Причины: маршрутизация CMS, кривые редиректы, «умные» страницы ошибок, защита хостинга
- После фикса — переобход в Search Console и Вебмастере, страницы возвращаются в индекс
Код ответа и содержимое — это разные вещи
Каждый ответ сервера состоит из двух частей: HTTP-статуса (200 OK, 301, 404, 500…) и тела — самого HTML. Это независимые вещи. Браузер устроен просто: получил тело — отрисовал его, какой бы код ни пришёл. Поэтому страница с кодом 404 и полным HTML внутри выглядит для человека абсолютно нормальной.
Поисковый робот работает иначе. Первым делом он читает код. Видит 200 OK — страница существует, её можно индексировать. Видит 404 Not Found — страницы нет, индексировать нечего, а если она уже была в индексе, её нужно оттуда убрать. И Google, и Яндекс здесь ведут себя одинаково — ориентируются на код, а содержимое при 404 просто игнорируют. Так и получается парадокс: страница одновременно живая для посетителей и несуществующая для поиска.
Почему это критично: разделы исчезают из выдачи
Коварство в том, что визуально всё хорошо. Сайт открывается, кнопки работают, заявки идут — с прямых заходов, из рекламы, из закладок. А органического трафика почти нет, и владелец не понимает почему: «сайт же работает».
Один из наших кейсов: у салона красоты в Минске 19 из 20 страниц — услуги, цены, контакты, онлайн-запись — отдавали код 404 при полностью живом контенте. В поиске существовала только главная. Для Google и Яндекса весь остальной сайт просто не существовал, сколько бы ссылок на него ни вело. Пока проблема не была найдена, любые вложения в продвижение уходили в пустоту: нельзя ранжировать страницу, которой для поисковика нет.
Откуда берётся 404 при живом контенте
Причина почти всегда техническая и находится на стороне сервера или CMS. Вот четыре типичных источника.
- Маршрутизация CMS. Роутер находит нужную страницу и рендерит её, но статус проставляет как «не найдено». Частая болезнь после переезда, редизайна или ручных правок роутера, а также «умных» шаблонов страницы ошибок, которые перехватывают всё подряд;
- Обработчик ошибок наоборот. Error-handler на 404 подставляет контент ближайшей страницы или общего шаблона вместо честной страницы ошибки. Пользователь видит осмысленный контент — и проблема маскируется, её замечают не сразу;
- Правила редиректов сервера (nginx, Apache,
.htaccess). Цепочки вроде «URL со слэшем → 301 → URL без слэша → 404», конфликтующие правила после переезда на HTTPS или смены структуры. Финал цепочки отдаёт 404, хотя страница по адресу есть; - Хостинг или защита. Антибот-защита, WAF или лимиты хостинга иногда отдают код 4xx в ответ роботу на легитимные страницы — особенно при частом обходе.
Как проверить ответ сервера
Главное правило: браузером эту проблему не поймать — он покажет страницу при любом коде. Смотреть нужно именно на HTTP-статус.
- Команда
curl -I— смотрите первую строку ответа:200— всё в порядке,404или другой 4xx/5xx — проблема подтверждена - Онлайн-проверка — в Яндекс Вебмастере есть инструмент «Проверка ответа сервера»; массово, по всем страницам сразу, ситуацию ловит наш SEO-аудит
- Google Search Console — отчёт «Индексирование страниц» → группа «Не найдено (404)»: там будут ваши живые URL, если они отдают 404
- Яндекс Вебмастер — «Страницы в поиске» → исключённые: страницы с кодом 4xx выпадают из поиска и попадают сюда
Как исправить
Лечение зависит от того, где именно теряется код, но логика одна — вернуть живым страницам честный 200 OK.
- CMS (WordPress, Bitrix, MODX и другие): проверьте настройки ЧПУ и маршрутизации, пересохраните структуру постоянных ссылок (в WordPress — «Настройки → Постоянные ссылки → Сохранить»), отключите конфликтующие плагины «умных 404» и кастомные страницы ошибок;
- Сервер (nginx, Apache): ревизия правил редиректов, уберите циклы «слэш / без слэша», настройте
error_pageтак, чтобы 404 отдавался только для реально несуществующих URL; - Хостинг и защита: если 4xx отдаёт WAF или антибот-система — добавьте роботов Google и Яндекса в исключения и снимите избыточные лимиты на обход.
Отдельная история — страницы, которые закрыты от индексации намеренно. Если часть URL и должна быть недоступна поиску, это делается не кодом 404, а корректными инструкциями: об этом — в гайде про управление индексацией через robots.txt, sitemap и noindex.
После правки отправьте затронутые страницы на переобход в Google Search Console и Яндекс Вебмастере. Возврат в индекс обычно занимает от нескольких дней до 2–3 недель — зависит от того, как часто робот обходит сайт.
Что дальше
Проверьте ключевые страницы сайта командой curl -I — главную, услуги, категории, карточки. Если хотя бы часть отдаёт не 200, вы теряете эти разделы в поиске прямо сейчас, и никакое продвижение это не компенсирует, пока код не исправлен.
Хотите увидеть коды ответа по всем страницам сайта сразу — с пометкой, где именно живой контент отдаёт 404? Закажите SEO-аудит: наш AI-аудитор проверяет ответ каждой страницы автоматически и ловит эту ошибку одной из первых, а заодно смотрит скорость, метатеги и видимость сайта в ИИ-поиске.
Коротко о коде 404 при живом контенте
Страница открывается в браузере — значит, всё в порядке? +
curl -I.Чем это отличается от soft 404? +
Как быстро страницы вернутся в индекс после исправления? +
Может ли это быть из-за хостинга или защиты от ботов? +
Сколько страниц вашего сайта невидимы для поиска?
Закажите SEO-аудит — проверим код ответа каждой страницы и покажем, где живой контент отдаёт 404, а заодно скорость, метатеги, разметку и видимость сайта в ИИ-ответах.