Headless-Auslieferung.

Wann sich Headless lohnt

Ein Headless-Aufbau rechnet sich, wenn mehrere Kanäle, Marken oder Frontends dieselben Inhalte brauchen, wenn das Frontend-Team im eigenen Rhythmus releasen muss oder wenn Ladezeit wichtiger ist als das Bearbeiten direkt auf der Seite. Er kostet Vorschau, Personalisierung und etwas Komfort in der Redaktion, wenn diese Punkte nicht von Anfang an geplant werden. Wir helfen Ihnen zu entscheiden, auf welcher Seite dieser Linie Sie stehen, bevor etwas gebaut wird.

Was wir bauen

Eine Content-API mit einem Modell und Abfragen, die zu Ihrem Seitenaufbau passen, und einem Caching, das die API günstig und die Inhalte aktuell hält.

# fetch one article by slug
query {
  article(slug: "roadmap") {
    title
    updated
    body
  }
}

Ein Next.js-Frontend mit Server-Rendering, damit Crawler und langsame Geräte vollständige Seiten erhalten. Eine Suche mit Indexierung und Relevanzabstimmung, die mit der Veröffentlichung Schritt hält. Und Personalisierung dort, wo sie sich lohnt, mit einem Plan, wie das belegt wird.

Worauf wir achten

• Die Redaktion sieht die fertige Seite, bevor sie veröffentlicht.
• Die Zeit zwischen Veröffentlichung und sichtbarer Änderung auf der Website und in der Suche wird gemessen, und ein Höchstwert wird mit Ihnen vereinbart.
• Wer was sehen darf, wird einmal festgelegt und überall angewendet, wohin die Inhalte gehen.
• Wo das Routing es erlaubt, laufen alte und neue Seiten während eines Umzugs parallel, eine Seitengruppe nach der anderen.

Wie wir meist beginnen

Mit einer kurzen Prüfung Ihres Content-Modells, Ihrer Kanäle und Ihres Redaktionsablaufs. Sie endet mit einer schriftlichen Empfehlung, ob sich Headless für Sie lohnt und, falls ja, in welcher Reihenfolge der Umstieg erfolgen sollte. Umfang und Preis der Prüfung werden vorab schriftlich vereinbart.

Plattformen

Optimizely, Contentful und Strapi als Content-Quellen, Umbraco dort, wo seine Delivery-API passt. Frontends in Next.js und React.