Сайт на Битриксе не открывается: причины и решение за 10 минут

Почему сайт на Битриксе перестаёт открываться

Белый экран и ошибка 500: что происходит на самом деле

Если сайт на Битриксе не открывается, а вместо привычной страницы появляется белый экран или сообщение об ошибке 500, — это значит, что система столкнулась с фатальной ошибкой на уровне PHP. Такой сбой не виден пользователю, но полностью останавливает работу сайта. Поэтому фраза «битрикс сайт не работает» обычно означает: скрипт упал раньше, чем успел отдать хоть какой-то контент браузеру.

В большинстве случаев белый экран Битрикс связан с одной из трёх причин:

• ошибка в пользовательском или модульном коде — например, Bitrix PHP Fatal error из-за несовместимости версии PHP;
• внезапная ошибка ядра или модуля, где устаревшая функция больше не поддерживается;
• битая библиотека или некорректное обновление — система просто не может завершить инициализацию.

Такие сбои не редкость: обновился модуль, изменился путь к классу, или в коде осталась ссылка на старый метод — и вот уже битрикс ошибка 500 на всех страницах. Иногда виноват плагин или компонент, подключённый “вручную”, без проверки. Тогда в логах можно увидеть строку вроде include(): Failed opening required — признак того, что произошла битрикс ошибка в модуле или файле шаблона.

Иногда битрикс ошибка ядра возникает после обновления системы: старый код перестаёт быть совместим с новой версией, и сайт перестаёт открываться сразу после апдейта. Хорошая новость в том, что такие ошибки можно диагностировать за несколько минут — нужно просто знать, где искать логи и как их читать. Об этом — в следующем блоке.

Ошибка 502, 503 или Internal Server Error — чем они отличаются

Когда битрикс не открывается, но вместо белого экрана появляется надпись 502 Bad Gateway или 503 Service Unavailable, — проблема не в самом сайте, а в цепочке между сервером и PHP. Такие ошибки часто путают с 500 Internal Server Error, хотя причины у них разные.

Ошибка 502 в Битриксе чаще всего означает, что PHP-процесс не успел ответить веб-серверу. Это бывает при резком росте нагрузки, бесконечном запросе в модуле или при использовании тяжёлого компонента, который завис на обращении к базе данных. В таких случаях логично увидеть классическое сообщение Bitrix site down — сайт не падает полностью, но «зависает» на ожидании ответа.

Ошибка 503 сигнализирует, что сервер временно недоступен. Это типичный случай после обновления системы или при рестарте Apache/Nginx. Иногда причина банальна — закончился лимит по оперативной памяти, и PHP просто не может запуститься. В этот момент можно сказать, что битрикс сайт упал, но не сломался: стоит только перезапустить сервис или очистить кеш — и он оживает.

Классический Internal Server Error (500) — это уже сбой в коде, плагине или ядре. А вот 502 и 503 — больше про окружение: тайм-ауты, нагрузку, нехватку памяти. Если битрикс не открывается на хостинге именно с этими кодами, стоит начать не с PHP, а с панели управления сервером и логов веб-сервера.

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

Сайт не загружается или админка не открывается

Иногда сайт на Битриксе вроде бы работает, но страница не загружается до конца или зависает на этапе соединения с сервером. Пользователь видит вечную загрузку, а в панели администратора ничего не происходит. Это не всегда “падение сайта” — часто причина в том, что процесс PHP завис или не может подключиться к базе данных.

На практике встречаются несколько типичных сценариев:

• неправильные данные для подключения к MySQL в dbconn.php после переноса сайта;
• ошибка в файле init.php, из-за которой система останавливается до загрузки ядра;
• повреждённый шаблон компонента — пропущена скобка, сломан include, или удалён нужный файл;
• сервер не справляется с нагрузкой и “обрывает” соединение с PHP;
• модуль или плагин после обновления вызывает ошибку, которая блокирует вывод страницы.

Если не открывается административная часть, стоит проверить лог ошибок и время отклика базы данных. Иногда проблема банальна — закончилось место на диске, и сервер просто не может создать временные файлы. Бывает и обратная ситуация: владелец вручную чистит кеш и случайно удаляет служебные файлы, после чего интерфейс перестаёт загружаться.

Часто после исправления причины сайт восстанавливается моментально. Главное — не паниковать и не трогать структуру файлов, пока не найдена конкретная ошибка. Любая спешка в таких случаях только увеличивает время восстановления.

Что делать, если сайт не работает после обновления PHP или ядра

После обновления PHP или ядра Битрикс сайт может перестать открываться вообще — появляется белый экран или ошибка 500. Это нормальная ситуация, особенно если проект давно не обновлялся. Новая версия PHP строже относится к синтаксису и просто “ломает” старые функции, которые раньше тихо игнорировались.

Первое, что стоит сделать — включить вывод ошибок, чтобы понять, на чём всё останавливается. Для этого можно временно добавить строки в bitrix/php_interface/dbconn.php или init.php:

ini_set('display_errors', 1);
error_reporting(E_ALL);
define('BX_DEBUG', true);

После этого обнови страницу и посмотри сообщение — в нём будет указан конкретный файл и строка, где произошла ошибка. Чаще всего это несовместимость кода с новой версией PHP: например, вызов устаревшего конструктора класса или функции, которая больше не поддерживается.

Иногда после обновления ядра страница не открывается из-за конфликтов с кастомными компонентами. Особенно часто это происходит в проектах, где правили файлы внутри системных директорий /bitrix/modules. Если есть резервная копия — восстанови её, затем проверь обновления через административную панель и установи их повторно.

Главное — не откатывать ядро “наугад”. Это может привести к повреждению базы данных и потере связей между модулями. Лучше временно вернуть старую версию PHP, проверить логи и пошагово обновить компоненты.

Почему сайт на битриксе может упасть без видимых причин

Иногда сайт перестаёт открываться неожиданно — без обновлений, вмешательств или изменений на сервере. В таких случаях кажется, что всё «сломалось само». На практике это не мистика, а следствие накопившихся технических факторов, которые проявляются именно в тот момент, когда совпадает несколько условий: кеш переполнен, диск почти заполнен, и хостинг внезапно обновил окружение.

Вот наиболее частые причины таких «необъяснимых» сбоев:

Ситуация	Что происходит	Как решить
Автообновление на стороне хостинга	Изменяется версия PHP или MySQL без уведомления, старые модули становятся несовместимыми.	Проверить логи и вернуть прежнюю версию окружения или обновить ядро Битрикс.
Переполнен диск	Система не может создать временные файлы или записи в базе данных, сайт перестаёт отвечать.	Очистить кеш и логи, проверить доступное место на сервере.
Сбой в кеше	Устаревшие файлы кеша вызывают конфликты при генерации страниц.	Удалить содержимое папок /bitrix/cache и /managed_cache, затем перезапустить PHP.
Проблемы с DNS или SSL	Домены не обновились, сертификат истёк, и браузер блокирует подключение.	Проверить зону DNS, обновить SSL и убедиться, что дата на сервере корректна.
Ошибки в планировщике задач	Автоматические агенты или крон запускают скрипты, которые завершаются ошибкой.	Отключить проблемные задания и проверить логи агента.

На первый взгляд всё это выглядит случайно, но у каждого сбоя есть источник. Даже если сайт работал годами без нареканий, любое обновление PHP, переезд на новый сервер или нехватка места в кеше могут вызвать цепную реакцию. Поэтому профилактика и регулярная проверка окружения часто спасают проект от простоя.

Быстрая диагностика — как определить причину за 10 минут

Проверка логов ошибок (error_log, bitrix/php_interface/init.php)

Первое, что стоит сделать, — посмотреть логи. Именно там всегда есть подсказка, что пошло не так. Файл error_log обычно лежит в корне сайта или в каталоге /bitrix. Если лога нет — создайте его вручную и дайте права на запись. Иногда полезно временно добавить строку в init.php:

error_log("Init check: " . date('Y-m-d H:i:s'));

После обновления страницы этот маркер должен появиться в логе. Если нет — значит, скрипт останавливается ещё до запуска ядра. Это помогает понять, где именно обрывается выполнение.

Включаем display_errors и находим проблемный участок

Когда логи не помогают, можно временно включить отображение ошибок прямо на экране. Делать это стоит аккуратно — только на тестовом сервере или с ограничением доступа по IP:

ini_set('display_errors', 1);
error_reporting(E_ALL);
define('BX_DEBUG', true);

После включения ошибок обновите страницу и внимательно прочитайте сообщение. В нём будет конкретный путь к файлу и строка, где всё оборвалось. Это помогает быстро определить, виноват ли шаблон, модуль или сторонний код.

Проверяем .htaccess, права доступа и свободное место на диске

Следующий шаг — убедиться, что сервер вообще может обслуживать запросы. Ошибки в файле .htaccess или неправильные права доступа на папки часто дают тот же эффект, что и сбой PHP — сайт просто не открывается. Проверь базовые вещи:

• .htaccess не содержит старых правил или лишних редиректов;
• папки /bitrix, /upload, /local имеют права 755, а файлы — 644;
• на сервере есть хотя бы 200–300 МБ свободного места.

Когда диск переполнен, Bitrix не может записывать кеш и логи — сайт перестаёт отвечать, хотя код формально работает.

Проблемы с базой данных MySQL и файлом dbconn.php

Если в логах встречается сообщение о невозможности подключения к базе данных, проверь файл dbconn.php. Там прописаны данные для соединения: хост, имя пользователя, пароль и название базы. Любая ошибка в этих строках приводит к полному отключению сайта.

Проблема	Проявление	Решение
Неверный логин или пароль	Ошибка “Access denied for user”	Уточнить данные в панели хостинга или через phpMyAdmin.
Локальный сокет недоступен	Ошибка “No such file or directory”	Заменить localhost на 127.0.0.1 в dbconn.php.
База переполнена	Ошибка “Table full” или “Out of space”	Очистить таблицы логов и кеша через phpMyAdmin.

После сохранения изменений стоит перезапустить PHP — иначе Bitrix может продолжить использовать старое соединение из кеша.

Как понять, что виноват модуль, шаблон или кэш

Если соединение с базой установлено, а сайт всё равно не открывается, стоит проверить пользовательский шаблон и установленные модули. Один из признаков — сайт работает на дефолтной теме, но падает на кастомной. В этом случае виноват шаблон или подключённый компонент.

Чтобы проверить, сбрось кеш:

/bitrix/cache/
/bitrix/managed_cache/

Если после очистки сайт заработал, значит, проблема была в устаревших данных. Если нет — отключи последний установленный модуль через административную панель или прямо в базе, установив флаг ACTIVE = N в таблице b_module.

Типовые причины, почему Битрикс не открывается

Ошибка PHP после обновления или перехода на PHP 8

Самая частая история — сайт перестаёт открываться сразу после перехода на новую версию PHP. Старые модули или шаблоны не успевают за изменениями языка. Особенно часто ломаются устаревшие функции вроде each() или split(), которые с PHP 8 больше не поддерживаются.

Fatal error: Uncaught Error: Call to undefined function split()

Если видите подобное, достаточно заменить устаревший вызов на современный аналог, либо вернуть временно старую версию PHP. После этого сайт обычно оживает без дополнительных вмешательств.

Повреждён .htaccess — сайт выдаёт 500 ошибку

Одна строка в .htaccess может уронить сайт полностью. Иногда достаточно лишнего символа или неправильного пути, чтобы сервер ответил ошибкой 500. Проверить можно быстро — просто временно переименуйте файл и обновите страницу. Если сайт заработал, значит проблема именно в правилах.

Минимальная рабочая версия для Битрикс выглядит так:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [L]

Если после этого сайт снова открывается, добавляйте остальные правила постепенно, проверяя результат на каждом шаге.

Переполнен диск на хостинге или закончились лимиты

Когда серверу не хватает места, сайт падает без предупреждения. CMS не может создать кеш, временные файлы или даже записать ошибку в лог. Проверить это просто — в панели хостинга или командой df -h. Если занято больше 95 %, система работает нестабильно.

Признак	Пояснение	Что делать
Не обновляются страницы	Кеш не записывается, Bitrix отдает старые данные.	Очистить папки /bitrix/cache и /managed_cache.
Не загружаются изображения	Каталог /upload/ переполнен или нет прав на запись.	Удалить старые файлы, проверить права 755/644.
Ошибка при записи логов	Журнал ошибок не создаётся из-за нехватки места.	Освободить 200–300 МБ и перезапустить PHP.

Ошибка в шаблоне компонента или кастомном модуле

Если сайт падает только на отдельных страницах, почти наверняка проблема в шаблоне. Неправильный include, опечатка в переменной или удалённый файл вызывают сбой именно там, где используется этот компонент. Чтобы проверить — временно переключите шаблон на стандартный и посмотрите, откроется ли страница.

Проблема с базой данных или авторизацией пользователя

Если Bitrix не может подключиться к MySQL, сайт перестаёт отвечать вообще. В логе часто видно строку вида Connection refused или Access denied for user. В этом случае проверьте данные в dbconn.php и убедитесь, что сервер базы запущен. Иногда помогает простая замена localhost на 127.0.0.1.

Ошибки авторизации тоже могут блокировать доступ — особенно если повреждены сессии или куки после обновления PHP. Очистка кеша и перезапуск сеанса решают проблему в считанные минуты.

Битрикс не открывается после переноса или установки SSL

После переезда сайта на новый сервер или подключения HTTPS появляются новые нюансы: пути в dbconn.php, ссылки в настройках и сертификаты. Если при загрузке видите бесконечный редирект — значит, старый URL-адрес по-прежнему прописан в настройках ядра.

Проверьте, чтобы в таблице b_option значения site_protocol и server_name соответствовали новому домену. При необходимости обновите их вручную через phpMyAdmin. После этого сайт снова откроется по защищённому протоколу без зацикливания редиректов.

Как починить сайт на Битриксе самостоятельно

Включить отображение ошибок и найти источник

Если сайт не открывается — нужно увидеть, где именно он «спотыкается». Для этого включи отображение ошибок. Это позволит понять, падает ли система из-за модуля, шаблона или конфигурации PHP. Добавь строки в файл /bitrix/php_interface/dbconn.php:

ini_set('display_errors', 1);
error_reporting(E_ALL);
define('BX_DEBUG', true);

После обновления страницы в браузере появится конкретная ошибка — с путём к файлу и номером строки. Это самый быстрый способ понять, что именно сломалось.

Очистить кеш и восстановить .htaccess

Если ошибок нет, а страница всё равно не открывается, попробуй очистить кеш. Часто сайт не загружается из-за устаревших данных, особенно после переноса или обновления модулей. Удали содержимое папок:

/bitrix/cache/
/bitrix/managed_cache/

После этого перезапусти PHP или просто обнови страницу. Если не помогло — временно переименуй .htaccess. Если сайт заработал, значит, проблема была в нём. Верни минимальную рабочую версию, а лишние правила добавь по одному.

Проверить совместимость PHP и модулей

С переходом на PHP 8 многие старые компоненты перестали работать. Если сайт перестал открываться после обновления, проверь логи — там почти всегда указана несовместимая функция. Иногда достаточно обновить только один модуль, чтобы вернуть всё в норму. А если проект старый — временно откати PHP до предыдущей версии.

Подробно разбираю этот процесс в статье «Переход на PHP 8 на 1С-Битрикс — пошагово и без стресса» — там показано, как избежать критических ошибок при переходе и что проверять в первую очередь.

Восстановить сайт из резервной копии

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

Проверь, чтобы копия совпадала по домену и путям. Если сайт был перенесён, восстанови сначала базу, потом директорию /upload — так сохранится контент и файлы без потери данных.

Как вернуть работу сайта без потери данных

Когда сайт снова открывается, важно убедиться, что всё функционирует корректно: формы, корзина, авторизация, административный раздел. Если какие-то страницы загружаются медленно, включи режим отладки и посмотри отчёт производительности.

После устранения причины стоит создать резервную копию вручную — чтобы в следующий раз восстановление заняло минуты, а не часы. Это простая привычка, которая спасает даже крупные проекты.

Когда стоит обратиться к специалисту

Ситуация	Как это выглядит	Что делает специалист
Сайт на Битриксе упал после обновления или миграции	После переноса или апдейта — белый экран, 500 ошибка или бесконечная загрузка. В логах пусто, а сайт не реагирует вообще.	Проверяет совместимость версий PHP, восстанавливает конфигурацию окружения, откатывает изменения без потери данных.
Проблема с подключением к серверу или MySQL	Сообщения вроде Connection refused, Access denied for user или “Database connection failed”.	Диагностирует соединение, правит параметры в dbconn.php, тестирует доступ к MySQL через консоль или phpMyAdmin.
Ошибки ядра, кастомные модули и доработки	После правок разработчика сайт открывается частично или падает при вызове определённых страниц. В логах — ошибки классов и include-файлов.	Отслеживает проблемные участки кода, сравнивает с оригинальным ядром, чинит кастом без удаления пользовательских данных.
Вирусы, инъекции и подозрительные файлы	Сайт перенаправляет на чужие страницы, появляются странные скрипты в /upload или внизу страниц, антивирус хостинга ругается на PHP-инъекции.	Чистит заражённые файлы, проверяет ядро на подмены, восстанавливает безопасную версию, закрывает дыры в доступах и правах.
Почему “починить за 10 минут” реально — если знаешь, где смотреть	Опытный специалист не тратит время на угадайку. Он сразу смотрит логи, конфиги и последние изменения в коде — и находит причину за пару минут.	Использует логику и шаблоны ошибок, а не “метод тыка”. Поэтому для него «сложный случай» — это просто 10 минут рутинной диагностики.

Реальные кейсы и решения

Белый экран после обновления — конфликт модуля

Клиент обновил систему, и сайт перестал открываться. Ни главная, ни админка не грузились — просто белый экран без ошибок. Это классическая ситуация, когда старый модуль не совместим с новой версией PHP или ядра.

После включения display_errors выяснилось, что в модуле обратной связи использовалась устаревшая функция each(), которую PHP 8 больше не поддерживает. Решение оказалось простым — модуль отключил, обновил до актуальной версии, очистил кеш и перезапустил PHP.

Сайт перестал открываться из-за переполненного кэша

Ещё один частый случай: сайт медленно загружался, а потом совсем перестал открываться. Ошибок в логах не было, только “висела” загрузка. После подключения к серверу стало ясно — диск переполнен на 100%, система не может создать временные файлы.

Шаг	Действие	Результат
1	Очистка директорий /bitrix/cache/ и /managed_cache/	Освободилось ~800 МБ места
2	Удаление старых логов и резервных архивов	Диск стал загружен на 72%
3	Перезапуск PHP-процессов	Сайт открылся сразу, без правок в коде

Причина оказалась банальной — автоматическая очистка кеша на хостинге была выключена. После включения этой функции проблема больше не повторялась.

Ошибка базы данных — восстановление доступа к MySQL

После переноса проекта на новый сервер сайт перестал открываться. На экране — ошибка подключения к базе данных. В логах: Bitrix\Main\DB\ConnectionException с сообщением “No such file or directory”.

Я сразу проверил dbconn.php и увидел стандартную ошибку: в старом окружении MySQL подключался через сокет, а на новом — требовался TCP. Достаточно было заменить строку:

$DBHost = "localhost"; 
// заменено на
$DBHost = "127.0.0.1";

После этого соединение восстановилось. Вся диагностика и правка заняли меньше пяти минут. Клиенту дополнительно настроил мониторинг MySQL, чтобы больше не ловить подобные сюрпризы.

SSL установлен неправильно — редирект и ошибка 502

Компания заказчика подключила HTTPS, но сайт перестал открываться. При заходе на любой URL происходил зацикленный редирект — браузер переходил между http и https, пока сервер не выдавал 502 Bad Gateway.

После проверки оказалось, что SSL-сертификат установлен корректно, но в .htaccess были дублирующие правила редиректа. В таблице b_option протокол сайта всё ещё оставался “http”. После синхронизации настроек и очистки кеша редиректы исчезли, сайт открылся по HTTPS.

Пример: сайт клиента восстановлен за 12 минут

Этот случай — классика. После перехода на PHP 8 сайт перестал открываться. Хостинг ответил “у нас всё нормально”, а заказчик уже готовился к переустановке. Я подключился, включил отображение ошибок и сразу увидел: вызов старого метода split() в кастомном компоненте.

Функцию заменил на explode(), почистил кеш и перезапустил PHP — сайт ожил. Всё заняло 12 минут с момента подключения.

Чеклист: что проверить, если сайт на Битриксе не открывается

Если сайт внезапно перестал работать, а паника уже близко — просто пройдись по этому списку. Этот чеклист поможет быстро понять, на каком этапе произошёл сбой.

• Проверь error_log — есть ли свежие ошибки за последние минуты;
• Убедись, что на сервере есть свободное место (не менее 300 МБ);
• Проверь права на папки /bitrix, /upload, /local — должны быть 755;
• Переименуй .htaccess и попробуй открыть сайт снова;
• Очисти кеш в /bitrix/cache/ и /managed_cache/;
• Проверь соединение с базой в файле dbconn.php;
• Убедись, что версия PHP соответствует требованиям ядра Битрикс;
• Временно включи display_errors, чтобы увидеть причину сбоя;
• Проверь, не закончился ли SSL-сертификат или срок аренды домена;
• Посмотри дату и время сервера — сбой синхронизации иногда ломает сессии и авторизацию.

Для удобства можно быстро отметить, что уже проверено:

Проверка	Статус	Комментарий
Логи ошибок и кеш	Проверено	Ошибки найдены и устранены
Подключение к базе	В процессе	Нужно проверить параметры dbconn.php
Права на папки	Проверено	Все установлены корректно
SSL и домен	Не проверено	Истекает срок сертификата — уточнить у хостинга

Типичные ошибки при восстановлении сайта на Битриксе

Когда сайт падает, первая реакция — «срочно всё чинить». Но именно в этот момент чаще всего совершаются ошибки, которые потом усложняют восстановление. Вот самые распространённые.

• 1. Удаление системных файлов без резервной копии.
  Часто пытаются «почистить всё лишнее» и случайно удаляют служебные каталоги /bitrix/modules или /upload. После этого сайт не подлежит восстановлению стандартными средствами.
• 2. Изменение ядра вместо локального шаблона.
  Правки в файлах ядра (/bitrix/modules, /bitrix/components) стираются при следующем обновлении. Любая правка должна быть в /local/ — иначе проект просто “разъедет” при апдейте.
• 3. Массовое обновление модулей без проверки версии PHP.
  Некоторые модули не совместимы с новыми версиями. Прежде чем обновлять всё подряд, стоит протестировать хотя бы на копии проекта или уточнить требования в документации.
• 4. Очистка кеша вручную без остановки сайта.
  Удаление кеша во время активных запросов может привести к повреждению данных и потере сессий. Лучше использовать административный интерфейс или cron-задачи.
• 5. Случайное изменение прав доступа.
  Некоторые FTP-клиенты при копировании меняют права на 777 или 600, из-за чего сайт либо становится уязвимым, либо перестаёт открываться вовсе.
• 6. Отключение модулей “наугад”.
  Пытаясь найти проблему, владельцы часто деактивируют всё подряд. После этого рушатся зависимости и структура данных. Лучше временно переименовать модульную папку, а не отключать через админку.
• 7. Неправильная работа с базой данных.
  Удаление таблиц, ручные правки без понимания структуры Bitrix — прямой путь к потере информации. Для таких задач нужен полный бэкап и опыт работы с SQL.
• 8. Игнорирование логов.
  Многие даже не открывают error_log или bitrix/logs/, считая, что “там всё равно непонятно”. А ведь именно там — прямая подсказка, где и почему сайт упал.

После восстановления сайта рекомендую проверить скорость и стабильность работы. Часто скрытые ошибки и медленные запросы проявляются именно после аварийного запуска.

Я подробно рассказал, как ускорить загрузку и разгрузить сервер в материале «Ускоряем 1С-Битрикс: инструкция для разработчиков и владельцев».

Из практики: как всё это происходит на деле

За последние годы я восстановил десятки сайтов, которые перестали открываться “внезапно”. У всех история примерно одна: кто-то обновил PHP, кто-то случайно удалил модуль, кто-то просто не знал, где лежат логи. Но в 9 из 10 случаев всё решается быстро — если не паниковать и действовать по шагам.

Обычно звонок звучит одинаково: “Сайт упал, помогите, мы ничего не делали”. Захожу по FTP, вижу белый экран, включаю вывод ошибок — и уже через минуту понятно, где искать. Иногда виноват один лишний символ в шаблоне, иногда старый модуль, оставшийся со времён PHP 5.6.

Помню случай с интернет-магазином, где после обновления PHP сайт вылетел в 500-ю ошибку. Заказчик уже собирался “всё переделывать”. На деле — конфликт одной строки в старом компоненте. Исправил, очистил кеш — магазин снова принял первый заказ через 12 минут.

Частые вопросы (FAQ)

1. Почему появляется белый экран без ошибок?

Обычно это фатальная ошибка PHP, но отображение ошибок отключено. Нужно включить display_errors или посмотреть файл error_log — там будет указана строка и причина сбоя.

2. Что делать, если админка не открывается?

Проверьте, подключается ли база данных, и не переполнен ли кеш. Часто помогает очистка директорий /bitrix/cache/ и /managed_cache/, а также проверка прав на запись в папку /bitrix.

3. Почему после обновления PHP сайт перестал работать?

Некоторые старые модули или шаблоны используют устаревшие функции. После перехода на PHP 8 стоит обновить ядро, а при необходимости — временно откатить версию PHP до прежней.

4. Можно ли починить сайт без доступа к админке?

Да, если есть FTP или доступ к файлам. Достаточно включить вывод ошибок в dbconn.php и проверить логи. Большинство проблем решается напрямую на уровне файлов и базы.

5. Почему хостинг пишет “ошибка 500”, а сайт не грузится?

Это общая ошибка сервера. Причина может быть в .htaccess, повреждённом модуле или нехватке памяти. Посмотрите логи Apache или Nginx — они покажут источник сбоя.

6. Как понять, что сайт заражён вирусом?

Признаки — резкое падение скорости, редиректы на другие сайты или неизвестные скрипты внизу страниц. Нужно проверить файлы через антивирус хостинга и удалить вредоносный код.

7. Можно ли восстановить сайт, если нет резервной копии?

В ряде случаев — да. На хостинге часто хранятся автоматические бэкапы за последние 7 дней. Их можно запросить в поддержке и восстановить выборочно: базу или только каталог /upload.

8. Сколько стоит починить сайт, если он не открывается?

Цена зависит от причины. Если это ошибка в модуле или настройках, восстановление занимает 10–15 минут. Сложные случаи с базой, вирусами и обновлением ядра — дольше, но всё начинается с диагностики.