Послуги з комплексного аудиту сайтів на 1С-Бітрікс

Аудит сайту Бітрікс: знайти проблеми, поки вони не знайшли вас

Уявіть: ви відкриваєте проект від попередньої команди — у init.php 3000 рядків, обробники OnBeforeIBlockElementUpdate вкладені один в одного, в корені сайту лежить dump.sql на 4 гігабайти, а каталог upload/ важить більше бази. Ми бачимо такі проекти щотижня. І це не виняток — це норма для Бітрікса після кількох років активної розробки без контролю якості. Аудит сайту на 1С‑Бітрікс — єдиний спосіб об'єктивно оцінити реальний стан проекту перед тим, як вкладати гроші в доопрацювання або масштабування. Він виявляє вузькі місця в коді, базі даних, конфігурації сервера та безпеки. А головне — показує, що виправити, щоб сайт працював швидше і не падав у пік продажів. Регулярний аудит сайту 1С‑Бітрікс окупається за 2–3 місяці: економія на хостингу може бути значною, а час на виправлення помилок скорочується втричі порівняно з реактивним підходом.

Як проводиться аудит сайту на 1С-Бітрікс?

Навіщо потрібен аудит сайту на Бітрікс?

Зміна підрядника — ви берете проект від іншої команди і не знаєте, які «міни» залишені в коді. Обробники подій у init.php, забуті скрипти, модифіковані файли ядра — все це може вистрілити в найнесподіваніший момент. Ми одного разу знайшли в одному проекті 47 обробників, з яких 12 були мертвими — інфоблоки видалені, а код продовжував смикати CIBlockElement::GetList() на кожному хіті. Кілька років такого навантаження — близько 12 мільйонів зайвих запитів до бази.

Падіння позицій — за просіданням органіки майже завжди стоять технічні причини: дублі сторінок, зламаний canonical, 50 тисяч сміттєвих URL в індексі. Аудит покаже, де Google втрачає ваш трафік. В одному типовому проекті кількість URL з параметрами сортування сягала 300 000 — кожна комбінація PAGEN_1=2&sort=price потрапляла в індекс окремо.

Гальма під навантаженням — сайт падає саме в розпал розпродажу, коли кожна хвилина простою коштує грошей. Ми знаходимо причини: неоптимізовані запити, відсутність кешу, важкі агенти. Наприклад, один запит до b_iblock_element_property без індексу може додавати 3–4 секунди до часу генерації сторінки.

Підозра на злом — спам-розсилки з сервера, редиректи на казино в мобільному трафіку, незрозумілі файли в /bitrix/modules/. Аудит безпеки виявить бекдори та веб-шелли.

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

Що приховується в init.php та базі даних?

Більша частина проблем на Бітріксі зосереджена в трьох місцях: init.php, база даних і конфігурація сервера. Ми розкладаємо кожен шар детально.

init.php і обробники подій — головне звалище коду. Там накопичуються OnAfterUserLogin, OnBeforeOrderAdd, OnAdminContextMenuShow, які ніхто не рефакторить роками. В одному проекті ми знайшли 47 обробників, з них 12 — мертві (інфоблоки видалені, але код продовжував смикати CIBlockElement::GetList() на кожному хіті). Аудит вичищає такий баласт і знижує навантаження на сервер.

Версії та сумісність. Версія ядра — якщо нижче 22.0, оновлення критичне (PHP 8.1 не підтримується). Модулі з Маркетплейсу часто конфліктують один з одним після оновлення. Ліцензія без активного ключа — немає оновлень безпеки.

Конфігурація сервера. PHP memory_limit < 256M — проблема на каталогах від 10 тисяч товарів. OPcache revalidate_freq = 0 в продакшні — процесор перевантажений. MySQL innodb_buffer_pool_size має займати 70–80% RAM. На MySQL 8.0+ query_cache видалено, але в старих конфігах залишається — генерує помилки в логах. Відсутність expires для статики в nginx — кожне оновлення сторінки завантажує JS/CSS заново.

База даних — тут найцікавіше. Таблиця b_event_log розростається до гігабайтів без налаштування очищення. В одному проекті вона займала 12 ГБ, хоча щодня туди записувалося 500 000 записів. Таблиця b_search_content_text з повнотекстовим індексом може важити більше самого контенту. Таблиці від видалених модулів (b_forum_*, b_learning_*) займають місце і гальмують бекапи. Вмикаємо slow query log, чекаємо добу, аналізуємо. Один запит до b_iblock_element_property без індексу може гальмувати весь сайт — ми фіксували затримки до 7 секунд на сторінку.

Файлова система. /upload/resize_cache/ — важить 50–100 ГБ, зберігає ресайзи давно видалених картинок. Бекапи в корені — backup_old.tar.gz поруч з index.php, доступний за прямим посиланням. Файли ядра, змінені вручну, перезапишуться при оновленні, і кастомна логіка мовчки зникне.

Як SEO-аудит прибирає дублі та сміття з індексу?

Параметри фільтрів і сортувань генерують тисячі URL: /catalog/?PAGEN_1=2, /catalog/?sort=price&order=asc — кожен в індексі як окрема сторінка. Модуль SEO Бітрікс вміє ставити canonical, але за замовчуванням не робить це для параметризованих URL. Стандартний robots.txt закриває /bitrix/, але не закриває /search/, /personal/, /ajax/ — там ще тисячі сміттєвих сторінок. Генератор sitemap.xml Бітрікса іноді включає неактивні елементи і 404-сторінки. Без структурованих даних Schema.org (Product, BreadcrumbList, Organization) снипети в видачі нудні. Core Web Vitals: LCP > 2.5 с на мобільних — звичайна справа для неоптимізованого Бітрікса; винні неоптимізовані зображення і блокуючий JS. В середньому після аудиту ми скорочуємо індекс на 60–80% — видаляємо дублі, налаштовуємо canonical і правильні noindex. Замовте SEO-аудит, щоб ваш сайт почав отримувати трафік з тих запитів, які втрачаєте зараз.

Навіщо перевіряти безпеку Бітрікса?

SQL-ін'єкції через $_REQUEST в кастомних компонентах — попередні розробники не завжди використовують $DB->ForSql(). XSS при виведенні користувацького вводу без htmlspecialcharsbx(). Кастомні форми завантаження файлів, що не перевіряють MIME-тип і розширення — завантажив .php як «картинку» і отримав веб-шелл. Типові знахідки: вимкнений модуль «Проактивний захист» (WAF не працює, журнал вторгнень порожній), адмінка без обмеження по IP (/bitrix/admin/ відкрита всьому світу), adminer.php або phpMyAdmin в корені — забули видалити після міграції, обфускований код у .htaccess з редиректом мобільного трафіку через RewriteCond %{HTTP_USER_AGENT}, модифіковані файли ядра з вставками eval(base64_decode(...)). В одному проекті ми знайшли 23 таких файли — сайт місяцями роздавав спамний вміст через протокол AMP. Детальніше про SQL-ін'єкції та міжсайтовий скриптинг. Зв'яжіться з нами для перевірки безпеки вашого проекту — ми виявимо вразливості, які не бачать сканери.

Як ми підвищуємо продуктивність?

Профілюємо через Blackfire або Tideways — бачимо, які функції споживають CPU. Частий кандидат — CIBlockElement::GetList() в циклі (класичний N+1). Дивимось hit rate OPcache, Memcached, керованого кешу Бітрікс. Якщо кеш композитного сайту інвалідується при кожному замовленні, він непотрібний — одного разу ми скоротили число інвалідацій з 80% до 2% за рахунок правильного налаштування тегів. Агенти Бітрікс — якщо agents_use_crontab не ввімкнено, вони виконуються на хітах користувачів; важкий агент = гальмо для випадкового відвідувача. Навантажувальне тестування: базовий RPS, деградація при 2× і 5× навантаженні, поведінка при перевищенні ліміту (коректна деградація або 502 Bad Gateway?). На одному проекті ми виявили, що піковий RPS упирався в 12, а після оптимізації став 150 — зростання в 12,5 разів.

Що шукаємо в коді?

Оцінюємо кастомні розробки попередніх команд: чи використовують D7 ORM або ліплять $DB->Query() в обхід всього. PSR-12, автозавантаження, структура модулів — чи все в одному файлі. N+1 — GetList() всередині while($arItem = $rsItems->Fetch()) — класика. Модифіковані файли ядра (bitrix/modules/sale/lib/) з ручними правками — при оновленні все зламається. «Тимчасові» рішення, які живуть третій рік — // TODO: переробити від позаминулого року. В середньому на один проект ми знаходимо 15–25 проблем в коді, половина з них — з потенційною втратою даних.

Формат звіту

Як ми проводимо аудит?

1. Доступи — панель Бітрікс, SSH, база, Яндекс.Вебмастер, Search Console.
2. Автоматика — «Монітор якості» Бітрікс, Screaming Frog, GTmetrix, сканери безпеки. Ловлять 60% проблем.
3. Ручний аналіз — решта 40%. Архітектура, код, бізнес-логіка, конфігурація — це тільки руками. Кожен аудит веде senior-розробник з 10+ роками досвіду.
4. Звіт з пріоритетами.
5. Обговорення — зустріч з вами, відповіді на питання, узгодження плану усунення.

Середній час повного циклу — 5 робочих днів для технічного аудиту, до 3 тижнів для комплексного. Гарантуємо конфіденційність результатів і збереження ваших даних.

Що входить у результати?

• Документований звіт з описом кожної проблеми та рекомендаціями щодо виправлення.
• Чек-лист критичних вразливостей та їх пріоритет.
• Список пропозицій щодо оптимізації продуктивності з оцінкою ефекту.
• Консультація після аудиту — розбір результатів, пріоритизація задач.
• Доступ до результатів тестів (скріншоти, логи профілювання, raw-дані).

Види аудиту та терміни

Ми провели 50+ аудитів проектів на Бітрікс — від інтернет-магазинів до корпоративних порталів. Наш досвід показує: в середньому аудит окупається протягом 2–3 місяців за рахунок зниження витрат на хостинг (економія може бути значною) та скорочення часу на виправлення помилок (в 3 рази швидше, ніж при реактивному підході). Документація 1С-Бітрікс підтверджує, що регулярний аудит — найкращий спосіб продовжити життя проекту.

Результат — не стос паперів, а керівництво до дії з конкретними задачами та пріоритетами. Потрібен аудит вашого сайту на Бітрікс? Отримайте консультацію вже сьогодні — зв'яжіться з нами, і ми оцінимо проект безкоштовно за 1 робочий день. Замовте комплексний аудит, щоб отримати повну картину перед серйозними вкладеннями.