Сайт зверстаний. Що далі? 10 речей між HTML/CSS-макетом і готовим бізнес-сайтом

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

Залишається «тільки викласти на сервер».

На практиці саме після цього «тільки» починається значна частина роботи.

HTML і CSS можуть ідеально відтворювати дизайн, але бізнесу потрібен не набір зверстаних сторінок. Йому потрібен сайт, який можна редагувати, який нормально працює на реальних пристроях, завантажується з прийнятною швидкістю, збирає заявки, передає дані в аналітику, індексується пошуковими системами і не перестає працювати після першого оновлення.

Розглянемо, що насправді відділяє хорошу верстку від готового сайту.

1. Верстку потрібно перетворити на систему

У статичному HTML усе просто: заголовок знаходиться в одному файлі, номер телефону — в іншому, картка товару — у третьому.

Поки сторінок п'ять, це не проблема.

Коли їх стає 50 або 500, ручне редагування перестає бути життєздатною моделлю.

Тому наступне питання після завершення верстки звучить не «як залити її на сервер?», а:

Хто і як буде змінювати цей сайт через пів року?

Для корпоративного сайту це може означати інтеграцію з WordPress або іншою CMS. Для магазину — WooCommerce, Shopify чи власну систему. Для вебзастосунку — підключення фронтенду до API.

І саме тут доводиться вирішувати, які частини сторінки мають бути керованими:

меню;
контакти;
ціни;
товари та послуги;
FAQ;
відгуки;
форми;
SEO-метадані;
повторювані блоки.

Чим раніше це продумано, тим менше доводиться ламати вже готову верстку.

2. Піксельна відповідність макету ще не означає адаптивність

У Figma можна намалювати версію для 1440 px і мобільний екран шириною 375 px.

У реальності між ними існують сотні варіантів.

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

І раптом акуратний макет починає жити власним життям.

Хороший адаптив — це не просто набір media queries. Це здатність інтерфейсу нормально поводитися з непередбачуваним контентом.

Тому після верстки варто перевіряти не лише контрольні ширини, а й проміжні:

320–360 px;
375–430 px;
планшети;
невеликі ноутбуки;
Full HD;
великі монітори.

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

3. Форми повинні не просто відправлятися

Форма, після натискання якої з'являється повідомлення «Дякуємо», ще не обов'язково працює.

Потрібно перевірити весь маршрут заявки:

користувач → сайт → сервер → пошта або CRM → менеджер.

Саме на цьому маршруті виникають дуже неприємні помилки.

Наприклад:

листи потрапляють у спам;
SMTP налаштований неправильно;
форма дозволяє надсилати порожні поля;
мобільний браузер некоректно обробляє номер телефону;
CRM отримує заявку без UTM-міток;
користувач натискає кнопку кілька разів і створює дублікати.

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

Тобто кнопка «Надіслати» — лише вершина конструкції.

4. Швидкість потрібно перевіряти вже не на localhost

Локально сайт майже завжди здається швидким.

Браузеру не потрібно далеко ходити за файлами, сервер знаходиться поруч, мережевої затримки фактично немає.

Після публікації додаються:

реальний сервер;
DNS;
SSL;
сторонні шрифти;
системи аналітики;
рекламні скрипти;
віджети;
зовнішні API;
кешування;
реальні фотографії замість оптимізованих заглушок.

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

Тому продуктивність має сенс перевіряти саме в умовах, максимально наближених до production.

Особливо варто стежити за:

LCP — коли користувач бачить основний контент;

INP — наскільки швидко сторінка реагує на його дії;

CLS — чи не стрибають елементи під час завантаження.

При цьому оптимізація не зводиться до встановлення кеш-плагіна. Іноді найбільше гальмує велике hero-зображення, іноді — сторонній JavaScript, а іноді — один невдалий запит до бази даних.

5. Зображення з макету майже ніколи не готові до production

Дизайнер працює з якістю картинки.

Сайт — з компромісом між якістю та вагою.

Якщо просто експортувати все з макета у високій роздільній здатності, можна отримати головну сторінку вагою 10–15 МБ.

Тому перед запуском доводиться вирішувати:

WebP чи AVIF;
які реальні розміри потрібні;
де використовувати srcset;
які зображення завантажувати ліниво;
яке зображення є критичним для першого екрана;
чи потрібна мобільна версія тієї самої фотографії.

Окрема історія — SVG.

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

6. SEO починається ще до написання статей

Часто SEO згадують уже після запуску:

«Сайт готовий. Тепер давайте його оптимізуємо».

Але частина SEO-рішень закладена значно глибше.

Наприклад, у структурі URL:

/services/web-design/

або

/page?id=173

У правильній ієрархії заголовків. У доступності контенту без JavaScript. У canonical. У пагінації. У тому, чи можна індексувати сторінку взагалі.

Навіть хороший дизайн не компенсує ситуацію, коли всі сторінки мають однаковий <title>, зображення не мають змістовного alt, а важливий текст з'являється лише після дії користувача.

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

SEO набагато дешевше врахувати під час розробки, ніж перебудовувати під нього вже запущений проєкт.

7. Аналітика повинна відповідати на бізнес-питання

Встановити Google Analytics — ще не означає налаштувати аналітику.

Перегляди сторінок самі по собі мало що говорять власнику бізнесу.

Значно цікавіше знати:

скільки людей натиснули номер телефону;
скільки відправили форму;
які послуги переглядали перед заявкою;
звідки прийшли клієнти;
де користувачі залишають сторінку;
які рекламні кампанії створюють звернення.

Тому до запуску варто визначити ключові події та протестувати їх.

Для простого корпоративного сайту це можуть бути:

click_phone
form_submit
click_email
messenger_click

Для магазину додаються перегляд товару, додавання до кошика, початок оформлення і покупка.

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

8. Потрібно перевірити те, що користувач може зламати

Розробник майже завжди користується сайтом «правильно».

Він знає, куди натискати. Знає, що поле телефону очікує номер. Не відкриває меню двадцять разів поспіль і не вводить emoji замість прізвища.

Користувач нічого цього не знає.

Тому перед запуском корисно навмисно поводитися неправильно:

відправити порожню форму;
вставити дуже довгий текст;
двічі натиснути Submit;
повернутися кнопкою Back;
перезавантажити сторінку під час оформлення;
відкрити сайт без cookies;
заблокувати JavaScript;
зайти зі старішого телефона.

Такі тести часто знаходять більше реальних проблем, ніж ще один перегляд макета дизайнером.

9. Production потребує власної інфраструктури

У розробника все може працювати на тестовому домені та тимчасовому сервері.

Бізнес-сайт потребує більш передбачуваного середовища.

Мінімальний набір:

SSL;
резервні копії;
контроль версій або хоча б зрозумілий процес оновлення;
захищені адміністративні акаунти;
актуальні версії PHP, CMS і плагінів;
моніторинг помилок;
правильно налаштована пошта.

Окремо варто відповісти на просте питання:

Що ми робимо, якщо завтра сайт перестає працювати?

Якщо відповідь — «будемо розбиратися», інфраструктура ще не готова.

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

10. Запуск — це не кінець розробки

Є речі, які неможливо нормально перевірити до появи реальних користувачів.

Після запуску варто подивитися:

які пристрої використовують відвідувачі;
які сторінки повільніші за інші;
де люди не знаходять потрібну кнопку;
які 404 почали з'являтися;
чи індексуються потрібні URL;
чи немає помилок JavaScript;
чи доходять усі заявки.

Тому нормальний запуск — це не момент, коли розробник натиснув Deploy.

Швидше це перехід із режиму створення у режим спостереження.

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

Коли сайт справді можна назвати готовим?

Напевно, ніколи в абсолютному сенсі.

Хороший сайт змінюється разом із бізнесом.

Але перед запуском він принаймні повинен пройти короткий контрольний список:

Контент
Усі тексти, телефони, адреси, ціни та посилання актуальні.

Адаптивність
Сторінки перевірені не лише на двох розмірах із макета.

Функціональність
Форми, кнопки, пошук, фільтри та інші сценарії протестовані.

Швидкість
Перевірена production-версія, а не localhost.

SEO
Є коректні title, description, canonical, sitemap, robots.txt та зрозуміла структура сторінок.

Аналітика
Відстежуються дії, які мають значення для бізнесу.

Безпека
Є резервне копіювання, захищені доступи та план відновлення.

Контроль після запуску
Хтось перевіряє помилки, індексацію, заявки та поведінку реальних користувачів.

Верстка — важливий етап. Без хорошої верстки не буде хорошого інтерфейсу.

Але між красивим HTML/CSS-макетом і сайтом, який щодня працює для бізнесу, залишається ще багато невидимої роботи.

І, як це часто буває у веброзробці, саме ця невидима частина зрештою визначає якість результату.

2026-08-12