HTTP-коды веб-страницы: что означают 200, 3xx, 404, 410, 429 и 5xx

HTTP-код — это не оценка качества страницы и не «SEO-статус». Он сообщает результат конкретного HTTP-запроса. Для обычной информационной страницы ожидаемым рабочим состоянием чаще всего будет 200 OK; при переносе URL нужен подходящий редирект; отсутствующий ресурс должен честно отвечать ошибкой; временная перегрузка сервера относится уже к другому классу состояний.Ошибки начинаются, когда код и фактическая ситуация расходятся. Страница не существует, но сервер возвращает 200. Материал перенесли, а старый URL отдаёт 404 вместо редиректа. Сервер перегружен, но CDN отвечает поисковому роботу постоянным 403. В каждом случае цифра формально существует, но интерпретировать её нужно вместе с тем, что произошло с ресурсом и что именно получил клиент.

Сначала: где HTTP-код находится в технической цепочке

До HTTP-ответа клиенту ещё нужно добраться до сервера: разобрать URL, разрешить доменное имя и установить соединение. Поэтому отсутствие ответа сервера и ответ с кодом 500 — разные типы проблемы.

Если нужно восстановить всю последовательность от адресной строки до HTML и рендеринга, она разобрана в материале «Что происходит после ввода URL: DNS, HTTPS, HTTP и HTML».

Здесь фокус уже уже: сервер получил запрос и сформировал HTTP-ответ. Нас интересует, что означает его статус и какие выводы из него делать нельзя.

Пять классов статусов — это карта, а не диагноз

HTTP использует трёхзначные status codes. Первая цифра задаёт общий класс ответа:

Класс	Общий смысл	Что чаще всего важно для веб-страницы
`1xx`	Информационный ответ	Промежуточное состояние протокола
`2xx`	Успешная обработка	Для обычного GET чаще всего ожидаем `200 OK`
`3xx`	Перенаправление или работа с кэшированной версией	Важно понимать временный или постоянный характер перехода
`4xx`	Ошибка на стороне запроса или недоступность ресурса	`401`, `403`, `404`, `410`, отдельно `429`
`5xx`	Серверная ошибка	`500`, `502`, `503` и другие временные или устойчивые сбои

Эта классификация помогает быстро понять направление диагностики. Но фраза «там 4xx» слишком грубая: 401 означает отсутствие подходящих учётных данных, 403 — отказ выполнить понятный запрос, а 404 — отсутствие текущего представления ресурса или нежелание сервера раскрывать его существование.

200 OK: запрос успешен, но на этом вывод заканчивается

По RFC 9110 код 200 OK означает, что запрос успешно выполнен. Для GET содержимое такого ответа представляет целевой ресурс.

Для обычной страницы это базовое состояние, но оно отвечает только на вопрос HTTP-уровня. Из 200 не следует, что:

страница обязательно попадёт в индекс;
контент соответствует поисковому интенту;
canonical выбран правильно;
в документе нет noindex;
JavaScript отрисовался без ошибок;
страница будет ранжироваться.

Google формулирует эту границу достаточно прямо: успешный ответ 2xx позволяет передать полученное содержимое на следующий этап обработки, но не гарантирует индексацию. Для 200 содержимое может попасть в indexing pipeline, а дальнейший результат зависит уже не от одного HTTP-кода.

Отсюда полезное правило диагностики: 200 — это «сервер успешно ответил», а не «со страницей всё хорошо».

204 No Content — успех без документа

204 No Content тоже относится к успешным ответам. Разница в том, что сервер сообщает об успешном выполнении запроса, но не передаёт содержимое ответа.

Для API, формы или операции сохранения такое поведение может быть совершенно нормальным. Для URL, от которого ожидается индексируемая информационная страница, смысл другой: Google прямо указывает, что при 204 содержимого для обработки нет.

Это хороший пример того, почему нельзя читать только первую цифру. И 200, и 204 относятся к 2xx, но для документа, который должен содержать страницу, их практический смысл различается.

3xx: сначала выясните, куда и зачем перенаправляют

Редиректы нужны, когда клиент должен продолжить работу с другим URL. На практике чаще встречаются 301, 302, 307 и 308.

Код	Смысл для HTTP	Как Google обычно интерпретирует направление
`301`	Moved Permanently	Постоянный redirect; сильный сигнал в пользу целевого URL
`302`	Found, обычно временный переход	Redirect выполняется, но сигнал в пользу целевого URL слабее
`307`	Temporary Redirect с сохранением метода	Для Google эквивалентен `302`
`308`	Permanent Redirect с сохранением метода	Для Google эквивалентен `301`

Важен не только сам код, но и конечная точка. Если URL проходит через несколько перенаправлений, диагностика должна сохранять всю цепочку. Googlebot для общего веб-контента обычно следует нескольким redirect hops, но наличие технического лимита не делает длинную цепочку хорошей архитектурой.

Выбор между постоянным и временным переносом, цепочки и конфликтующие сценарии вынесены в отдельную статью про редиректы при переносе страниц.

304 Not Modified — не ошибка и не пустая страница

304 Not Modified появляется в условных запросах к уже известному ресурсу. Его смысл — сообщить клиенту, что сохранённое представление можно использовать снова, потому что ресурс не изменился в рамках условий запроса.

Такой ответ нельзя трактовать как «сервер не отдал страницу». Он работает вместе с кэшем. RFC 9110 отдельно указывает, что 304 не содержит обычного response content, потому что клиент уже располагает подходящим представлением.

Для Google это тоже специальный случай: crawler сообщает следующему этапу обработки, что содержимое совпадает с предыдущим обходом.

401 и 403: ресурс может существовать, но быть недоступным

401 Unauthorized означает, что запрос не применён из-за отсутствия действующих credentials для целевого ресурса. Несмотря на привычное название кода, речь здесь именно об аутентификации.

403 Forbidden сообщает другую вещь: сервер понял запрос, но отказывается его выполнять. Причина может быть связана с правами доступа, сетевой политикой, WAF, CDN или иной серверной логикой.

Для публичной страницы, которую должен получать поисковый робот, постоянный 401 или 403 — не мелкая деталь. Google не использует содержимое URL, отвечающих обычными 4xx; уже проиндексированные URL при устойчивом состоянии со временем удаляются из индекса.

Есть тонкость: Google выделяет 429 отдельно. Поэтому фраза «любой 4xx одинаков» тоже неверна.

404 и 410: похожий результат для поиска, разная семантика протокола

404 Not Found означает, что сервер не нашёл текущего представления ресурса или не хочет сообщать о его существовании. Сам по себе 404 не говорит, временно исчез URL или навсегда.

410 Gone точнее: ресурс больше недоступен, и сервер считает это состояние, вероятно, постоянным. RFC 9110 рекомендует использовать 404, если сервер не знает, постоянна ли потеря ресурса.

Для Google Search большинство 4xx, кроме 429, обрабатываются сходно: содержимое ответа не используется для индексирования, а URL, который раньше был в индексе, со временем перестаёт использоваться. Поэтому выбирать 410 только в надежде на «особый SEO-бонус» нет смысла. Его ценность — в более точной HTTP-семантике.

Если страница действительно удалена и подходящей замены нет, Google рекомендует возвращать настоящий 404 или 410, а не маскировать отсутствие документа успешным ответом.

Soft 404: когда сервер говорит «всё хорошо», а страница показывает обратное

Soft 404 — это не отдельный HTTP-код. Это ситуация, когда URL формально отвечает успехом, часто 200, но содержимое выглядит как страница ошибки, пустой документ или материал без нормального основного контента.

Типичный сценарий:

GET /old-product
HTTP/1.1 200 OK

<h1>Товар не найден</h1>
<p>Такой страницы больше нет.</p>

Для HTTP запрос успешен. Для пользователя ресурс фактически отсутствует. Google может классифицировать такой URL как soft 404 и исключить его из Search.

Причины бывают не только редакционными. Google приводит среди примеров сбой server-side include, проблему с базой данных, пустую страницу результатов поиска или не загрузившийся JavaScript-файл. То есть soft 404 иногда маскирует уже не ошибку маршрута, а поломку самой страницы.

Здесь особенно полезно смотреть одновременно на три вещи: status code, фактический основной контент и ожидаемое состояние URL.

429 Too Many Requests: перегрузка или rate limiting — отдельный случай

429 Too Many Requests применяется, когда клиент отправляет слишком много запросов за определённый период. Сервер может добавить Retry-After, чтобы подсказать время следующей попытки.

Для Google этот код отличается от большинства других 4xx. Его crawlers воспринимают 429 как сигнал перегрузки сервера и обрабатывают как server error: обход временно замедляется.

Поэтому использовать 403 или 404 для намеренного ограничения Googlebot — плохая подмена смысла. В документации Google для временной перегрузки прямо упоминаются 500, 503 и 429.

5xx: сервер не смог нормально выполнить запрос

Класс 5xx означает серверную ошибку. Для сайта важны не только сами коды, но и продолжительность проблемы.

Частые варианты:

500 Internal Server Error — общий внутренний сбой сервера;
502 Bad Gateway — промежуточный сервер получил некорректный ответ от upstream;
503 Service Unavailable — сервис временно недоступен, например из-за перегрузки или обслуживания.

Google при 5xx и 429 временно снижает интенсивность обхода. Уже известные URL не исчезают из индекса мгновенно, но при устойчивых серверных ошибках могут быть удалены. Когда сервер снова стабильно отвечает 2xx, crawl rate постепенно восстанавливается.

Отсюда практический вывод для обслуживания: временная недоступность и постоянное отсутствие страницы — разные состояния. Возвращать 404 только потому, что backend сейчас перегружен, значит сообщать клиентам не то, что происходит на самом деле.

Код ответа нужно проверять на конечном URL и в цепочке

Одна из частых диагностических ошибок — открыть страницу в браузере, увидеть нормальный экран и считать проверку законченной. Браузер мог автоматически пройти редиректы и показать уже другой URL.

Полезнее фиксировать цепочку:

https://example.com/page
→ 301 https://www.example.com/page
→ 301 https://www.example.com/page/
→ 200 HTML

Так видно сразу несколько вещей: исходный URL не отдаёт документ, между ним и финальной страницей два перехода, а содержимое приходит только в последней точке.

То же относится к CDN и reverse proxy. Код, который кажется «ответом сайта», иногда формирует промежуточный слой, а приложение до запроса вообще не доходит. Поэтому для спорной ситуации полезно сохранять response headers вместе со статусом.

Диагностическая матрица: какое состояние считать нормальным

Ситуация	Ожидаемая логика ответа	Что проверить дальше
Обычная опубликованная HTML-страница	`200 OK` + реальный основной контент	Indexability, canonical, HTML/rendering
Страница навсегда переехала	Постоянный redirect на релевантный новый URL	Конечный статус, цепочку, внутренние ссылки
Переезд временный	Временный redirect	Не превратился ли временный сценарий в постоянный
Ресурс удалён без замены	`404` или при осознанно постоянном удалении `410`	Нет ли внутренних ссылок и sitemap-URL на удалённую страницу
Страница ошибки отвечает `200`	Проверить soft 404 и исправить код или содержимое	Почему сервер считает ошибочный документ успешным
Сервис временно перегружен	Подходящий временный server/rate-limit status	Продолжительность, Retry-After, источник перегрузки
Публичная страница отвечает `401`/`403`	Проверить, действительно ли доступ должен быть закрыт	WAF, CDN, authentication, IP/user-agent rules

Матрица не заменяет HTTP-спецификацию. Она нужна, чтобы быстро проверить соответствие между состоянием ресурса и тем, что сервер сообщает наружу.

Почему проверка HTTP-кода — только один этап технической готовности

После корректного ответа остаются другие уровни: доступ поискового робота, директивы индексирования, canonical, основной HTML-контент, JavaScript и внутренняя связность. Именно поэтому проверка одного 200 OK не заменяет технический контроль целевой страницы целиком.

Для страницы, которую собираются активно продвигать, эти проверки удобнее рассматривать вместе — как единый pre-publish и pre-promotion gate технической готовности.

HTTP здесь остаётся первым понятным фильтром: если сервер уже на этом уровне сообщает не то состояние, которое мы ожидаем от документа, переходить к более сложным объяснениям рано.

Источники

Источники проверены 19 августа 2026 года. Для семантики HTTP использованы стандарты IETF; для обработки ответов Google — официальная документация Google.