Headless CMS für Lovable-Sites: Wann lohnt es sich – und welches passt?

Das Setup: Lovable + Headless CMS klingt logisch – ist es aber nicht immer

Lovable generiert dir eine React/Vite/Tailwind-App mit echtem Code. Das Frontend kann also alles konsumieren, was eine API ausspricht. Headless CMS sprechen APIs. Match made in heaven?

Nicht ganz. Bevor du Sanity, Strapi oder Contentful an deine Lovable-Site flanschst, lohnt eine ehrliche Frage: Brauchst du das überhaupt? Wir haben dazu einen eigenen Artikel geschrieben – der ist die ehrlichere Brücke. Dieser hier nimmt an, dass du dich bereits dafür entschieden hast.

Drei Konstellationen, in denen ein Headless CMS für Lovable-Sites Sinn ergibt

1. Redakteure ohne Lovable-Zugang

Lovable ist ein Builder, kein Redaktionssystem. Wenn dein Marketing-Team täglich Texte ändern, Bilder tauschen oder Landingpages spinnen will – ohne dass jedes Mal jemand das Lovable-Projekt öffnet – brauchst du eine Editor-Oberfläche, die nicht der Lovable-Editor ist.

2. Multi-Channel-Content

Derselbe Content auf Website, Newsletter, App und Partnerportal? Dann muss Content zentral liegen und per API überall hin ausgespielt werden. Eine reine Lovable-Site mit Lovable Cloud reicht, solange es nur eine Site gibt. Sobald ein zweiter Konsument dazukommt, gewinnt ein echtes CMS.

3. Bestehende Editorial-Workflows

Wenn dein Team bereits in Contentful, Sanity oder Storyblok lebt – respektiere das. Migrieren ist teuer und politisch. Lovable als Frontend an ein bestehendes CMS anzubinden ist trivial; das CMS gegen Lovable Cloud zu tauschen ist ein Change-Management-Projekt.

Welches Headless CMS passt zu einer Lovable-Site?

Lovable-Sites sind React-Vite-SPAs, die per Playwright zu statischem HTML pre-rendered und auf Vercel Edge deployed werden (so läuft dieses Projekt hier). Die wichtigsten Auswahlkriterien:

• API-Qualität (REST oder GraphQL, idealerweise typsicher)
• Free Tier, der für reale Projekte reicht
• DSGVO-Konformität / EU-Hosting-Option
• Editor-UX, die nicht-technische Menschen tatsächlich nutzen

Sanity – die pragmatische Standardwahl

• ✅ Großzügiger Free Tier (3 User, unbegrenzte Inhalte)
• ✅ Echtzeit-Kollaboration, gutes Editor-Studio
• ✅ TypeScript-SDK, @sanity/client integriert sich in Vite ohne Drama
• ⚠️ Hosting in den USA (EU-Region kostenpflichtig)
• 👉 Gut für: Marketing-Sites, Blogs, Portfolios

Strapi – wenn du self-hosten willst

• ✅ Open Source, self-hosted auf eigener Infra
• ✅ REST + GraphQL out of the box
• ✅ Volle Datenhoheit, DSGVO unproblematisch
• ⚠️ Du betreibst einen Node-Server – Wartung, Updates, Security
• 👉 Gut für: Agenturen, regulierte Branchen, größere Setups

Payload CMS – die TypeScript-First-Option

• ✅ Code-driven Config (kein Klick-Studio), passt zum Builder-Mindset
• ✅ TypeScript end-to-end, exzellente DX
• ✅ Self-hosted oder Payload Cloud
• ⚠️ Jüngeres Ökosystem, weniger Plugins als Strapi
• 👉 Gut für: Developer-getriebene Teams, die ihr CMS wie Code behandeln

Storyblok – wenn Editoren Visual Editing brauchen

• ✅ Echter Visual Editor (Klick auf Element = bearbeiten)
• ✅ EU-Hosting verfügbar
• ⚠️ Visual Editing braucht ein Live-Preview-Setup im Lovable-Projekt
• 👉 Gut für: Marketing-lastige Teams, die WYSIWYG vermissen

Für einen vollständigen Vergleich aller Optionen – inklusive Contentful, Hygraph und Ghost – schau in den Headless-CMS-Hub für AI First Builders.

Integration in eine Lovable-Site: Das Pattern

Egal welches CMS du wählst, das Muster ist immer dasselbe:

// src/lib/cms.ts
import { createClient } from "@sanity/client"

export const cms = createClient({
  projectId: import.meta.env.VITE_SANITY_PROJECT_ID,
  dataset: "production",
  apiVersion: "2024-01-01",
  useCdn: true,
})

export async function getPosts() {
  return cms.fetch(`*[_type == "post"] | order(date desc)`)
}

In einer Lovable-Komponente:

const { data: posts } = useQuery({
  queryKey: ["posts"],
  queryFn: getPosts,
})

Das war's. React Query (in Lovable-Projekten standardmäßig dabei) kümmert sich um Caching, der CMS-Client um die API.

Build-Time vs. Runtime

Zwei Strategien:

• Runtime-Fetching (wie oben): Content wird live im Browser geladen. Einfach, aber jeder Visit löst API-Calls aus.
• Build-Time-Fetching (Static Site Generation): Content wird beim Deploy gefetcht und ins Bundle gebacken. Schneller, SEO-stark, aber Updates brauchen einen Re-Deploy.

Für die meisten Marketing-Sites ist SSG die richtige Antwort. Dieses Blog hier macht genau das – Markdown wird beim Build gerendert, Vercel deployed statisches HTML. Mit einem Headless CMS funktioniert es identisch: Webhook vom CMS → Vercel-Deploy → fertig.

Lovable Cloud als Alternative – nicht vergessen

Bevor du ein externes CMS dazuholst: Lovable Cloud vs. Supabase erklärt, warum die eingebaute Datenbank für viele Content-Use-Cases reicht. Eine posts-Tabelle mit RLS, ein einfaches Admin-Interface im selben Lovable-Projekt, fertig. Kein zweiter Anbieter, keine zweite Rechnung, kein zweites Login.

Faustregel: Wenn nur du oder maximal 2-3 technische Menschen Content pflegen, reicht Lovable Cloud. Sobald nicht-technische Redakteure dazukommen oder mehrere Frontends bedient werden müssen, lohnt der Sprung zum Headless CMS.

Ein Sonderfall: CMS am Edge

Wenn du sowieso auf Cloudflare/Vercel Edge deployst, lohnt ein Blick auf neuere Optionen wie Cloudflare's eigene Lösung – wir haben Emdash CMS auf Cloudflare im Detail angesehen. Spannend, weil es Content-Storage und Edge-Delivery in einem Schritt löst.

Fazit: Nicht jedes Lovable-Projekt braucht ein CMS, aber wenn dann ein passendes

Headless CMS für Lovable-Sites funktionieren technisch hervorragend – React Query plus API-Client plus typisierte Inhalte ist ein robustes Setup. Die wirkliche Frage ist nicht welches CMS, sondern ob.

Für 80% der Lovable-Projekte reicht Lovable Cloud. Für die restlichen 20% – Marketing-Sites mit redaktionellem Workflow, Multi-Channel-Setups, bestehende CMS-Investitionen – ist Sanity der pragmatische Default, Payload die Developer-Lieblingswahl und Strapi die Self-Hosted-Antwort.

---

Du planst eine Lovable-Site mit redaktionellem Content-Workflow? Sprich mit uns – wir helfen bei Stack-Entscheidung und Integration.

📚 Mehr zum Thema: Alle Artikel zu Headless CMS, Jamstack & API-First findest du in unserem Headless-CMS-Hub für AI First Builders.