Content Automation: AI-Generated Descriptions for 1C-Bitrix
Every online store faces the same challenge: hundreds or thousands of products without unique descriptions. Copying competitors' texts risks penalties; manual writing is slow and expensive. The solution is integrating an AI model with Bitrix infoblock. We've set up this pipeline for 50+ projects: the system pulls product characteristics from the infoblock, builds a prompt, and returns the finished text to the product card. The time to write one description drops from 20 minutes to 20 seconds, and the content budget is reduced by up to 80%.
Our team consists of certified engineers with over 5 years of hands-on experience. We've automated catalogs ranging from household appliances to industrial equipment. REST API and infoblocks v2.0 are our daily stack. The result: organic traffic to product cards grows up to 34% within 3 months after indexing. Contact us — we'll demonstrate how it works on your data. Order an audit of your current state, and we'll propose an implementation plan.
How We Collect Data for the Prompt
The data collection process consists of several steps:
- Retrieve the infoblock element via
CIBlockElement::GetByID.
- Extract fields (name, section) and all properties, excluding technical ones like
MORE_PHOTO.
- Add the current price via
CCatalogProduct::GetOptimalPrice.
- Build a context string with line breaks.
The quality of the text is directly proportional to the quality of input data. Example implementation:
function buildProductContext(int $elementId): string {
$element = CIBlockElement::GetByID($elementId)->GetNextElement();
$fields = $element->GetFields();
$props = $element->GetProperties();
$context = "Product: {$fields['NAME']}\n";
$context .= "Catalog section: " . getSectionName($fields['IBLOCK_SECTION_ID']) . "\n";
foreach ($props as $prop) {
if (!empty($prop['VALUE']) && $prop['CODE'] !== 'MORE_PHOTO') {
$context .= "{$prop['NAME']}: {$prop['~VALUE']}\n";
}
}
// Add price for context
$price = CCatalogProduct::GetOptimalPrice($elementId);
$context .= "Price: {$price['PRICE']['PRICE']} {$price['PRICE']['CURRENCY']}\n";
return $context;
}
Properties like MORE_PHOTO and other technical ones are skipped — only semantically significant data should be included in the prompt. As the 1C-Bitrix documentation states: "An infoblock is a universal way to store structured information."
Multi-Level Prompt System
Not one prompt for all products — separate templates for each product category. Electronics and children's clothing require different tone and structure.
The prompt system with inheritance:
- Base prompt: general instructions on style, forbidden phrases, and structure.
- Category prompt: specifics of the category (technical language for electronics, emotional for lifestyle products).
- Infoblock prompt: store specifics (brand's unique voice).
If a category prompt is not set, the prompt from the parent category is used, then the base one.
| Level |
Purpose |
Example Parameters |
| Base |
Tone, structure, restrictions |
Length 200–350 words, no hyperboles |
| Category |
Category specifics |
Emotionality, typical characteristics |
| Infoblock |
Brand's unique voice |
Brand phrases, tone of voice |
Formatting and Output Structure
Asking AI to return pure HTML text is unreliable — the model may break the structure. It's better to request structured JSON:
{
"preview_text": "Short description up to 100 words for listing",
"detail_text": "Full description 200–350 words with HTML formatting",
"bullet_points": ["key advantage 1", "key advantage 2"],
"target_audience": "Who this product is for"
}
JSON mode is available in OpenAI via response_format: {type: "json_object"}. Bullet points are used for the "Advantages" block on the product card via an infoblock property of type S with the MULTIPLE flag.
How to Organize Batch Generation?
GPT-4o-mini has a 128K token context window. You can send a batch of several products in one request — this reduces overhead from system tokens:
Describe the following 5 products. Return a JSON array of 5 objects...
[product 1]
[product 2]
...
A batch of 5 products saves up to 30% of tokens on system instructions. But if an error occurs, the entire batch is lost — we implement retry with escalation and limit batches to 3–5 products maximum.
Why Is Prompt Testing Important?
For highly competitive categories, it's worth testing different prompts:
- Group A: technical style (specifications → benefits)
- Group B: emotional style (lifestyle → technical details)
Bitrix supports A/B testing via the marketing module, but it's easier to store the prompt variant in a product property and measure conversion through goals in Yandex.Metrica.
Case Study: Generating Descriptions for 28,000 SKUs from Our Practice
Challenge: household appliances, 3 categories (large, small, climate), different text requirements.
Implementation:
- 3 category prompts developed with a marketer in 2 days
- GPT-4o-mini for the bulk (80%), GPT-4o for the top 100 SKUs by revenue
- Batches of 3 products, 8 parallel workers
- Total generation time for 28,000 descriptions: 14 hours
Result: organic traffic to product cards increased by 34% within 3 months after indexing. Content budget savings up to 80% compared to manual writing. Request a consultation — we'll select the optimal configuration for your store.
What's Included in the Work
- Prompt system design: analysis of your catalog, development of base and category templates
- Infoblock integration: context collector, data transmission to AI, writing results back to element properties
- Batch generator: queue task management, retry processing, error logging
- Quality control: moderation of the first 100 descriptions, checklist setup
- Training and documentation: system handover, operational instructions, one-month support
Timeline
| Phase |
Duration |
| Prompt system design and iterations |
2–4 days |
| Product context collector, infoblock integration |
1–2 days |
| Batch generator, queues, retry |
1–2 days |
| Quality control, moderation |
1 day |
| A/B tests, analytics |
2–3 days (optional) |
Total: 5–9 business days until first productive generation.
Get a consultation on content automation for your store — our engineers will help you choose the optimal solution. Contact us, and we'll show you how it works on your data.
1C-Bitrix Catalog Development: How to Transform a 4-Second Filter into Instant Response
In an online store with 80,000 products, the smart filter on Bitrix is sluggish — every click on a property turns into a 4-second wait. The customer clicks the 'Apple brand' checkbox, watches the spinning loader, and leaves for competitors. Conversion drops by 20%. This is a familiar pain. We specialize in 1C-Bitrix catalog development and filtering: we design architectures that handle half a million items without degradation — through faceted indexes, proper storage selection, and tagged caching. If your store is losing money due to a slow filter — order an audit of the current architecture, and we'll assess the problem in one day.
How Do Information Blocks Affect Catalog Performance?
Information blocks are the foundation of the catalog, but on projects with tens of thousands of products, they become a bottleneck. The standard bitrix:catalog.smart.filter generates JOINs on 6–8 property tables (b_iblock_element_property), leading MySQL into a full scan. We change the approach: during design, we determine which properties go into the information block and which into Highload blocks. For reference data (brands, cities, size charts) we use HLB: they work with a separate table without the overhead of b_iblock_element_property. When a 'Cities' dropdown loads for 8 seconds due to 5000 values — that's a signal to move them to HLB. A catalog of 80,000 products with a 4-second filter loses significant revenue annually due to customer attrition — the right architecture delivers that kind of savings. Contact us to estimate the benefit for your project.
What Is the Faceted Index and Why Is It Important?
The core performance lies here. Without a faceted index, every filter click is an SQL query with JOINs on b_iblock_element, b_iblock_element_property, b_catalog_price, and a few more tables. On 100,000 products, such a query takes 2–4 seconds. With a faceted index — 30–80 ms. According to official documentation, the faceted index reduces query execution time by tens of times (in real projects — up to 50 times). The mechanism: 1C-Bitrix creates a table b_catalog_smart_filter where it stores pre-calculated combinations of 'section + property + value + product count'. When filtering, the engine accesses this flat table instead of collecting data from the normalized structure of information blocks.
Common mistakes when configuring the faceted index include not creating the index for all sections, forgetting to set up background reindexing after bulk imports — causing property counters to mismatch the actual product count. Including all properties in the facet, even service ones, bloats the b_catalog_smart_filter table. On catalogs with over 300,000 items, its size can exceed a gigabyte — monitoring via SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' is essential. Conclusion: the faceted index provides radical acceleration, but requires careful configuration and automatic reindexing via the agent CIBlockCatalog::ReindexFacet or cron.
Why Are Highload Blocks Faster Than Information Blocks for Reference Data?
| Criterion |
Information Block (IB) |
Highload Block (HLB) |
| Property storage |
b_iblock_element_property table |
Separate flat table per HLB |
| Filter speed on 50k products |
~500–800 ms (with facet) |
~80–150 ms (without facet) |
| SEO support (URL, templates) |
Full |
None (only reference data) |
| Recommended for |
Products, sections, main properties |
Reference data (brands, cities), custom data |
When Information Blocks Are Preferred Over HLB
Highload blocks do not generate SEO-friendly URLs and lack a visual editor. If the reference data requires separate pages (e.g., brands with unique H1s), use information blocks. HLB is strictly for service data that does not need indexing.
In practice, the best architecture is hybrid. Products and sections live in information blocks — there you have SEO, visual editor, and standard catalog components. Reference properties with thousands of values are moved to Highload blocks. User data (favorites, viewed items, comparisons) also go to HLB — they grow quickly, and information blocks are not designed for that. Want to know which architecture to choose for your catalog? Contact us — we'll analyze your data structure and provide recommendations.
SEO Filters: How to Get SEO-Friendly URLs and Not Get Penalized by Yandex?
The standard filter generates ?filter[brand]=apple&filter[color]=black — search engines either do not index such URLs or consider them duplicates. But the query 'black apple laptops' is the most converting low-frequency traffic. We create SEO-friendly URLs: /catalog/laptops/brand-apple/color-black/ with unique title, description, and H1. Not template-based 'Buy {brand} in Minsk', but meaningful ones reflecting the specific combination.
- Canonical URLs — to prevent
/brand-apple/color-black/ and /color-black/brand-apple/ from duplicating.
- Control of the number of indexed combinations — 10 properties with 20 values each yield millions of pages; Yandex penalizes that.
- Automatic sitemap for SEO filter pages.
- Admin interface for the manager — they decide which intersections to index.
Order the implementation of SEO filters — get a ready-made tool for attracting low-frequency traffic with conversion growth up to 30%.
What Methods Provide a Significant Performance Boost?
- Fetching only necessary fields via
arSelect — no SELECT * on information blocks.
- Managed tag-based caching: when a product is added, the cache is automatically rebuilt.
- Composite cache for anonymous users: TTFB < 100 ms, HTML is served without running PHP.
- Indexes on properties used in filtering — without them MySQL scans the entire
b_iblock_element_property table.
- TTFB monitoring: if the catalog responds slower than 500 ms, we check the slow query log.
What Is Included in Comprehensive Catalog Development on 1C-Bitrix
We deliver not just working code, but a complete set of documentation and tools for independent management. Deliverables include:
- Audit of current catalog and filtering architecture.
- Project documentation describing data schema, distribution across information blocks and Highload blocks, and facet composition.
- Ready smart filter with AJAX mode, grouping, and state persistence.
- Configured faceted index with cron reindexing.
- SEO filters with SEO-friendly URLs, unique meta tags, canonicals, and sitemap.
- Integration of quick view and sorting (AJAX, mobile adaptation).
- Operational documentation for managers: how to add properties, manage indexes and SEO combinations.
- 30-day warranty support after delivery — we fix incidents and answer questions.
How We Develop a Catalog: Step-by-Step Plan
We don't just install components. The process includes:
- Audit of the current catalog — analysis of property structure, identification of bottlenecks, checking indexes and cache.
- Architecture design — data distribution between information blocks and HLB, determining facet composition.
- Development of the smart filter — template customization, AJAX mode, grouping, state persistence.
- Faceted index configuration — creation, cron reindexing, monitoring.
- SEO filters — SEO-friendly URLs, meta tags, canonicals, sitemap.
- Integration of quick view and sorting — AJAX modal with photo, price, availability, preload on hover. On mobile — bottom sheet instead of popup.
- Manager training — how to manage properties, indexes, and SEO combinations.
- Warranty support — 30 days after delivery.
Implementation Timeline
| Task |
Estimated Duration |
| Smart filter configuration |
3–5 days |
| Faceted search |
2–3 days |
| SEO filters |
1–2 weeks |
| Quick view |
3–5 days |
| Custom catalog template |
1–2 weeks |
| Migration to Highload blocks |
2–4 weeks |
| Comprehensive catalog development |
4–8 weeks |
The catalog pays off through conversion growth and an influx of SEO traffic from low-frequency queries. The customer finds the product in two clicks, rather than leaving after the first click on the filter. Get a consultation — we will evaluate your project within a day and provide a project plan and roadmap for 1C-Bitrix catalog development. Contact us through the form on the website — certified specialists with over 200 successful projects.