Skip to content
Digital Cuisine

Websites & content platforms

Your website.
Your next step.

We develop websites and portals that present your brand and that your own team can take further. With a clear structure, considered design and the right content management. Our release gate: performance of at least 95 on desktop and 90 on mobile, accessibility, best practices and SEO at 100. Lab scores, but binding.

Good content needs good tools.

Your editorial team should be able to maintain pages and publish content without needing a development ticket for every change. We develop clear building blocks and a content model that fits your topics and workflows.

Information structure, design and technology take shape together. This turns the relaunch into a website that can keep evolving after handover.

Visibility in search and AI answers

GEO is SEO.

Machines only use what they can access and interpret. We check access, content, structure and whether each section makes sense on its own. This helps people, search engines and AI systems alike. A citation in an AI answer is a possible outcome, not a promise.

SEO and GEO in detail

Performance in the release gate

Speed is measurable.

Every change passes through our gate on staging using the PageSpeed Insights API: performance of at least 95 on desktop, 90 on mobile, accessibility, best practices and SEO at 100. These are lab scores. They replace neither field data from real visitors nor testing of complete user journeys. But nothing below the gate goes live without a conscious decision.

Web performance in detail

This website works without a cookie banner.

No banner, no consent dialogue, no tracking cookie. We measure reach using access data at the edge, without cookies or profiles. Today this is no longer a feat, but a decision: if you do not collect personal data for advertising, you do not need consent for it.

The same does not automatically apply to your website. As soon as you measure campaigns or build audiences, you need consent and an architecture that respects it. How the two fit together without every visit starting with a dialogue is explained under Server-Side Tracking.

From design to CMS with approval.

We break down a Figma frame rather than simply rebuilding it: design and development clarify states, content rules and behaviour. This produces the component schema in the CMS and the Next.js component, supported by AI but approved by people.

Editors and developers check the building blocks in the CMS before proceeding. No step without sign-off.

AI works the same way in operations: it proposes metadata, alternative text and translations as drafts, and approval happens in the CMS.

Recomposition rather than transformation

Migration without a big bang.

We plan content, addresses and interfaces as a connected transition. At Linde, we supported changes across several CMS generations. At KIND, we migrated SharePoint from an on-premises environment to SharePoint Online.

1. ExtractionWe extract the complete content inventory from the legacy system. This reveals missing content before import.

2. Canonical intermediate formatWe parse all content into a uniform format. A coverage report shows what could be read and where decisions are still needed.

3. Analysis of all existing contentWe examine components, special cases and orphaned content on a common basis.

4. MappingWe separate mapping to the new content model from parsing. This keeps schema changes manageable.

5. ImportWe import repeatably via the management API. Manual one-off approaches are excluded.

6. Editorial recompositionThe editorial team decides which content to merge, shorten or rebuild. Proposals are approved together.

7. Media, redirects and quality assuranceWe transfer assets, plan redirects and check content, functions and indexability against the original content. After the switch, we monitor visibility. Fluctuations cannot be ruled out.

A headless CMS separates content and presentation.

A headless CMS manages content and delivers it via an API. The frontend determines its presentation. Editorial teams maintain information in one place and can use it on the website, in an app or in another channel.

One piece of content, many interfaces

Backend and frontends can evolve independently. A new design or another channel does not change the content. We connect search, forms and third-party systems through defined interfaces.

Which CMS fits when

Whether headless, traditional or Git-based: AI is not a separate variant, but an option for all three, from quick prototypes to drafts in ongoing operations. What matters is who maintains the content and for how long. Where the circumstances allow, we recommend headless.

Headless, where circumstances allowContent, code and design remain separate: the design can be renewed without migrating content, and the public website can be delivered without a CMS backend. This reduces the attack surface. The same content is also available to apps, partner portals and other channels.
A traditional CMS, when one website is enoughA company website with a familiar editorial environment and limited integration needs is often quicker to build and cheaper to run with WordPress. We recommend the platform based on the task, not the trend.
Git-based, for small technical teamsContent lives as files in the repository, and every change is reviewed like code. This suits small, technical editorial teams; it is how we run this website too.

CMS selection

System selection you can verify.

If the platform question is open, we assess candidates against weighted requirements: your shortlist, your existing system, market analyses and systems from our practice, all against the same questions. The result is a ranking you can trace back to each individual answer, with product dossiers and a decision paper.

How CMS selection works

Developing together

Co-delivery rather than handover.

Your developers can join the project early. We agree how they contribute to suit the team, task and responsibilities.

Contribute earlyJoint planning and pairing let your team experience architecture and implementation first-hand.

Understand decisionsArchitecture Decision Records document the reasons, alternatives and consequences of important decisions.

Prepare operationsRunbooks describe recurring processes, responsibilities and responses to incidents.

Continue independentlyKnowledge develops through working together and remains available in your team.

Operations and quality processes

After go-live.

A website changes after publication. Content, interfaces, updates and requirements are added. We combine development with monitoring, maintenance and traceable approvals. Our certified management system provides the framework. The management system is certified, not an individual project.

A clearly scoped starting point

What the website check delivers.

We clarify the task in conversation. The proposal defines the selection of pages, templates or user journeys, the access required, the deliverables and the costs.

Documented starting positionWe record measurement conditions and unavailable evidence.

Prioritised findingsYou see what affects visitors, editors, content or measurement.

Verifiable actionsRecommendations include effort estimates and criteria for subsequent checks.

A clearly scoped next stepWhere implementation makes sense, you receive a proposal with clear responsibility and sign-off.

The next step

What should your website do next?

Tell us about your idea or challenge. Together we work out what makes sense and how we can support you.

Book a call (30 min)

Loading form.

Your next project.
Let's talk.

A website, an app, a digital process or an AI idea: tell us what you have in mind. Together we work out how your task becomes the right solution.

The digital cuisine team
Consulting, design and development

info@cuisine.digital+49 511 165 909 0
The digital cuisine team in conversation