Zum Inhalt springen

Content-Management-Integration

Headless-CMS-Integration

Contentful, Sanity, Strapi, Payload oder WordPress als Headless-Quelle - im App Router verdrahtet, mit typisierten Inhalten, passendem Caching und Preview, das den Cache nicht kostet.

Eine Headless-CMS-Integration geht jedes Mal an denselben drei Stellen schief, und keine davon ist das CMS. Die Inhalte sind untypisiert, also wird eine Feldumbenennung zum Laufzeitfehler in Produktion. Das Caching ist falsch, also veröffentlichen Redakteure und warten. Und die Vorschau funktioniert entweder nicht oder funktioniert, indem sie jede Route dynamisch macht.

Was wir bauen

Typisierte Inhalte, durchgängig. Das CMS-Schema erzeugt TypeScript-Typen, und die Fetch-Schicht parst, was zurückkommt, statt es zu behaupten. Ein umbenanntes Feld scheitert dann am Build oder am Rand mit einer Meldung, die es benennt - nicht drei Komponenten später als undefined is not a function.

Caching, das zur Arbeitsweise der Redaktion passt. Inhalte werden getaggt, nicht zeitrevalidiert. Ein Webhook aus dem CMS leert das Tag für das, was sich geändert hat, und die Seite aktualisiert sich in Sekunden, ohne die Route dynamisch zu machen. Die Alternative - überall revalidate: 60 - heißt, dass Redakteure eine Minute warten und Ihr Origin Traffic bekommt, den es nicht brauchte.

Vorschau, die den Cache nicht kostet. Draft Mode nur auf der Vorschau-Route, auf die Session der Redakteurin begrenzt, damit die veröffentlichte Route für alle anderen statisch bleibt. Redaktion sieht Unveröffentlichtes; Besucher bekommen das CDN.

Ein Blockmodell, das hält. Die meisten Projekte modellieren Inhalte als Seiten mit festen Feldern, und dann fragt das Marketing nach einem Layout, das das Modell nicht ausdrücken kann. Wir modellieren von Anfang an komponierbare Blöcke, mit einem Renderer, der gegen die Block-Union typisiert ist - ein nicht behandelter Block ist damit ein Compilerfehler und keine leere Stelle.

Welches CMS

Wir sind an keines gebunden und sagen Ihnen, wenn das gewählte für Ihr Vorhaben falsch ist - aber das ist selten die interessante Frage. Die Integration ist der größte Teil der Arbeit und hat weitgehend dieselbe Form, welches Sie auch nehmen.

Migrieren Sie von WordPress weg und behalten es als Redaktionsoberfläche, funktioniert das: WordPress als Headless-Quelle mit Next.js als Rendering ist eine legitime Architektur und oft der günstigste Weg, weil die Redaktion ihr gewohntes Werkzeug behält.

Was wir von Ihnen brauchen

Zugang zum CMS und jemanden, der "wofür ist dieses Feld" beantworten kann. Das Zweite ist wichtiger als das Erste - ein Content-Modell, das ein altes Template spiegelt statt der tatsächlichen Inhalte, macht den Umbau teuer, und eine Stunde Gespräch davor ist es wert.