500

Как работает

Когда сервер получает запрос, но не может его обработать из-за ошибки в приложении, он возвращает статус 500 Internal Server Error. Это самый общий из кодов 5xx — сервер сообщает: «что-то пошло не так, конкретизировать не могу». Родственные статусы уточняют картину: 502 — сбой между прокси и бэкендом, 503 — сервис временно недоступен (перегрузка или техработы), 504 — таймаут ожидания бэкенда.

Пример заголовков:

HTTP/1.1 500 Internal Server Error
Content-Type: text/html; charset=utf-8

Google и Яндекс воспринимают все 5xx как временную недоступность. Робот повторяет запрос спустя время: сначала быстрее, потом всё реже. Если 500 держится долго, URL временно исчезает из индекса, но не удаляется — при возврате в 200 OK страница обычно быстро восстанавливается.

Почему важно для SEO

Разовые 500 при высокой нагрузке — нормальная ситуация, поисковик это простит. Массовые и регулярные 5xx на важных страницах ведут к серьёзным последствиям: URL перестают ранжироваться, краулинговый бюджет расходуется впустую на ретраи, а после нескольких недель Google может пересмотреть общую оценку доступности сайта и снизить приоритет обхода.

Google Search Central в разделе о сканировании прямо предупреждает: если сайт часто отдаёт 5xx, робот замедляет частоту обходов, чтобы не усугублять проблему. Для интернет-магазинов и медиа это означает потерянные позиции по коммерческим и новостным запросам — с восстановлением на недели.

Яндекс.Вебмастер отдельно ведёт раздел «Диагностика» с фиксацией ошибок сервера. Если 5xx массово ловится на конкретном разделе — этот раздел рискует получить пометку «сайт частично недоступен», что напрямую бьёт по CTR в выдаче.

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

• Кастомная страница-заглушка отдаёт 200 вместо 500 — робот сохранит её содержимое как контент страницы.
• Ошибка приложения ловится в глобальный try/except и возвращает пустой 200 — то же самое soft 200 при реальном сбое.
• Load balancer настроен так, что при падении одного бэкенда все запросы уходят в 502 — недоступна не одна страница, а весь сайт.
• Технические работы проходят под 500 вместо 503 с заголовком Retry-After — робот не понимает, когда возвращаться.
• Нет мониторинга: ошибки сервера копятся часами, никто не видит.

Как проверить

Первое место — логи веб-сервера (Nginx error.log, Apache error_log) и логи приложения. В браузере — DevTools → Network → колонка Status. В терминале: curl -I https://example.com/some-page/. В Google Search Console раздел «Индексирование страниц» ловит URL со статусом «Ошибка сервера (5xx)», а «Статистика сканирования» показывает процент запросов с ошибками во времени. В Яндекс.Вебмастере — «Диагностика» и «Индексирование → Сканирование».

SEO Crawler фиксирует все 5xx при обходе, разбивает по подтипам (500, 502, 503, 504), показывает первопричинные URL и связанные внутренние ссылки. В отчёте это блок «Ошибки сервера» — с указанием, сколько страниц пострадало и на каких разделах сайта проблема концентрируется.

Вывод

500 — сигнал о нестабильности бэкенда, и поисковик реагирует на такие сигналы понижением приоритета обхода. Стройте мониторинг ошибок сервера отдельно от аналитики трафика, для запланированных техработ используйте 503 с Retry-After вместо 500, и не маскируйте сбои под 200 OK — честный статус ошибки лучше для SEO, чем «зелёный» ответ с пустой заглушкой.