--- title: "Websites & content platforms | Digital Cuisine" description: "Websites and content platforms for independent editorial teams. From structure and design through headless CMS and migration to visibility, performance and operations." url: "https://cuisine.digital/en/services/websites" lang: en generated: cuisines-markdown-v1 --- 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. [Discuss a project](https://cuisine.digital/en/contact)[Understanding lab measurements](https://cuisine.digital/en/services/web-performance.md) ## 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](https://cuisine.digital/en/services/seo-geo.md) 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](https://cuisine.digital/en/services/web-performance.md) ## 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](https://cuisine.digital/en/services/server-side-tracking.md). ## 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\. Extraction** We extract the complete content inventory from the legacy system. This reveals missing content before import. **2\. Canonical intermediate format** We 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 content** We examine components, special cases and orphaned content on a common basis. **4\. Mapping** We separate mapping to the new content model from parsing. This keeps schema changes manageable. **5\. Import** We import repeatably via the management API. Manual one-off approaches are excluded. **6\. Editorial recomposition** The editorial team decides which content to merge, shorten or rebuild. Proposals are approved together. **7\. Media, redirects and quality assurance** We 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. Headless CMS: content is provided via an API for websites, apps and other channels. Backend and API deliver content maintained once to separate frontends, each with its own look. ## 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](https://cuisine.digital/en/services/cms-selection.md) ## Technology to suit the task [Contentful](https://cuisine.digital/en/services/contentful.md) Headless CMS for content across many channels and international platforms. [Storyblok](https://cuisine.digital/en/services/storyblok.md) Headless CMS with a visual editor for editorial teams that assemble pages themselves. [Payload](https://cuisine.digital/en/services/payload.md) Code-first headless CMS in your own Next.js application, for data sovereignty and self-hosting. [Sitecore](https://cuisine.digital/en/services/sitecore.md) Content management and integrations for complex digital enterprise platforms. [WordPress](https://cuisine.digital/en/services/wordpress.md) Flexible company websites with a familiar editorial environment and custom functions. 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 early** Joint planning and pairing let your team experience architecture and implementation first-hand. **Understand decisions** Architecture Decision Records document the reasons, alternatives and consequences of important decisions. **Prepare operations** Runbooks describe recurring processes, responsibilities and responses to incidents. **Continue independently** Knowledge 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. [Hosting and operations](https://cuisine.digital/en/services/hosting.md) Ideally with us: our own servers with monitoring, alerting, hardening and backups, operated under our ISO 27001-certified management system. Also available on Azure, AWS or STACKIT, or in your own infrastructure on request. [Certifications](https://cuisine.digital/en/certifications.md) What has been audited in our management system and how we work with it. 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 position** We record measurement conditions and unavailable evidence. **Prioritised findings** You see what affects visitors, editors, content or measurement. **Verifiable actions** Recommendations include effort estimates and criteria for subsequent checks. **A clearly scoped next step** Where 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)](https://outlook.office.com/book/AIcuisine@cuisine.digital/) --- [Original page](https://cuisine.digital/en/services/websites) ยท [Contact and project enquiry](https://cuisine.digital/en/contact)