Kamaankamaan

Wie du deinem SaaS-Produkt einen Blog hinzufügst: ein Entwickler-Leitfaden

Die meisten SaaS-Produkte behandeln den Blog als Nachgedanken und zahlen jahrelang dafür. Hier ist der ehrliche Weg: REST-API-Delivery, Multi-Site von Anfang an, in unter einer Stunde live.

Junaid Khalid
Junaid Khalid
27. Mai 2026 · 12 min read

Die meisten SaaS-Produkte fügen einen Blog erst nachträglich hinzu, drei Jahre nach Launch, wenn das Marketing-Team endlich fragt, warum der organische Traffic flach ist. Die Entwickler richten WordPress auf einer Subdomain ein, die SEO leckt zwischen zwei Properties, und niemand besitzt die Integration. Zwei Jahre später muss der Blog in fünf Sprachen erscheinen und der Gründungsentwickler schreibt mittwochabends um 23 Uhr eine eigene Übersetzungspipeline. Es gibt einen saubereren Weg, deinem SaaS-Produkt einen Blog hinzuzufügen, und er erfordert nichts davon.

Kurz-Takeaways

  • Ein Blog innerhalb deines SaaS-Produkts braucht drei Dinge: einen Content-Store, eine Delivery-API und eine Render-Schicht in deiner App. Überspringst du eines davon, bereust du es später.
  • Subdirectories (deineapp.com/blog) bündeln SEO. Subdomains (blog.deineapp.com) zersplittern sie. Das ist die teuerste einzelne Entscheidung, die Leute falsch treffen.
  • Contentful Lite startet bei 300 $/Monat. Sanity Free deckelt bei 10.000 Dokumenten. Ein eigenes CMS zu bauen kostet 4 bis 12 Wochen Engineering. Keines davon ist die richtige Antwort für ein kleines SaaS-Team, das diese Woche einen Blog live haben will.
  • Die REST API Delivery von Kamaan liefert Standard-JSON an jedes Framework: Next.js, Nuxt, SvelteKit, Astro oder was auch immer. Auto-Multilingual Delivery veröffentlicht spanische, deutsche, französische und italienische Versionen in dem Moment, in dem du auf Englisch veröffentlichst.
  • Der erste Monat ist kostenlos. Ein Kamaan-Konto deckt unbegrenzt Sites zu einem flachen Monatspreis ab, sodass das Hinzufügen des Blogs zu deinem zweiten Produkt später keine zweite Rechnung erzeugt.

Die drei beweglichen Teile eines SaaS-Blogs

Jeder SaaS-Blog hat die gleichen drei Teile, egal wie du ihn baust.

Der erste Teil ist der Content-Store. Hier leben Artikel als strukturierte Daten, mit Feldern für Titel, Body, Slug, Metadaten, geplante Veröffentlichungszeiten und Übersetzungen. Der zweite Teil ist eine Delivery-API, die diesen Content an die App weiterreicht, die ihn rendern soll. Der dritte Teil ist die Render-Schicht in deinem SaaS-Frontend, die die API abfragt, den Content in dein bestehendes Layout einfügt und ihn unter deiner Domain ausliefert.

Wenn Teams hier abkürzen, lassen sie meist die API weg und betten ein iframe ein, oder sie überspringen die Render-Schicht und hosten den Blog unter einer anderen Domain. Beide Abkürzungen kosten mehr, als sie sparen. Ein iframe-Blog trägt nicht zur SEO deiner Site bei, weil Google die Quell-Domain des iframes indexiert, nicht deine. Ein Subdomain-Blog (blog.deineapp.com) wird zwar indexiert, aber Google behandelt Subdomains als getrennte Properties, sodass dein Link-Equity sich nicht zwischen Produkt und Blog summiert. Subdirectory-Hosting (deineapp.com/blog) hält alles unter einer Domain und einer SEO-Oberfläche, was seit zehn Jahren jede seriöse SEO-Studie zeigt.

Warum "nimm halt WordPress" für ein SaaS-Produkt meistens falsch ist

WordPress ist der Standardvorschlag, weil es jeder schon mal installiert hat. Für eine Marketing-Site, die keine Domain mit einem Produkt teilt, ist das in Ordnung. Für einen Blog, der in einem React- oder Next.js-SaaS-Frontend leben muss, ist es ein erzwungener Fit.

Die Integration wird immer zu einem Reverse-Proxy-Problem. Du fährst WordPress entweder auf einer Subdomain (was dich die SEO-Bündelung kostet) oder du baust eine Reverse-Proxy-Regel, die /blog/* auf eine getrennte WordPress-Installation umschreibt. Der Reverse-Proxy-Ansatz funktioniert, bringt aber ein zweites Deployment, einen zweiten Satz an Security-Patches und eine Styling-Grenze mit sich, an der deine SaaS-App aufhört, wie sie selbst auszusehen. WordPress geht außerdem standardmäßig von server-side Rendering aus, was modernen SaaS-Frontends auf Next.js, Nuxt oder SvelteKit zuwiderläuft. Du kannst WordPress headless nutzen, aber dann hast du alle Betriebskosten von WordPress plus die Integrationskosten eines headless CMS, und keinen der mehrsprachigen oder Multi-Site-Vorteile, die dir ein zweckgebautes headless CMS geben würde.

Ein Blog in einem SaaS-Produkt ist keine separate Website. Es ist Content, der von derselben App gerendert wird, die deine Produkt-UI rendert. Genau das löst ein headless CMS, und deshalb lautet die Frage nicht "WordPress oder nicht" sondern "welches headless CMS".

Diagramm zeigt eine SaaS-App, die Blog-Content von einem REST-API-Endpoint abruft, der von Kamaan, dem headless Blog-CMS, geliefert wird

Wie eine saubere Integration tatsächlich aussieht

Eine saubere Integration hat vier Eigenschaften. Erstens: Blog-Content wird von einem einzigen REST-Endpoint mit vorhersagbarem JSON abgerufen. Zweitens: Dieser Endpoint ist schnell genug, um auf jeden Request hin aufgerufen zu werden, ohne Build-Schritt. Drittens: Derselbe Content-Store serviert jede Sprachversion jedes Artikels, indexiert auf eine Art, die die API versteht. Viertens: Die Integration berührt dein bestehendes Repo, nicht ein separates.

In Next.js ist das Muster eine Server Component oder ein Route Handler unter /app/blog/[slug]/page.tsx, der die CMS-API zur Render-Zeit aufruft. Mit Kamaans REST-API-Auslieferung sieht dieser Aufruf aus wie ein Standard-fetch gegen /v1/sites/{site_id}/articles?slug=<slug>&language=en und liefert Artikel-Body, SEO-Felder, Featured-Image-URL und die komplette Übersetzungs-Map in einer Antwort. Du renderst es mit deinem bestehenden Layout, deiner bestehenden Typografie und deiner bestehenden Analytics. Kein zweites Deployment, keine separate Styling-Schicht, keine Proxy-Regeln.

Dasselbe Muster funktioniert in Nuxt mit einer Server-Route, in SvelteKit mit einer +page.server.ts Load-Funktion und in Astro mit einer statischen oder dynamischen Route. Dem CMS ist egal, welches Framework du nutzt. Genau das ist der Punkt einer REST-API: Der Vertrag ist das Netzwerkprotokoll, nicht das Framework.

Wie du wählst, in einer Tabelle

Die meisten Teams haben keine Wochen, um jedes headless CMS am Markt zu evaluieren. Unten steht die ehrliche Version des Vergleichs, bewertet auf den Dimensionen, die die Integration eines kleinen SaaS-Teams tatsächlich kaputt machen.

Ansatz Setup-Zeit Monatliche Kosten Multi-Site Auto-i18n Lock-in-Risiko
Eigenes CMS bauen 4 bis 12 Wochen Engineering-Zeit Ja (dein Code) Nein Hoch (dein Code)
WordPress auf Subdomain 1 bis 3 Tage Etwa 20 $/Monat Hosting 1 Installation pro Site Plugin, kostenpflichtig Mittel
Contentful Lite 1 bis 2 Tage 300 $/Monat Add-on Environments Manueller Workflow Mittel-hoch
Sanity Free 3 bis 7 Tage (Studio-Config) 0 $ bis 15 $/User/Monat Dataset pro Site Manueller Workflow Niedrig-mittel
Kamaan Unter 1 Stunde Erster Monat kostenlos, dann flach jährlich Unbegrenzt unter einem Konto 99+ Sprachen beim Publish Niedrig (Standard-REST)

Die Infografik unten listet denselben Vergleich mit den Callouts, die für ein kleines Team, das in diesem Quartal einen Blog hinzufügt, am wichtigsten sind.

Vergleichsinfografik von fünf Wegen, einem SaaS-Produkt einen Blog hinzuzufügen: selbst bauen, WordPress auf Subdomain, Contentful Lite, Sanity Free und Kamaan, bewertet nach Setup-Zeit, Monatskosten, Multi-Site, Auto-Übersetzung und Lock-in-Risiko

Contentful verlangt 300 $/Monat im ersten bezahlten Tier. Sanity verlangt Schema-as-Code und einen Entwickler zum Konfigurieren. Storyblok verlangt pro Space, was sich über mehrere Produkte schnell summiert. Wenn du ein Produkt, eine Sprache und Erfahrung mit headless hast, ist Sanity Free vernünftig. Wenn du mehrere Produkte hast oder in Europa oder LATAM verkaufst, sind die Multi-Site- und Multilingual-Spalten dort, wo sich die Kostenunterschiede aufsummieren.

Schritt für Schritt: Einen Blog zu einer bestehenden SaaS-App in unter einer Stunde hinzufügen

Das ist der Weg mit Kamaan. Ersetze durch dein Wunsch-Tool, wenn du andere evaluierst, aber die Form der Schritte ist für jedes headless CMS mit REST-API gleich.

  1. Lege die Site in deinem CMS an. Wähle einen Site-Identifier, der zu deiner Domain passt. Bei Kamaan ist das ein Formular, ein Klick. Du bekommst eine API-Base-URL und einen Read-API-Key zurück. Kein Schema zu designen, kein Studio zu deployen. Das Article CMS gibt dir Rich Text, SEO-Felder, Featured Image und Scheduling out of the box.
  2. Füge deiner SaaS-App eine /blog-Route hinzu. In Next.js ist das /app/blog/page.tsx für die Index-Seite und /app/blog/[slug]/page.tsx für den Artikel. In Nuxt, SvelteKit oder Astro die jeweils dateibasierte Route.
  3. Hole die Daten serverseitig von der API. Nutze das empfohlene Datafetching-Muster deines Frameworks. Für Kamaan liefert GET /v1/sites/{site_id}/articles?status=published den Index und GET /v1/sites/{site_id}/articles?slug={slug} einen einzelnen Artikel. Die Antwort enthält den Artikel-Body als HTML, die SEO-Meta-Felder, die CDN-URL des Featured Image und die Übersetzungs-Map.
  4. Rendere mit deinem bestehenden Layout. Wickle den Artikel-Body in deine Typografie-Komponente. Behalte Header, Footer und Analytics aus dem Rest der App. Füge die Meta-Tags aus der API-Antwort in deinen <head> ein. Setze hreflang-Tags aus der Übersetzungs-Map.
  5. Richte Locale-Routing ein. Für mehrsprachige SaaS lautet das empfohlene URL-Muster /[lang]/blog/[slug]. Kamaan liefert eine Übersetzungs-Map pro Artikel, sodass du jede Sprachversion unter ihrem eigenen Locale-Präfix rendern kannst, ohne einen zweiten Fetch pro Sprache.
  6. Veröffentliche. Schreibe den Artikel im Kamaan-Dashboard, plane oder veröffentliche, und die API liefert ihn sofort. Mit Auto-Multilingual Delivery gehen Spanisch, Deutsch, Französisch und Italienisch gleichzeitig unter ihren lokalisierten Slugs live.

Die Gesamtzeit für einen Entwickler, der sein Framework kennt, liegt deutlich unter einer Stunde. Der größte Teil davon entfällt auf die Typografie und das Verdrahten der Meta-Tags in deiner App, nicht auf die CMS-Seite.

Wo Gründer typischerweise Monate verlieren, die sie nicht verlieren mussten

Drei Fehlermodi erklären den Großteil der verschwendeten Zeit, die wir sehen.

Der erste ist, den Blog in Woche eins auf eine Subdomain zu setzen, weil es einfacher war. Sechs Monate später sind die SEO-Zahlen flach, jemand macht das Audit und das Team baut die Integration ohnehin auf einem Subdirectory neu. Wähle das Subdirectory an Tag eins und du sparst dir diesen Zyklus.

Der zweite ist, ein CMS zu wählen, das Schema-as-Code verlangt (Sanity, Strapi), für einen Blog, der dieselben fünf Felder hat wie jeder Blog. Titel, Body, Slug, Featured Image, Veröffentlichungsdatum. Es gibt kein Schema zu designen. Konfigurationszeit auf einem Schema-as-Code-CMS ist echte Engineering-Arbeit, und für einen Blog zahlt sich das nicht aus. Wähle ein CMS, das mit dem Blog-Content-Type bereits definiert ausgeliefert wird.

Der dritte ist, mehrsprachig nachträglich zu bezahlen. Contentful, Sanity und Storyblok unterstützen mehrsprachigen Content, aber der Workflow ist "lege die englische Version an, dann für jede Sprache manuell einen übersetzten Eintrag". Für ein Team, das 4 Artikel im Monat in 5 Sprachen ausliefert, sind das 20 Übersetzungsaufgaben pro Monat, die jemand managen muss. Kamaans Auto-Multilingual Delivery veröffentlicht spanische, deutsche, französische und italienische Versionen jedes Artikels in dem Moment, in dem du auf Englisch publish drückst. Null Extra-Schritte.

Reale Szenarien

Eine Solo-Gründerin, die ein B2B-SaaS-Rechnungstool betreibt, will einen Blog für SEO. Sie wählt Kamaan, legt eine Site an, packt eine /blog-Route in ihre Next.js-App und zeigt sie auf die Kamaan-REST-API. Ihr erster Artikel ist denselben Nachmittag unter kamaan.io/blog/... live. Sie schreibt den nächsten Post auf Englisch, drückt publish und innerhalb von zehn Minuten hat Kamaan spanische, deutsche, französische und italienische Versionen unter /es/blog/, /de/blog/, /fr/blog/ und /it/blog/ auto-veröffentlicht. Google indexiert alle fünf in 48 Stunden. Sie hat kein einziges Wort in einer zweiten Sprache geschrieben und keinen Übersetzungsanbieter bezahlt.

Ein bootstrappender Gründer, der drei SaaS-Produkte betreibt, publiziert Blog-Updates für alle drei aus einem einzigen Kamaan-Dashboard. Ein Konto deckt alle drei Sites zu einem flachen Monatspreis ab. Derselbe Artikel teilt zwischen unterschiedlichen Produkten keinen Content, aber der Integrationscode in jedem Frontend ist identisch: gleiche REST-Endpoint-Form, gleiches Artikel-Schema, gleiches mehrsprachiges Handling. Wenn er nächstes Quartal Produkt Nummer vier launcht, fügt er eine Site hinzu, packt dieselbe /blog-Route hinein und geht am selben Tag live.

FAQ

Wie füge ich einer Next.js-SaaS-App einen Blog hinzu, ohne meine bestehenden Routen kaputtzumachen?

Erstelle /app/blog/page.tsx für die Index-Seite und /app/blog/[slug]/page.tsx für einzelne Artikel. Hole die Daten zur Render-Zeit mit fetch() innerhalb der Server Component aus deinem headless CMS. Wickle die Antwort in deine bestehenden Layout-Komponenten. Mit Kamaans REST API Delivery kommt der Artikel-Body als HTML zurück, also legst du ihn in einen Typografie-Wrapper und servierst ihn unter deiner bestehenden Domain.

Sollte mein Blog auf blog.meineapp.com oder meineapp.com/blog liegen?

meineapp.com/blog. Subdirectory-Hosting bündelt SEO unter deiner Hauptdomain. Subdomains werden von Google als getrennte Properties behandelt, was deine Link-Equity zersplittert und die Zeit bis zum Ranking verlängert. Der einzige Grund, eine Subdomain zu nutzen, ist, dass du dein SaaS-Framework buchstäblich nicht dazu bringst, Content unter /blog zu rendern, was bei Next.js, Nuxt, SvelteKit oder Astro im Wesentlichen nie der Fall ist.

Kann ich ein kostenloses headless CMS für meinen SaaS-Blog nutzen?

Ja, mit Vorbehalten. Sanity Free deckelt bei 10.000 Dokumenten, was für einen Blog Jahre reicht. Contentful Free hat engere Grenzen bei Einträgen und API-Calls, ist aber für einen kleinen Blog tauglich. Der Haken bei beiden: Mehrsprachige Workflows sind manuell und Multi-Site kostet extra. Kamaans erster Monat ist kostenlos mit voller Mehrsprachigkeit beim Publish, was der sauberere Trial für ein Team ist, das weiß, dass es Übersetzungen braucht.

Brauche ich einen Entwickler, um einen headless-CMS-Blog aufzusetzen?

Für Sanity, Strapi oder jedes Schema-as-Code-CMS, ja. Für Kamaan, Contentful oder Storyblok ist das CMS selbst no-code; die Integration in deine App braucht einen Entwickler für Routing, Fetching und Layout-Arbeit, was typischerweise ein Nachmittag für jemanden ist, der das Framework kennt.

Wie mache ich meinen SaaS-Blog mehrsprachig, ohne Übersetzer einzustellen?

Wähle ein CMS, in dem Mehrsprachigkeit nativ ist, nicht ein Add-on. Kamaans Auto-Multilingual Delivery veröffentlicht spanische, deutsche, französische und italienische Versionen in dem Moment, in dem du auf Englisch publish drückst. Jede Version bekommt ihren eigenen lokalisierten Slug unter /[lang]/blog/<slug>. Hreflang-Tags werden aus derselben Übersetzungs-Map erzeugt. Die Übersetzungsrechnung bleibt bei null.

Was ist der Unterschied zwischen einem headless CMS und einem traditionellen CMS für einen SaaS-Blog?

Ein traditionelles CMS wie WordPress geht davon aus, dass es das Rendering besitzt. Ein headless CMS speichert und liefert Content über eine API; deine App übernimmt das Rendering. Für ein SaaS-Produkt, in dem der Blog innerhalb einer bestehenden React-, Vue- oder Svelte-App leben muss, ist headless die einzige Architektur, die ohne Reverse-Proxy-Hack funktioniert.

Wie schnell muss eine headless-CMS-API für einen SaaS-Blog sein?

Antwortzeit unter 100 ms ist die Grenze, über der eine Blog-Seite sich langsam anfühlt. Kamaans REST API Delivery wird von einem CDN-Edge vor dem Content-Store ausgeliefert, sodass typische Reads deutlich darunter liegen. Für server-renderte Seiten hast du außerdem die Option, Antworten in der Daten-Schicht deines Frameworks zu cachen (Next.js revalidate, Nuxt useFetch mit Cache-Headern), sodass die meisten Requests den Origin gar nicht treffen.

Schädigt das Hinzufügen eines Blogs zu meinem SaaS-Produkt meine Core Web Vitals?

Nur, wenn du es falsch machst. Rendere den Blog serverseitig mit den gleichen Layout-Komponenten wie den Rest deiner App, serve Bilder von einem CDN mit korrekten Width- und Height-Attributen und halte den JavaScript-Footprint der Blog-Route schlank. Mit Kamaans REST API Delivery und einer statischen oder server-renderten Blog-Route bleiben die Core Web Vitals dort, wo sie vor dem Blog waren.

Verwandt auf Kamaan

Mit Kamaan starten

Ein REST-Endpoint, jede Sprache, jede Site, die du launchst.

Kamaan gibt dir ein Dashboard für alle deine Produkt-Blogs, auto-übersetzt in 99+ Sprachen bei jedem Publish. Ein Konto deckt unbegrenzt Sites zu einer flachen Rate. Der MCP Server lässt dich aus Claude oder ChatGPT publizieren. Erster Monat kostenlos.

Kostenlos starten — kamaan.io

Frequently asked

FAQ · 8 ITEMS
Wie füge ich einer Next.js-SaaS-App einen Blog hinzu, ohne meine bestehenden Routen kaputtzumachen?

Erstelle `/app/blog/page.tsx` für die Index-Seite und `/app/blog/[slug]/page.tsx` für einzelne Artikel. Hole die Daten zur Render-Zeit mit `fetch()` innerhalb der Server Component aus deinem headless CMS. Wickle die Antwort in deine bestehenden Layout-Komponenten. Mit Kamaans REST API Delivery kommt der Artikel-Body als HTML zurück, also legst du ihn in einen Typografie-Wrapper und servierst ihn unter deiner bestehenden Domain.

Sollte mein Blog auf blog.meineapp.com oder meineapp.com/blog liegen?

`meineapp.com/blog`. Subdirectory-Hosting bündelt SEO unter deiner Hauptdomain. Subdomains werden von Google als getrennte Properties behandelt, was deine Link-Equity zersplittert und die Zeit bis zum Ranking verlängert. Der einzige Grund, eine Subdomain zu nutzen, ist, dass du dein SaaS-Framework buchstäblich nicht dazu bringst, Content unter `/blog` zu rendern, was bei Next.js, Nuxt, SvelteKit oder Astro im Wesentlichen nie der Fall ist.

Kann ich ein kostenloses headless CMS für meinen SaaS-Blog nutzen?

Ja, mit Vorbehalten. Sanity Free deckelt bei 10.000 Dokumenten, was für einen Blog Jahre reicht. Contentful Free hat engere Grenzen bei Einträgen und API-Calls, ist aber für einen kleinen Blog tauglich. Der Haken bei beiden: Mehrsprachige Workflows sind manuell und Multi-Site kostet extra. Kamaans erster Monat ist kostenlos mit voller Mehrsprachigkeit beim Publish, was der sauberere Trial für ein Team ist, das weiß, dass es Übersetzungen braucht.

Brauche ich einen Entwickler, um einen headless-CMS-Blog aufzusetzen?

Für Sanity, Strapi oder jedes Schema-as-Code-CMS, ja. Für Kamaan, Contentful oder Storyblok ist das CMS selbst no-code; die Integration in deine App braucht einen Entwickler für Routing, Fetching und Layout-Arbeit, was typischerweise ein Nachmittag für jemanden ist, der das Framework kennt.

Wie mache ich meinen SaaS-Blog mehrsprachig, ohne Übersetzer einzustellen?

Wähle ein CMS, in dem Mehrsprachigkeit nativ ist, nicht ein Add-on. Kamaans Auto-Multilingual Delivery veröffentlicht spanische, deutsche, französische und italienische Versionen in dem Moment, in dem du auf Englisch publish drückst. Jede Version bekommt ihren eigenen lokalisierten Slug unter `/[lang]/blog/<slug>`. Hreflang-Tags werden aus derselben Übersetzungs-Map erzeugt. Die Übersetzungsrechnung bleibt bei null.

Was ist der Unterschied zwischen einem headless CMS und einem traditionellen CMS für einen SaaS-Blog?

Ein traditionelles CMS wie WordPress geht davon aus, dass es das Rendering besitzt. Ein [headless CMS](/blog/what-is-headless-cms) speichert und liefert Content über eine API; deine App übernimmt das Rendering. Für ein SaaS-Produkt, in dem der Blog innerhalb einer bestehenden React-, Vue- oder Svelte-App leben muss, ist headless die einzige Architektur, die ohne Reverse-Proxy-Hack funktioniert.

Wie schnell muss eine headless-CMS-API für einen SaaS-Blog sein?

Antwortzeit unter 100 ms ist die Grenze, über der eine Blog-Seite sich langsam anfühlt. Kamaans REST API Delivery wird von einem CDN-Edge vor dem Content-Store ausgeliefert, sodass typische Reads deutlich darunter liegen. Für server-renderte Seiten hast du außerdem die Option, Antworten in der Daten-Schicht deines Frameworks zu cachen (Next.js `revalidate`, Nuxt `useFetch` mit Cache-Headern), sodass die meisten Requests den Origin gar nicht treffen.

Schädigt das Hinzufügen eines Blogs zu meinem SaaS-Produkt meine Core Web Vitals?

Nur, wenn du es falsch machst. Rendere den Blog serverseitig mit den gleichen Layout-Komponenten wie den Rest deiner App, serve Bilder von einem CDN mit korrekten Width- und Height-Attributen und halte den JavaScript-Footprint der Blog-Route schlank. Mit Kamaans REST API Delivery und einer statischen oder server-renderten Blog-Route bleiben die Core Web Vitals dort, wo sie vor dem Blog waren.

Junaid Khalid
Written by
Junaid Khalid

Junaid Khalid is the founder of Kamaan, a headless blog CMS that auto-publishes in five languages and lets you manage every product blog from one dashboard.