Das Versprechen, das selten eingelöst wird
„Damit kannst du alles selbst ändern." Diesen Satz hört fast jedes Unternehmen beim Website-Verkaufsgespräch. Gemeint ist meistens: ein CMS ist installiert, du bekommst einen Login, und theoretisch kannst du Texte, Bilder und Preise selbst austauschen.
In der Praxis reicht das oft nicht. Eine Umfrage unter Website-Betreibern zeigt ein wiederkehrendes Muster: Ohne Grundverständnis des jeweiligen Systems und ohne Zeit für regelmäßige Pflege bleibt die Selbstpflege Theorie – am Ende ruft man doch wieder bei der Agentur an, weil der Editor Rätsel aufgibt oder ein Update etwas zerschossen hat. Das Problem liegt selten am guten Willen, sondern an drei Dingen: der Bedienung des Editors, der Angst, etwas kaputt zu machen, und der Wartungslast, die klassische CMS mitbringen.
Was „selbst pflegen" konkret bedeutet
Bevor du ein System bewertest, lohnt sich eine Liste dessen, was regelmäßige Website-Pflege tatsächlich umfasst: Sicherheitsupdates einspielen, Kontaktdaten und Öffnungszeiten aktuell halten, neue Angebote und Blogartikel veröffentlichen, SEO-Feinschliff an Texten und Technik – und das alles, ohne dass die Seite dabei instabil wird oder langsamer lädt.
Genau hier trennt sich, was ein System auf dem Papier kann, von dem, was ein Team im Alltag tatsächlich macht. Ein CMS, das theoretisch alles erlaubt, aber jede Änderung mit Unsicherheit verbindet, wird in der Praxis kaum genutzt. Die Inhalte veralten, die Seite verliert an Relevanz – und genau das straft Google beim Ranking ab.
WordPress: einfacher Einstieg, wachsender Wartungsaufwand
WordPress ist aus gutem Grund das meistgenutzte CMS: Die Installation ist schnell, der Block-Editor ist für einfache Texte intuitiv, und es gibt für fast jedes Problem ein Plugin. Für einen Blog oder eine einfache Marketingseite ist das oft der schnellste Einstieg.
Der Haken zeigt sich erst später. WordPress trennt Inhalt und Darstellung nicht sauber – Theme, Plugins und Kernsystem greifen ineinander, und genau das macht die Plattform zu einem der häufigsten Angriffsziele im Netz. Wer selbst pflegen will, braucht laufend Sicherheitsupdates, Backups und ein Auge auf Plugin-Konflikte. Bei mehreren Kundenseiten heißt das: jede Seite altert einzeln, jedes Update muss einzeln eingespielt werden. Individualisierung über den Standard hinaus bedeutet meist zusätzlichen Code – und damit wieder Abhängigkeit von einem Entwickler, genau an der Stelle, wo eigentlich Unabhängigkeit versprochen wurde.
Headless-Ansätze gehen den Weg andersherum: Inhalt und Darstellung werden konsequent getrennt. Das reduziert die Angriffsfläche, weil das CMS die Website nie direkt ausliefert, sondern Inhalte nur über eine Schnittstelle bereitstellt. Der Preis dafür ist üblicherweise mehr Konzeptarbeit am Anfang – für Unternehmen, die nicht selbst entwickeln, sondern eine fertige Lösung wollen, ist das erst mal ein Nachteil.
Wie es aussieht, wenn Bearbeiten kein Risiko mehr ist
Bei Websites auf dem orbilyte-Fundament – unserer eigenen Next.js- und Sanity-Basis – läuft die Pflege über Visual Editing: Du klickst direkt auf ein Element der echten, laufenden Seite, änderst den Text oder tauschst das Bild aus und siehst das Ergebnis sofort, genau so, wie es später live steht. Kein separates Backend, das anders aussieht als die Website, kein Rätselraten, welches Feld welchen Bereich der Seite steuert.
Auch Gestaltung ist Teil davon: Farben, Schriften, Abstände und Rundungen lassen sich im CMS einstellen, ohne dass jemand Code anfassen muss. Was du nicht änderst, ist die Struktur dahinter – die Bausteine (Hero, FAQ, Blog, Kontakt) sind vordefiniert, damit die Seite konsistent bleibt, egal wer gerade etwas einträgt.
Der zweite Unterschied liegt hinter der Oberfläche. Weil alle Kundenseiten auf demselben Fundament laufen, rollen Sicherheitsupdates und neue Bausteine zentral aus – ohne dass Inhalte oder Design einzelner Seiten angefasst werden. Bei WordPress-Installationen ist das Gegenteil der Normalfall: jede Seite ihr eigener Wartungsfall. Für ein Unternehmen mit einer Website heißt das: seltener Ärger. Für eine Agentur mit zehn Kundenseiten heißt das: der Wartungsaufwand steigt nicht linear mit, sondern bleibt kontrollierbar.
Struktur ist der eigentliche Unterschied, nicht Freiheit
Es ist verlockend, „Selbstpflege" mit maximaler Freiheit gleichzusetzen – jedes Feld frei editierbar, jede Farbe frei wählbar. In der Praxis führt das zu Seiten, die mit der Zeit auseinanderdriften: eine Unterseite mit anderer Schrift, ein Formular, das nicht mehr zum Rest passt, weil irgendwann jemand „nur kurz" etwas geändert hat.
Der bessere Maßstab ist nicht, wie viel du ändern kannst, sondern wie sicher du dabei bist, dass die Seite danach noch zusammenpasst. Ein Baustein-System mit klaren Grenzen – dieser Bereich ist Text, jener ist Bild, jene Reihenfolge ist die Reihenfolge der Sektionen – gibt genau die Freiheit, die im Alltag gebraucht wird, ohne dass am Ende jede Seite anders aussieht. Das ist auch der Grund, warum ein Content-Management-System für den Mittelstand heute weniger über einzelne Funktionen entscheidet als darüber, ob es Redaktionsarbeit erleichtert oder ausbremst.
Wann sich ein Wechsel lohnt
Nicht jede WordPress-Seite muss weg. Ein Wechsel lohnt sich, wenn eines der folgenden Muster regelmäßig auftaucht:
- Änderungen werden aufgeschoben, weil niemand im Team sich an den Editor traut.
- Jedes Update kommt mit der Sorge, dass danach etwas anderes kaputtgeht.
- Die Ladezeit ist trotz Cache-Plugin und Hosting-Wechsel nicht wirklich schnell.
- Individuelle Wünsche (ein Buchungswidget, eine Anfragestrecke) enden regelmäßig bei einem weiteren Plugin, das die Seite noch komplexer macht.
Trifft nichts davon zu und die Seite läuft stabil, ist ein Wechsel reine Symbolpolitik. Trifft mehreres zu, lohnt sich ein ehrlicher Blick auf die Alternative – nicht, weil WordPress schlecht ist, sondern weil der Wartungsaufwand irgendwann größer wird als der Nutzen der vermeintlichen Unabhängigkeit.
Am Ende zählt nicht, welches System auf dem Papier mehr kann, sondern welches im Alltag tatsächlich genutzt wird. Eine Website, die niemand pflegt, weil die Pflege Angst macht, verliert langsam an Relevanz – unabhängig davon, wie gut sie beim Launch aussah.
Wenn du wissen willst, wie eine Website auf dem orbilyte-Fundament in deinem konkreten Fall aussehen würde, ist ein unverbindliches Erstgespräch der einfachste erste Schritt. Wie sich der Bausteinansatz konkret anfühlt, zeigt auch unser Beitrag zu Landing Pages auf modernem Stack.
Häufige Fragen
Kann ich eine Website wirklich komplett ohne Entwickler pflegen?
Texte, Bilder, Reihenfolge von Bausteinen und Gestaltung wie Farben oder Schriften ja – dafür braucht es kein Entwickler-Wissen, wenn das CMS mit klar definierten Bausteinen statt freiem Code arbeitet. Strukturelle Änderungen, etwa ein neuer Seitentyp oder eine neue Funktion, bleiben Entwicklungsarbeit.
Warum wird WordPress trotz einfacher Installation oft doch zum Wartungsfall?
Weil Theme, Plugins und Kernsystem eng ineinandergreifen. Sicherheitsupdates, Plugin-Konflikte und Backups summieren sich, besonders wenn mehrere Personen an der Seite arbeiten oder mehrere Seiten parallel gepflegt werden müssen.
Was ist der Unterschied zwischen einem klassischen CMS und Visual Editing auf Basis von Sanity?
Bei einem klassischen CMS bearbeitest du Inhalte meist in einem separaten Backend, das anders aussieht als die fertige Seite. Visual Editing zeigt die echte Seite und lässt dich direkt auf den Elementen klicken, die du ändern willst – die Vorschau ist die Live-Ansicht.
Lohnt sich ein Wechsel des CMS für eine kleine Unternehmenswebsite?
Nur, wenn die aktuelle Pflege regelmäßig Unsicherheit oder Mehraufwand erzeugt – etwa Angst vor Updates, spürbar langsame Ladezeiten oder immer neue Plugins für einfache Wünsche. Läuft die bestehende Seite stabil und wird sie tatsächlich gepflegt, ist ein Wechsel selten der Engpass.
Bleiben meine Inhalte bei einem Wechsel des technischen Fundaments erhalten?
Inhalte lassen sich in der Regel migrieren, die Struktur ändert sich aber – Inhalte werden als Bausteine statt als freie Seiten angelegt. Das ist der eigentliche Umstellungsaufwand, nicht die reine Textübertragung.