Профессиональный рерайт описаний товаров для 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. Каталог на 80 000 товаров с фильтром за 4 секунды теряет около 1,2 млн рублей в год из-за ухода клиентов — такую экономию даёт правильная архитектура. Свяжитесь с нами, чтобы прикинуть выгоду для вашего проекта.

Что такое фасетный индекс и почему он важен?

Основная производительность кроется здесь. Без фасетного индекса каждый клик по фильтру — 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 успешных проектов за плечами.