HTTP 500, 503 и 429: как разбирать ошибки на страницах поиска

Почему страница иногда недоступна роботу

Мини-кейс: форма заявки использует API, которое иногда отвечает 500, тогда как HTML страницы всегда 200. Посетитель видит предложение, но не может отправить запрос; простой мониторинг главной ничего не замечает. Проверяйте и критические действия страницы, и сырой HTML. Если 503 связан с обслуживанием, запишите длительность и повторяемость; постоянная «временная» ошибка перестает быть временной для пользователя. Для 429 сопоставьте ограничения по IP и user-agent с реальными всплесками, чтобы не ослабить защиту вслепую. Приемка должна подтверждать стабильные ответы в часы прежнего сбоя.

Ночной 503 на услуге может совпадать с резервным копированием базы; 429 после маркетинговой кампании - с правилом WAF. Эти случаи нельзя лечить одинаковым cache-control или статической страницей с 200. Для отчета сохраните интервал, затронутые URL и долю ошибочных запросов. После ремонта проверьте тот же временной слот и нагрузку, иначе одиночный успешный ответ днем создаст ложное ощущение решения.

Свяжите коды ответа со временем сбоя

Зафиксируйте код, URL, момент, длительность, user-agent, серверный узел и ответ после повтора. Единичный скриншот браузера не показывает ночную или региональную ошибку.

Сопоставьте ошибки с деплоем, нагрузкой, WAF, лимитами API и временем ожидания базы. Проверьте, не маскируется ли ошибка под 200 с пустым шаблоном.

Найдите источник 500, 503 или 429

5xx и 429 описывают разные причины, но обе означают, что запрошенный ресурс недоступен в момент запроса. Массовая замена ошибки на 200 с текстом «попробуйте позже» создает ложную успешную страницу.

Исправьте сервис, а не маскируйте ответ

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

Ограничение агрессивного неизвестного бота может быть оправдано. Но правило WAF не должно случайно перекрывать легитимных посетителей и известных поисковых роботов.

Разведите краткое обслуживание, перегрузку и программную ошибку по журналам и времени. Ответ 429 от CDN и 503 от приложения могут иметь разные причины и разных ответственных. Покажите человеку понятное сообщение, но не маскируйте недоступность ответом 200.

Настройте внешнюю проверку шаблонов

Настройте проверку типовых URL с внешней точки и записью исходного HTTP-ответа. Разделите проверки главной, услуги, статьи и файлов: частичный отказ одного шаблона легко пропустить.

Проверьте серию запросов после ремонта

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

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

Проверка результата

• Намерение страницы определено
• Сохранена выборка URL до исправления
• HTTP-ответ и содержимое сверены
• Внутренние ссылки проверены
• Исключения учтены
• Проверка после релиза записана

Скачать таблицу примера

Вопросы по теме

Читайте также