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

Therefore, we separate content management from public delivery where this separation offers a genuine advantage.

How we implement this at machbar.de

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

flowchart TB
  A["Redaktion"] --> B["CMS"]
  B --> C["Freigabe"]
  C --> D["Build"]
  D --> E["Website"]
  E --> F["Besuchende"]

The editorial process 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 deploy AI where it enhances and accelerates editorial work, not as a public feature on the live site. AI prepares suggestions; human editors 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 texts, 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, re-evaluation upon 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 – ensuring language remains controllable.

SEO doesn't start 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.

Implementation on machbar.de

SEO and machine readability are integral to the same publishing system: clear URLs, metadata, canonicals, language assignment, sitemap, structured data, and the semantic relationships between services and projects. Editors manage the website directly, rather than maintaining a separate SEO system afterwards.

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 decision often improves several of these: what doesn't need to load on every request also doesn't need to be vulnerable, require consent, or be slow on 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 data remains on the server.

flowchart TB
  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["Secured 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 than a service portal, a product platform, or a recruitment application. Therefore, we don't start with a system label, but with the question of 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. For client projects, this could be TYPO3, WordPress, or another headless approach – the requirement is what matters, 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 editorial team" .-> Payload
Cookiebot["Cookiebot"] -. "Consent in frontend" .-> Astro