Fünf Wege, ein CMS hinter eine bereits bestehende HTML-Website zu setzen — und was dich jeder davon wirklich kostet an Einrichtungszeit, Codeänderungen und Hosting-Umzügen. Einen davon bauen wir, und wir sagen klar, wo er die falsche Antwort ist.
Der schnellste Weg, einer bestehenden HTML-Website ein CMS zu geben, ist ein gehosteter Editier-Layer, angehängt mit einem einzigen Script-Tag. Markup, Styling und Hosting bleiben exakt wie sie sind, und der Inhalt wird an Ort und Stelle bearbeitbar — meist in unter fünf Minuten.
Alle Alternativen bedeuten, am Build zu arbeiten. Ein Neubau in WordPress ersetzt die Art, wie die Seiten erzeugt werden. Ein Git-basiertes CMS braucht ein Repository und eine Deploy-Pipeline. Ein Headless CMS braucht jemanden, der den Inhalt modelliert und in Templates verdrahtet. Ein Flat-File-PHP-CMS braucht PHP auf dem Server und Schreibrechte im Web-Root.
Entscheide über zwei Fragen: Muss der Code angefasst werden? und Braucht der Kunde irgendwo ein Konto? Alles andere ist Detail.
| Layer per Script-Tag | WordPress-Neubau | Git-basiertes CMS | Headless CMS | Flat-File-PHP | |
|---|---|---|---|---|---|
| Beispiele | Qixoo | WordPress + ein ThemeElementor, Bricks | TinaCMS, DecapCloudCannon, Sveltia | Contentful, SanityStoryblok, Prismic | Sitecake, CouchCMSGetSimple |
| Realistische Einrichtung | ~5 Minuten | 1–3 Tage | 2–6 Stunden | 1–2 Tage Entwicklung | 1–2 Stunden |
| Musst du an den Code? | Eine Zeile | Von Grund auf neu gebaut | Templates werden annotiert | Templates neu geschrieben | Kommentar-Tags pro Bereich |
| Zieht die Website um? | Nein — bleibt, wo sie ist | Meistens ja | Braucht Git und einen Build | Braucht einen Build oder einen Server | Braucht PHP-Hosting |
| Kunde braucht ein Konto | Nein — Einladungslink | Ja, ein WordPress-Benutzer | Ja, meist ein Git-Login | Ja, ein CMS-Seat | Ja, ein CMS-Passwort |
| Wessen Marke trägt der Editor | Neutral, oder deineEigenes Logo über das White-Label-Modul, 29 $ einmalig | WordPress | Unterschiedlich, oft die des Anbieters | Die des Anbieters | Die des Tools |
| Laufende Wartung | Auf deiner Seite keine | Core-, Theme- und Plugin-Updates | Build-Pipeline pflegen | Integration pflegen | PHP-Updates, Dateirechte |
| Typische Kosten | $0–$99/moDer Gratis-Tarif deckt 1 Website | Hosting plus deine ZeitDie Software ist kostenlos | Free–$100/moDecap und Tina sind Open Source | $100–$500+/mo | Einmalige LizenzOft unter 100 $ |
| Inhalt liegt im Quell-HTML | Wird im Browser wieder eingesetzt | Ja | Ja, zur Build-Zeit | Ja, wenn serverseitig gerendert | Ja, in die Datei geschrieben |
Die Zeiten gelten für eine fünfseitige Broschüren-Website, die an einen nicht-technischen Kunden übergeben wird, von jemandem, der das Werkzeug schon kennt. Beim ersten Mal bist du mit jedem davon langsamer.
Jede Option auf dieser Seite ist für irgendjemanden die beste. Hier steht, wer an welcher vorbeigehen sollte.
Ein Blog mit einem Beitrag pro Tag, ein Shop mit tausend Artikeln, eine Jobbörse — alles, wo Inhalt in Menge entsteht und in dem Moment im Quell-HTML stehen muss, in dem er sich ändert, gehört in ein echtes CMS mit Templates und Datenbank.
Lass es auch, wenn du einen Redaktions-Workflow brauchst: Entwürfe, Freigabe, geplantes Veröffentlichen, drei Personen, die einen Absatz abnicken.
Passt zu: Broschüren-Websites, Landingpages und Seiten lokaler Betriebe — denen, die sich ein paar Mal im Monat ändern.
Eine fertige Website in WordPress neu zu bauen kostet Tage, und an dem Tag, an dem du fertig bist, hast du dir einen Wartungsjob eingehandelt: Core-Updates, Plugin-Updates, Sicherheit, Backups. Jemand zahlt das für immer, und meistens bist das du.
Außerdem wirft es alles weg, was deinen ursprünglichen Build schnell und sauber gemacht hat.
Passt zu: Websites, die Plugins wirklich brauchen — Mitgliedschaften, Buchungen, ein echter Shop.
Decap, Tina und CloudCannon sind gute Werkzeuge, günstig oder kostenlos, und sie halten den Inhalt in deinem Repository. Sie setzen aber ein Repository voraus, einen Build und ein Deploy, das bei Inhaltsänderungen läuft. Jemand muss diese Pipeline verantworten.
Wenn der Build bricht, erscheint die Änderung des Kunden nicht — und angerufen wirst du.
Passt zu: Websites, die Entwickler betreuen, Dokumentation und Teams, die ohnehin in Git leben.
Contentful, Sanity und Storyblok sind für Inhalt in großem Maßstab über viele Kanäle gebaut. Für ein Restaurant mit einer Karte und einem Öffnungszeiten-Block verbringst du einen Tag damit, Inhaltstypen zu modellieren und Templates umzuschreiben — für ein Problem, das einen Satz lang war.
Der Monatspreis liegt ebenfalls in einer anderen Größenordnung.
Passt zu: Multi-Channel-Inhalte, Apps und mehrere Websites, die sich einen Inhaltspool teilen.
Sitecake und CouchCMS schreiben direkt zurück in deine HTML-Dateien, was elegant ist — und PHP braucht, Schreibrechte im Web-Root und einen Hoster, der beides duldet. Netlify, Vercel und Cloudflare Pages tun das nicht.
Mehrere Werkzeuge dieser Kategorie haben zudem seit Jahren kein nennenswertes Update mehr gesehen.
Passt zu: klassisches Shared Hosting mit cPanel und FTP.
Wenn die Person, die die Website bearbeitet, Entwickler ist, leg den Inhalt in Git. Wenn ein Marketing-Team sie täglich bearbeitet, kauf ein echtes CMS. Wenn es der Restaurantbesitzer ist, der sonntags einen Preis ändern will und sich noch nie irgendwo eingeloggt hat, lass das Bearbeiten auf der Seite selbst.
Die falsche Antwort ist immer: „Schick mir einfach die Änderungen, ich mach das.“
Einmal vor </head> auf jeder Seite einfügen, oder in das Custom-Code-Head-Feld der Plattform, die die Website hostet. Sonst ändert sich am Markup nichts.
Öffne die Live-Website angemeldet und klick eine Überschrift, einen Absatz, ein Bild oder einen Link an, um ihn zu ändern. Gespeicherter Inhalt wird bei jedem Seitenaufruf wieder eingesetzt.
Er öffnet seine eigene Website und bearbeitet sie in einem reduzierten Editor ohne Qixoo-Branding. Kein Konto, kein Dashboard, kein Code. Dein eigenes Logo kommt über das White-Label-Modul dorthin.
Texte und Überschriften, Bilder, Links, Buttons, Listenpunkte, Menüs, Galerien und Slider — die Dinge, deren Änderung Kunden tatsächlich anfragen. Du kannst auch fertige Blöcke einsetzen (ein FAQ, eine Preisliste, eine Reihe Testimonials), ohne Markup zu schreiben.
Es strukturiert dein Layout nicht um, und es ist keine Rechte-Sandbox: Der Kunden-Editor ist eine reduzierte Oberfläche, die strukturelles Bearbeiten versteckt, kein Schloss auf der darunterliegenden Seite. Deine Website hostet es auch nicht — das HTML liefert weiterhin dein Hoster aus.
Dein Hoster liefert weiterhin das HTML aus, das du geschrieben hast, ein Crawler bekommt also immer eine vollständige Seite. Über den Layer bearbeiteter Inhalt wird im Browser wieder eingesetzt, das heißt eine Änderung kann später aufgegriffen werden als eine Änderung an der Quelldatei. Für eine Überschrift oder einen Einleitungsabsatz, der sich ein paar Mal im Jahr ändert, ist das kein Thema. Muss der gesamte Inhalt einer Seite am Tag der Änderung indexiert sein, ändere auch das HTML.
Nein. Ein Editier-Layer per Script-Tag hängt sich an das HTML, das du längst veröffentlicht hast — Markup, Styling und Hosting bleiben, wie sie sind. Neu bauen musst du nur auf dem WordPress- oder Headless-Weg; beide ersetzen die Art, wie die Seiten erzeugt werden.
Das ursprüngliche HTML wird weiter von deinem Hoster ausgeliefert, die Seite, die ein Crawler bekommt, ist also die, die du geschrieben hast. Bearbeiteter Inhalt wird im Browser wieder eingesetzt, geänderter Text kann deshalb später gesehen werden als eine statische Änderung. Für Texte, die sich gelegentlich ändern, ist das in Ordnung; ändere auch die Quelle, wenn eine Seite am Tag der Änderung indexiert sein muss.
Bei Qixoo nicht — du schickst einen Einladungslink, und er bearbeitet seine eigene Live-Website. Bei Webflow Client Seats, WordPress oder einem Headless CMS braucht jede bearbeitende Person ein Konto auf dieser Plattform.
Es funktioniert auf jeder Website, die HTML ausliefert, ganz gleich bei welchem Hoster: handgeschriebenes HTML, statische Generatoren, exportierte Webflow- oder Framer-Websites, WordPress-Themes und alles auf Netlify, Vercel, Render, cPanel oder einem VPS. Auf Websites bei Webflow kommt das Tag unter Site Settings → Custom Code, was einen bezahlten Webflow-Site-Tarif voraussetzt.
Sie bleibt online, alle gespeicherten Änderungen bleiben erhalten — Besucher sehen den aktuellen Inhalt. Nur das Bearbeiten pausiert, bis wieder ein Tarif aktiv ist. Nichts wird gelöscht, nichts muss zurückmigriert werden.
Nach bestem Bemühen. Apps, die das DOM nach dem Laden neu rendern, können eingesetzten Inhalt überschreiben — teste also eine Seite, bevor du es einem Kunden zusagst. Serverseitig gerendertes HTML und statische Exporte sind der verlässliche Fall.
Mehrere. Decap CMS und TinaCMS sind kostenlos und Open Source, wenn die Website in einem Git-Repository liegt und dir eine Build-Pipeline recht ist. Der Gratis-Tarif von Qixoo deckt eine Website ohne Zeitlimit. Die WordPress-Software ist kostenlos; Hosting, Migrationszeit und Wartung sind es nicht.
Dann fang mit der Seite an, die genau dafür geschrieben ist: Ersatz für den alten Webflow-Editor und das White-Label. Sie behandelt Client Seats, was sich am 4. August 2026 geändert hat und wie du das Bearbeiten per Klick unter deiner eigenen Marke zurückholst.
Eine Zeile Code. Die erste Website ist kostenlos, ohne Zeitlimit und ohne Karte.
Kostenlos starten →