--- title: "Headless CMS, klassisches CMS oder statische Website?" canonical: https://wavect.io/de/software-development-guide/headless-cms-vs-traditional-cms/ language: de description: "Vergleiche gängige Konfigurationen nach Bearbeitung, Vorschau, Wiederverwendung, Migration und laufender Verantwortung. Beginne bei den Menschen, die Inhalte …" image: "https://wavect.io/img/general/bak/open_graph_preview.jpg" --- Briefing für die Beauftragung # Welcher Websiteaufbau passt zu deiner Redaktion? Vergleiche gängige Konfigurationen nach Bearbeitung, Vorschau, Wiederverwendung, Migration und laufender Verantwortung. Beginne bei den Menschen, die Inhalte pflegen. Kurze Antwort Wähle zuerst den Redaktionsablauf. Headless trennt Inhaltsverwaltung und Darstellung; statisch beschreibt die Auslieferung. Beides kann zusammengehen und ist kein pauschales Upgrade. Passt für - Teams vor Websitebau oder Migration mit offener Redaktionsentscheidung. - Redaktionen - die Wiederverwendung und Frontend-Betrieb gegeneinander abwägen. Nicht Gegenstand - Headless automatisch mit höherer Geschwindigkeit oder besseren Rankings gleichsetzen. - Ein funktionierendes CMS ohne konkretes Redaktionsproblem ersetzen. // 01 ## Die Optionen im Vergleich Typische Konfigurationen, keine garantierten Produktfunktionen. | Frage | Klassisches CMS | Inhalte als Code | Headless CMS | | --- | --- | --- | --- | | Tägliche Pflege | Oft integrierter Seiteneditor | Meist technischer Ablauf | Separater Editor; Vorschau braucht Anbindung | | Wiederverwendung | Abhängig von Modell und Schnittstellen | Mit strukturierten Dateien möglich | Mehrere Kanäle über eine API möglich | | Vorschau und Freigabe | Produkt und Einrichtung prüfen | Branchvorschau und Review prüfen | Entwürfe, Vorschau und Veröffentlichung zusammen prüfen | | Betrieb | CMS, Erweiterungen und Hosting | Repository, Build und Hosting | CMS plus Frontend, Builds und Integration | | Migration und Export | Inhalte, Medien und Plugins prüfen | Formate und Buildabhängigkeiten prüfen | API, Schema und Medienexport prüfen | // 02 ## Wo Wavect hier steht Ein gesundes CMS zu behalten kann sinnvoll sein. Bessere Templates, Inhaltsstruktur oder Wartung lösen Redaktionsprobleme oft ohne Migration. Eine eigene Inhalts-API bringt Verantwortung mit und braucht einen echten Bedarf. [WordPress dokumentiert Inhaltszugriff per REST API](https://developer.wordpress.org/rest-api/); ein bekanntes CMS kann also auch ein getrenntes Frontend bedienen. Der [Astro-CMS-Leitfaden](https://docs.astro.build/en/guides/cms/) beschreibt externe Inhalte zusammen mit Frontend-Rendering. Quellen geprüft am 19. Oktober 2026, keine Stackvorgabe. Drei illustrative Situationen: Ein kleines Unternehmen mit stabilen Seiten behält möglicherweise sein CMS oder nutzt Inhalte als Code, wenn technische Betreuung verfügbar ist. Eine häufig und mehrsprachig publizierende Redaktion sollte Rollen, Vorschau und Übersetzungen praktisch testen. Wer strukturierte Inhalte in mehreren Kanälen nutzt, kann von Headless profitieren, wenn Frontend und Betrieb klare Eigentümer haben. Andere Fähigkeiten oder Abläufe können jede Empfehlung ändern. Vor Migration: Seiten, Medien und URLs inventarisieren. Inhaltsfelder, Weiterleitungen, Sprachfassungen, Metadaten, Canonicals und strukturierte Daten zuordnen. Entwürfe von öffentlicher Indexierung fernhalten und wichtige bisherige Einstiege nach dem Start prüfen. Architektur allein verbessert keine Rankings und garantiert ihren Erhalt nicht. Trenne Gestaltung und Umsetzung, Inhaltseingabe, Migration, Lizenzen, Hosting, Buildnutzung, Anbindungen und Wartung. Prüfe Zugriffs- und Exportrechte, statt Headless oder Open Source mit Abhängigkeitsfreiheit gleichzusetzen. KI-gestützte Produktion ist ein Lieferprozess, keine CMS-Kategorie. Entwürfe brauchen Fakten- und Funktionsprüfung. Besprich den Ablauf mit [Websiteentwicklung](/de/services/website-development/); für Produktfunktionen nutze [Web Apps](/de/services/web-apps/). ### In jedem Kandidaten denselben Redaktionsablauf testen Gib einer redigierenden Person eine repräsentative Leistungsseite, ein Bild, eine Übersetzung und eine Korrektur. Sie soll Entwurf, echte Frontend-Vorschau, Suchfelder, Freigabe und Veröffentlichung durchlaufen. Danach Seite zurücknehmen oder eine ältere Fassung wiederherstellen. Beobachte, wo Entwicklungshilfe nötig ist. Eine Demo mit nur einem Titelfeld prüft diesen Ablauf nicht. Lege fest, wer unveröffentlichte Inhalte sehen darf und was bei fehlender Übersetzung passiert. Prüfe, ob Vorschau und Produktion dasselbe Inhaltsmodell verwenden und ob ein fehlgeschlagener Build die letzte funktionierende Website verfügbar lässt. Das sind Produkt- und Umsetzungsfragen; die Bezeichnung Headless beantwortet sie nicht. ### Inhalte für tatsächlich benötigte Wiederverwendung modellieren Ein Leistungsdatensatz kann Titel, Zusammenfassung, Text, Referenz und Kontaktaktion trennen. Wird er auch in einem anderen Kanal genutzt, kläre gemeinsame und darstellungsspezifische Felder. Ein einziger unstrukturierter Seitentext ist ungünstig, wenn andere Kanäle einzelne Fakten brauchen. Umgekehrt lohnt sich kein universelles Modell für unbenannte zukünftige Anwendungen. Teste lange echte Überschriften, fehlende optionale Felder und mehrere Sprachen. Kläre Verweise, Medien und die Verantwortung für gemeinsam genutzte Daten. Wiederverwendung reduziert doppelte Pflege, erhöht aber die Wirkung einer fehlerhaften gemeinsamen Änderung. ### Migration und Ausstieg vor der Auswahl proben Exportiere eine repräsentative Seite samt Medien, Beziehungen und Sprachversionen. Das übernehmende Team muss den Export ohne exklusives Anbieter-Plugin verstehen können. Benenne nicht übertragbare Teile: Vorschau, Vorlagen, Freigaben oder Erweiterungsdaten müssen möglicherweise neu aufgebaut werden. Ordne wichtige alte URLs ihren erhaltenen oder neuen Zielen zu und prüfe sie nach dem Umzug. Vergleiche den gesamten Betrieb: Redaktionssupport, CMS-Updates, Frontend-Abhängigkeiten, Buildfehler, Sicherung und Wiederherstellung. Bleibe beim gesunden Bestand, wenn eine kleinere Vorlagen- oder Ablaufänderung das Problem löst. // 03 ## Wo das meistens schiefgeht - Die Inhalts-API existiert, Vorschau und Freigaben aber nur auf Folien. Den vollständigen Redaktionsablauf im vorgeschlagenen Setup testen lassen. - Jede Seite wird ein eigener Inhaltstyp. Mit repräsentativen Vorlagen beginnen und echte strukturelle Unterschiede bestimmen. - Die Migration kalkuliert Medien, Links, Übersetzungen oder Weiterleitungen nicht ein. Diese Objekte inventarisieren und ihre Prüfung vor dem Angebot zuordnen. // 04 ## Die Checkliste Nutze diese Punkte für deinen Umfang. - Wer pflegt wie oft und mit welchen technischen Fähigkeiten? - Welche Inhaltstypen, Sprachen und Kanäle brauchen Wiederverwendung? - Welche Vorschau, Rollen und Freigaben müssen praktisch funktionieren? - Welche Formulare, Anbindungen und bisherigen URLs bleiben wichtig? - Wer verantwortet CMS-Konten, Frontend, Export, Hosting und Wartung? - Entwurf, Vorschau, Freigabe, Veröffentlichung, Rücknahme und Wiederherstellung proben. - Export mit Medien, Beziehungen und Sprachversionen praktisch testen. - Verantwortung für Fehler und Updates in CMS und Frontend zuordnen. // 05 ## Wie das in unserer Arbeit aussieht MyMerch liefert Kontext zur Storefront-Entwicklung, keinen Beleg für eine Headless-CMS-Migration. ### [MyMerch](/de/case-studies/mymerch/) - **Status:** Live - **Outcome:** ~50% - Effizienzgewinn (laut Kunde) - **Summary:** ~50% Effizienzgewinn (laut Kunde). Auslieferungsfehler reduziert, Shopify-Conversion gesteigert. Kein Rewrite. - **Stack:** Shopify, Shopify Liquid, JavaScript Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 75+ Produkte ausgeliefert. // 06 ## Passende Leistungen & Lektüre - [LEISTUNG Websiteentwicklung](/de/services/website-development/) - [LEITFADEN Checkliste für Softwareübergabe](/de/software-development-guide/software-handover-checklist/) - [FALLSTUDIE Mymerch](/de/case-studies/mymerch/) // 07 ## Häufige Fragen ### Kann eine statische Website ein CMS haben? Ja. Inhalte können getrennt gepflegt und zur statischen Generierung genutzt werden. Statische Auslieferung und Headless-Inhaltsverwaltung beschreiben unterschiedliche Entscheidungen. ### Wann reicht ein klassisches CMS? Wenn Bearbeitung, Vorschau und Veröffentlichung dort gut funktionieren und kein eigener Frontend- oder Wiederverwendungsbedarf zusätzlichen Betrieb rechtfertigt. ### Können nichttechnische Kollegen Inhalte pflegen? Teste ihre konkreten Aufgaben im gewählten Produkt samt Vorschau. Das Architekturetikett beantwortet diese Frage nicht. ### Welche Kosten bleiben nach dem Start? Lizenzen, Hosting, Buildnutzung, Integrationen und Wartung hängen vom Aufbau ab. Frage nach Verantwortung und Ausstiegs- oder Exportbedingungen. Zuletzt geprüft: 2026-10-19 von [Kevin Riedl](/de/team/kevin-riedl/) [wiki ↗](https://www.wikidata.org/wiki/Q139796365) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/software-development-guide/headless-cms-vs-traditional-cms/#webpage", "@type": "WebPage", "dateModified": "2026-10-19", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-10-19", "url": "https://wavect.io/de/software-development-guide/headless-cms-vs-traditional-cms/" } ] } ``` ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/de/software-development-guide/headless-cms-vs-traditional-cms/#article", "@type": "Article", "about": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-10-19", "datePublished": "2026-10-19", "description": "Vergleiche gängige Konfigurationen nach Bearbeitung, Vorschau, Wiederverwendung, Migration und laufender Verantwortung. Beginne bei den Menschen, die Inhalte pflegen.", "headline": "Welcher Websiteaufbau passt zu deiner Redaktion?", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-10-19", "mainEntityOfPage": "https://wavect.io/de/software-development-guide/headless-cms-vs-traditional-cms/#webpage", "mentions": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, { "@type": "Service", "name": "Websiteentwicklung", "url": "https://wavect.io/de/services/website-development/" } ], "name": "Welcher Websiteaufbau passt zu deiner Redaktion?", "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "reviewedBy": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/" }, "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".cmp-hero__headline", ".cmp-hero__lead" ] }, "url": "https://wavect.io/de/software-development-guide/headless-cms-vs-traditional-cms/" }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/software-development-guide/", "name": "Leitfaden zur Softwareentwicklung", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/software-development-guide/headless-cms-vs-traditional-cms/", "name": "Welcher Websiteaufbau passt zu deiner Redaktion?", "position": 3 } ] } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ja. Inhalte können getrennt gepflegt und zur statischen Generierung genutzt werden. Statische Auslieferung und Headless-Inhaltsverwaltung beschreiben unterschiedliche Entscheidungen." }, "name": "Kann eine statische Website ein CMS haben?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Wenn Bearbeitung, Vorschau und Veröffentlichung dort gut funktionieren und kein eigener Frontend- oder Wiederverwendungsbedarf zusätzlichen Betrieb rechtfertigt." }, "name": "Wann reicht ein klassisches CMS?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Teste ihre konkreten Aufgaben im gewählten Produkt samt Vorschau. Das Architekturetikett beantwortet diese Frage nicht." }, "name": "Können nichttechnische Kollegen Inhalte pflegen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Lizenzen, Hosting, Buildnutzung, Integrationen und Wartung hängen vom Aufbau ab. Frage nach Verantwortung und Ausstiegs- oder Exportbedingungen." }, "name": "Welche Kosten bleiben nach dem Start?" } ], "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".faq-question", ".faq-answer" ] } } ```