HTTP-коды ответа и SEO: как настроить 200, 301, 404, 410 и 5xx

Как выбрать HTTP-код по судьбе URL, найти мягкие 404, проверить редиректы и согласовать ответы сервера с canonical, ссылками и sitemap.

SEO-специалист проверяет маршруты сайта и статусы ответов сервера

Короткий ответ: код ответа должен честно описывать судьбу URL. Рабочая страница возвращает 200, окончательно перенесённая — 301 на равноценный новый адрес, временно перенесённая — 302 или 307, удалённая без замены — 404 или 410, временно недоступная из-за работ — 503. Красивый экран ошибки с кодом 200 остаётся ошибкой: поисковик видит противоречие между ответом сервера и содержимым.

Поэтому проверять нужно не только то, что показал браузер. Важны первый ответ сервера, заголовок Location, вся цепочка переходов, код конечной страницы, её содержимое, canonical, внутренние ссылки и sitemap.

Что HTTP-код сообщает поисковику

HTTP-код — это технический статус запроса. Он отвечает на простой вопрос: что сейчас происходит с конкретным адресом? Документ существует, переехал, удалён или временно недоступен.

Содержание страницы не заменяет корректный статус. Если полезная статья отдаёт 404, она технически считается отсутствующей. Если по вымышленному адресу открывается шаблон «ничего не найдено», но сервер отвечает 200, возникает мягкая 404. Если приложение сломалось, а аварийный экран отдаётся с 200, мониторинг может не заметить сбой, а робот получит вместо документа страницу ошибки.

Какой код выбрать

200 OK — документ существует

Возвращайте 200, когда по адресу действительно есть самостоятельная полезная страница: услуга, статья, категория, карточка или контакты. URL, title, H1, canonical и содержание должны описывать один и тот же документ.

Типичная проблема — мягкая 404. Так бывает, когда карточка удалена, поиск ничего не нашёл или параметр некорректен, но маршрутизатор всё равно показывает общий шаблон с кодом 200. Не ориентируйтесь только на дизайн: запросите заведомо вымышленный URL и проверьте фактический статус.

301 — постоянный перенос

301 нужен, когда старый адрес больше не используется, а на сайте есть постоянная и близкая по смыслу замена. Например, изменилась структура URL, объединены дубли или две старые страницы услуг заменены одной полноценной.

Редирект должен вести сразу на конечную страницу. Цепочка старый URL → промежуточный → новый → версия со слешем усложняет обход и диагностику. После переноса замените внутренние ссылки, canonical и адреса в sitemap: сайт не должен постоянно ходить через собственные редиректы.

Не отправляйте все удалённые страницы на главную. Она редко является равноценной заменой карточке, статье или услуге. Подготовку карты соответствий и проверку цепочек я отдельно разобрал в материале про редиректы при переезде сайта.

302 и 307 — временный перенос

Временный редирект подходит, если исходный URL планируется вернуть: например, на время короткого эксперимента или технического переключения. Для обычного постоянного переезда нужен 301.

307 требует сохранить метод запроса. В SEO-задаче сначала ответьте на главный вопрос: исходный адрес вернётся или перенос окончательный?

404 — страницы нет

404 — нормальный ответ для опечатки, неизвестного идентификатора и удалённой страницы без замены. Само наличие таких ответов не вредит сайту. Исправлять нужно внутренние ссылки на 404, пропавшие важные страницы и ошибочные URL в sitemap.

Страница 404 может содержать меню и ссылки на полезные разделы, но её статус должен оставаться 404. Найти внутренние переходы на отсутствующие документы поможет инструкция про битые ссылки на сайте.

410 — ресурс удалён окончательно

410 уместен, когда вы точно знаете: URL существовал, его осознанно удалили и возвращать не будут. Например, закрыли ошибочно созданный раздел или большую группу спамных страниц.

Необязательно переводить каждое удаление на 410. Если система надёжно возвращает 404, этого обычно достаточно. Важнее убрать адрес из ссылок и sitemap.

500, 502, 503 и 504 — сервер не справился

5xx означает проблему на стороне сайта. 500 — внутренняя ошибка приложения, 502 — некорректный ответ вышестоящего сервиса, 504 — превышение времени ожидания шлюза. Для плановых работ обычно используют 503 Service Unavailable. Если срок восстановления известен, можно добавить Retry-After.

Не заменяйте 503 страницей «ведутся работы» с кодом 200 и не возвращайте 404 для всех документов из-за недоступной базы. Короткая единичная ошибка не равна катастрофе, но массовые или длительные 5xx мешают пользователям и обходу. Для расследования сопоставьте время сбоя с логами прокси, приложения и базы; базовый подход есть в статье про серверные логи для SEO.

Решение за четыре вопроса

Перед настройкой любого URL ответьте:

  1. Есть ли по адресу полезный документ прямо сейчас?
  2. Если нет, существует ли постоянная равноценная замена?
  3. Если замены нет, удаление окончательное или сбой временный?
  4. Согласованы ли код, содержимое, canonical, внутренние ссылки и sitemap?

Если документ существует — 200. Если навсегда переехал на релевантный адрес — 301. Если исходный URL скоро вернётся — 302 или 307. Если страницы нет и замены нет — 404 либо осмысленно выбранный 410. Если страница должна работать, но инфраструктура временно не справляется, — 5xx, а при плановых работах обычно 503.

Не выбирайте код ради желаемого результата в индексе. 301 — не команда «передать вес куда угодно», а 404 — не повод маскировать отсутствие документа.

Пошаговая проверка кодов ответа

Шаг 1. Соберите разные типы URL

Возьмите услуги, категории, карточки, пагинацию, фильтры, URL с параметрами, старые адреса, удалённые объекты и вымышленный путь. На большом сайте сгруппируйте их по шаблонам.

Источники: sitemap, выгрузка CMS, внутренний обход, аналитика, серверные логи и таблица редиректов. Один источник не показывает всю картину: sitemap не найдёт бесконечные параметры, а краулер не увидит старый URL, на который ведут только внешние ссылки.

Шаг 2. Посмотрите первый ответ и цепочку

Сначала проверяйте исходный адрес без автоматического перехода, затем всю цепочку. Например:

curl -I https://example.ru/old-page/
curl -IL https://example.ru/old-page/

Некоторые приложения неверно обрабатывают HEAD, поэтому спорный результат повторите GET-запросом. При переносе старый адрес должен отдать 301 с корректным Location, конечный — 200 и self-canonical.

Шаг 3. Сопоставьте статус и содержимое

Откройте тело ответа для каждого шаблона. Страница с 200 должна содержать заявленный документ, 404 — понятное сообщение об отсутствии, 503 — сообщение о временной недоступности. Проверьте исходный HTML и отрисованную версию, если сайт зависит от JavaScript.

Шаг 4. Сверьте остальные сигналы

Индексируемый URL с 200 обычно должен иметь self-canonical и присутствовать в sitemap, если это важная страница. Адресам с 301, 404, 410 и 5xx в карте сайта не место. Внутренние ссылки должны вести сразу на конечные страницы с 200.

Canonical не исправляет неверный код. Связь статусов, карты сайта и директив подробнее разобрана в гайде про sitemap, robots.txt и canonical.

Шаг 5. Проверьте граничные случаи

Добавьте и уберите завершающий слеш, смените регистр, подставьте неизвестный ID, пустое значение и несуществующую страницу пагинации. Сайт не должен создавать бесконечное пространство бессмысленных URL с 200.

Шаг 6. Закрепите правила мониторингом

Составьте таблицу: шаблон URL, ожидаемый статус, допустимый редирект, тестовый адрес и ответственный модуль. После релиза автоматически проверяйте хотя бы ключевые страницы, циклы, смену 200 на 404/5xx и редиректы на неожиданный домен.

Практический сценарий: объединение услуг

Компания объединяет три услуги в одну комплексную. Две старые страницы полностью покрываются новой: для них настраивают прямые 301, меняют ссылки в меню и статьях, удаляют прежние URL из sitemap. Новая страница отвечает 200 и содержит self-canonical.

Третья услуга закрыта и по смыслу не входит в новую. Редирект на общий раздел ввёл бы посетителя в заблуждение, поэтому старый URL возвращает 404 или 410. Внутренние ссылки на него убирают контекстно.

Во время выкладки база несколько минут недоступна. Прокси возвращает 503, а не 200 с пустым шаблоном и не массовый 404. После восстановления проверка подтверждает: новая услуга — 200, два старых адреса — прямые 301, закрытая услуга — выбранный код удаления.

Ограничения проверки

  • HEAD и GET иногда обрабатываются по-разному, поэтому спорный результат нужно перепроверять.
  • CDN и кэш могут временно отдавать старый статус после изменения правил.
  • Код сам по себе не доказывает качество или релевантность страницы: 200 может возвращать слабый либо пустой документ.
  • Для большого сайта выборочная проверка не заменяет обход по всем шаблонам и анализ логов.

Частые ошибки

  • Все неизвестные URL отвечают 200 и превращаются в мягкие 404.
  • Любое удаление ведёт на главную, даже если она не заменяет документ.
  • Старые правила образуют цепочки или циклы редиректов.
  • Внутренние ссылки продолжают вести через 301.
  • Дизайн 404 есть, но сервер возвращает 200.
  • Экран технических работ маскируется кодом 200.
  • Удалённые и перенесённые адреса остаются в sitemap.
  • Проверяется только финальная страница, поэтому первый статус скрыт.
  • Canonical используют вместо редиректа.

Чек-лист перед выпуском

  • [ ] Важные страницы возвращают 200 и полезное содержимое.
  • [ ] Вымышленный URL возвращает 404, а не общий шаблон с 200.
  • [ ] Постоянные переезды ведут прямым 301 на релевантный финальный адрес.
  • [ ] Временный редирект стоит только там, где исходная страница вернётся.
  • [ ] Удалённые страницы без замены отвечают 404 или обоснованным 410.
  • [ ] Плановые работы возвращают 503; при необходимости задан Retry-After.
  • [ ] Нет циклов и лишних цепочек.
  • [ ] Внутренние ссылки, canonical и sitemap ведут на URL с 200.
  • [ ] Адреса с 301, 404, 410 и 5xx убраны из sitemap.
  • [ ] Проверены слеши, регистр, параметры, ID и пагинация.
  • [ ] После изменений выполнен обход и просмотрены серверные логи.
  • [ ] Для ключевых шаблонов настроен мониторинг.

Если адресов много, в XelaGroup можно подготовить классификацию URL и черновик проверочного сценария. Но финальное решение принимайте по назначению страницы и реальному ответу сервера. Если нужен разбор конкретного сайта и карты редиректов, напишите мне в Telegram.

FAQ

Вредят ли 404 продвижению сайта?

Нет, корректный 404 для несуществующего адреса — нормальное поведение. Проблема возникает, когда 404 получают важные страницы, внутренние ссылки или URL из sitemap.

Нужно ли перенаправлять каждую удалённую страницу?

Нет. 301 ставят только при наличии постоянной релевантной замены. Если её нет, честнее вернуть 404 или 410.

Чем мягкая 404 отличается от обычной?

Обычная 404 возвращает код 404. При мягкой 404 полезного документа нет, но сервер отвечает 200 или перенаправляет на нерелевантную страницу.

Когда выбирать 410 вместо 404?

Когда удаление заведомо окончательное и это правило удобно поддерживать. Если отдельная настройка усложняет систему, корректного 404 обычно достаточно.

Какой код нужен на время технических работ?

Обычно 503 Service Unavailable. Если известен срок восстановления, добавьте Retry-After, а после работ убедитесь, что страницы снова отвечают 200.

Можно ли оставить 301 надолго?

Да. Старые публичные адреса разумно поддерживать, если на них ведут внешние ссылки или сохранённые закладки. При этом ссылки внутри сайта и sitemap должны вести прямо на новый URL.

Почему браузер открывает страницу, а проверка видит ошибку?

Браузер мог автоматически пройти редирект, показать кэш или дорисовать интерфейс JavaScript. Проверяйте отдельно первый ответ, цепочку переходов и конечный HTML.