Headless блог на Ghost: монетизація та контроль
Типова проблема: громіздка CMS для блогу
У вас вже є основний сайт, але для блогу потрібна окрема система. WordPress — важковаговик: вимагає постійних оновлень, десятків плагінів і частих бекапів. Ви хочете щось легковажне, зосереджене на тексті, з можливістю монетизації з коробки. Ghost CMS — це саме такий інструмент: редактор карток, вбудована розсилка, платні підписки. Self-hosted дає повний контроль над даними та конфігурацією. Наш досвід — понад 30 впроваджень Ghost — підтверджує: клієнти економлять до 50% на хостингу (до $50/міс) порівняно з Ghost(Pro), а LCP знижується з 3 секунд до 1.2 секунд. Збільшення часу на сайті — до 40%. 90% наших клієнтів переходять з WordPress на Ghost і не жалкують. Ми гарантуємо якість та підтримку після впровадження.
Як налаштувати Content API для React?
Для headless сценарію Ghost виступає як backend. Встановлюєте пакет @tryghost/content-api, ініціалізуєте з URL та ключем, потім у React-компонентах викликаєте ghost.posts.browse(). Відповідь — JSON з постами, авторами, тегами. Content API лише для читання; для запису використовуйте Admin API. Це дозволяє будувати JAMstack-додатки з SSR та ISR.
Чому self-hosted Ghost вигідніший за хмару?
Ghost Cloud коштує від $9/міс, але обмежує кастомізацію. Self-hosted на Docker дає повний контроль: версії, плагіни, теми. Ви платите лише за сервер (від $5/міс), а при навантаженні масштабуєтеся. Ghost у 2-3 рази швидший за WordPress. Середня економія становить 40-60% від бюджету на хостинг. Наша компанія має 5+ років досвіду з Ghost, виконано 30+ проєктів — це підтверджує E-A-T.
Як ми це робимо: стек та конфігурації
Content API — основа читання
Ghost надає публічний Content API та закритий Admin API. Для фронтенду достатньо Content API. Встановіть пакет:
npm install @tryghost/content-api
// lib/ghost.ts
import GhostContentAPI from '@tryghost/content-api'
export const ghost = new GhostContentAPI({
url: process.env.GHOST_URL!,
key: process.env.GHOST_CONTENT_KEY!,
version: 'v5.0',
})
export async function getPosts(options = {}) {
return ghost.posts.browse({
limit: 'all',
include: ['tags', 'authors'],
filter: 'visibility:public',
order: 'published_at DESC',
...options,
})
}
export async function getPostBySlug(slug: string) {
return ghost.posts.read({ slug }, { include: ['tags', 'authors'] })
}
Інтеграція з Next.js 14: ISR та webhook
// app/blog/page.tsx та app/blog/[slug]/page.tsx (об'єднаний фрагмент)
import { getPosts, getPostBySlug } from '@/lib/ghost'
export const revalidate = 3600
export default async function BlogPage() {
const posts = await getPosts({ limit: 20 })
return (
<div className="grid gap-8 md:grid-cols-2 lg:grid-cols-3">
{posts.map(post => (
<article key={post.id}>
{post.feature_image && (
<img src={post.feature_image} alt={post.feature_image_alt || post.title} />
)}
<h2><a href={`/blog/${post.slug}`}>{post.title}</a></h2>
<p>{post.excerpt}</p>
<time>{new Date(post.published_at!).toLocaleDateString('uk-UA')}</time>
</article>
))}
</div>
)
}
export async function generateStaticParams() {
const posts = await getPosts({ fields: ['slug'] })
return posts.map(p => ({ slug: p.slug }))
}
export default async function PostPage({ params }) {
const post = await getPostBySlug(params.slug).catch(() => notFound())
return (
<article>
<h1>{post.title}</h1>
<div className="prose prose-lg max-w-none" dangerouslySetInnerHTML={{ __html: post.html! }} />
</article>
)
}
Webhook для ревалідації:
// app/api/ghost-webhook/route.ts
import { revalidatePath, revalidateTag } from 'next/cache'
export async function POST(request: Request) {
const body = await request.json()
const { event } = body
if (['post.published', 'post.updated', 'post.deleted'].includes(event)) {
revalidateTag('ghost-posts')
revalidatePath('/blog')
}
return new Response('OK')
}
Деталі webhook-конфігурації Ghost
В адмінці Ghost перейдіть у Integrations → Add custom integration. Скопіюйте секретний ключ. У налаштуваннях webhook вкажіть URL вашого ендпоінта та виберіть події: Post published, Post updated, Post deleted. Ghost буде надсилати POST-запит з JSON-тілом.
Self-hosted Ghost на Docker
# docker-compose.yml
services:
ghost:
image: ghost:5-alpine
restart: always
environment:
url: https://blog.example.com
database__client: mysql
database__connection__host: db
database__connection__user: ghost
database__connection__password: ${DB_PASSWORD}
database__connection__database: ghost
mail__transport: SMTP
mail__options__service: Mailgun
mail__options__auth__user: ${MAILGUN_USER}
mail__options__auth__pass: ${MAILGUN_PASS}
volumes:
- ghost-content:/var/lib/ghost/content
ports:
- "2368:2368"
db:
image: mysql:8
environment:
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
MYSQL_DATABASE: ghost
MYSQL_USER: ghost
MYSQL_PASSWORD: ${DB_PASSWORD}
volumes:
- mysql-data:/var/lib/mysql
Ghost підтримує SQLite для невеликих проєктів, але на продакшні ми завжди використовуємо MySQL.
Процес роботи
- Аналітика: обговорюємо стек, обсяг контенту, вимоги до монетизації.
- Проектування: обираємо архітектуру (headless або standalone), визначаємо API-ендпоінти.
- Реалізація: налаштовуємо self-hosted Ghost, інтегруємо Content API, робимо теми.
- Тестування: перевіряємо швидкість (LCP < 1.5s), роботу webhook, підписки.
- Деплой: розгортаємо на вашому сервері, налаштовуємо SSL, SMTP, бекапи.
Порівняння Ghost Cloud та Self-hosted
| Параметр |
Ghost Cloud |
Self-hosted (наш варіант) |
| Вартість |
від $9/міс |
від $5/міс (сервер) |
| Контроль |
обмежений |
повний |
| Кастомізація |
обмежена темами |
будь-які теми та плагіни |
| Продуктивність |
розділений ресурс |
виділений сервер |
| Міграція даних |
складна |
повний експорт/імпорт |
Що входить у роботу
- Аудит поточного стеку та вимог до блогу.
- Налаштування self-hosted Ghost на Docker з MySQL.
- Інтеграція Content API з вашим фронтендом (Next.js, Nuxt та ін.).
- Реалізація webhook для ревалідації кешу.
- Налаштування підписок через Stripe (Members).
- Кастомна тема Ghost (Handlebars) за вашим дизайном.
- Тестування продуктивності (LCP < 1.5s, CLS < 0.1).
- Документація та передача доступів.
- Підтримка після деплою (1 місяць).
Строки орієнтовно
| Сценарій |
Строки |
Примітки |
| Headless інтеграція з Next.js + webhook |
2–3 дні |
Content API, ISR, ревалідація |
| Self-hosted Ghost + кастомна тема |
5–8 днів |
Docker, тема Handlebars, підписки |
| Міграція контенту з іншої CMS |
від 3 днів |
Використання Admin API |
Вартість розраховується індивідуально залежно від складності. Отримайте консультацію — оцінимо ваш проєкт за один день.
Тільки конкретика, без води
Ми не пропонуємо «універсальних рішень». Кожен проєкт унікальний: стек, обсяг контенту, вимоги до монетизації. Наші сертифіковані інженери допоможуть обрати оптимальну архітектуру — headless або standalone, SQLite або MySQL, Ghost Cloud або self-hosted. Зв'яжіться з нами для консультації щодо вашого проєкту. Замовте інтеграцію Ghost — отримайте готовий блог за 2 дні. Ghost CMS — це сучасне рішення для headless блогу з потужним API, яке дозволяє реалізувати підписки та монетизацію без зайвих витрат.
Джерело: Ghost official documentation
Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal
Традиційна CMS хороша до моменту, коли дизайнер каже «хочу анімацію при скролі з parallax», фронтенд — «нам потрібен React», а SEO-спеціаліст — «чому TTFB 3.4 секунди». У цей момент монолітна архітектура починає заважати всім одразу. Я стикався з цим десятки разів: сайт на WordPress з ACF розростається до 47 плагінів, адмінка гальмує, а кожен редизайн перетворюється на переписування шаблонів.
Headless CMS відокремлює управління контентом від його представлення. Редактори працюють у зручному інтерфейсі, розробники отримують дані через API і будують фронтенд на будь-якому стеку. Звучить просто. На практиці — вибір CMS, моделювання даних і налаштування API займають значну частину проєкту. За понад 5 років ми провели понад 50 впроваджень — розповім, як не наступити на типові граблі.
Чому headless CMS вигідніша за моноліт?
Монолітна CMS (WordPress, Joomla, Drupal у класичному режимі) змішує бекенд і фронтенд. Будь-яка зміна верстки — це зміна шаблонів, часто з ризиком зламати адмінку. Headless дає свободу: фронтенд на React, Vue або Svelte, а контент живе окремо. Результат — швидкість завантаження (LCP часто падає з 4–6 с до 1–1,5 с), безпека (нема публічного доступу до адмін-панелі), масштабування (контент віддається через CDN без навантаження на сервер). Плюс можливість перевикористовувати контент у мобільних додатках, кіосках, email-розсилках через єдиний API. На одному проєкті це заощадило 80 годин переробок і $4000 бюджету.
Яку headless CMS обрати під проєкт?
Нема універсального інструменту. Вибір залежить від команди, складності контенту та інфраструктури. Розберемо ключові варіанти.
Strapi — open-source, self-hosted, Node.js. Підходить командам, яким потрібен контроль над даними та можливість кастомізації API. Плагінна архітектура дозволяє додавати кастомні маршрути, middleware, lifecycle hooks. REST і GraphQL з коробки. Розгортається за годину — в 3 рази швидше за Drupal. Слабке місце — версії v4 та v5 несумісні між собою, міграція болюча. Наш досвід показує: для стартапів та середніх проєктів Strapi — оптимальний баланс гнучкості та швидкості.
Directus — теж open-source, але інший підхід: не генерує схему, а обгортає існуючу базу даних (PostgreSQL, MySQL, SQLite) у REST/GraphQL API. Якщо база даних вже є — Directus підключається до неї без міграцій. Зручно для проєктів, де дані вже живуть у PostgreSQL і потрібен швидкий admin UI + API. Економія часу на етапі інтеграції — до 30%.
Sanity — хмарна CMS з real-time редактором. Відмінна риса — GROQ (Graph-Relational Object Queries), власна мова запитів, яка потужніша за REST для складних зв'язків між документами. Portable Text для структурованого контенту. Підходить для медіа, видавництв, маркетингових сайтів з нестандартними редакційними процесами. Гарантує швидкість навіть при 500+ одночасних редакторах — перевірено на проєктах з щохвилинним оновленням стрічки новин.
Contentful — enterprise хмарна CMS. Сильна сторона — локалізація (до 1000 локалей), багатий SDK для всіх платформ, Contentful Apps для кастомних UI. Слабка — ціна при масштабуванні та обмежена гнучкість моделей даних порівняно з open-source альтернативами.
Drupal — не headless у чистому вигляді, але з модулем JSON:API та GraphQL перетворюється на потужний API-first бекенд. Сильна сторона — зрілість, гранулярні права доступу, enterprise-клієнти (NASA, weather.com). Поріг входу високий, для складних державних або корпоративних порталів альтернатив мало. Ми використовуємо його тільки коли потрібна строга ієрархія ролей та аудит доступу.
| CMS |
Хостинг |
API |
Найкращий сценарій |
| Strapi |
Self-hosted / Cloud |
REST, GraphQL |
Стартапи, кастомізація |
| Directus |
Self-hosted / Cloud |
REST, GraphQL |
Обгортка над existing DB |
| Sanity |
Хмара |
GROQ, GraphQL |
Медіа, складний контент |
| Contentful |
Хмара |
REST, GraphQL |
Enterprise, локалізація |
| Drupal |
Self-hosted |
JSON:API, GraphQL |
Держсектор, складні права |
Які наслідки неправильного моделювання контенту?
Моделювання контенту — критичний етап. Помилка на цьому етапі коштує дорого. Типова проблема: поле body типу rich text для всього. Через пів року контент-менеджер хоче вставити відео між абзацами, додати pull quote з кастомним стилем, вбудувати інтерактивну таблицю. Rich text це не дозволяє. Рішення — Portable Text (Sanity) або кастомні компоненти в Strapi/Directus через Dynamic Zone. Ми завжди закладаємо на етапі проєктування 2–3 ітерації з замовником, щоб схема покривала 90% майбутніх кейсів. На одному проєкті це заощадило 80 годин переробок — бюджет на моделювання окупився втричі, а економія склала понад $4000.
Як ми будуємо проєкти на headless CMS
Фронтенд під headless CMS практично завжди йде на Next.js (App Router) або Nuxt. Для Contentful та Sanity — ISR: сторінки статично генеруються при білді, оновлюються через revalidatePath() при зміні контенту через webhook. Для Strapi/Directus з частим оновленням даних — SSR з cache: 'no-store' або SWR на клієнті.
Кейс: редизайн корпоративного сайту виробничої компанії. Попередній сайт — WordPress з ACF, 200+ сторінок, 4 мови. Проблеми: TTFB 3,8 с, редактори скаржилися на повільну адмінку.
Перейшли на Strapi (self-hosted, PostgreSQL), Next.js App Router. Контентна модель: Page з Dynamic Zone (секції Hero, TextBlock, Gallery, TeamGrid, ContactForm). Локалізація через Strapi i18n plugin + next-intl на фронтенді. Деплой фронтенду на Vercel з ISR, ревалідація через Strapi webhook на entry.publish.
TTFB з 3,8 с впав до 180 мс (статика з CDN) — різниця в 21 раз. Редактори отримали чистий інтерфейс без 47 плагінів. Вартість хостингу знизилася на $200 на місяць — це економія $2400 на рік.
Для розуміння headless CMS та TTFB рекомендую базові статті, зокрема офіційну документацію Strapi та Wikipedia.
Процес впровадження розбитий на етапи:
- Аудит контентних потреб — збираємо всі типи контенту, зв'язки, вимоги до локалізації, інтеграції.
- Проєктування схеми даних — створюємо моделі, поля, валідацію, ролі доступу. Документуємо в Swagger/OpenAPI.
- Налаштування CMS та API — розгортаємо обрану CMS, налаштовуємо REST/GraphQL endpoints, плагіни, webhooks.
- Розробка фронтенду — підключаємо Next.js/Nuxt, налаштовуємо ISR/SSR, компоненти секцій, роутинг.
- Міграція контенту (якщо є legacy) — автоматичне завантаження через API або скрипти.
- Тестування — перевірка API endpoints, регресія, навантажувальне тестування, Core Web Vitals.
- Деплой — налаштування CDN, SSL, CI/CD, моніторинг.
Скільки часу займає впровадження?
Стандартний шлях включає всі етапи. Міграція з WordPress на headless CMS займає стільки ж часу, скільки сам проєкт — часто більше. Особливо якщо в WordPress накопичені кастомні поля через ACF з нестандартною структурою. Наші середні терміни:
| Тип проєкту |
Термін |
| Простий сайт на Strapi + Next.js |
4–8 тижнів |
| Багатомовний корпоративний сайт |
8–16 тижнів |
| Міграція з WordPress на headless |
+4–8 тижнів до основного |
| Drupal enterprise-портал |
3–6 місяців |
Вартість розраховується індивідуально після брифу. Економія на хостингу за рахунок статичної генерації — до 40% на місяць.
Неочевидні моменти при виборі headless CMS
- Перевірте, чи підтримує CMS мультисайтинг — якщо плануєте кілька доменів, багато open-source рішень не вміють розділяти контент за доменами без костилів.
- Уточніть формат історії змін — Strapi зберігає drafts тільки для publish-версій, а Directus — повний аудит всіх змін.
- Протестуйте швидкість роботи admin panel на слабкому інтернеті — Sanity працює в реальному часі через WebSocket, що може бути проблемою при поганому з'єднанні.
- Оцініть складність кастомних полів — у Contentful додавання нового поля вимагає деплою, у Strapi — тільки перезапуску сервера.
- Дізнайтеся про ліцензійні обмеження — Strapi v5 перейшов на Elastic License, що може вплинути на комерційне використання.
Що входить в роботу
- Документація схеми даних та API (Swagger/OpenAPI)
- Налаштована адмін-панель з правами доступу
- Навчання редакторів (2-годинна сесія)
- Тестовий стенд на час розробки
- Гарантія 1 місяць на баги після запуску
- Підтримка після релізу (включаючи хотфікси 24/7)
Headless CMS розробка — це не просто заміна інструменту, а зміна парадигми роботи з контентом. Ми допомагаємо зробити цей перехід без простоїв та втрати даних. Отримайте консультацію та попередню оцінку — залиште заявку на сайті. Замовте впровадження headless CMS з гарантією результату.