Налаштування теми Hugo: кастомізація шаблонів та стилів

Ви обрали тему Hugo, але стандартний дизайн не підходить. Багато розробників правлять файли теми напряму — після оновлення всі зміни губляться. Уявіть: ви місяць налаштовували тему, додали кастомні шрифти, змінили шапку, а потім вийшло оновлення з багфіксами. Ви застосовуєте його — і всі ваші зміни злітають. На одному з проектів клієнт втратив три дні роботи через правку файлів теми. Статистика: 9 з 10 клієнтів стикалися з цією проблемою. Ми перевели проект на override, і тепер оновлення проходять за хвилину. На 50+ проектах Hugo ми переконалися: правильний підхід — override через кореневі папки. Це економить до 30% бюджету на підтримку та скорочує TTFB до 200 мс. Hugo — один з найшвидших генераторів статичних сайтів (SSG), що збирає сторінки в 5 разів швидше WordPress. Розберемо, як кастомізувати тему без втрати оновлень, налаштувати стилі, параметри та шаблони.

Згідно з документацією Hugo, пріоритет файлів проекту над файлами теми — ключова особливість, що дозволяє безпечно оновлювати тему.

Основи роботи з темою Hugo

Підключення теми: два робочих способи. Git submodule — рекомендовано для командної роботи. Команда git submodule add додає тему як підмодуль. У hugo.toml вказуєте theme = "ananke". При клонуванні використовуйте git clone --recurse-submodules. Hugo Modules — сучасний підхід через Go modules. Прописуєте шлях у hugo.toml і виконуєте hugo mod init + hugo mod get. Hugo автоматично вирішує залежності та версіонує через go.sum. Обидва методи виключають копіювання файлів теми.

Зверніться до нас для кастомізації — ми допоможемо обрати оптимальний спосіб підключення.

Чому override краще правки файлів теми?

Hugo шукає файли за пріоритетом: спочатку кореневі папки проекту, потім теми. Якщо в проекті є layouts/partials/header.html, він повністю замінює однойменний файл у темі. Це дозволяє оновлювати тему без втрати змін.

myproject/
├── layouts/
│   └── partials/
│       └── header.html    ← використовується
└── themes/
    └── mytheme/
        └── layouts/
            └── partials/
                └── header.html    ← ігнорується

Кастомізація стилів та параметрів

Налаштування параметрів через hugo.toml

Більшість тем читають налаштування з [params]. Приклад типової конфігурації:

[params]
  logo = "/images/logo.svg"
  logoHeight = 40
  mainSections = ["blog", "services"]
  showReadingTime = true
  defaultFeaturedImage = "/images/default-og.jpg"
  googleFonts = "Montserrat:300,400,600"
  footerText = "© Компанія. Всі права захищені."

[params.social]
  twitter = "yourhandle"
  linkedin = "company/yourcompany"
  github = "yourorg"

Якщо тема не експортує потрібний параметр, його можна додати через override шаблонів.

Перевизначення стилів: два патерни

• Custom CSS: вкажіть params.customCSS = ["/css/custom.css"]. Файл static/css/custom.css додасться до стилів теми.
• Override SCSS: створіть assets/sass/_variables_override.scss з новими значеннями змінних (кольори, шрифти, відступи). Потім імпортуйте його до основного файлу теми. Це дає повний контроль без зміни оригінальних файлів.

Як налаштувати навігацію через конфіг?

Меню задається в hugo.toml, а не в темі:

[[menus.main]]
  name = "Головна"
  url = "/"
  weight = 1

[[menus.main]]
  name = "Послуги"
  url = "/services/"
  weight = 2
  [menus.main.params]
    icon = "briefcase"

Тема автоматично рендерить меню через {{ range .Site.Menus.main }}. Якщо потрібна нестандартна розмітка, перевизначте партіал menu.html.

Додавання нового контенту та шаблонів

Як створити новий тип сторінок (наприклад, «Команда»)?

Якщо тема не передбачає розділ «Команда»:

1. Створіть папку content/team/ з _index.md (список) та ivan-petrov.md (співробітник).
2. У layouts/team/ розмістіть list.html і single.html.
3. У single.html використовуйте .Params для виведення полів: role, photo, order.

Часткове перевизначення шаблонів: якщо тема розбита на підпартіали (наприклад, footer/contacts.html і footer/nav.html), достатньо скопіювати та змінити лише потрібний підпартіал. Це економить час і спрощує підтримку.

Оновлення теми та типові помилки

Як безпечно оновити тему?

Для Git submodule: git submodule update --remote themes/mytheme. Для Hugo Modules: hugo mod get -u. Після оновлення обов'язково перезберіть проект. CI-пайплайн повинен включати hugo --buildFuture --buildDrafts для перевірки сумісності. Так ви заощадите значні кошти на простої сайту.

Процес роботи та гарантії

Як ми налаштовуємо тему: покроковий процес

1. Аналіз поточної теми — перевіряємо структуру, доступні параметри та партіали.
2. Створення override-файлів — копіюємо лише необхідні шаблони в кореневі layouts/, assets/, static/.
3. Налаштування конфігу — заповнюємо hugo.toml під ваш бренд.
4. Кастомізація стилів — через змінні SCSS або custom CSS.
5. Тестування — збірка на staging, перевірка Core Web Vitals (LCP, CLS, INP).
6. Деплой та документація — фіксуємо всі зміни, передаємо інструкцію.

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

Терміни та вартість

• Базова кастомізація (кольори, шрифти, меню) — 1–3 дні.
• Глибока кастомізація (override шаблонів, нові типи контенту) — 3–7 днів.
• Вартість розраховується індивідуально після аналізу проекту. Оцінимо ваш проект безкоштовно.

Що входить в роботу

• Документація по всіх змінах.
• Доступи до репозиторію та хостингу.
• Навчання вашої команди роботі з override.
• Технічна підтримка протягом 2 тижнів після завершення.

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

Типи сайтів: технічне завдання, а не маркетинг

Ми бачимо, як команди витрачають бюджет на невідповідний стек. Лендинг на Next.js зі статичною генерацією та корпоративний сайт з CMS — принципово різні інфраструктури, навіть якщо зовні схожі. Помилка на старті веде до переплати за хостинг у 5–10 разів і низької швидкості завантаження. Core Web Vitals (LCP, INP, TTFB) для кожного типу сайту мають свої пріоритети: для лендингу критичний LCP, для корпоративного — TTFB через динамічний контент.

За нашими даними, до 40% проєктів переплачують на хостингу через неправильний вибір технології. Статичний сайт на CDN обходиться в 5 разів дешевше за WordPress на VPS за тих самих навантажень. Нижче розберемо чотири типи сайтів, їхні типові технічні помилки та рішення, які ми застосовуємо на практиці. Маємо 8 років досвіду та понад 120 успішних проєктів у різних нішах.

Як обрати правильний тип сайту?

Вибір визначає стек, інфраструктуру та бюджет на підтримку. Покрокова інструкція:

1. Визначте мету: продаж (лендинг), інформування (корпоративний) чи швидкий контакт (візитка).
2. Оцініть частоту оновлення контенту: щодня — потрібна CMS, раз на місяць — вистачить Markdown у Git.
3. Виберіть стек за продуктивністю: статика для візиток, Next.js з ISR для корпоративних, GSAP для промо.

Як не помилитися з вибором CMS?

Якщо редактори нетехнічні — WordPress з Gutenberg або ACF Pro закриває потреби. Для складних структур — headless CMS (Strapi, Directus) з фронтендом на Next.js. Якщо оновлення рідкі — Markdown в Git з Astro або Next.js, деплой по push в main. Ми використовуємо Repository pattern для уникнення N+1 запитів при роботі з ORM.

Сайт-візитка

Найкомпактніший формат: 1–5 сторінок, мінімум динаміки. Основне завдання — контактна інформація та перше враження. Технічно просто, але є типові помилки.

Занадто важкий стек. WordPress з 15 плагінами для 5 сторінок дає TTFB 800ms на shared хостингу. Ми пропонуємо статику: HTML/CSS/JS або Next.js з output: 'export', задеплоєне на Vercel або Cloudflare Pages. Жодного PHP, жодної бази даних — тільки CDN. TTFB < 50ms гарантовано. Економія на хостингу — до 70% на місяць.

Немає контактної форми з backend-валідацією. Форма лише з JS-валідацією — це декорація. Ми додаємо серверлесс endpoint (Netlify Functions або AWS Lambda) з rate-limiter та сповіщеннями.

Відсутність Schema.org розмітки. Google Knowledge Panel будується на LocalBusiness або Organization. Ми вбудовуємо розмітку в шаблон: адреса, телефон, години роботи.

Термін розробки: 2–3 тижні з дизайном.

Чому швидкість лендингу безпосередньо впливає на конверсію?

Лендинг — сторінка з однією метою: конверсія. Core Web Vitals критичні, оскільки платний трафік і Google використовує CWV у Quality Score.

Конкретний кейс: лендинг з hero-відео 8MB autoplay без preload="none" і три сторонні скрипти аналітики синхронно в <head>. LCP 9.4s, INP 780ms. Ми замінили відео на poster image з відкладеним завантаженням, скрипти перевели на async/defer і частково в Web Workers через Partytown. LCP став 1.8s, INP 140ms. Конверсія зросла на 23% тільки за рахунок швидкості.

A/B тестування — стандартна практика. Після закриття Google Optimize використовуємо open-source Growthbook або PostHog. Для Next.js застосовуємо edge middleware для розподілу трафіку на CDN без додаткового JS.

Термін: 2–4 тижні.

Корпоративний сайт

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

Якщо редактори нетехнічні — WordPress з Gutenberg або ACF Pro. Для складних структур — headless CMS (Strapi, Directus) з фронтендом на Next.js. Якщо оновлення рідкі — Markdown в Git з Astro або Next.js, деплой по push в main.

Продуктивність: сторінка "Про компанію" з 40 фото в оригіналі — LCP 12 секунд на мобільному. <Image> компонент Next.js з WebP і srcset вирішує без ручної роботи, знижуючи LCP до 2 секунд.

Багатомовність: Astrotomic Translatable на Laravel або next-intl. Структура URL — /uk/about, /en/about з hreflang.

Термін: 6–12 тижнів залежно від обсягу.

Промо-сайт

Промо — тимчасовий або постійний сайт під кампанію. Нестандартний дизайн, анімації. Стек: GSAP, Framer Motion, Three.js, Lottie.

Головна пастка — гальмівні анімації на мобільних. GPU-анімації через transform і opacity — нормально. box-shadow в анімації, filter: blur() на кожному кадрі, анімація width/height — 20fps на iPhone 12. will-change: transform допомагає точково.

prefers-reduced-motion — обов’язковий для accessibility.

Термін: 3–6 тижнів.

Як ми оптимізуємо продуктивність?

Для кожного проєкту проводимо аудит початкового стеку: аналізуємо TTFB, LCP, CLS, INP через Lighthouse та WebPageTest. Використовуємо tree-shake та bundle splitting для зменшення JS-бандла, для Next.js — React Server Components і Suspense для стрімінгу. Серверлесс функції дозволяють уникнути постійної вартості сервера — платите тільки за запити. Наприклад, корпоративний сайт на Next.js + Strapi дає TTFB <200ms, що у 5 разів менше ніж аналог на WordPress.

Автоматично конвертуємо зображення в WebP/AVIF, генеруємо srcset для всіх роздільних здатностей, використовуємо lazy loading з Intersection Observer. Для фонових зображень — техніка progressive loading.

Порівняльна таблиця

Вартість у кожному випадку розраховується індивідуально після вивчення технічного завдання. — Google рекомендує TTFB під 0.8s, у нас <0.2s.

Що входить в роботу

• Аналітика та прототипування (структура, користувацькі сценарії)
• Дизайн-концепція (адаптивний, mobile-first)
• Верстка з оптимізацією LCP, CLS, INP
• Вибір та налаштування CMS (якщо потрібна)
• Інтеграція з CRM/маркетинговими інструментами
• Тестування (кросбраузерне, load-testing)
• Документація та передача доступів
• Навчання редакторів (відео + письмово)
• гарантія 3 місяці (безкоштовні правки)

Друга таблиця: порівняння підходів за продуктивністю

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