Ошибка 404, 410 и soft 404: как работать с удалёнными страницами
Вредит ли 404 ранжированию, когда нужен 410, чем опасен soft 404 и что делать с удалённой страницей — редирект...
Читать
HTTP-код состояния — это трёхзначное число, которое сервер возвращает в ответ на каждый запрос. Для SEO это число значит не меньше, чем текст на странице: именно по нему Google решает, индексировать ли страницу, переходить ли по редиректу, вернуться позже или убрать URL из индекса.
Самое частое заблуждение: «страница открывается в браузере, значит всё в порядке». Страница может выглядеть идеально и при этом не индексироваться или склеиваться с неправильным каноническим URL — только из-за кода, который сервер отдал первым.
Когда браузер или поисковый робот запрашивает страницу, сервер возвращает две вещи: код состояния и содержимое. Код — часть протокола HTTP (описан в RFC 9110) — сообщает судьбу запроса: успех, переезд, не найдено или сбой сервера.
Документация Google формулирует это прямо: коды состояния «генерируются сервером, на котором размещён сайт, когда он отвечает на запрос клиента — например браузера или поискового робота».
Главная мысль для SEO: код — самостоятельный сигнал, отдельный от содержимого. Google сначала читает код и, если код говорит иное, до содержимого может не дойти вовсе.
200 OK — код, который должна отдавать каждая страница, предназначенная для индексации. По формулировке Google, при этом коде «Google рассматривает контент для обработки».
Но важно: 200 необходим, но недостаточен. Google может не индексировать страницу с кодом 200 из-за качества, дублирования и других причин. Ответ на вопрос «страница отдаёт 200, почему её нет в индексе?» обычно лежит в контенте, а не в коде — это тема семантического SEO и критериев полезного контента.
Есть ещё 204 No Content — успешный ответ с пустым телом. Индексировать нечего, поэтому такие страницы на практике могут расцениваться как soft 404.
Это самая недопонятая часть темы. Документация Google формулирует различие открыто:
То есть 302 «не передаёт ничего» — неверная формулировка: сигнал просто слабый, и исходный URL может продолжать появляться в выдаче. Использовать 302 для действительно постоянного переезда — классическая ошибка настройки.
Google также задаёт лимит: по умолчанию его роботы проходят до 10 переходов редиректа. Более длинные цепочки бросаются.
Все детали этого семейства — какой способ когда работает, переезд домена, цепочки и петли — вынесены в отдельный материал: разница между 301 и 302.
В это же семейство входит 304 Not Modified — сигнал кеширования о том, что сохранённая копия актуальна. На ранжирование напрямую не влияет, но помогает эффективному сканированию крупных сайтов.
Страница не отдаётся из-за проблемы на стороне запроса: её нет, она запрещена или закрыта для этого клиента.
| Код | Значение | Как ведёт себя Google |
|---|---|---|
| 401 | Требуется авторизация | Контент не используется; на скорость сканирования не влияет |
| 403 | Запрещено | То же — контент невиден, сканирование не замедляется |
| 404 | Не найдено | Проиндексированный URL со временем удаляется; новые 404 не обрабатываются |
| 410 | Удалено (Gone) | Практически тот же результат, что и 404 |
| 429 | Слишком много запросов | Исключение: трактуется как перегрузка сервера, сканирование замедляется |
Отсюда два практических вывода.
Первый: замедлить Googlebot через 401/403 не получится — эти коды на скорость сканирования не влияют, они лишь делают контент невидимым.
Второй: сам по себе 404 не наказание. Риск в другом — вы теряете трафик страницы и входящие на неё ссылки, а в массовом случае впустую расходуете краулинговый бюджет. Подробности: 404, 410 и soft 404.
Запрос был корректным, но сервер не смог его выполнить: 500 (внутренняя ошибка), 502 (bad gateway), 503 (сервис недоступен), 504 (gateway timeout).
Ключевой факт для SEO: это не приводит к мгновенной деиндексации. По документации Google, ошибки 5xx и 429 заставляют роботов временно замедлиться, причём снижение скорости сканирования пропорционально числу URL, отдающих ошибку. Когда сервер снова начинает отвечать кодом 2xx, Google постепенно повышает скорость.
То есть короткий сбой — не катастрофа. А вот длительные ошибки 5xx в итоге приводят к выпадению контента из индекса.
Для планового обслуживания правильный код — 503, а не сломанный 200 и не редирект на временную страницу: в первом случае Google проиндексирует не тот контент, во втором — использует редирект для индексации.
За кодами стоят два разных вопроса:
| Вопрос | Что говорит код |
|---|---|
| Сканировать ли это? | 5xx и 429: «замедлись, зайди позже». 3xx: «иди туда». Остальные 4xx на скорость сканирования не влияют |
| Индексировать ли и под каким URL? | 2xx: кандидат. 4xx: убрать. 301/308: склеить с целью (сильный сигнал). 302/307: слабый сигнал |
Единственное, что ломает эту модель, — случай, когда код и содержимое противоречат друг другу.
Soft 404 — страница, которая отдаёт 200, но её содержимое говорит «такого нет»: пустой результат, сообщение «товар не найден» или фантомная страница из-за неверной настройки CMS.
Google выявляет проблему не на уровне кода, а на уровне содержимого, и помечает такие страницы в Search Console. Руководство Google по краулинговому бюджету для крупных сайтов формулирует это прямо: «страницы soft 404 продолжают сканироваться и расходуют ваш бюджет».
Типичные источники: сайты на JavaScript, отдающие 200 для несуществующих маршрутов; пустые страницы результатов в каталогах с фильтрами; удалённые товары, тихо превращённые в страницу «похожие товары».
Решение простое: код должен соответствовать реальности. Страницы нет — отдавайте 404 (или 410), чтобы Google смог аккуратно убрать URL.
В браузере: DevTools → вкладка Network → обновите страницу → кликните по первому (document) запросу → колонка Status.
В терминале:
# только заголовки (один запрос)
curl -I https://example.com/stranica
# пройти всю цепочку редиректов
curl -IL https://example.com/staraya-stranica
# проверить, представившись Googlebot
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/stranica
Search Console: инструмент проверки URL показывает статус, который увидел Google, — самый надёжный источник, потому что браузер и Googlebot могут видеть разное.
1. Перенаправлять все 404 на главную. Это создаёт нерелевантные редиректы и часто расценивается как soft 404. Есть подходящая страница — редиректьте; нет — отдавайте 404.
2. Отдавать 200 во время техработ. Если страница «сайт на обслуживании» приходит с кодом 200, Google проиндексирует именно её.
3. Оставлять 302 на постоянном переезде. Сигнал канонизации остаётся слабым, старый URL продолжает мелькать в выдаче.
4. Длинные цепочки редиректов. Цепочки длиннее 10 переходов бросаются, и каждый переход стоит скорости.
5. Пытаться «управлять» роботами через 403. Скорость сканирования не изменится, контент просто станет невидимым.
Код 200 не гарантирует индексацию. Причина обычно в качестве контента, дублировании, выборе канонического URL или нехватке внутренних ссылок. Смотрите ярлык причины в отчёте «Страницы» в Search Console.
Сам по себе 404 — не наказание: Google не использует контент URL с кодами 4xx и со временем убирает такие URL из индекса. Реальная потеря в другом: трафик страницы, входящие внешние ссылки и — в массовом случае — краулинговый бюджет.
При коротком сбое Google просто замедляет сканирование и постепенно восстанавливает скорость после возврата 2xx. Длительные ошибки 5xx в итоге приводят к выпадению контента — поэтому 503 стоит мерить часами, а не неделями.
С точки зрения SEO оба — постоянные редиректы с одинаково сильным сигналом. Техническое отличие в сохранении метода запроса: 308 оставляет исходный метод (POST остаётся POST).
Совместите два источника: проверку URL в Search Console (что увидел Google) и логи сервера (история реальных запросов). Браузер и онлайн-чекеры быстры, но дают лишь одну точку данных.
Вредит ли 404 ранжированию, когда нужен 410, чем опасен soft 404 и что делать с удалённой страницей — редирект...
Читать
Разница между кодами 301, 302, 307 и 308, различие сильного и слабого сигнала у Google, способы редиректа, цеп...
Читать
Как связать сущности через JSON-LD: ссылки @id, структура @graph, подтверждение sameAs, поля Organization, пра...
Читать