Понедельник, 9:17 утра. Сайт не работает
Звонит клиент — владелец магазина детской одежды. Голос напряжённый: «Сергей, покупатели пишут, что сайт не открывается. Белый экран и какая-то ошибка. Мы в пятницу запустили рекламу на 120 тысяч, а тут такое.»
Заходим на сайт. На главной — всё работает. Каталог — тоже. А вот страница оформления заказа выдаёт «500 Internal Server Error». Белые буквы на белом фоне отчаяния.
Рекламу уже открутили на 40 тысяч за выходные. Покупатели приходили, набирали товары в корзину, нажимали «Оформить заказ» — и получали ошибку. Сколько заказов потерялось? По логам насчитали 186 попыток оформления. При среднем чеке в 3 200 рублей это почти 600 тысяч рублей за два дня.
Причина? PHP-скрипт оформления заказа упёрся в лимит памяти после обновления модуля доставки. Исправили за 40 минут. Но деньги — уже ушли.
И знаете, что самое обидное? Эту ситуацию можно было предотвратить. Если бы за сервером кто-то наблюдал, проблема обнаружилась бы через минуты, а не через два дня. Но давайте по порядку.
Что такое ошибка 500 простым языком
Ошибка 500 на сайте — что это такое? Без технических терминов: это сигнал, что сервер не смог выполнить запрос. Не потому что вы ввели неправильный адрес (это ошибка 404). Не потому что у вас нет доступа (это 403). А потому что внутри сервера что-то сломалось.
Представьте ресторан. Вы сели за стол, сделали заказ. Официант ушёл на кухню — и не вернулся. Через пять минут выходит менеджер и говорит: «Извините, у нас что-то случилось на кухне, мы не можем выполнить ваш заказ.» Что именно случилось? Не сообщают. Может, повар уронил кастрюлю. Может, закончился газ. Может, кухня горит.
Ошибка 500 — это именно такой ответ: «что-то пошло не так, но мы не скажем что». И в этом её главное коварство. Код 500 — самый неинформативный из всех серверных ответов. Он не говорит ни причину, ни способ решения. Чтобы разобраться, нужно лезть в серверные логи.
Для владельца магазина это означает одно: если сайт выдаёт ошибку 500, вы не исправите её сами. Это не «перезагрузите страницу» и не «почистите кэш браузера». Это проблема на стороне сервера, и нужен человек, который в этом сервере разбирается.
Почему ошибка 500 на Битриксе — особый случай
Серверный сбой с кодом 500 может случиться на любом сайте. Но на Битриксе он случается чаще — и вот почему.
Битрикс — мощная система. Десятки модулей, интеграции с 1С, сложная логика скидок, персональные цены, многоуровневые каталоги. Каждый из этих модулей — это PHP-код, который потребляет память и процессорное время сервера. Чем больше модулей, тем выше шанс, что что-то пойдёт не так.
Вот пять главных причин ошибки 500 на Битриксе, которые мы видим регулярно:
- Нехватка памяти PHP. Стандартный лимит — 128 Мб. Битрикс с каталогом на 5 000 товаров легко потребляет 256 Мб. Результат — скрипт «падает» посреди генерации страницы.
- Таймаут при обмене с 1С. Выгрузка 10 000 товаров занимает 15–20 минут. Если сервер настроен на таймаут в 30 секунд — обмен обрывается, сервер возвращает код 500. Данные не синхронизируются, цены на сайте устаревшие.
- Конфликты модулей после обновления. Обновили Битрикс — а сторонний модуль доставки или оплаты ещё не адаптирован под новую версию. Результат — сбой на конкретных страницах. Причём не на всех, а только там, где этот модуль подключается.
- Переполнение диска. Бэкапы, логи, временные файлы обмена с 1С — всё это копится. Когда диск забит на 95%, Битрикс не может записать кэш и сессии. Сайт начинает «сыпаться».
- Некорректные права доступа к файлам. После переноса сайта или обновления ОС права на файлы могут сбиться. Веб-сервер не может прочитать нужный скрипт — и отдаёт пятисотку вместо страницы.
Каждая из этих причин — серверная. Разработчик сайта может про них ничего не знать. Хостер скажет «у нас всё работает». А владелец магазина видит только результат: покупатели не могут оформить заказ.
Скрытые ошибки 500: те, которых вы не видите
А теперь — самое неприятное. Серверный сбой, который вы видите, — это ещё полбеды. Гораздо хуже те, которые происходят незаметно.
Как это возможно? Очень просто.
Вы — владелец магазина. Вы заходите на свой сайт, проверяете главную, каталог, пару товаров. Всё работает. Прекрасно. Но вы не проверяете каждую из 8 000 товарных страниц. Не проверяете страницу оформления заказа с пятью товарами из разных категорий при доставке в Новосибирск. Не проверяете AJAX-запрос обновления корзины на мобильном телефоне. Не проверяете, что происходит, когда три покупателя одновременно применяют промокод на товар со скидкой.
А покупатели — проверяют. Каждый день. И часть из них натыкается на серверный сбой на страницах, о которых вы даже не подозреваете.
Вот реальный пример. Магазин строительных материалов. Владелец уверен: сайт работает нормально. Мы подключили мониторинг и за первую неделю зафиксировали 347 серверных сбоев. Все — на страницах фильтрации каталога. Когда покупатель выбирал фильтр «цемент + фасовка 50 кг + цена до 500 рублей», сервер не справлялся с запросом к базе данных и отдавал код 500. Владелец никогда не пользовался фильтрами на собственном сайте. А покупатели — пользовались. Каждый день. Десятки раз.
347 сбоев за неделю. Это 347 человек, которые хотели купить, но не смогли. Скрытые ошибки сайта — невидимая дыра в выручке. Вы не увидите её в Метрике, потому что технически визит состоялся. Покупатель дошёл до нужной страницы — просто вместо товаров увидел белый экран.
Другой случай. Магазин автозапчастей. Сбой возникал только при добавлении в корзину товара с персональной скидкой по купону. Без купона — всё работало. С купоном — белый экран. Купонами пользовались постоянные клиенты — то есть самая ценная аудитория. Они получали ошибку, звонили в магазин, но администратор не понимал, в чём дело: «У меня всё открывается.» Проблема жила три месяца, пока не поставили мониторинг.
Три месяца. Представьте, сколько лояльных клиентов ушло за это время. И ни один из них не написал в поддержку «у вас ошибка 500 при применении купона на товар артикула XYZ». Люди просто уходят молча.
Сколько денег вы теряете прямо сейчас
Посчитаем на конкретных цифрах.
Средний интернет-магазин на Битриксе получает 3 000–10 000 посетителей в день. Конверсия в заказ — 1,5–3%. Допустим, у вас 5 000 посетителей и конверсия 2%. Это 100 заказов в день.
Теперь допустим, что 5% посетителей сталкиваются со скрытыми серверными сбоями. Это 250 человек в день. Из них какая-то часть ушла бы и без ошибки — но исследования показывают, что около 40% пользователей, столкнувшихся с серверной ошибкой, не возвращаются. Вообще. Это не «попробую позже». Это «пойду в другой магазин».
Делаем арифметику. 250 человек × 40% = 100 потерянных потенциальных покупателей в день. При конверсии 2% — это 2 заказа в день. При среднем чеке 4 000 рублей — 8 000 рублей ежедневных потерь. За месяц — 240 000 рублей. За год — почти 3 миллиона.
И это только прямые потери от ошибки. Есть ещё косвенные:
- SEO-позиции. Яндекс и Google мониторят ответы сервера. Если поисковый робот регулярно получает код 500 вместо содержимого страницы, эти страницы вылетают из индекса. Меньше страниц в индексе — меньше поискового трафика — меньше покупателей.
- Рекламный бюджет. Вы платите за клик в Директе или Google Ads. Покупатель кликает, приходит на сайт, получает ошибку и уходит. Деньги за клик вы уже заплатили. Рекламный бюджет сгорает впустую.
- Репутация. Покупатель, получивший ошибку, запоминает: «этот магазин не работает». В следующий раз он пойдёт к конкуренту. Не потому что у конкурента дешевле — а потому что у конкурента сайт открывается.
Как исправить ошибку 500 и не допустить повторения
Сначала — как тушить пожар, если сайт выдаёт ошибку 500 прямо сейчас. Потом — как сделать так, чтобы пожар не повторялся.
Шаг 1. Найти причину в логах
Ошибка 500 — это симптом. Причина — всегда в логах сервера. Нужно открыть лог ошибок веб-сервера (обычно это файл error.log) и лог PHP. Там будет написано, что именно сломалось: нехватка памяти, синтаксическая ошибка в PHP-файле, таймаут запроса к базе данных или что-то ещё.
Проблема: большинство владельцев магазинов не имеют доступа к логам. И это нормально — вы не обязаны. Но кто-то должен иметь. Если у вас нет человека, который знает, где эти логи и как их читать, — это первое, что стоит исправить.
Шаг 2. Устранить конкретную причину
Увеличить лимит памяти PHP. Поднять таймаут. Почистить диск от старых бэкапов. Исправить права доступа. Откатить проблемное обновление модуля. Конкретное решение зависит от конкретной причины — универсального рецепта нет.
Обычно исправление занимает от 20 минут до 2 часов. Но только если человек знает, что искать. Если не знает — можно провозиться день и сделать хуже. Мы видели случаи, когда владелец магазина по совету из форума менял настройки PHP прямо на боевом сервере. Сайт «починился» — но через два часа упал окончательно, потому что новые настройки съели всю оперативную память.
Шаг 3. Поставить мониторинг (самое важное)
Исправить ошибку — это потушить пожар. А мониторинг — это пожарная сигнализация. Разница — между «починить за 40 минут» и «потерять 600 тысяч за выходные».
Что должен отслеживать мониторинг:
- HTTP-статусы всех ключевых страниц (главная, каталог, корзина, оформление заказа)
- Время ответа сервера — если страница грузится дольше 3 секунд, скоро будут и ошибки
- Свободное место на диске
- Нагрузку на процессор и память
- Ошибки в логах PHP и веб-сервера
При правильном мониторинге вы узнаёте о проблеме до того, как о ней узнает покупатель. У нашего клиента с магазином детской одежды, с которого мы начали эту статью, после установки мониторинга за полгода не было ни одного инцидента с потерей заказов. Не потому что серверные сбои перестали возникать — а потому что мы их ловили и исправляли раньше, чем они добирались до покупателей.
Шаг 4. Решить вопрос «а кто за этим следит?»
Мониторинг — это софт. Но кто-то должен реагировать на его сигналы. Три часа ночи, суббота, мониторинг прислал алерт: «ошибки на странице оформления заказа». Кто встанет и починит?
Варианта три. Сисадмин в штате — дорого, от 80 000 рублей в месяц, и для одного магазина избыточно. Разработчик сайта — он про код, а не про сервер, это разные профессии. Сервис на абонентке — команда, которая мониторит, реагирует, бэкапит и обновляет. Мы построили «Апельсин Код» вокруг третьего варианта — не потому что он «лучший», а потому что для владельца интернет-магазина он самый рациональный по соотношению цены и покрытия рисков.
Часто задаваемые вопросы об ошибке 500
Ошибка 500 — это взлом?
Чаще всего — нет. В 90% случаев это техническая проблема: нехватка ресурсов, ошибка в коде или конфликт обновлений. Но иногда — да, внедрённый вредоносный код может вызывать ошибку 500. Если ошибка появилась без видимых причин, проверка на взлом лишней не будет.
Если сайт выдаёт ошибку 500, теряю ли я позиции в Яндексе?
Если сбой кратковременный — за пару часов ничего страшного не произойдёт. Поисковые роботы вернутся позже и увидят нормальную страницу. Но если страницы отдают код 500 регулярно или в течение нескольких дней, Яндекс начнёт исключать их из индекса. Google ведёт себя аналогично. Восстановление позиций после такого занимает недели, а иногда — месяцы, если страницы были конкурентными по высокочастотным запросам.
Можно ли исправить ошибку 500 самому?
Если у вас есть доступ к серверу и вы понимаете, что такое логи, — можно попробовать. Но для владельца магазина честный ответ: скорее нет. Это задача для администратора сервера. Не для разработчика сайта (он отвечает за код, а не за сервер), и не для хостера (он отвечает за физическое оборудование, а не за настройки вашего проекта).
Как быстро нужно реагировать?
Каждый час простоя — это потерянные заказы. Если ошибка на странице оформления заказа — реагировать нужно в минутах, не в часах. Если на второстепенной странице — в часах, не в днях. Но лучше всего — не реагировать на уже случившееся, а предотвращать через мониторинг.
Что делать прямо сейчас
Ошибка 500 на сайте — это не мелочь и не «глюк, который сам пройдёт». Это конкретная серверная проблема, которая стоит конкретных денег. Особенно опасны скрытые ошибки сайта — те, которые видят покупатели, но не видите вы. Они не отображаются в обычной аналитике, не вызывают тревогу у хостера и не попадают в отчёты разработчика.
Три вещи, которые можно сделать уже сегодня:
- Попросите того, кто обслуживает ваш сервер, проверить лог ошибок за последнюю неделю. Если там есть записи с кодом 500 — у вас проблема.
- Проверьте свободное место на диске. Если занято больше 80% — пора чистить.
- Пройдите ключевые сценарии на сайте: оформите тестовый заказ, примените промокод, отфильтруйте каталог. Всё работает? Хорошо. Но это проверка одного сценария из тысячи.
Если хотите узнать реальную картину — мы можем проверить ваш сервер бесплатно. За 24 часа посмотрим логи, нагрузку, состояние дисков, наличие скрытых ошибок. Пришлём отчёт с конкретными цифрами и рекомендациями. Без обязательств — просто чтобы вы знали, что происходит внутри вашего сервера на самом деле.
→ Закажите бесплатный аудит вашего сервера на admin.orangecode.ru — отчёт за 24 часа