Copywriting Product Descriptions for 1C-Bitrix
Imagine: you've invested in promotion, set up filters, uploaded products, but search engines return dozens of identical cards from different stores. The manufacturer provided the text—and everyone copied it. Google and Yandex see duplicates and lower rankings. Conversion drops. The solution—unique product descriptions tailored to your assortment and audience.
We have been filling Bitrix catalogs for over 5 years. During this time, we have completed more than 150 projects—from small to large-scale. A unique description boosts conversion 2–3 times compared to template texts. The cost of the service pays off: clients typically save $200–500 per month on ad spend after implementing unique descriptions. Our pricing starts at $2 per description for basic products; a 500-product catalog typically costs $1500, recouped within 3 months through reduced ad spend. Official Bitrix documentation emphasizes that unique description is a ranking factor (see Bitrix developer guide).
Double description in Bitrix
In Bitrix, a product card stores two fields: PREVIEW_TEXT (short, up to 300 characters) and DETAIL_TEXT (full, HTML). They serve different purposes. PREVIEW_TEXT is displayed in catalog listings and used as meta-description during auto-generation. Requirements: 150–160 characters, contains the main benefit and key product parameter, no fluff.
Example of poor PREVIEW_TEXT: "You will definitely like this product for its quality and reliability. Perfect for home."
Example of effective: "Grohe Eurosmart basin mixer, chrome, monolitic spout 180 mm. Cartridge 35 mm, 5-year warranty."
DETAIL_TEXT is the full description with structure: problem → how the product solves it → specific technical parameters → applicability → package contents. For complex products, we always add tables and lists.
Why template texts fail
Template descriptions are copies from the manufacturer or competitors. Search engines quickly detect duplicates and do not rank such cards. Users also leave if the text doesn't answer their questions. According to our data, cards with unique descriptions receive 60% more views in organic search—that's 3x more than duplicate cards. Conversion to target action is 2.5–3 times higher. In fact, unique descriptions are 3 times better than template texts in terms of conversion.
Full catalog filling cycle
We provide a full cycle: from category brief to upload via API. The service includes:
- Analysis of target audience and competitors for each category
- Development of structure templates for uniformity of cards
- Writing texts with SEO requirements (uniqueness from 85%)
- Checking uniqueness via Text.ru or Advego
- Upload through standard Bitrix import (XML or REST API)
The official Bitrix documentation emphasizes that unique description is a ranking factor.
What's included in the work
- Category brief and competitor analysis
- Template development for uniform card structure
- Copywriting with 85%+ uniqueness
- Uniqueness check report
- Technical documentation for import (XML/API)
- Access to project management board
- Training session for your team (1 hour)
- Post-launch support for 30 days
Full description structure
[Buyer's problem/task]
[How this product solves the problem—specifically]
### Features and Benefits
- [fact with parameter, not epithet]
- [fact with parameter]
...
### Technical Specifications
[Table of key parameters—duplicated from infoblock properties]
### Application
[Where and how it is used]
### Package Contents
[What is included]
Text requirements by product type
Technical products (electronics, tools, plumbing):
- Specific numbers: not "powerful" but "power 2000 W"
- Technical standards and certifications
- Compatibility with other models/systems
- Installation or connection specifics
Clothing and footwear:
- Material composition and properties
- Size table in the description—buyers look for it here
- Care and washing instructions
- What to pair with (outfit)—aids cross-linking
Food products:
- Composition, nutritional value per 100g and per serving
- Cooking/usage method
- Storage conditions
- Taste and texture
What is unacceptable in Bitrix catalog descriptions
- Paraphrasing technical characteristics. Characteristics are already in infoblock properties—no need to repeat in description.
- "Wide assortment", "high quality", "affordable prices"—empty words.
- Describing the company instead of the product. "Our company since 2010..."—not needed.
- Keyword stuffing in the text.
Volume and uniqueness
| Product type |
PREVIEW_TEXT |
DETAIL_TEXT |
| Simple product |
100–150 characters |
400–800 characters |
| Technically complex product |
150–200 characters |
800–2000 characters |
| Product with many variants |
100–150 characters |
600–1200 characters |
| Premium product |
150–200 characters |
1000–3000 characters |
Uniqueness—from 85% (for technical descriptions 75–80% is sufficient).
How we industrialize copywriting
- Category brief—target audience, competitors, differentiators.
- Structure template—uniform scheme for the category.
- Upload via import—Excel → XML import or API.
- Uniqueness check before upload—automated check built into the process.
Timelines
| Scope of work |
Timelines |
| 50–100 products of one category |
5–10 working days |
| 500 products (multiple categories) |
4–6 weeks |
| Template development + brief + 100 turnkey cards |
2–3 weeks |
Example real project: filling a plumbing catalog with 600 products
We developed a template for each category (mixers, shower systems, accessories). PREVIEW_TEXT contained the key parameter (type, finish, warranty). DETAIL_TEXT included a size table, list of compatible systems, and usage scenarios. Upload via REST API took 2 days. Text uniqueness—88%. After 3 months, traffic to categories increased by 40%.
Contact us for a consultation to get a cost and timeline estimate for your catalog.
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.