Технический аудит сайта: что проверяют и что обычно находят

За полтора года мы провели больше 60 технических аудитов сайтов на Битрикс. На 49 из них нашли хотя бы одну проблему, о которой владелец не знал. На 17 — критические: то, что могло обрушить магазин в любой момент. Рассказываем, что именно проверяем и почему это важно.

Весной 2024 года позвонил клиент — владелец интернет-магазина сантехники. «Сергей, нашёл фрилансера, который сделает технический аудит сайта за 2500 рублей. Стоит взять?» Я спросил: «А что именно он будет проверять?» Пауза. «Ну... написал — технический аудит. Скорость загрузки, мета-теги, заголовки».

Оказалось — фрилансер имел в виду SEO-аудит. Полезная вещь, но к серверу никакого отношения. А у клиента в тот момент диск на сервере был заполнен на 91%. Бэкапы создавались, но уже три недели не записывались — места не хватало. Последняя рабочая копия — месячной давности.

Мы обнаружили это случайно: клиент написал по другому поводу. За сорок минут расчистили диск, убедились, что бэкапы пошли. Обошлось. Но могло не обойтись.

За полтора года мы провели больше 60 технических аудитов сайтов на Битрикс. На 49 нашли хотя бы одну проблему, которую владелец не видел. На 17 — критические. Ниже — что именно мы проверяем и что из этого выходит.

Почему «технический аудит» — это не то, что вы думаете

Слово «аудит» используют все кому не лень. SEO-специалисты проводят «технический аудит сайта» и проверяют robots.txt, скорость по PageSpeed и наличие H1. Разработчики смотрят качество кода. Хостинги рапортуют: «у вас всё работает» — и это правда, у них всё работает.

Технический аудит сайта в нашем понимании — это проверка инфраструктуры. Сервер, база данных, настройки, резервные копии, безопасность. То, что не видно в браузере. То, о чём хостинг не расскажет, потому что это не его зона ответственности.

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

Что входит в технический аудит сайта: 6 блоков проверки

Мы структурируем проверку в шесть независимых блоков. Каждый — своя зона рисков.

1. Состояние сервера

Сколько свободного места на диске и куда оно уходит. Нагрузка на процессор и память: нормальная рабочая или хроническая с пиками. Какая операционная система и когда в последний раз обновлялась. Лимиты PHP, настройки MySQL или MariaDB — под ваш реальный каталог и трафик, а не под «стандартный сайт» из комплекта хостинга.

2. Резервные копии

Создаются ли вообще? Как часто и куда сохраняются — только на сам сервер или куда-то ещё? Проверялось ли восстановление хотя бы один раз? Последний пункт — ключевой. Бэкап, который никогда не тестировался, — это лотерея с неизвестным исходом.

3. Безопасность

Версии Битрикс и ОС: насколько устарели и есть ли для них известные уязвимости. Какие порты и доступы открыты наружу. Защита от брутфорса на форму входа и от ботовых атак на каталог. SSL-сертификат: действует сейчас, обновляется автоматически или однажды закончится неожиданно.

4. Производительность

Реальное время генерации страниц на сервере — не оценка PageSpeed, а фактический серверный ответ. Работает ли кэширование и насколько эффективно. Есть ли медленные запросы к базе данных, которые тормозят всё остальное. Как обмен с 1С влияет на нагрузку в рабочие часы.

5. Мониторинг и оповещения

Есть ли мониторинг вообще? Кто получает уведомление, если сайт упал в 3 ночи? Как быстро сбой обнаруживается — сразу или когда клиенты уже в гневе звонят? Без мониторинга время реакции на падение — случайная величина. Иногда час, иногда полдня.

6. Чистота и порядок

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

Итого — больше 30 параметров. За 24 часа мы проходим все шесть блоков и составляем отчёт с оценкой по каждому пункту.

Что мы находим на аудитах: топ-5 реальных проблем

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

Диск заполнен больше 80% — 46% случаев

Виновники одни и те же: старые бэкапы, которые никто не чистил, логи за несколько лет и кэш, накопившийся быстрее, чем очищался. Когда диск переваливает за 95%, Битрикс не может писать кэш, MySQL не справляется с временными таблицами — и сайт начинает сыпать ошибками. Потом падает.

Самое неприятное: при таком сценарии последний рабочий бэкап нередко оказывается двухнедельной давности. Более свежие просто не создавались — места не было. И никто об этом не знал.

Битрикс или ОС не обновлялись больше 6 месяцев — 61% случаев

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

Из 47 взломов магазинов на Битрикс, которые мы разбирали за два года, 40 произошли на версиях, для которых патч уже существовал и был доступен. Его просто не поставили.

Резервные копии не проверялись ни разу — 38% случаев

Бэкапы есть, создаются регулярно — но последний раз восстанавливали из них никогда. Это как огнетушитель, который висит на стене с 2020 года. Может работать. Может нет.

На трёх аудитах из тридцати мы обнаружили, что резервные копии повреждены и не восстанавливаются. Люди были уверены, что застрахованы — защиты не было.

Мониторинга нет — 54% случаев

Владелец узнаёт о падении сайта от клиентов. Или сам замечает через 2–3 часа. За это время — потерянные заказы, брошенные корзины, испорченная репутация у тех, кто хотел купить и не смог.

Настройка базового мониторинга занимает час и стоит копейки или вообще бесплатно. Но до аудита этого не было сделано у больше чем половины магазинов, которые к нам приходили.

Лимиты PHP не настроены под нагрузку — 55% случаев

Стандартный лимит памяти для PHP — 128 мегабайт. При генерации страницы каталога с фильтром Битрикс легко требует 200–300. Процесс упирается в лимит, начинает использовать медленный файловый своп — и страница, которая должна грузиться секунду, грузится три-четыре.

Поднять лимит и настроить OPcache несложно. Но без аудита никто не знает, что именно это тормозит сайт. Разработчик смотрит код. Хостер смотрит свою инфраструктуру. А настройки — в промежутке, где никто не смотрит.

Три проверки, которые можно сделать прямо сейчас

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

Проверка 1. Дата последнего обновления Битрикс

Войдите в административную панель вашего сайта. Перейдите: «Marketplace» → «Обновление платформы». Посмотрите дату последнего обновления. Если больше 3 месяцев назад — повод поговорить с тем, кто обслуживает ваш сервер.

Проверка 2. Куда сохраняются резервные копии

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

Проверка 3. Тест скорости без Wi-Fi

Откройте главную страницу вашего магазина с телефона, отключив Wi-Fi — только мобильный интернет. Засеките время до полной загрузки страницы. Больше 4 секунд — серверные настройки, скорее всего, не оптимизированы под вашу нагрузку.

Три проверки дадут первичную картину. Если хотя бы одна показала тревожный сигнал — стоит смотреть глубже.

Где заканчивается «сам» и нужен специалист

Три проверки выше — это поверхность. Дальше идёт то, для чего нужен прямой доступ к серверу.

• Анализ логов ошибок в реальном времени — что происходит на сервере прямо сейчас
• Нагрузка на CPU и память по времени суток — когда пики и с чем они связаны
• Конфигурация PHP и MySQL под реальную нагрузку вашего магазина
• Сканирование файлов на предмет изменений и вредоносного кода
• Тест восстановления из резервной копии — реально ли она работает
• Настройка мониторинга, если его нет

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

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

Мы проводим технический аудит сайта бесплатно. Без скрытых условий и без обязательства что-то покупать.

1. Заявка. Оставляете запрос на support.orangecode.ru — пишете, что хотите аудит.
2. Созвон. Связываемся в течение 2 часов, уточняем: какой хостинг, что беспокоит, когда удобно провести.
3. Доступ. Вы предоставляете доступ к серверу на время аудита — через отдельного пользователя с ограниченными правами. Как именно — объясним.
4. Аудит. Проверяем все шесть блоков в течение 24 часов.
5. Отчёт. Получаете документ: что нашли, что критично, что желательно исправить, что несрочно. С объяснениями, без жаргона.

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

Что вы получаете на выходе

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

После аудита у вас есть реальная картина: что работает нормально, что требует внимания в ближайший месяц, что критично и нужно исправить прямо сейчас.

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

Частые вопросы о техническом аудите сайта