Серверные ошибки (5xx)

Что это

Серверные ошибки 5xx — HTTP-статусы от 500 до 511, которые сервер возвращает краулеру или браузеру, когда не может выполнить запрос по своей вине. В отличие от 4xx, где проблема на стороне клиента, здесь виноват сервер: упал PHP-процесс, переполнилась память, не ответила база данных, истёк таймаут бэкенда. Ответ с кодом 5xx означает: страница существует, но прямо сейчас недоступна.

Самые частые коды: 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable), 504 (Gateway Timeout).

---

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

Поисковые роботы — Яндекс.Бот и Googlebot — при обходе сайта запоминают, какой статус вернула страница. Если URL стабильно отдаёт 5xx, Яндекс снижает частоту переобхода этой страницы и в итоге исключает её из индекса. Google действует аналогично: по данным документации, если страница возвращает ошибку сервера несколько раз подряд, робот помечает её как временно недоступную и перестаёт индексировать. Для крупных интернет-магазинов с 50 000+ страниц даже 2–3% URL с 5xx на момент краула — это тысячи выпавших из индекса товаров.

Поведенческий сигнал усугубляет картину: пользователь, попавший на страницу с ошибкой, сразу уходит. Яндекс учитывает отказы через ИКС, Google — через Core Web Vitals и сигналы удовлетворённости. Постоянный 503 на мобильной версии в часы пиковой нагрузки способен обвалить позиции раздела за 2–3 недели.

---

Как проверить вручную

1. Яндекс.Вебмастер → раздел «Индексирование» → «Страницы в поиске» → фильтр по «Ошибки сервера». Здесь же в разделе «Диагностика сайта» видны страницы, которые бот не смог обойти из-за 5xx.

1. Google Search Console → «Страницы» → статус «Не проиндексировано» → причина «Ошибка сервера (5xx)». Экспортируй список в CSV и сравни с ситуацией неделю назад.

1. Screaming Frog → запусти краул, после завершения перейди в «Response Codes» → фильтр 5xx. Столбец Address покажет все проблемные URL. Дополнительно проверь вкладку «Response Time» — страницы с временем ответа >5 с часто предшествуют 504.

1. Curl в терминале — быстрая ручная проверка конкретного URL:

``bash curl -I https://example.ru/catalog/product-slug ` Смотри строку HTTP/2 5xx` в ответе.

1. Топвизор (мониторинг доступности) — настрой алерт на HTTP-статус, чтобы узнавать о 5xx в течение 1–2 минут, а не через сутки из GSC.

---

Как исправить

Общий алгоритм:

1. Открой лог сервера (/var/log/nginx/error.log или /var/log/apache2/error.log) и найди записи, соответствующие времени ошибки.
2. Определи причину: нехватка памяти PHP (Allowed memory size exhausted), упавший бэкенд, долгий SQL-запрос.
3. Устрани первопричину, а не симптом.

Nginx — пример обработки 502/504:

proxy_connect_timeout 10s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;
fastcgi_read_timeout 60s;

Если таймаут всё равно срабатывает — оптимизируй медленный запрос к БД, а не увеличивай лимиты бесконечно.

PHP — увеличение памяти (временная мера):

memory_limit = 256M
max_execution_time = 60

WordPress — отключи плагины по одному через wp-admin или переименуй папку wp-content/plugins через FTP, чтобы найти конфликт. Частая причина 500 — несовместимый плагин после обновления ядра.

Tilda — серверная часть на стороне платформы. При 5xx открывай тикет в поддержку Tilda с указанием URL и времени ошибки. Для кастомного домена проверь настройки проксирования у хостера.

1C-Bitrix — проверь /bitrix/php_interface/dbconn.php на корректность реквизитов БД и мониторь лимиты в «Производительность» → «Монитор производительности». Включи кеш композитного сайта — снижает нагрузку и число 503 при пиках трафика.

Webflow — инфраструктура управляется платформой. 5xx при кастомном коде или через Webflow Logic проверяй в разделе «Project Settings» → «Integrations» → логи запросов.

---

Типичные ошибки

• Игнорировать периодические 5xx. «Иногда 503, не страшно» — краулер попал именно в это «иногда», страница выпала из индекса.
• Настраивать кастомную страницу 500 с кодом 200. Мягкая 404 (или мягкая 500) — робот считает страницу рабочей, но индексирует бесполезный контент ошибки.
• Не различать 503 и 301. Временное обслуживание надо отдавать как 503 + Retry-After, а не редирект. Иначе Яндекс может переиндексировать страницу-заглушку.
• Повышать таймауты вместо оптимизации. proxy_read_timeout 300s — это не решение, а маскировка медленного запроса к БД.
• Не настраивать алерты. Узнавать о 5xx из жалоб клиентов или из недельного отчёта GSC — значит терять краулинговый бюджет и позиции.

---

Влияние на разные типы сайтов

Интернет-магазины страдают сильнее всего: каталог товаров часто генерируется динамически, и при нагрузочных пиках (распродажи, сезон) сервер не справляется. 504 на страницах категорий в момент краула Яндекса обнуляет весь SEO-трафик раздела. Решение — кеширование на уровне CDN или Nginx, горизонтальное масштабирование.

Контентные сайты и медиа уязвимы к 500 при публикации «вирусных» материалов, когда трафик резко вырастает. SaaS и лендинги с небольшим числом страниц переживают единичные 5xx легче, но если главная страница или лендинг несколько часов отдавали 500 — ждите просадки в ранжировании и проблем с переиндексацией через Я.Нейро и Google AI Overviews, где свежесть и доступность контента критичны.