Zum Hauptinhalt springen

Moderne Websites & Web-Apps

Wir bauen Websites. Diese hier ist unser Proof.

machbar.de ist nicht nur unser eigener Webauftritt. Die Website zeigt, wie wir Content, Design, Entwicklung, KI, Übersetzung, SEO und Publishing zu einem belastbaren digitalen System verbinden. Was wir Kunden empfehlen, haben wir hier selbst umgesetzt.

Redaktion und Website müssen nicht dasselbe System sein

Wer Inhalte pflegt, hat andere Anforderungen als jemand, der eine Website besucht. Eine Redaktion muss Inhalte strukturieren, vorbereiten, übersetzen, prüfen und freigeben können. Für Besuchende zählen klare Nutzerführung, kurze Ladezeiten und ein zuverlässiges Frontend.

Deshalb trennen wir Content Management und öffentliche Auslieferung dort, wo diese Trennung einen echten Vorteil bringt.

Umsetzung auf machbar.de

Inhalte werden zentral im CMS gepflegt. Speichern und Veröffentlichen sind getrennt. Freigegebene Inhalte werden als fertige Website ausgeliefert — das Content-System muss nicht bei jedem Seitenaufruf mitlaufen. Die öffentliche Seite läuft als schnelles, statisches Frontend auf unserem Server in Deutschland.

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

Die Redaktion bleibt dynamisch, während die öffentliche Website schlank und schnell ausgeliefert werden kann.

Inhalte sollten wissen, wozu sie gehören

Eine Website ist mehr als eine Sammlung einzelner Seiten. Leistungen, Projekte und Themen stehen in Beziehung. Leben diese Zusammenhänge nur im Fließtext, kann das System nichts damit anfangen — und die Redaktion müsste dieselben Verbindungen immer wieder von Hand herstellen.

Umsetzung auf machbar.de

Leistungen sind als strukturiertes Modell im CMS angelegt. Projekte sind mit den Kompetenzen verknüpft, die tatsächlich in ihnen stecken. Case Studies und Snapshots werden Teil eines Netzes aus Leistungen, Projekten und Referenzen — und tauchen dort wieder auf, wo sie relevant sind, etwa auf Leistungsseiten zu Web & App Design oder Development.

flowchart TD
  A["Leistungen"] --> D["Beziehungen"]
  B["Case Studies"] --> D
  C["Snapshots"] --> D
  D --> E["Service-Seiten"]
  D --> F["Projektseiten"]
  D --> G["Passende Arbeiten"]

So wächst die Website nicht nur um Seiten. Sie wächst um Wissen.

KI und Mehrsprachigkeit im kontrollierten Prozess

Wir setzen KI dort ein, wo sie redaktionelle Arbeit besser und schneller macht — nicht als öffentliches Feature auf der Live-Seite. Vorschläge vorbereiten ja; Verantwortung für Veröffentlichung bleibt bei Menschen.

Mehrsprachigkeit ist mehr als maschinelles Übersetzen. Über Jahre muss klar sein, welche Fassung aktuell ist, was sich seit der letzten Übersetzung geändert hat und welche Sprachversion indexiert werden darf.

Umsetzung auf machbar.de

KI hilft bei Übersetzung, Textüberarbeitung, ALT-Texten, SEO-Metadaten, strukturierten Daten und Leistungsinhalten. Im CMS beantwortet eine Redaktionshilfe Fragen zu System und Abläufen. Deutsch und Englisch laufen in einem kontrollierten Workflow: Glossar für Markenbegriffe, Review vor Freigabe, bei Änderungen erneute Prüfung — sichtbar ja, indexiert erst nach Freigabe.

flowchart LR
  A["Inhalt"] --> B["KI"]
  B --> C["Redaktion"]
  C --> D{"Review"}
  D -->|Freigabe| E["Publikation"]
  D -->|Überarbeitung| A
  A --> F["DE"]
  F --> G["Übersetzung"]
  G --> H["EN Review"]
  H --> I["SEO-Freigabe"]

Wir automatisieren Arbeit, nicht Verantwortung — und Sprache bleibt steuerbar.

Sichtbarkeit und Maschinenlesbarkeit

SEO beginnt nicht kurz vor dem Launch mit Meta-Feldern. Ob klassische Suche und zunehmend KI-Antwortsysteme Inhalte verstehen, entscheidet sich an Informationsarchitektur, Contentmodell, URLs und den Beziehungen zwischen Inhalten.

Umsetzung auf machbar.de

SEO und Maschinenlesbarkeit sind Teil desselben Publishing-Systems: klare URLs, Metadaten, Canonicals, Sprachzuordnung, Sitemap, strukturierte Daten und die Semantik zwischen Leistungen und Projekten. Redaktion pflegt nicht erst die Website und danach ein separates SEO-System.

flowchart TD
  A["Inhalt"] --> B["Semantik"]
  A --> C["SEO"]
  A --> D["Strukturierte Daten"]
  A --> E["Sprachen"]
  B --> F["Publikation"]
  C --> F
  D --> F
  E --> F

Inhalte für Menschen gestalten — und so strukturieren, dass Maschinen sie verstehen können.

Technische Qualität: was der Browser bekommt — und was bewusst nicht

Performance, Datenschutz, Barrierefreiheit und Sicherheit sind keine getrennten Spätphasen-Themen. Dieselbe Architekturentscheidung verbessert oft mehrere davon: Was nicht bei jedem Aufruf laden muss, muss auch nicht bei jedem Aufruf angreifbar, einwilligungspflichtig oder langsam sein.

Umsetzung auf machbar.de

Schriften und Projektvideos können first-party ausgeliefert werden. Externe Dienste nur wo nötig und — wo erforderlich — erst nach Consent. Öffentliche Seiten entstehen vor dem Request als fertiges Frontend. Semantik, Skip-Link, Fokus und Tastaturbedienung gehören zur Basis. Formulare sind serverseitig abgesichert; Geheimnisse bleiben auf dem Server.

flowchart LR
  Browser["Browser"] --> Site["machbar.de"]
  Site --> Own["Eigene Assets und Medien"]
  Site --> Static["Fertiges Frontend"]
  Site --> Gate{"Consent"}
  Gate -->|erteilt| Ext["Externe Dienste"]
  Site --> Forms["Geschützte Formulare"]
  Forms --> Server["Serverseitige Prüfung"]

Weniger laufende Systeme auf der öffentlichen Fläche bedeuten weniger Angriffsfläche — und mehr Kontrolle darüber, was wirklich freigegeben ist.

Von der Website zur Web-App

Die Prinzipien auf machbar.de sind dieselben, mit denen wir individuelle Web-Anwendungen entwickeln: Inhalte und Daten strukturieren, Systeme verbinden, Interfaces für konkrete Aufgaben gestalten.

  • Eine Corporate Website kann andere Anforderungen haben als ein Serviceportal, eine Produktplattform oder eine Recruiting-Anwendung. Deshalb starten wir nicht mit dem Systemlabel, sondern mit der Frage, was das digitale Produkt leisten muss.
  • Aus dieser Aufgabe entsteht die Architektur für Content, UX, Frontend, CMS, Schnittstellen, KI und Publishing.
  • Für diese Website sind Payload und Astro die richtige Wahl. In Kundenprojekten kann das TYPO3, WordPress oder ein anderer Headless-Ansatz sein — entscheidend ist die Anforderung, nicht das Label.

Eine mögliche Architektur. Konkret: unsere.

Für machbar.de verbinden wir Payload CMS, Astro, AWS S3, Gemini, Hetzner und Cookiebot zu einer Architektur, die zu unseren redaktionellen und technischen Anforderungen passt. Für andere Aufgaben kann die richtige Lösung anders aussehen.

flowchart TB

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

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

Gemini["Gemini"] -. "unterstützt Redaktion" .-> Payload
Cookiebot["Cookiebot"] -. "Consent im Frontend" .-> Astro

TYPO3, WordPress, Headless oder ein anderer Ansatz.

Dann schreiben Sie uns.