English
العربية
Deutsch
EspañolContent-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.
Wie es geschnitten ist
Geben Sie uns Lesezugriff auf das CMS und eine halbe Stunde mit der Person, die sagen kann, wofür jedes Feld da ist. Dieses Gespräch schätzt das Projekt genauer als die Seitenzahl.
Der Leistungsumfang kommt mit dem Inhaltsmodell zurück, entweder bestätigt oder neu gezeichnet, dazu die Templateliste, der Ansatz für Preview und Revalidierung, und ein Preis. Er wird vor Baubeginn unterschrieben. Muss das Modell umgebaut werden, ist das eine eigene Phase mit eigener Zahl, denn genau dieser Teil verdoppelt ein Projekt still, wenn man ihn implizit lässt.
Dann der Bau, je Phase deployt, mit einer Redaktion, die Preview nutzt, bevor das Frontend fertig ist.
Was Sie erhalten
Das Frontend, die typisierte Inhaltsschicht dazwischen, der funktionierende Preview-Pfad für die Redaktion und die an die CMS-Webhooks angeschlossene Revalidierung, damit eine Veröffentlichung erscheint, ohne dass jemand neu deployt.
Unterschätzt wird das Inhaltsmodell. Wo es umgebaut werden musste, bekommen Sie das neue dokumentiert, samt der Migration, die die bestehenden Einträge hineingebracht hat, denn ein Modell, das niemand aufgeschrieben hat, driftet binnen eines Jahres zurück.
Wann Inhalte geholt und wie lange sie gehalten werden entscheidet, ob sich die Integration schnell oder brüchig anfühlt, und das ist ebenso eine Entscheidung über das Inhaltsmodell wie über das Caching. Eine CMS-getriebene Site erzeugt außerdem ihre URLs selbst, Canonicals und Sitemap müssen also produziert und nicht gepflegt werden. Wo die Site bereits rankt und nicht umziehen darf, läuft Technical SEO daneben mit.