Копірайтинг описів товарів для 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Копірайтинг описів товарів для 1С-Бітрікс
Середній
~1-2 тижні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1360
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    694
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    832
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1075

Уявіть: ви вклали гроші в просування, налаштували фільтри, завантажили товари, а пошуковик видає десятки однакових карток від різних магазинів. Виробник дав текст — і всі його скопіювали. Google та Яндекс бачать дублі та знижують видачу. Конверсія падає. Вихід — унікальні описи товарів, адаптовані під ваш асортимент та аудиторію.

Ми займаємося наповненням каталогів Бітрікс понад 5 років. За цей час реалізували понад 150 проєктів — від дрібних до масштабних. Унікальний опис підвищує конверсію в 2–3 рази порівняно з шаблонними текстами. При цьому витрати на послуги окупаються за рахунок зростання органічного трафіку та зниження частки відмов.

Як влаштовано подвійний опис у Бітрікс?

У Бітрікс картка товару зберігає два поля: PREVIEW_TEXT (короткий, до 300 символів) та DETAIL_TEXT (повний, HTML). Вони вирішують різні завдання. PREVIEW_TEXT виводиться у списку каталогу та використовується як мета-опис при автогенерації. Вимоги: 150–160 символів, містить головну вигоду та ключовий параметр товару, без води.

Приклад поганого PREVIEW_TEXT: "Цей товар обов'язково сподобається вам своєю якістю та надійністю. Ідеально підходить для дому." Приклад робочого: "Змішувач Grohe Eurosmart для раковини, хром, монолітний вилив 180 мм. Картридж 35 мм, гарантія 5 років."

DETAIL_TEXT — повний опис зі структурою: задача → як товар вирішує її → конкретні технічні параметри → застосовність → комплектація. Для складних товарів обов'язково додаємо таблиці та списки.

Чому шаблонні тексти не працюють?

Шаблонні описи — копія від виробника або конкурентів. Пошуковики швидко обчислюють дублі та не ранжують такі картки. Користувачі теж: якщо текст не відповідає на їхні запитання, вони йдуть. За нашими даними, картки з унікальним описом отримують на 60% більше переглядів в органічній видачі. А конверсія в цільову дію вища в 2,5–3 рази.

Повний цикл наповнення каталогу

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

  • Аналіз цільової аудиторії та конкурентів по кожній категорії
  • Розробка шаблонів структури для єдності карток
  • Написання текстів з урахуванням SEO-вимог (унікальність від 85%)
  • Перевірка унікальності через сервіси Text.ru або Advego
  • Завантаження через штатний імпорт Бітрікс (XML або REST API)

В офіційній документації Бітрікс підкреслюється, що унікальний опис є фактором ранжування.

Структура повного опису

[Завдання/проблема покупця]
[Як цей товар вирішує завдання — конкретно]
### Особливості та переваги
- [факт з параметром, не епітет]
- [факт з параметром]
...
### Технічні характеристики
[Таблиця ключових параметрів — продубльовані з властивостей інфоблоку]
### Застосування
[Де та як використовується]
### Комплектація
[Що входить у комплект]

Вимоги до текстів за типами товарів

Технічні товари (електроніка, інструмент, сантехніка):

  • Конкретні цифри: не «потужний», а «потужність 2000 Вт»
  • Технічні стандарти та сертифікати
  • Сумісність з іншими моделями/системами
  • Особливості монтажу або підключення

Одяг та взуття:

  • Склад матеріалу та його властивості
  • Таблиця розмірів в описі — покупці шукають саме тут
  • Догляд та прання
  • З чим поєднується (образ) — допомагає перелінкуванню

Продукти харчування:

  • Склад, КБЖУ на 100г та на порцію
  • Спосіб приготування/застосування
  • Умови зберігання
  • Смак та текстура

Що неприпустимо в описах Бітрікс-каталогу

  • Перефраз технічних характеристик. Характеристики вже є у властивостях інфоблоку — в описі вони не потрібні ще раз.
  • «Широкий асортимент», «висока якість», «доступні ціни» — слова-пустушки.
  • Опис компанії замість опису товару. «Наша компанія...» — не потрібно.
  • Ключові слова через кому в тексті.

Обсяг та унікальність

Тип товару PREVIEW_TEXT DETAIL_TEXT
Простий товар 100–150 символів 400–800 символів
Технічно складний товар 150–200 символів 800–2000 символів
Товар з великим вибором варіантів 100–150 символів 600–1200 символів
Преміальний товар 150–200 символів 1000–3000 символів

Унікальність — від 85% (для технічних описів достатньо 75–80%).

Як ми ставимо копірайтинг на потік?

  1. Бриф на категорію — цільова аудиторія, конкуренти, точки відмінності.
  2. Шаблон структури — єдина схема для категорії.
  3. Завантаження через імпорт — Excel → XML-імпорт або API.
  4. Перевірка унікальності до завантаження — автоперевірка вбудована в процес.

Строки

Обсяг робіт Строки
50–100 товарів однієї категорії 5–10 робочих днів
500 товарів (кілька категорій) 4–6 тижнів
Розробка шаблонів + бриф + 100 карток під ключ 2–3 тижні
Приклад реального проєкту: наповнення каталогу сантехніки на 600 товарів Ми розробили шаблон для кожної категорії (змішувачі, душові системи, аксесуари). PREVIEW_TEXT містив ключовий параметр (тип, покриття, гарантія). DETAIL_TEXT включав таблицю розмірів, список сумісних систем та сценарії застосування. Завантаження через REST API зайняло 2 дні. Унікальність текстів — 88%. Через 3 місяці трафік на категорії зріс на 40%.

Зв'яжіться з нами для консультації — ми оцінимо ваш проєкт та запропонуємо оптимальне рішення. Замовте оцінку вартості та строків для вашого каталогу.

Розробка каталогу 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-блоки швидші за інфоблоки для довідників?

Критерій Інфоблок (IB) Highload-блок (HLB)
Зберігання властивостей Таблиця b_iblock_element_property Окрема плоска таблиця на кожен HLB
Швидкість фільтрації на 50 тис. товарів ~500–800 мс (з фасетом) ~80–150 мс (без фасета)
Підтримка SEO (URL, шаблони) Повна Відсутня (тільки довідники)
Рекомендується для Товари, розділи, основні властивості Довідники (бренди, міста), користувацькі дані
Коли інфоблоки кращі за HLBHighload-блоки не формують SEO-URL та не мають візуального редактора. Якщо довідник повинен мати окремі сторінки (наприклад, бренди з унікальними H1), використовуйте інфоблоки. HLB — для суто службових даних, що не потребують індексації.

На практиці найкраща архітектура — гібридна. Товари та розділи живуть в інфоблоках — там 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 днів після здачі.

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

Завдання Орієнтовний строк
Налаштування розумного фільтра 3–5 днів
Фасетний пошук 2–3 дні
SEO-фільтри 1–2 тижні
Швидкий перегляд 3–5 днів
Кастомний шаблон каталогу 1–2 тижні
Міграція на Highload-блоки 2–4 тижні
Комплексна розробка каталогу 4–8 тижнів

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