Einen Blog zu deiner SaaS-App hinzufügen, ohne ein CMS zu bauen

Früher oder später braucht jedes SaaS-Unternehmen einen Blog: für Produktankündigungen, Anleitungen und den Long-Tail-Traffic aus der Suche, der über Jahre wächst. Die meisten Entwicklerteams machen den Fehler, „einen Blog hinzufügen“ entweder als WordPress-Installation am Wochenende oder als internes CMS-Projekt für ein ganzes Quartal zu behandeln. Es gibt einen dritten Weg, der dir an einem Nachmittag einen produktionsreifen Blog auf deiner eigenen Domain bringt.

Entscheide, wo der Blog liegt: Subdomain oder Unterverzeichnis

Bevor du Code schreibst, leg die URL fest. Du hast drei Möglichkeiten:

• blog.yourapp.com – eine Subdomain, die meist auf eine separate gehostete Plattform zeigt.

• yourapp.com/blog – ein Unterverzeichnis deiner Hauptseite, gerendert von deinem eigenen Frontend.

• Eine fremde Domain – du veröffentlichst auf Medium oder Ähnlichem.

Für SEO ist das Unterverzeichnis die stärkste Option: Jeder Artikel stärkt die Autorität der Domain, auf der dein Produkt läuft, interne Links verbinden Marketingseiten und Beiträge ganz von selbst, und die Analytics bleiben in einer Property. Eine Subdomain geht auch; bei einer fremden Domain kommt die Autorität komplett jemand anderem zugute.

Das Unterverzeichnis bringt eine Vorgabe für die Architektur mit: Deine eigene Anwendung muss die Beiträge rendern. Damit fallen gekoppelte Plattformen weg, die ihre Seiten unbedingt selbst ausliefern wollen, und alles spricht für ein API-first-Setup: Inhalte im Dashboard schreiben, als JSON abrufen, von deinem Frontend rendern lassen.

Die Architektur aus drei Schichten

Ein SaaS-Blog braucht genau drei Schichten, und nur eine davon ist dein Code:

1. Schreiben – ein Dashboard, in dem Beiträge entstehen: Rich-Text-Editor, Tags, Kategorien, Entwürfe, SEO-Metadaten (Titel, Beschreibung, Open-Graph-Bild) und geplantes Veröffentlichen.

2. Ausliefern – eine API, die veröffentlichte Beiträge als JSON ausliefert, mit Paginierung, Tag-Filter und Suche.

3. Rendern – zwei Routen in deiner App: eine Listenseite und eine Beitragsseite.

An den Schichten 1 und 2 scheitern interne Blog-Projekte: Allein der Editor ist Arbeit für Wochen, und dann kommen Bild-Uploads, Entwürfe, Berechtigungen und Slugs. Ein Content-Backend liefert dir beide Schichten als Dienst, und dein ganzes Projekt ist Schicht 3.

Rendern: zwei Routen und ein Abruf

Mit einem typisierten SDK bleibt die Rendering-Schicht klein. Die Listenseite holt eine Seite mit Beiträgen:

const { data: posts } = await kookee.blog.list({ page: 1, limit: 10 });

Die Beitragsseite holt den Beitrag über seinen Slug:

const post = await kookee.blog.getBySlug(params.slug);

Rendere den Inhalt mit deinen eigenen Komponenten und deinem bestehenden Designsystem. In React geht es mit noch weniger Aufwand: Hooks wie useBlogPosts und useBlogPost kümmern sich um Ladezustände und Paginierung, und eine Content-Komponente rendert das HTML des Beitrags für dich. Oder du sparst dir das Markup ganz: Serverseitig gerenderte Komponenten rendern Beitragsliste, Tag-Filter, Paginierung und Beitragsseite aus den Daten, die du abrufst; siehe Einen Blog mit den React-Komponenten bauen.

Zwei Regeln halten die Qualität hoch:

• Auf dem Server rendern. Nutze SSR oder statische Generierung, damit Crawler und Leser fertiges HTML bekommen. Reines Client-Rendering funktioniert, aber dann verschenkst du das SEO, für das du das Unterverzeichnis gewählt hast.

• Echte 404 zurückgeben. Wenn ein Slug ins Leere läuft, antworte mit Status 404, nicht mit einer gestalteten „Nicht gefunden“-Seite mit Status 200. Soft 404s verschmutzen den Index.

Checkliste für die Metadaten

Jede Beitragsseite sollte Folgendes ausgeben, aus Daten, die das CMS schon speichert:

• <title> und Meta-Description aus den SEO-Feldern des Beitrags.

• Eine Canonical-URL, die auf den eigenen Pfad des Beitrags zeigt.

• Open-Graph- und Twitter-Card-Tags, einschließlich des Beitragsbilds.

• article:published_time und article:modified_time.

• Strukturierte Daten als JSON-LD vom Typ Article.

Da all das aus einer API-Antwort stammt, passt es in eine Hilfsfunktion. Füg einen RSS-Feed und pro Beitrag einen Sitemap-Eintrag hinzu. Beides lässt sich einfach aus demselben list-Endpunkt erzeugen, den deine Blogseite schon aufruft.

Tags, Suche und die Funktionen, die du gratis dazubekommst

Sobald Beiträge strukturierte Daten sind, werden Funktionen, die in einem selbst gebauten System eigene Projekte wären, zu Abfrageparametern:

• Tag-Seiten: kookee.blog.list({ tags: ['engineering'] }) hinter einer Route /blog/tags/:tag.

• Suche: kookee.blog.list({ search: query }) hinter einem Suchfeld.

• Kommentare und Reaktionen: kommen aus derselben API, wenn du Interaktion unter deinen Beiträgen willst.

• Übersetzungen: Ruf die anderen Sprachversionen eines Beitrags ab, wenn du international wächst.

Für nichts davon brauchst du Schemaänderungen oder Migrationen auf deiner Seite; das Backend bildet all das schon ab.

Was dich das kostet

Die ehrliche Rechnung für den API-first-Weg:

• Dein Code: zwei Routen, eine Hilfsfunktion für Metadaten, ein Feed. In den meisten Frameworks ein Tag Arbeit, weniger, wenn du von deinen bestehenden Seitenvorlagen ausgehst.

• Laufend: ein Abo für eine Content-Plattform. Bei nutzungsbasierten kostenlosen Plänen (bei Kookee sind 100.000 API-Anfragen im Monat enthalten) läuft ein typischer Blog lange im Free-Plan.

• Was dir erspart bleibt: einen Editor, einen Medienspeicher, einen Workflow fürs Veröffentlichen und eine zweite deployte Anwendung zu bauen und zu pflegen.

Vergleich das mit dem selbst gehosteten Weg: erst ein Aufbau, der Wochen dauert, dann für immer Sicherheitspatches und Abhängigkeits-Updates für ein System, das nicht dein Produkt ist.

Eine konkrete Reihenfolge

1. Leg ein Projekt in deinem Content-Backend an und schreib einen Testbeitrag.

2. Füg die Routen /blog und /blog/:slug hinzu, die ihn abrufen und serverseitig rendern.

3. Bau die Hilfsfunktion für Metadaten ein: Titel, Beschreibung, Canonical, OG-Tags, JSON-LD.

4. Füg den Tag-Filter und den RSS-Feed hinzu.

5. Schick dein Team ins Dashboard und streich „Blog bauen“ aus dem Backlog der Entwicklung.

Der Blog selbst ist nie das Schwierige. Schwierig ist, dafür zu sorgen, dass die Entwicklungsarbeit in dein Produkt fließt und das Marketing trotzdem eine schnelle Publikation im eigenen Design und auf der eigenen Domain bekommt. Genau das bringt dir die Trennung zwischen Content-Backend und einer dünnen Rendering-Schicht.