Професійний рерайт описів товарів для 1С-Бітрікс

Проблема дублювання контенту в каталогах Бітрікс

Ми часто бачимо каталоги, де описи товарів скопійовані у виробника або конкурентів. Пошукові системи давно навчилися визначати текстові дублі та знижують усі копії у видачі. Наприклад, в одному проекті 60% карток мали ідентичні тексти, що призвело до падіння трафіку на 40% за пів року. Наш рерайт перетворює ці тексти на унікальні — зі збереженням сенсу та точності даних. Це не синонімайзинг, а глибока переробка структури та подачі. Реалізуємо рерайт під ключ: від аналізу до завантаження готових описів в інфоблоки. Замовте консультацію — оцінимо ваш каталог безкоштовно. При цьому вартість рерайту окупається в середньому за 2-3 місяці за рахунок приросту органічного трафіку.

Як ми підходимо до рерайту

Рерайт у каталозі — не синонімайзинг (заміна слів синонімами при збереженні структури). Синонімайзинг легко визначається алгоритмами, крім того, дає химерні тексти, які погано читаються. Якісний рерайт для каталогу Бітрікс — це переробка зі зміною структури, точок зору, пріоритетів викладу.

Джерелами для рерайту служать:

• Опис з сайту виробника
• Описи конкурентів
• Технічні паспорти, сертифікати
• Відгуки покупців (виявляють реальні споживчі властивості)
• Дані з властивостей інфоблоку (характеристики)

Автоматизація збору вихідників через інфоблоки

Перед рерайтом потрібно зібрати вихідний контент. Для цього дані із зовнішніх джерел тимчасово складаються у допоміжну властивість інфоблоку:

// Додаємо службову властивість для зберігання вихідника
$iblock = new \CIBlock();
$iblock->Update(CATALOG_IBLOCK_ID, []); // без змін, просто синхронізуємо

// Додаємо властивість SOURCE_TEXT через API
\CIBlockProperty::Add([
    'NAME'      => 'Текст-вихідник для рерайту',
    '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',
]);

Після рерайту властивість очищається. Розділення на «вихідник» і «готовий текст» дозволяє кільком редакторам працювати паралельно без плутанини.

Вивантаження та завантаження описів

Вивантажуємо картки, яким потрібен рерайт, у CSV для роботи в Google Таблицях:

// Звіт: товари з низькою унікальністю (прапорець у властивості)
$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', 'Назва', 'Короткий опис', 'Повний опис']);
while ($el = $result->Fetch()) {
    fputcsv($csv, [
        $el['ID'],
        $el['NAME'],
        strip_tags($el['PREVIEW_TEXT']),
        strip_tags($el['DETAIL_TEXT']),
    ]);
}

Після рерайту — масове завантаження з CSV:

// Імпорт відредагованих текстів
if (($handle = fopen($csvFile, 'r')) !== false) {
    fgetcsv($handle); // пропускаємо заголовок
    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) {
            // Скидаємо прапорець «потребує рерайту»
            \CIBlockElement::SetPropertyValueCode($id, 'NEEDS_REWRITE', '');
            // Скидаємо кеш сторінки
            \CBitrixComponent::clearComponentCache('bitrix:catalog.element');
        }
    }
}

Після масового завантаження текстів необхідно скинути кеш задіяних компонентів, інакше сторінки віддають старі версії описів. Докладніше про кешування — в документації Бітрікс.

Як визначити пріоритетні картки для рерайту?

Не всі картки однаково цінні. Ми використовуємо пріоритизацію за кількома критеріями:

• Сторінки з високим трафіком і низькою конверсією — потенційний приріст продажів максимальний.
• Сторінки в топ-20 за комерційними запитами — невелике покращення позицій дає помітний приріст кліків.
• Найдорожчі та наймаржинальніші товари — ROI від інвестицій у контент вищий.
• Сторінки з попередженнями про дублі в Google Search Console або Яндекс Вебмастер.

Порівняння: синонімайзинг vs професійний рерайт

Синонімайзинг замінює слова за словником, зберігаючи структуру речення. Унікальність — 50-60%, читабельність страждає, алгоритми Яндекса та Google легко розпізнають такий метод. Професійний рерайт змінює структуру, додає приклади, переформульовує смисли. Унікальність досягає 80-100%, текст залишається природним. Наш підхід дозволяє отримати результат, який у 2-3 рази ефективніший за синонімайзинг за поведінковими факторами.

Чому рерайт кращий за синонімайзинг?

Синонімайзинг дає тимчасовий приріст унікальності, але не покращує читабельність і довіру. Професійний рерайт не тільки підвищує позиції, але й збільшує час на сайті на 20-40%. Наприклад, після рерайту 200 карток в одному проекті конверсія зросла на 25% за місяць. Економія витрат на просування за рахунок органічного трафіку склала близько 30%. Інвестиції в рерайт окупаються в середньому за 2-3 місяці.

Що входить у роботу з рерайту під ключ

Критерії необхідності рерайту: наявність дублів сторінок у Search Console, конверсія нижче 2% при трафіку >1000 на місяць, тексти коротші за 300 символів, товари в топ-20 не в топ-5, маржинальність товарів >30%. Якщо хоча б 3 пункти — рерайт потрібен.

• Аудит поточних описів та оцінка пріоритетів
• Збір вихідних матеріалів (виробники, конкуренти, паспорти, відгуки)
• Написання унікальних текстів (середній або глибокий рерайт)
• Завантаження готових описів в інфоблоки Бітрікс
• Скидання кешу компонентів каталогу
• Налаштування додаткових властивостей для відстеження статусу
• Навчання редакторів роботі з системою
• Гарантія унікальності (перевірка на антиплагіат)

Орієнтовні терміни

Чому варто замовити рерайт у нас?

Ми працюємо з Бітрікс більше 5 років, реалізували 200+ проектів з оптимізації каталогів. Наші фахівці сертифіковані за напрямом «1С-Бітрікс: Управління сайтом». Використовуємо власну методику оцінки пріоритетів та автоматизації процесів, що скорочує час рерайту на 30% порівняно з ручним підходом. Отримайте консультацію — проаналізуємо поточні описи та запропонуємо план робіт.

Розробка каталогу 1С-Бітрікс: як перетворити фільтр за 4 секунди на миттєвий відгук

В інтернет-магазині 80 000 товарів, розумний фільтр на Бітрікс гальмує — кожен клік по властивості перетворюється на 4-секундне очікування. Покупець тикає чекбокс «бренд Apple», дивиться на лоадер, що крутиться, і йде до конкурентів. Конверсія падає на 20%. Це знайомий біль. Ми займаємося розробкою каталогу 1С-Бітрікс та фільтрації: проєктуємо архітектуру, яка тримає півмільйона позицій без деградації — завдяки фасетним індексам, правильному вибору сховищ і тегованому кешуванню. Якщо ваш магазин втрачає гроші на повільному фільтрі — замовте аудит поточної архітектури, ми оцінимо проблему за один день.

Як інфоблоки впливають на продуктивність каталогу?

Інфоблоки — основа каталогу, але на проєктах із десятками тисяч товарів вони стають вузьким місцем. Стандартний bitrix:catalog.smart.filter генерує JOIN на 6–8 таблиць властивостей (b_iblock_element_property), і MySQL йде в full scan. Змінюємо підхід: на етапі проєктування визначаємо, які властивості підуть в інфоблок, а які — в Highload-блоки. Для довідкових даних (бренди, міста, розмірні сітки) використовуємо HLB: вони працюють з окремою таблицею без overhead b_iblock_element_property. Коли випадаючий список «Міста» завантажується 8 секунд через 5000 значень — це сигнал переносити їх на HLB. Правильна архітектура дає суттєву економію. Зв'яжіться з нами, щоб прикинути вигоду для вашого проєкту.

Що таке фасетний індекс і чому він важливий?

Основна продуктивність криється тут. Без фасетного індексу кожен клік по фільтру — SQL-запит із JOIN по b_iblock_element, b_iblock_element_property, b_catalog_price і ще парі таблиць. На 100 000 товарів такий запит виконується 2–4 секунди. З фасетним індексом — 30–80 мс. Згідно з офіційною документацією, фасетний індекс скорочує час виконання запиту в десятки разів (у реальних проєктах — до 50 разів). Механізм: 1С-Бітрікс створює таблицю b_catalog_smart_filter, куди складає попередньо розраховані комбінації «розділ + властивість + значення + кількість товарів». При фільтрації движок звертається до цієї плоскої таблиці замість збору даних із нормалізованої структури інфоблоків.

При налаштуванні фасетного індексу часто допускають одні й ті самі помилки. Індекс створюють не для всіх розділів, забувають налаштувати фонову переіндексацію після масового імпорту — тоді лічильники властивостей перестають відповідати реальній кількості товарів. Вмикають у фасет усі властивості підряд, навіть службові, що роздуває таблицю b_catalog_smart_filter. На каталогах понад 300 тисяч позицій її розмір може перевищувати гігабайт — без моніторингу через SHOW TABLE STATUS LIKE 'b_catalog_smart_filter' не обійтися. Висновок: фасетний індекс дає радикальне прискорення, але потребує вдумливого налаштування та автоматичної переіндексації через агент CIBlockCatalog::ReindexFacet або cron.

Чому Highload-блоки швидші за інфоблоки для довідників?

На практиці найкраща архітектура — гібридна. Товари та розділи живуть в інфоблоках — там SEO, візуальний редактор, штатні компоненти каталогу. А довідкові властивості з тисячами значень переносимо в Highload-блоки. Користувацькі дані (обране, переглянуті, порівняння) — теж у HLB, вони швидко зростають, і інфоблоки під це не заточені. Хочете дізнатися, яку архітектуру обрати для вашого каталогу? Зв'яжіться з нами — проаналізуємо структуру даних і дамо рекомендації.

SEO-фільтри: як отримати ЧПУ і не потрапити під фільтр Яндекса?

Стандартний фільтр генерує ?filter[brand]=apple&filter[color]=black — пошуковики такі URL або не індексують, або вважають дублями. А запит «ноутбуки apple чорні» — найконверсійніший низькочастотний трафік. Робимо ЧПУ: /catalog/noutbuki/brand-apple/color-black/ з унікальними title, description і H1. Не шаблонними «Купити {бренд} у Мінську», а осмисленими — з урахуванням конкретної комбінації.

• Канонічні URL — щоб /brand-apple/color-black/ і /color-black/brand-apple/ не дублювалися.
• Контроль кількості комбінацій, що індексуються — 10 властивостей по 20 значень дають мільйони сторінок, Яндекс за таке б'є фільтром.
• Автоматична sitemap для SEO-сторінок фільтрації.
• Адміністративний інтерфейс для менеджера — він сам вирішує, які перетини індексувати.

Замовте впровадження SEO-фільтрів — отримайте готовий інструмент для залучення низькочастотного трафіку зі зростанням конверсії до 30%.

Які методи дають відчутний приріст продуктивності?

• Вибірка лише потрібних полів через arSelect — жодних SELECT * по інфоблоках.
• Керований кеш із тегами: додали товар — кеш перестворився автоматично.
• Композитний кеш для анонімів: TTFB < 100 мс, HTML віддається без запуску PHP.
• Індекси на властивостях, що беруть участь у фільтрації — без них MySQL сканує b_iblock_element_property цілком.
• Моніторинг TTFB: якщо каталог відповідає довше 500 мс — ліземо в slow query log.

Що входить у комплексну розробку каталогу на 1С-Бітрікс?

Ми передаємо не просто робочий код, а повний комплект документації та інструментів для самостійного управління. До deliverables входять:

• Аудит поточної архітектури каталогу та фільтрації.
• Проєктна документація з описом схеми даних, розподілу по інфоблоках і Highload-блоках, фасетного складу.
• Готовий розумний фільтр з ajax-режимом, групуванням і збереженням стану.
• Налаштований фасетний індекс з cron-переіндексацією.
• SEO-фільтри з ЧПУ, унікальними метатегами, канонікалами та sitemap.
• Інтеграція швидкого перегляду та сортувань (AJAX, мобільна адаптація).
• Документація з експлуатації для менеджерів: як додавати властивості, керувати індексами та SEO-комбінаціями.
• Гарантійна підтримка 30 днів після здачі — виправляємо інциденти та відповідаємо на запитання.

Як ми розробляємо каталог: покроковий план

Ми не просто ставимо компоненти. Процес включає:

1. Аудит поточного каталогу — розбір структури властивостей, виявлення вузьких місць, перевірка індексів і кешу.
2. Проєктування архітектури — розподіл даних між інфоблоками та HLB, визначення фасетного складу.
3. Розробка розумного фільтра — кастомізація шаблону, ajax-режим, групування, збереження стану.
4. Налаштування фасетного індексу — створення, cron-переіндексація, моніторинг.
5. SEO-фільтри — ЧПУ, метатеги, канонікали, sitemap.
6. Інтеграція швидкого перегляду та сортувань — AJAX-модалка з фото, ціною, наявністю, попереднє завантаження при наведенні. На мобільних — bottom sheet замість попапа.
7. Навчання менеджерів — як керувати властивостями, індексами та SEO-комбінаціями.
8. Гарантійна підтримка — 30 днів після здачі.

Строки реалізації

Каталог окупається через зростання конверсії та приплив SEO-трафіку по низькочастотці. Покупець знаходить товар за два кліки, а не йде після першого тику у фільтр. Отримайте консультацію — оцінимо ваш проєкт протягом дня та надамо розрахунок вартості з roadmap робіт з розробки каталогу 1С-Бітрікс. Зв'яжіться з нами через форму на сайті — сертифіковані спеціалісти та понад 200 успішних проєктів за плечима.