Professional Product Description Rewriting for 1C-Bitrix Catalogs

The Problem of Duplicate Content in Bitrix Catalogs

We often see catalogs where product descriptions are copied from manufacturers or competitors. Search engines have long learned to detect text duplicates and lower all copies in rankings. For example, in one project, 60% of product cards had identical texts, which led to a 40% drop in traffic over six months. Our rewriting transforms these texts into unique ones — while preserving meaning and data accuracy. This is not synonymization but a deep reworking of structure and presentation. We implement turnkey rewriting: from analysis to uploading finished descriptions into infoblocks. Get a free catalog evaluation — contact us for a consultation. The cost of rewriting typically pays for itself within 2–3 months due to organic traffic growth.

How We Approach Rewriting

Rewriting in a catalog is not synonymization (replacing words with synonyms while preserving the structure). Synonymization is easily detected by algorithms and produces awkward, hard-to-read texts. High-quality rewriting for a Bitrix catalog involves reworking with changes in structure, points of view, and presentation priorities.

Sources for rewriting include:

• Manufacturer's website descriptions
• Competitor descriptions
• Technical passports, certificates
• Customer reviews (reveal real consumer properties)
• Data from infoblock properties (characteristics)

Automating Source Collection via Infoblocks

Before rewriting, we need to collect source content. For this, data from external sources is temporarily stored in an auxiliary infoblock property:

// Add a service property for storing source text
$iblock = new \CIBlock();
$iblock->Update(CATALOG_IBLOCK_ID, []); // no changes, just sync

// Add SOURCE_TEXT property via API
\CIBlockProperty::Add([
    'NAME'      => 'Source text for rewriting',
    'CODE'      => 'SOURCE_TEXT',
    'IBLOCK_ID' => CATALOG_IBLOCK_ID,
    'PROPERTY_TYPE' => 'S',
    'ROW_COUNT'     => 10,
    'COL_COUNT'     => 60,
    'FILTRABLE'     => 'N',
    'SEARCHABLE'    => 'N',
    'IS_REQUIRED'   => 'N',
    'ACTIVE'        => 'Y',
]);

After rewriting, the property is cleared. Separating "source" and "finished text" allows multiple editors to work in parallel without confusion.

Export and Import of Descriptions

We export cards that need rewriting to CSV for work in Google Sheets:

// Report: products with low uniqueness (flag in property)
$result = \CIBlockElement::GetList(
    ['NAME' => 'ASC'],
    [
        'IBLOCK_ID' => CATALOG_IBLOCK_ID,
        'ACTIVE'    => 'Y',
        'PROPERTY_NEEDS_REWRITE' => '1',
    ],
    false,
    ['nPageSize' => 500],
    ['ID', 'NAME', 'PREVIEW_TEXT', 'DETAIL_TEXT', 'PROPERTY_NEEDS_REWRITE']
);

$csv = fopen('php://output', 'w');
fputcsv($csv, ['ID', 'Name', 'Preview Text', 'Detail Text']);
while ($el = $result->Fetch()) {
    fputcsv($csv, [
        $el['ID'],
        $el['NAME'],
        strip_tags($el['PREVIEW_TEXT']),
        strip_tags($el['DETAIL_TEXT']),
    ]);
}

After rewriting, we do a bulk import from CSV:

// Import edited texts
if (($handle = fopen($csvFile, 'r')) !== false) {
    fgetcsv($handle); // skip header
    while (($row = fgetcsv($handle)) !== false) {
        [$id, , $previewText, $detailText] = $row;
        $id = (int)$id;
        if (!$id) continue;

        $el = new \CIBlockElement();
        $result = $el->Update($id, [
            'PREVIEW_TEXT'      => htmlspecialchars_decode($previewText),
            'DETAIL_TEXT'       => htmlspecialchars_decode($detailText),
            'DETAIL_TEXT_TYPE'  => 'html',
        ]);

        if ($result) {
            // Clear the 'needs rewrite' flag
            \CIBlockElement::SetPropertyValueCode($id, 'NEEDS_REWRITE', '');
            // Clear page cache
            \CBitrixComponent::clearComponentCache('bitrix:catalog.element');
        }
    }
}

After bulk text upload, you must clear the cache of affected components — otherwise pages serve old versions of descriptions. More about caching in the Bitrix documentation.

How to Prioritize Cards for Rewriting?

Not all cards are equally valuable. We prioritize based on several criteria:

• Pages with high traffic and low conversion — potentially maximum sales increase.
• Pages in the top 20 for commercial queries — a slight improvement in positions yields noticeable click growth.
• The most expensive and high-margin products — higher ROI from content investment.
• Pages with duplicate warnings in Google Search Console or Yandex Webmaster.

Comparison: Synonymization vs Professional Rewriting

Synonymization replaces words from a dictionary, keeping sentence structure. Uniqueness is 50-60%, readability suffers, and Yandex and Google algorithms easily detect such methods. Professional rewriting changes structure, adds examples, and rephrases meanings. Uniqueness reaches 80-100%, and the text remains natural. Our approach yields results that are 2-3 times more effective than synonymization in terms of behavioral factors.

Why Rewriting is Better than Synonymization?

Synonymization provides a temporary uniqueness boost but does not improve readability or trust. Professional rewriting not only improves rankings but also increases time on site by 20-40%. For example, after rewriting 200 cards in one project, conversion increased by 25% in a month. Savings on promotion costs due to organic traffic amounted to about 30%. Investment in rewriting pays back within 2-3 months on average.

What is Included in Turnkey Rewriting

Criteria for needing rewriting: duplicate pages in Search Console, conversion below 2% with traffic over 1000 per month, texts shorter than 300 characters, products in the top 20 but not top 5, margin above 30%. If at least 3 points apply, rewriting is needed.

• Audit of current descriptions and priority assessment
• Collection of source materials (manufacturers, competitors, passports, reviews)
• Writing unique texts (medium or deep rewriting)
• Uploading finished descriptions to Bitrix infoblocks
• Clearing catalog component cache
• Setting up additional properties for status tracking
• Training editors on the system
• Uniqueness guarantee (anti-plagiarism check)

Estimated Timelines

Why Order Rewriting from Us?

We have been working with Bitrix for over 5 years and have completed 200+ catalog optimization projects. Our specialists are certified in "1C-Bitrix: Site Management." We use our own methodology for priority assessment and process automation, reducing rewriting time by 30% compared to manual approaches. Contact us for a free analysis of your current descriptions and a proposed work plan.

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?

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:

1. Audit of the current catalog — analysis of property structure, identification of bottlenecks, checking indexes and cache.
2. Architecture design — data distribution between information blocks and HLB, determining facet composition.
3. Development of the smart filter — template customization, AJAX mode, grouping, state persistence.
4. Faceted index configuration — creation, cron reindexing, monitoring.
5. SEO filters — SEO-friendly URLs, meta tags, canonicals, sitemap.
6. Integration of quick view and sorting — AJAX modal with photo, price, availability, preload on hover. On mobile — bottom sheet instead of popup.
7. Manager training — how to manage properties, indexes, and SEO combinations.
8. Warranty support — 30 days after delivery.

Implementation Timeline

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.