Структура сайту і кошторис: 100 сторінок чи 10 шаблонів?

Фраза «нам потрібен сайт приблизно на сто сторінок» ще не описує обсяг робіт і не дає підстав для точного бюджету. Для команди суттєво відрізняються сто незалежних сторінок із власними сценаріями та сто URL, що працюють на основі десяти повторюваних шаблонів. Тому структура сайту і кошторис мають формуватися не з лічильника адрес, а з карти типів сторінок, компонентів, даних і функцій.

До погодження робіт бізнесу варто з'ясувати: скільки існує типів сторінок, що редактори створюватимуть самостійно в CMS, де потрібні унікальні інтерфейсні рішення, які варіанти блоків слід реалізувати та хто відповідатиме за наповнення. Це допомагає зіставити пропозиції виконавців, встановити межі першого релізу й зменшити ризик, що важливі роботи залишаться поза узгодженим обсягом.

Чому кількість URL не дорівнює обсягу робіт

URL — це адреса конкретної сторінки, а не одиниця дизайну чи розробки. Наприклад, 45 статей можуть мати 45 різних адрес, але використовувати один шаблон матеріалу: однакові правила для заголовка, автора, змісту, медіа, цитат, пов'язаних публікацій і метаданих. Команда проєктує та реалізує цей каркас один раз, а далі редактор створює окремі записи за визначеними правилами.

Зворотна ситуація теж поширена: десять URL можуть бути складним проєктом, якщо кожен екран має власну функцію. Нестандартний калькулятор, багатокрокова форма, інтеграція з CRM, особистий кабінет, різні ролі користувачів або складна фільтрація збільшують обсяг незалежно від кількості адрес. Сторінки можуть виглядати подібно, але бути різними з погляду даних, сценаріїв і тестування.

Коректний кошторис прив'язаний до унікальних шаблонів, варіантів компонентів, контентних моделей, інтеграцій і сценаріїв перевірки, а не лише до кількості URL.

Саме тому оцінювання сторінок сайту варто починати з групування: лістинги, картки послуг, матеріали, сервісні сторінки, юридичні документи, посадкові сторінки, кабінети. Лише після цього можна визначити, де працює повторюваний патерн, а де потрібне окреме рішення.

Структура сайту і кошторис: що формує бюджет

Кількість шаблонів сторінок є важливим показником, але не єдиним. У матеріалі «ціна розробки сайту» бюджет розглянуто через склад робіт; для конкретного проєкту цей склад варто зафіксувати окремими результатами, а не об'єднувати в загальне формулювання «сайт під ключ».

• Архітектура: карта розділів, навігація, пріоритетні сценарії, логіка переходів і контентна модель.
• Дизайн-система: сітка, типографіка, кольори, правила для кнопок, карток, форм, повідомлень і мобільної версії.
• Шаблони: окремі каркаси для типів сторінок та їхня адаптивна поведінка.
• Повторювані компоненти сайту: форми, картки, фільтри, галереї, таблиці, блоки заклику до дії, пошук і навігація.
• CMS та дані: типи записів, поля, зв'язки між матеріалами, ролі редакторів, імпорт або перенесення контенту.
• Функціональність: інтеграції, кабінети, платежі, мультимовність, пошук, фільтрація та правила доступу.
• Контроль якості: перевірка форм, адаптивності, прав доступу, помилкових і порожніх станів, контентних крайніх випадків.

Шаблон, компонент і CMS-запис — різні одиниці

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

Розробити шаблон статті означає створити правила для всіх майбутніх статей. Завести 45 статей означає підготувати або перенести 45 наборів тексту, медіа та метаданих, перевірити їхнє відображення й погодити матеріали. Друге не потребує 45 нових макетів, але все одно є окремою роботою, яку слід врахувати в плані.

Що ускладнює навіть один шаблон

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

Так само «форма» не є достатнім описом обсягу. Одне поле для номера телефону і набір форм з масками, умовними полями, згодами, передаванням заявок у CRM, захистом від спаму та різними повідомленнями після відправлення — це різні рівні складності. У кошторисі корисно зазначати не лише назву компонента, а й його варіанти та поведінку.

Навчальна карта: 100 URL і 10 шаблонів

Нижче наведено умовний навчальний приклад B2B-сайту з послугами, кейсами, блогом, базою знань і вакансіями. Це не готовий кошторис і не універсальна модель для будь-якого бізнесу. Його завдання — показати, чому 100 URL не означають 100 окремих макетів або 100 незалежних циклів розробки.

У цій карті рівно 100 URL. Водночас у ній 10 шаблонів: головна, інформаційна сторінка, лістинг послуг, картка послуги, лістинг кейсів, картка кейсу, лістинг матеріалів, матеріал, лістинг вакансій і картка вакансії. Блог і база знань мають різні URL та різний контент, але в навчальній моделі використовують спільні шаблони. Так само чотири інформаційні сторінки побудовані на одному каркасі з різними модулями.

Це припущення слід перевіряти в кожному реальному проєкті. Якщо контакти потребують складної карти та маршрутизації заявок, а юридичні документи мають окремі вимоги до відображення, їх можуть виділити в самостійні шаблони. Навпаки, якщо картки кейсу й послуги мають однакові поля та сценарії, їх іноді можна об'єднати. Предмет оцінки — не назва розділу, а відмінності у структурі, даних і поведінці.

Як розділити дизайн шаблонів і створення записів у CMS

На етапі проєктування дизайну сайту доцільно погоджувати не сто майбутніх URL по черзі, а систему правил. Для кожного шаблону визначаються інформаційна ієрархія, модулі, обмеження для контенту, стани компонентів, адаптивна поведінка та допустимі варіації. Це дає змогу передати макети й специфікації в розробку без прихованого припущення, що кожен новий матеріал потребуватиме окремого дизайну.

Створення записів у CMS — інший потік робіт. До нього можуть входити підготовка текстів, підбір або обробка медіа, заповнення полів, метаданих і категорій, перенесення URL, налаштування перенаправлень, перевірка верстки після введення контенту та погодження матеріалів. Якщо це не зафіксувати окремо, замовник може очікувати повністю наповнений сайт, а виконавець — лише готову систему для самостійної роботи редакторів.

Практичне формулювання для обсягу: «Розробити шаблон картки кейсу — одна одиниця; створити або перенести картки кейсів — 18 записів; підготувати тексти й медіа — відповідальність визначеної сторони». Такий запис не замінює деталізовану оцінку, проте прибирає критичну неоднозначність.

Чекліст для перевірки обсягу до кошторису

Фінальні тексти не завжди потрібні до старту, але структура має бути достатньо чіткою, щоб не оцінювати проєкт на припущеннях. Пройдіть цей список разом із виконавцем:

1. Згрупуйте всі плановані URL за типами: лістинги, картки, статті, сервісні, юридичні та посадкові сторінки.
2. Позначте, які типи можуть використовувати один шаблон, а які відрізняються полями, логікою або цільовою дією.
3. Для кожного шаблону перелічіть компоненти та варіанти: форми, картки, фільтри, таблиці, галереї, блоки заклику до дії.
4. Розділіть разову роботу з дизайну й коду від контентних операцій, що множаться як CMS-записи.
5. Опишіть інтеграції: куди надходять заявки, звідки беруться дані, чи потрібні ролі, платежі або синхронізація.
6. Зафіксуйте джерело контенту: готові матеріали, міграція, підготовка з нуля чи наповнення внутрішньою командою.
7. Окремо визначте мовні версії, SEO-міграцію, перенаправлення, аналітику, вимоги доступності та тестування.
8. Погодьте межі першого релізу й перелік функцій, які свідомо переносяться на наступний етап.

Запитання, які захищають бюджет

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

Формулювання «десять шаблонів» без переліку їхніх назв і функцій мало що пояснює. Натомість опис на кшталт «картка послуги з редагованими секціями, блоком запитань, формою та пов'язаними кейсами» можна перевірити в дизайні, CMS і готовому продукті. Так бізнес розуміє, за що сплачує, а команда отримує конкретні критерії реалізації.

Як скоротити обсяг без втрати цінності

Оптимізація не означає механічно прибрати сторінки. Її мета — зберегти ключові сценарії користувача, але не множити разові рішення. Зазвичай для першого релізу можна об'єднати близькі типи контенту в один шаблон, обмежити набір секцій, використати спільні компоненти, відкласти рідкісні сценарії та другорядні інтеграції.

Водночас не варто об'єднувати сторінки лише через візуальну схожість. Картка послуги й вакансія можуть містити текст та форму, але мають різні дані, маршрути заявок, відповідальних осіб і користувацькі завдання. Неправильно спрощена модель часто створює витрати на переробку, коли сайт уже потрібно розвивати.

Висновок для замовника

Сто URL можуть бути компактним проєктом, якщо це контентні записи в кількох стабільних шаблонах. Десять URL можуть вимагати значного ресурсу, якщо кожен має унікальну функцію, складні стани або інтеграції. Перед погодженням бюджету варто вимагати карту структури, список шаблонів, опис компонентів, поділ між розробкою системи та наповненням CMS, а також межі першого релізу.

Такий підхід переводить обговорення з абстрактного «скільки сторінок» у керування перевірюваним обсягом. Це полегшує вибір пріоритетів, допомагає уникати непорозумінь і створює основу для масштабування сайту без хаотичного множення унікальних макетів.