Чому кастомна Webflow CMS ламається на масштабі
Webflow CMS добре тримає перші десятки записів: колекції, reference- та multi-reference-зв'язки, фільтри на сторінках шаблонів.
Проблеми починаються не на старті, а коли контент-модель переростає початковий задум — коли колекцій стає більше десяти, а між ними з'являються зв'язки другого й третього рівня.
Перша типова відмова — розсинхрон полів. Поле перейменували або змінили тип в одній колекції, а шаблони, вкладені списки й фільтри, які на нього посилалися, продовжують тягнути старе значення.
Ззовні сторінка жива, але частина карток виводиться порожньою, а умови фільтрації мовчки перестають спрацьовувати.
Друга — дублі та «висячі» записи. Під час ручного перенесення контенту між колекціями та під час імпорту через CSV одна й та сама сутність заводиться двічі, а зв'язки вказують на застарілу копію.
Обмеження CMS не підсвічують це як помилку: бите посилання просто не рендериться, і помітити його можна лише вибірковою перевіркою сторінок.
Третя — ручні правки, які не переживають оновлення структури. Якщо контент-редактор поправив текст прямо в записі, а потім структуру колекції перебудували під новий розділ, частина правок губиться під час перезапису полів.
На масштабуванні контенту це перетворюється на регулярне звіряння «що було до і що стало після» — ручне й без гарантій.
Далі розбираємо, як це закривається: схемою колекцій із запасом на зростання, правилами зв'язків і перевірками, які ловлять розсинхрон до публікації, а не після.
Що дає правильно спроєктована структура колекцій
Структура колекцій у Webflow CMS — це, по суті, схема даних проєкту: які сутності є, як вони посилаються одна на одну і які поля обов'язкові.
Якщо її спроєктували до наповнення, редактор публікує матеріал за хвилини; якщо «нарощували по ходу» — кожна правка перетворюється на ручну синхронізацію десятка карток.
Ключовий ефект — частка ручних операцій. Коли зв'язки між колекціями задані через reference-поля, а не дублюванням тексту, зміна автора або категорії підтягується в усі картки автоматично.
На практиці це прибирає 60–80% ручних правок при масових оновленнях і закриває цілий клас відмов: розсинхрон назв, биті посилання, дублі записів.
Другий ефект — швидкість публікації та онбординг. Зрозуміла схема з осмисленими назвами полів і підказками дозволяє новому редактору вийти на самостійну роботу за один-два дні замість тижня: він бачить, куди що вводити, і не може випадково зламати верстку.
Третій — цілісність даних. Обов'язкові поля, обмеження на типи та єдине джерело для повторюваних сутностей не дають накопичити «сміття», яке потім доводиться чистити вручну.
Ми проєктуємо схему так, щоб вона витримувала зростання: додавання нового типу сторінки не потребує перезбирання наявних колекцій.
Варіанти реалізації: нативна CMS, кастомні поля, зовнішнє джерело
Вибір підходу визначається трьома параметрами: скільки типів сутностей у моделі, наскільки складні зв'язки між ними і хто буде редагувати контент. Нативна CMS закриває більшість завдань без коду, але впирається в ліміти на кількість колекцій і полів.
Кастомні поля розширюють модель, поки логіка вміщується в правила валідації. Зовнішнє джерело потрібне, коли дані живуть в іншій системі і повинні залишатися там єдиним джерелом правди.
| Варіант | Коли підходить | Обмеження підходу |
|---|---|---|
| Нативна CMS | Каталог, блог, довідник з передбачуваною структурою і зв'язками «один-до-багатьох» | Жорсткі ліміти на кількість колекцій і полів, немає обчислюваних значень і умовної логіки |
| Кастомні поля і зв'язки | Потрібні складені типи, перехресні посилання, різний набір полів під категорію | Зростає складність моделі: редактору потрібна інструкція, а розробці — регламент змін |
| Зовнішнє джерело даних | Контент уже ведеться в іншій системі, потрібна вибірка за фільтрами в реальному часі | Залежність від доступності та схеми зовнішнього сервісу, кешування й обробка відмов на нашій стороні |
На практиці підходи комбінують: статичні розділи тримають на нативній CMS, динаміку підтягують із зовнішнього джерела, а кастомні поля ставлять тільки там, де без них модель ламається.
Таке розв'язання знижує кількість правок при зростанні каталогу і залишає редактору зрозумілий інтерфейс.
Ми фіксуємо межі кожного варіанта до старту: які сутності залишаться в CMS, що піде в зовнішнє джерело і де знадобиться кастомна логіка. Це знімає переробки на етапі наповнення, коли зміна архітектури коштує найдорожче.
Як ми проєктуємо та впроваджуємо кастомні колекції
Проєктування починаємо з контентної моделі: розбираємо, які сутності живуть у системі, хто їх створює і за якими правилами вони пов'язані.
На цьому етапі фіксуємо схему зв'язків — один-до-багатьох, довідники, вкладені колекції, — бо переробка структури після наповнення дорожча, ніж пауза на узгодження.
- Розбір контентної моделі. Виписуємо сутності, їхні атрибути та життєвий цикл: що створюється вручну, що підтягується з довідника, що обчислюється. На виході — карта полів із типами та обов'язковістю.
- Схема зв'язків. Визначаємо, як колекції посилаються одна на одну, де потрібні проміжні таблиці, а де достатньо референсного поля. Перевіряємо, що структура витримає зростання: додавання розділу не ламає наявні зв'язки.
- Налаштування полів і ролей. Заводимо поля під кожен тип контенту, налаштовуємо доступи редакторів, авторів і модераторів. Обмеження на рівні ролей прибирають клас помилок, коли контент править не той, хто має.
- Міграція даних. Переносимо наявний контент зі старої системи: чистимо дублі, нормалізуємо розмітку, зіставляємо старі поля з новими. Міграцію проганяємо на копії та звіряємо кількість записів і зв'язків до і після.
- Перевірка сценаріїв редактора. Проходимо шлях від створення запису до публікації: чернетка, передперегляд, відкат, оновлення пов'язаних блоків. Тут випливають неочевидні конфлікти полів, які не видно на порожній базі.
- Навантажувальна перевірка. Дивимося, як поводяться списки та фільтри на реальному обсязі контенту, а не на десяти тестових записах.
- Передача проєкту. Віддаємо схему колекцій, опис ролей, інструкцію для редакторів і регламент додавання нових полів — щоб команда замовника розвивала структуру без нас.
Кожен крок закінчується артефактом: картою моделі, схемою зв'язків, налаштованими ролями, звітом міграції. Так на передачі у замовника залишається не «якось працює», а задокументована структура, яку можна розширювати.
Що залишається у вас після здачі проєкту
Проєкт здається не «доступом до акаунта», а комплектом, за яким ваша команда далі працює без нас. Нижче — що саме передаємо по кожному проєкту на Webflow CMS.
- Схема колекцій — карта всіх CMS-колекцій із призначенням кожної, зв'язками між ними (reference та multi-reference) і логікою вкладеності. За нею видно, чому матеріал лежить саме тут і що станеться при додаванні нового запису.
- Опис полів — таблиця по кожній колекції: ім'я поля, тип, обов'язковість, допустимі значення, дефолт. Окремо позначені поля, які не можна перейменовувати без правки шаблонів.
- Правила зв'язків — які колекції посилаються одна на одну, де зв'язок обов'язковий, а де опціональний, і як це відображається на сторінках-шаблонах.
- Ролі доступу — матриця прав: хто редагує контент, хто керує колекціями, хто публікує. Налаштовані окремі ролі для редакторів, щоб вони не могли зламати структуру.
- Регламент публікації — порядок виведення правок у прод: чернетка → перевірка → публікація, що робити при відкаті та як узгоджуються зміни між редакторами.
- Інструкція редактора — покроковий документ зі скріншотами: як додати запис, заповнити поля, прив'язати зв'язки, поставити в чергу та опублікувати. Розрахована на людину без технічного бекграунду.
- Карта шаблонів — які сторінки збираються з яких колекцій і полів, щоб правка контенту не вимагала правки верстки.
Усе це — живі документи у вашому репозиторії, а не разовий файл. При зміні структури колекцій ми оновлюємо схему та опис полів у тому самому коміті, тому документація не розходиться з реальністю через місяць після запуску.
Кейс: перебудова каталогу на 40 зв'язків без зупинки публікацій
Клієнт — промисловий постачальник з каталогом на 40 зв'язках між колекціями: товар посилався на категорію, категорія на серію, серія на документи та аналоги.
Каталог жив на Webflow CMS, і кожне редагування структури перетворювалося на ручний прохід по сотнях карток: зв'язки рвалися, публікація займала години, а після оновлення доводилося вручну звіряти, чи не відпали перехресні посилання.
Що було до
Публікація одного матеріалу займала в середньому 40 хвилин: контент-менеджер правил картку, вручну переприв'язував пов'язані записи та перевіряв, що посилання не ведуть у порожнечу.
При зміні структури колекцій частка помилок сягала третини правок — частина зв'язків залишалася битою, і її знаходили вже на проді.
Що змінили
Ми перебудували модель зв'язків: винесли повторювані сутності в окремі колекції, налаштували посилальні поля замість дублювання тексту та додали перевірки цілісності на етапі збірки.
Публікація перестала залежати від ручного переприв'язування — зв'язки підтягуються автоматично, а невідповідності відсікаються до викладки.
Що стало
| Метрика | До | Після |
|---|---|---|
| Час публікації матеріалу | ~40 хвилин | 5-7 хвилин |
| Ручних правок на матеріал | 12-15 | 2-3 |
| Частка помилок при зміні структури | ~30% | поодинокі випадки |
Публікації не зупинялися ні на день: перебудову вели частинами, старі та нові зв'язки працювали паралельно, поки каталог не перейшов повністю.
Відкат на попередню схему залишався доступним на кожному кроці — якби перевірки виявили проблему, повернулися б до попередньої структури без втрати даних.
Чим кастомна колекція відрізняється від окремої сутності
Кастомна колекція — це окремий тип контенту зі своєю схемою полів, а окрема сутність — запис усередині вже наявної колекції.
Різниця проявляється не в редакторі, а в тому, як дані лягають у структуру: одна велика колекція з десятком необов'язкових полів швидко перетворюється на звалище, де половина атрибутів порожня в більшості записів, а фільтри й сортування працюють за розрідженими значеннями.
Коли контент відрізняється за частотою змін, його виносять у пов'язані колекції. Довідник міст або категорій змінюється раз на квартал, а картки товарів — щодня; тримати їх в одній сутності означає переіндексовувати весь набір при кожній правці довідника.
Зв'язок через reference-поле дозволяє оновлювати довідник точково, а вибірка за зв'язком залишається передбачуваною.
Права доступу — другий критерій. Якщо редактори контенту й власники довідника — різні люди, розмежувати ролі всередині однієї колекції складно: права видаються на колекцію цілком, а не на окремі поля.
Рознесення на пов'язані колекції дає чисту модель ролей: одна група править записи, інша — лише довідкові значення, і ніхто не зачіпає чужу схему.
Практичне правило: якщо в сутності більше двох-трьох полів, які заповнюються рідко і лише частиною записів, або якщо її редагує окрема роль — виносьте в кастомну колекцію й пов'язуйте.
Якщо поля однорідні й змінюються одним потоком — залишайте однією сутністю, зайвий зв'язок додасть запитів на видачі без виграшу в структурі.
Технічні сумніви перед стартом робіт
Перенесення контенту — перше, про що запитують перед стартом. Ми заздалегідь збираємо карту поточних сутностей: які типи записів є зараз, як вони пов'язані між собою, де дублі та «сміттєві» поля.
Далі розкладаємо їх по колекціях CMS і налаштовуємо зв'язки між ними, щоб структура витримала зростання каталогу, а не перетворилася на плоский список на сотні записів. Старі адреси зберігаємо через правила перенаправлення — пошуковий трафік і зовнішні посилання не втрачаються.
Які обмеження у платформи і що з ними робити?
У будь-якої платформи є стеля: ліміти на кількість записів, глибину вкладеності посилань, обсяг медіа та частоту звернень до API. Ми перевіряємо ці межі на етапі проєктування схеми, а не після запуску.
Якщо задача впирається в ліміт, частину логіки виносимо у зовнішній шар — платформа залишається вітриною, а важкі операції виходять за її межі.
Як розмежувати ролі редакторів?
Налаштовуємо ролі під реальні обов'язки: контент-редактор править тексти та медіа, але не чіпає структуру колекцій; старший редактор керує зв'язками та публікацією; адміністратор відповідає за схему та доступи.
Права видаємо за принципом мінімальної необхідності — випадкова правка шаблону не обвалить верстку всього сайту.
Що з підтримкою після запуску?
Після здачі залишається регламент: як додавати нові поля, як викочувати зміни без простою, до кого йти при збої. Ми фіксуємо це в документації та передаємо команді замовника — сайт живе без постійної участі підрядника.
Чим ризикує міграція?
Головні ризики — втрата зв'язків між записами та биті адреси. Закриваємо їх так: спочатку переносимо структуру та зв'язки на тестовий контур, звіряємо кількість і цілісність записів, і тільки потім перемикаємо робочий домен. Відкат на попередню версію залишається можливим до самого моменту перемикання.
Обговоримо вашу контентну модель і повернемося з планом
Щоб повернутися з планом впровадження, а не із загальними словами, нам потрібна ваша поточна картина: які типи контенту вже є, як вони пов'язані між собою і що заважає редакції працювати без розробника.
Опишіть завдання у вільній формі — список сторінок, довідників, повторюваних блоків і ролей доступу. Цього достатньо, щоб оцінити обсяг і побачити слабкі місця в структурі.
Далі ми збираємо схему зв'язків: які колекції стають джерелами, які посилаються на них, де потрібні довідники та фільтри, а де вистачить статичних полів. За цією схемою рахуємо обсяг робіт і порядок викатки — що переносимо першим, що можна докатати без зупинки сайту.
- Розбір поточної структури контенту та точок, де редакція впирається в ручну правку
- Схему зв'язків колекцій: джерела, посилання, довідники, правила фільтрації
- Оцінку обсягу: скільки колекцій, полів і шаблонів належить зібрати
- План впровадження за етапами з зрозумілим результатом на кожному
- Порядок перенесення даних і перевірку, що старі адреси сторінок не губляться
- Розкладку ролей: що редактор змінює сам, що залишається за розробником
- Перелік перевірок перед запуском і порядок відкату, якщо щось піде не так
Наступний крок — коротка розмова по суті: ви показуєте структуру, ми ставимо уточнювальні запитання і повертаємося з оцінкою обсягу, схемою зв'язків і планом впровадження. Опишіть завдання — повернемося з конкретикою.
