Landing Page Development in 1C-Bitrix
A landing page in the 1C-Bitrix ecosystem can be built in two fundamentally different ways: through the built-in landing module (also known as "Sites 24") and through a custom template on the "Website Management" engine. The choice between them determines the budget, launch speed, and ceiling of what you can do with this page in six months.
Landing Module: Block Constructor
The bitrix:landing module appeared in the "Business" edition and became the standard for quick landing pages within Bitrix. The principle of operation is a library of ready-made blocks that are dragged onto the page in a visual editor.
What's included in the standard package:
- Over 150 blocks — hero sections, galleries, price tables, timers, testimonials, maps
- CRM form binding through the
crm.site.formcomponent — a lead enters the funnel without additional setup - Built-in A/B testing mechanism: a copy of the page is created, traffic is split, statistics are collected in the "Analytics" section
- SEO fields at the page level — title, description, og-tags, canonical
- Yandex.Metrica and Google Analytics connection through standard settings
The constructor works on top of its own framework, unrelated to classic Bitrix components. Blocks are stored in the database as JSON structures, rendered through a REST wrapper. This provides isolation but simultaneously limits access to familiar development tools.
Custom Landing on a Template
An alternative approach is creating a landing page as a separate site template (/bitrix/templates/landing_custom/) with direct access to the platform API. There's no visual editor in the usual sense — content is managed through infoblocks or page properties.
What custom development provides:
- Full control over HTML/CSS/JS — no framework constructor limitations
- Connection of any Bitrix components:
bitrix:form.result.new,bitrix:catalog.section,bitrix:sale.order.ajax - Integration with the
highloadblockmodule to store applications with arbitrary structure - Arbitrary PHP logic: multi-step forms, dynamic content based on UTM tags, personalization by CRM segments
- Native work with composite cache and CDN
Technical Differences: Constructor vs Custom
| Parameter | Landing Module | Custom Template |
|---|---|---|
| Content editing | Visual drag-and-drop | Admin panel (infoblocks / properties) |
| Access to PHP | No | Full |
| CRM integration | Built-in (crm.site.form) | Via API / webhooks |
| A/B tests | Standard mechanism | Google Optimize or custom implementation |
| Launch speed | 1–3 days | 5–15 days |
| Custom JS logic | Limited (block sandbox) | Unlimited |
| Scaling | Limited by block library | Unlimited |
| Composite cache | Not supported | Full support |
| Module connection | Only through REST | Any core modules |
When the Constructor is Enough
The landing module closes the task if the landing is a typical promotional page with a lead collection form. A marketer builds the page themselves, without involving a developer. The CRM form creates a lead, a notification goes to the manager, and analytics count the conversion.
Typical scenarios for the constructor:
- A promo campaign with a limited lifespan
- Collecting applications for a webinar or event
- Quickly testing a hypothesis before developing a full section
- Internal pages for employees (surveys, registration for corporate events)
When Custom Markup is Needed
The transition to a custom template is justified when at least one of these conditions appears:
- Complex form — multi-step, dependent fields, file uploads, validation by external services (FIAS, INN)
- Dynamic content — substitution of texts and images depending on traffic source, region, interaction history
-
Catalog integration — displaying products or services through
bitrix:catalog.sectionwith filtering and sorting - High speed requirements — composite cache, Core Web Vitals optimization, lazy loading of heavy sections
- Non-standard design — animations, parallax, interactive elements that cannot be implemented within the block system
Hybrid Approach
In practice, a combination is often used: the main structure is built on a custom template, and the CRM form is connected through crm.site.form as an embedded widget. This provides full control over markup while maintaining native CRM integration without writing additional integration code.
A second variant of the hybrid is extending the constructor with custom blocks. The landing module supports registration of custom blocks through \Bitrix\Landing\Block::register(). A block is described in a YAML manifest, contains its own markup and styles, but works inside the visual editor. The approach requires initial effort to create the block, but then the marketer uses it on par with standard blocks.
Practical Recommendations
When choosing an approach, it's worth considering not only the current task but also the page's lifecycle. A landing that will live for two weeks is a candidate for the constructor. A page that will evolve, gain sections and integrations — a reason to immediately lay down a custom template.
A separate point is SEO. The constructor provides basic meta-tags but doesn't allow fine control over Schema.org micromarkup, hreflang for multilingual support, or server-side redirects. If the landing should work on organic traffic, custom development removes these limitations.