Простой сайта даже в течение 1 часа может стоить e-commerce проекту от 10 000 до 500 000 рублей в зависимости от трафика и среднего чека. В 60% случаев причина недоступности кроется не в сбое дата-центра, а в некорректном изменении прав доступа или ошибке в конфигах после обновления плагинов или CMS.
Диагностика по коду ответа сервера
Первым делом смотрим на HTTP-статус: 403 Forbidden означает проблему с правами, 500 Internal Server Error — ошибку в .htaccess или PHP-скрипте, а 503 Service Unavailable часто указывает на перегрузку ресурсов или техработы хостинга. Если вы видите разница между ошибками 403, 404 и 503, вы экономите минимум 30 минут на бессмысленный перебор вариантов.
Кейс: сайт на WordPress перестал открываться после обновления плагина кэширования — сервер выдал 500 ошибку. Причина: запись в .htaccess перебила основные правила перенаправления. Решение: временное переименование файла в .htaccess_bak восстановило доступ за 2 минуты.
Экспертный вывод: никогда не начинайте правку кода, пока не определили числовой код ошибки; это база, которая отсекает 50% ложных путей поиска.
Проверка прав доступа к файлам
Стандарт безопасности для большинства Linux-хостингов: папки должны иметь права 755, а файлы — 644. Если вы случайно выставили 777 на корень сайта, многие современные панели управления (например, ISPmanager или cPanel) или системы безопасности сервера заблокируют доступ к ресурсу в целях защиты от инъекций.
Ошибка новичка: установка прав 777 для «исправления» ошибки записи в лог. Это не только опасно, но и часто ведет к тому, что сервер возвращает 403 ошибку из-за политики безопасности сервера. Правильный подход — поиск конкретного файла, требующего записи, и точечное изменение прав.
Экспертный вывод: используйте рекурсивную смену прав только в крайнем случае. Безопаснее проверить права на index.php и .htaccess вручную.
Анализ .htaccess и конфигурации Nginx
Файл .htaccess — самое уязвимое место в конфигурации Apache. Одна лишняя точка или опечатка в директиве RewriteRule мгновенно «кладет» сайт. В 40% случаев проблема возникает при попытке настроить редирект с http на https или при установке SSL-сертификата.
Пример: попытка добавить правило перенаправления с неправильным синтаксисом в строке 12 вызывает критический сбой. Чтобы быстро проверить, виноват ли конфиг, достаточно переименовать файл. Если сайт ожил (пусть и без красивых ссылок), значит, проблема в синтаксисе.
Экспертный вывод: всегда делайте бэкап .htaccess перед любым изменением. Даже один текстовый файл весом в 2 Кб может стать единственной причиной простоя всего бизнеса.
Лимиты ресурсов и PHP-ошибки
Если сайт тормозит или выдает 503 ошибку, проверьте memory_limit и max_execution_time в php.ini. Для современных CMS (WordPress, Bitrix) лимит памяти в 128 МБ часто оказывается недостаточным; оптимальный стандарт для стабильной работы — 256 МБ или 512 МБ.
Кейс: при импорте товаров в магазин сайт ушел в «недоступно». Проверка логов показала Fatal error: Allowed memory size of 134217728 bytes exhausted. Увеличение лимита до 512 МБ в панели хостинга решило проблему за 30 секунд.
Экспертный вывод: если ваш сайт работает на тяжелых темах или плагинах, стандартные настройки хостинга (часто 128 МБ) — это путь к постоянным сбоям при пиковых нагрузках.
Локальная проверка и внешние сервисы
Важно понять: сайт лежит для всех или только для вас. Ошибка «Страница недоступна» может быть следствием бана вашего IP-адреса брандмауэром сервера (например, после 5 неудачных попыток входа в админку). Проверка доступности сайта через внешние сервисы поможет исключить проблему локального DNS или кэша браузера.
Статистика показывает, что до 15% заявок в техподдержку хостингов решаются простым сбросом кэша DNS или переходом на другой IP. Если внешние мониторинги показывают статус 200 OK, значит, проблема в вашем сетевом окружении или прокси-сервере.
Экспертный вывод: прежде чем писать в поддержку, проверьте сайт с мобильного интернета (другой IP). Это сэкономит вам до 2 часов ожидания ответа тикета.
Вывод
При недоступности сайта действуйте по алгоритму: Код ошибки → Проверка внешнего доступа → Права файлов → Конфиги (.htaccess) → Лимиты PHP. Начинайте с самого простого (внешняя проверка и переименование .htaccess), так как это занимает секунды и исключает большинство проблем. Избегайте установки прав 777 на папки и не меняйте настройки сервера «наугад» — фиксируйте каждое изменение, чтобы иметь возможность откатиться. Самый надежный вариант — держать актуальный бэкап конфигурационных файлов вне основного сервера.