Content editors have different requirements than website visitors. An editorial team needs to structure, prepare, translate, review, and approve content. Visitors, however, prioritise clear user guidance, fast loading times, and a reliable frontend.

That's why we separate content management from public delivery where this distinction offers a genuine advantage.

Implementation on machbar.de

Content is managed centrally in the CMS. Saving and publishing are separate. Approved content is delivered as a finished website – the content system doesn't need to be involved with every page request. The public site runs as a fast, static frontend on our server in Germany.

flowchart LR
  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 relationships only exist within the body text, the system cannot process them – and the editorial team would have to manually create the same connections repeatedly.

Implementation on machbar.de

Services are structured as a model within the CMS. Projects are linked to the competencies they actually 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 where it improves and accelerates editorial work – not as a public feature on the live site. AI prepares suggestions; humans retain responsibility for publication.

Multilingualism extends beyond 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 operate within a controlled workflow: a glossary for brand terms, review before approval, and re-evaluation upon changes – visible, but indexed only after approval.

flowchart LR
  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 – ensuring language remains controllable.

SEO does not begin just before launch with meta fields. Whether traditional search engines and increasingly AI-powered answer systems understand content depends on information architecture, content models, URLs, and the relationships between content elements.

Implementation on machbar.de

SEO and machine readability are integral to the same publishing system: clear URLs, metadata, canonicals, language assignments, sitemaps, structured data, and the semantic connections between services and projects. The editorial team manages these within the website, not in 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.

Performance, data protection, accessibility, and security are not separate, late-stage concerns. The same architectural decisions often improve several of these aspects: 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, if required, only after consent. Public pages are generated as a complete frontend before the request. Semantics, skip links, focus management, and keyboard navigation are fundamental. Forms are secured server-side; sensitive information remains on the server.

flowchart LR
  Browser["Browser"] --> Site["machbar.de"]
  Site --> Own["First-party assets and media"]
  Site --> Static["Pre-rendered frontend"]
  Site --> Gate{"Consent"}
  Gate -->|Granted| Ext["External services"]
  Site --> Forms["Protected forms"]
  Forms --> Server["Server-side validation"]

Fewer active systems on the public interface mean a smaller attack surface – and greater control over what is truly released.

The principles applied 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. Therefore, we begin not with the system label, but by asking what the digital product needs to achieve.
• 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. In client projects, this could be TYPO3, WordPress, or another headless approach – the requirement is decisive, 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 optimal solution may differ.

flowchart TB

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

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

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