1C-Bitrix Site Audit Services

1C-Bitrix Site Audit

You open a project from the previous team — init.php has 3,000 lines, OnBeforeIBlockElementUpdate handlers nested inside each other, a dump.sql file of 4 gigabytes sitting in the root, and /upload/ weighs more than the database. And this is a typical situation, not an exception. An audit is the way to understand the scale of the disaster before you start investing money in improvements.

When an Audit Goes from "Nice to Have" to "Needed Yesterday"

• Switching vendors — you need to understand what the previous team left behind. Code quality, architectural decisions, ticking time bombs
• Rankings dropped — behind an organic traffic decline there are almost always concrete technical causes: duplicate pages, broken canonical, 50K junk URLs in the index
• Site is slow under load — and crashes precisely during a sale, when every minute of downtime costs money
• Suspected breach — spam being sent from the server, mobile traffic redirecting to gambling sites, unknown files in /bitrix/modules/
• Before major development — investing in a project without knowing its real condition is like building a floor without checking the foundation

Technical Audit: What We Actually Check

Most problems on Bitrix are in three places: init.php, the database, and server configuration.

init.php and event handlers — the project's main dumping ground. This is where OnAfterUserLogin, OnBeforeOrderAdd, OnAdminContextMenuShow handlers accumulate and nobody refactors them for years. One project — 47 handlers in init.php, 12 of which no longer did anything (the infoblocks had long been deleted), but continued calling CIBlockElement::GetList() on every hit.

Versions and compatibility:

• Core version — if below 22.0, update is mandatory (PHP 8.1 is not supported)
• Marketplace modules — often conflict with each other and the core after updates
• License — without an active license, there are no security updates

Server configuration:

• PHP: memory_limit < 256M — a problem for catalogs with 10K+ products. OPcache revalidate_freq = 0 in production — CPU suffers
• MySQL: innodb_buffer_pool_size should be 70–80% of RAM. query_cache on MySQL 8.0+ — removed, but often lingers in configs, generating log errors
• nginx: missing expires for static files, no gzip for JS/CSS, no fastcgi_cache

Database — this is usually where it gets interesting:

• The b_event_log table — grows to gigabytes if cleanup isn't configured
• b_search_content_text — full-text index that can weigh more than the content itself
• "Dead" tables from removed modules — b_forum_*, b_learning_* — take up space and slow down backups
• Slow query log — we enable it, wait 24 hours, analyze. A single query to b_iblock_element_property without an index can slow down the entire site

File system:

• /upload/resize_cache/ — can weigh 50–100 GB. Often stores resized versions of long-deleted images
• Backups in the root — backup_2019.tar.gz next to index.php. Accessible via direct URL. We've seen it happen
• Manually modified core files — will be overwritten on update, and custom logic silently disappears

SEO Audit: Duplicates, Canonicals, and Index Pollution

• Duplicates — filter and sorting parameters generate thousands of URLs. /catalog/?PAGEN_1=2, /catalog/?sort=price&order=asc — each indexed as a separate page
• canonical — the Bitrix SEO module can set canonical, but doesn't do it by default for parameterized URLs
• robots.txt — the default Bitrix one blocks /bitrix/, but doesn't block /search/, /personal/, /ajax/ — and there are thousands more junk pages there
• sitemap.xml — the Bitrix generator sometimes includes inactive elements and 404 pages
• Schema.org — Product, BreadcrumbList, Organization. Without structured data, search snippets are boring
• Core Web Vitals — LCP > 2.5s on mobile is the norm for an unoptimized Bitrix site. Usually caused by unoptimized images and render-blocking JS

Security Audit: Backdoors, Web Shells, and Forgotten Scripts

Vulnerability checks:

• SQL injection via $_REQUEST in custom components — previous developers don't always use $DB->ForSql()
• XSS — outputting user input without htmlspecialcharsbx()
• File uploads — custom forms that don't validate MIME type and extension. Upload a .php as an "image" — get a web shell

Typical findings:

• "Proactive Protection" module disabled — WAF isn't working, intrusion log is empty
• Admin panel accessible without IP restrictions — /bitrix/admin/ open to the entire internet
• adminer.php or phpMyAdmin in the site root — forgotten after migration
• Obfuscated code in .htaccess — mobile traffic redirect via RewriteCond %{HTTP_USER_AGENT}
• Modified core files — include.php in modules with inserted eval(base64_decode(...))

Performance Audit

Server side:

• Profiling via Blackfire or Tideways — we see which functions consume CPU. Often it's CIBlockElement::GetList() in a loop — the classic N+1
• Cache: OPcache hit rate, Memcached, Bitrix managed cache. If the composite site cache is invalidated on every order — it's useless
• Bitrix agents — if agents_use_crontab isn't enabled, agents execute on user hits. A heavy agent = a slowdown for a random visitor

Load testing:

• Baseline RPS, degradation at 2x, 5x load
• How does the site behave when the limit is exceeded — graceful degradation or 502 Bad Gateway?

Code Audit

We evaluate custom development from previous teams:

• Are they using D7 ORM or slapping $DB->Query() bypassing everything
• PSR-12, autoloading, module structure — or everything in one file
• N+1 — GetList() inside while($arItem = $rsItems->Fetch()) — a classic
• Modified core files — bitrix/modules/sale/lib/ with manual edits. Everything breaks on update
• "Temporary" solutions living their third year — // TODO: refactor from 2021

Report Format

Each issue: what we found → where → how it impacts → how to fix → effort estimate.

How We Conduct It

1. Access — Bitrix panel, SSH, database, Yandex.Webmaster, Search Console
2. Automation — Bitrix "Quality Monitor," Screaming Frog, GTmetrix, security scanners. Catch 60% of issues
3. Manual analysis — the remaining 40%. Architecture, code, business logic, configuration — this is hands-on only
4. Report — systematization, priorities, recommendations
5. Discussion — meeting with the client, answering questions, remediation plan

Audit Types and Timelines

The result is not a stack of papers, but an actionable guide with specific tasks and priorities.