We build websites. This one is our proof.

Those who maintain content have different requirements than those who visit a website. An editorial team needs to structure, prepare, translate, review, and approve content. For visitors, clear user guidance, fast loading times, and a reliable frontend are crucial. That's why we separate content management and public delivery where this separation offers a real advantage. ### Implementation on machbar.de Content is centrally managed in the CMS. Saving and publishing are separate processes. Approved content is delivered as a finished website – the content system does not need to run with every page view. The public site runs as a fast, static frontend on our server in Germany. ```mermaid flowchart TB A["Editorial team"] --> B["CMS"] B --> C["Approval"] C --> D["Build"] D --> E["Website"] E --> F["Visitors"] ``` The editorial team remains dynamic, while the public website can be delivered lean and fast.

A website is more than a collection of individual pages. Services, projects, and topics are interconnected. If these connections only exist in the body text, the system cannot process them, and editors would have to manually create the same links repeatedly.

Implementation on machbar.de

Services are structured as a model within the CMS. Projects are linked to the specific expertise they involve. Case studies and snapshots become part of a network of services, projects, and references, reappearing where relevant, such as on service pages for web & app design or development.

flowchart TD
  A["Services"] --> D["Relationships"]
  B["Case Studies"] --> D
  C["Snapshots"] --> D
  D --> E["Service pages"]
  D --> F["Project pages"]
  D --> G["Related work"]

The website grows not just with pages, but with knowledge.

We use AI to enhance and accelerate editorial work, not as a public feature on the live site. AI prepares suggestions, but humans retain responsibility for publication.

Multilingualism involves more than machine translation. Over time, it must be clear which version is current, what has changed since the last translation, and which language version can be indexed.

Implementation on machbar.de

AI assists with translation, text revision, alt text, SEO metadata, structured data, and service content. Within the CMS, an editorial assistant answers questions about the system and processes. German and English content follows a controlled workflow: a glossary for brand terms, review before approval, and re-evaluation for changes – visible, but indexed only after approval.

flowchart TB
  A["Content"] --> B["AI"]
  B --> C["Editorial team"]
  C --> D{"Review"}
  D -->|Approval| E["Publication"]
  D -->|Revision| A
  A --> F["DE"]
  F --> G["Translation"]
  G --> H["EN Review"]
  H --> I["SEO approval"]

We automate tasks, not responsibility – maintaining control over language.

SEO is not just about meta fields shortly before launch. Whether traditional search and increasingly AI answer systems understand content depends on information architecture, content model, URLs, and the relationships between content.

Implementation on machbar.de

SEO and machine readability are part of the same publishing system: clear URLs, metadata, canonicals, language assignment, sitemap, structured data, and the semantics between services and projects. Editorial teams do not maintain the website first and then a separate SEO system.

flowchart TD
  A["Content"] --> B["Semantics"]
  A --> C["SEO"]
  A --> D["Structured data"]
  A --> E["Languages"]
  B --> F["Publication"]
  C --> F
  D --> F
  E --> F

Design content for people — and structure it so machines can understand it.

Performance, data protection, accessibility, and security are not separate late-stage issues. The same architectural decision often improves several of them: what doesn't need to load with every request also doesn't need to be vulnerable, require consent, or be slow with every request.

Implementation on machbar.de

Fonts and project videos can be delivered first-party. External services are used only where necessary and — where required — only after consent. Public pages are generated as a complete frontend before the request. Semantics, skip-links, focus, and keyboard operation are fundamental. Forms are secured server-side; secrets remain on the server.

flowchart TB
  Browser["Browser"] --> Site["machbar.de"]
  Site --> Own["Own assets and media"]
  Site --> Static["Ready-made frontend"]
  Site --> Gate{"Consent"}
  Gate -->|granted| Ext["External services"]
  Site --> Forms["Protected forms"]
  Forms --> Server["Server-side validation"]

Fewer running systems on the public surface mean less attack surface — and more control over what is truly released.

The principles we apply to machbar.de are the same ones we use to develop custom web applications: structuring content and data, connecting systems, and designing interfaces for specific tasks.

• A corporate website may have different requirements from a service portal, a product platform, or a recruitment application. That's why we start by defining what the digital product needs to achieve, rather than with a system label.
• This task then informs the architecture for content, UX, frontend, CMS, interfaces, AI, and publishing.
• For this website, Payload and Astro are the right choice. For client projects, this could be TYPO3, WordPress, or another headless approach – the requirements are what matter, not the label.

For machbar.de, we combine Payload CMS, Astro, AWS S3, Gemini, Hetzner, and Cookiebot into an architecture that suits our editorial and technical requirements. For other tasks, the right solution may look different.

flowchart TB

Editors["Editors"] --> Payload["Payload CMS"]
Payload --> Rebuild["Publish / Rebuild"]
Rebuild --> Astro["Astro Frontend"]
Astro --> Hetzner["Hetzner · DE"]

Payload <--> S3["AWS S3 Media"]

Gemini["Gemini"] -. "supports editors" .-> Payload
Cookiebot["Cookiebot"] -. "Consent in frontend" .-> Astro