Разбираем редко обсуждаемые HTTP-статусы: 304 Not Modified, 429 Too Many Requests и 451 Unavailable For Legal Reasons. Как они влияют на краулинговый бюджет, индексацию и позиции сайта в Яндексе.
Введение
Ошибка 404 — знакома каждому. Пятьсотую видели все. Про 301 и 302 написаны тома. Но есть коды состояния HTTP, которые живут в тени своих популярных собратьев. Они редко попадаются на глаза, их не подсвечивают типовые аудиты, о них молчат базовые руководства по SEO. А между тем именно они способны незаметно подтачивать позиции сайта, съедать краулинговый бюджет и создавать ситуации, когда страницы выпадают из индекса без видимых причин. Речь о трёх статусах: 304 Not Modified, 429 Too Many Requests и 451 Unavailable For Legal Reasons. Первый — тихий трудяга, который при правильной настройке экономит ресурсы, а при неправильной — вводит робота в заблуждение. Второй — крик сервера о помощи, который робот Яндекса слышит, но интерпретирует по-своему. Третий — редкий гость, означающий, что ваш контент столкнулся с государственным регулированием. В этой статье мы разберём каждый из этих трёх кодов: как они работают, при каких условиях возникают, как их правильно настраивать и интерпретировать, и главное — как их появление влияет на индексацию и позиции в Яндексе.
304 Not Modified: невидимый страж кеша
Код 304 — это, пожалуй, самый тихий и незаметный из всех HTTP-статусов. Браузер или поисковый робот запрашивает страницу и добавляет к запросу заголовок с датой прошлого получения или с ETag-меткой. Сервер смотрит: контент не менялся. Вместо того чтобы гнать по сети всё содержимое страницы заново, он отвечает коротко: 304 Not Modified, и тело ответа пустое. Клиент достаёт копию из своего кеша и показывает пользователю. С точки зрения SEO это обоюдоострый меч. С одной стороны, 304 — это благословение. Робот Яндекса, получая 304, не тратит время на скачивание мегабайта неизменившегося контента. Он переходит к следующей странице, и краулинговый бюджет расходуется эффективнее. Сайт, который грамотно настроил условные запросы и отдаёт 304 на статику и редко обновляемые страницы, обходится роботом быстрее и полнее. С другой стороны, есть риск. Если сервер настроен некорректно и отдаёт 304 на страницу, контент которой на самом деле изменился, робот останется со старой копией. Новая информация не попадёт в индекс до тех пор, пока не истечёт срок кеша или пока робот не запросит страницу без условных заголовков.
Как робот Яндекса работает с кодом 304
Яндекс в своей документации прямо указывает, что его поисковый робот поддерживает условные GET-запросы с заголовками If-Modified-Since и If-None-Match. Это означает, что при повторном обходе страницы бот может отправить дату предыдущего обхода или ETag и получить в ответ 304, если ничего не поменялось. Для SEO-специалиста это означает три важных вывода. Вывод первый: страницы, которые отдают корректный 304, не будут переиндексированы, но и не выпадут из индекса. Яндекс считает их актуальными и оставляет в выдаче на прежних позициях. Вывод второй: если страница изменилась, а сервер по ошибке отдал 304, это равносильно тому, что вы запретили роботу видеть новую версию. Проверяйте корректность ETag и Last-Modified, особенно после ручных правок файлов на сервере. Вывод третий: если сервер вообще не поддерживает условные запросы и на каждый повторный обход отдаёт полный контент с кодом 200, это не страшно для маленького сайта, но для большого проекта означает неэффективный расход краулингового бюджета. Робот будет перекачивать одни и те же страницы, не добираясь до новых.
Диагностика: проверяем, отдаёт ли сервер 304
Проверить поддержку 304 можно за минуту через консоль. Выполняем первый запрос к странице, сохраняя заголовки: curl -I https://vash-sait.ru/stranica. В ответе находим Last-Modified или ETag. Копируем значение Last-Modified. Делаем второй запрос, добавляя сохранённую дату: curl -I -H "If-Modified-Since: Thu, 01 Jan 2026 12:00:00 GMT" https://vash-sait.ru/stranica. Если сервер отвечает HTTP/1.1 304 Not Modified — условные запросы работают. Если приходит 200 с полным телом — сервер игнорирует заголовки, и кеширование через условные запросы не настроено. Настройка выполняется на уровне веб-сервера. В nginx за это отвечают директивы etag on и if_modified_since. Если etag выключен, а if_modified_since установлен в off, сервер будет игнорировать условные заголовки и всегда отдавать 200. Для статики это плохо — бот будет перекачивать неизменные файлы. Для HTML-страниц это допустимо, если контент обновляется часто и вы хотите, чтобы бот всегда получал свежую копию.
429 Too Many Requests: когда сервер просит пощады
Код 429 — это официальный способ сервера сказать: «Вы меня завалили запросами, притормозите». Он возникает, когда клиент превышает установленный лимит частоты запросов. В контексте SEO этот код появляется в двух типичных ситуациях. Ситуация первая: робот Яндекса слишком агрессивно обходит сайт. Сервер не справляется, начинает отвечать 429, и робот, если он корректно реализован, должен снизить темп. Ситуация вторая: владелец сайта настроил ограничение частоты запросов для защиты от DDoS или парсинга, но сделал это слишком жёстко, и под раздачу попал легитимный поисковый бот. Последствия для SEO зависят от того, как долго и как часто сервер отвечает 429. Если это единичный эпизод, робот Яндекса, согласно документации, воспринимает 429 как временную ошибку и планирует повторный обход позже. Страница не выпадает из индекса. Но если 429 ошибки становятся регулярными, робот может снизить частоту обхода сайта в целом, что замедлит индексацию новых страниц и обновление существующих.
Как найти и исправить проблему с 429
Первый признак того, что 429 мешает индексации — необъяснимое замедление обхода сайта роботом. Вы публикуете новые страницы, а они индексируются с задержкой в неделю вместо обычных суток. Заходите в логи сервера и ищете строки с кодом 429 в комбинации с User-Agent Яндекса. Если таких строк десятки в день — робот упирается в ограничение частоты. Решений три. Первое: увеличить лимит запросов для User-Agent Яндекса. В конфигурации nginx это делается через директиву limit_req, где для ботов можно задать отдельную, более высокую квоту. Второе: отключить ограничение частоты для IP-диапазонов Яндекса. Список диапазонов публикуется в справке Вебмастера и обновляется. Добавьте эти IP в белый список, и бот Яндекса будет обходить сайт без ограничений. Третье: если сервер физически не справляется с нагрузкой от ботов, ограничения снимать нельзя — сервер ляжет. В этом случае нужно оптимизировать производительность сайта или сменить тариф хостинга на более мощный. Временная мера — вручную ограничить скорость обхода в настройках Яндекс.Вебмастера, чтобы снизить нагрузку контролируемо, а не через 429.
451 Unavailable For Legal Reasons: когда закон вмешивается в SEO
Самый редкий и самый тревожный из трёх кодов. HTTP 451 был утверждён как стандарт относительно недавно, и его название отсылает к роману Рэя Брэдбери «451 градус по Фаренгейту». Код означает: «Контент недоступен по юридическим причинам». Проще говоря, страница заблокирована по требованию государственных органов. В России это может быть решение Роскомнадзора о блокировке страницы, внесённой в реестр запрещённой информации. В отличие от 403 Forbidden, который может быть вызван внутренними правилами сервера, 451 — это сигнал о внешнем юридическом принуждении. Для SEO 451 — это однозначный сигнал к немедленному действию. Яндекс, получая 451 при обходе страницы, исключает её из поисковой выдачи. Это не временная ошибка, как 503, это постоянное исключение, пока причина блокировки не будет устранена. Если 451 получает главная страница или важный раздел — это катастрофа для трафика.
Что делать, если сайт начал отдавать 451
Первое: не паниковать, а проверить факт блокировки. Зайдите на сайт через разные сети и разных операторов. Иногда блокировка может быть частичной — только у определённого провайдера. Проверьте сайт через сервис проверки доступности от Роскомнадзора — официальный реестр покажет, внесён ли ваш домен или конкретная страница в список заблокированных. Второе: если блокировка подтверждена, выясните причину. Возможно, на странице размещён контент, нарушающий законодательство. Удалите противоправный контент и подайте заявку на разблокировку через портал Роскомнадзора. Третье: пока идёт процесс разблокировки, настройте сервер так, чтобы для робота Яндекса заблокированная страница временно отдавала код 503 с заголовком Retry-After. Это скажет роботу «скоро всё починим, зайди попозже», и страница может остаться в индексе с пометкой о временной недоступности. Но этот метод этически спорный и работает не всегда — если блокировка на уровне провайдера, ваш сервер вообще не получит запрос от бота. Четвёртое: если блокировка затронула только одну страницу из многих, настройте 301 редирект с заблокированного URL на живой, если это уместно по смыслу. Но не перенаправляйте на нерелевантный контент — это только усугубит ситуацию.
Мониторинг редких кодов ответа: как не пропустить проблему
304, 429 и 451 объединяет одно: они не бросаются в глаза при беглом осмотре. 304 — это не ошибка, и многие системы мониторинга его игнорируют. 429 — ошибка, но часто кратковременная, и на графиках доступности она тонет в шуме. 451 — настолько редок, что многие вообще не знают о его существовании. Чтобы держать руку на пульсе, настройте регулярный анализ логов сервера с группировкой по кодам ответа. Раз в неделю выгружайте статистику: сколько ответов каждого HTTP-статуса отдал сервер за семь дней. Если 304 вдруг стало в десять раз больше обычного — возможно, робот зациклился на обходе одних и тех же страниц, не получая нового контента. Если появились 429 там, где их раньше не было — кто-то упёрся в лимит, и нужно выяснять, легитимный ли это бот или паразитный скрейпер. Если мелькнул 451 — немедленно разбираться, пока страница не вылетела из индекса. Добавьте эти три кода в дашборд мониторинга наравне с 404 и 500 — они не менее важны, просто реже встречаются.
Часто задаваемые вопросы
Может ли 304 ошибка навредить ранжированию? Сама по себе — нет. 304 не является ошибкой, это нормальный ответ сервера при корректно настроенном кешировании. Но если из-за неправильной настройки сервер отдаёт 304 на страницу, которая на самом деле изменилась, робот не увидит обновлённый контент. В этом смысле вред не от кода 304, а от ошибки в логике кеширования. Регулярно проверяйте, что страницы, контент которых обновился, отдают 200, а не 304.
Как отличить 429 от DDoS-атаки? Смотрите в логи. Если 429 ошибки приходят в ответ на запросы от одного IP или узкого диапазона IP, и User-Agent нетипичный для браузера — это похоже на атаку или агрессивный парсинг. Если 429 размазаны по множеству разных IP с нормальными User-Agent — возможно, у вас всплеск легитимного трафика, и сервер не справляется. Если 429 приходят в ответ на запросы YandexBot — проблема в настройках лимитов, нужно белить IP Яндекса.
Обязан ли я отдавать 451 при блокировке страницы Роскомнадзором? Технически — нет. Протокол HTTP не обязывает использовать именно этот код. Но использование 451 является хорошей практикой: оно чётко сигнализирует поисковым системам, что блокировка носит юридический, а не технический характер, и помогает быстрее исключить страницу из выдачи, избежав дополнительных штрафов за недоступность.
Влияет ли 429 на позиции сайта в Яндексе? Прямо — нет, если это единичные эпизоды. Но если 429 ошибки носят систематический характер и робот Яндекса регулярно не может обойти страницы из-за ограничений, это приводит к замедлению индексации, устареванию контента в выдаче и потенциальному исключению страниц, которые бот не может проверить длительное время. Косвенно это вредит позициям.
Где посмотреть статистику по кодам ответа для робота Яндекса? В Яндекс.Вебмастере в разделе «Индексирование» — «Статистика обхода» есть график с распределением кодов ответа, которые получал робот при обходе сайта. Там видны 200, 301, 404, 500 и другие коды. Это агрегированная статистика, которая поможет заметить аномалии. Для детального анализа используйте логи сервера, о которых мы подробно рассказывали в отдельной статье.
