Website ohne CMS aktualisieren: Nachricht rein, Vorschau-Link raus

So funktioniert die Aktualisierung einer Website ohne CMS: Sie senden die Änderung in einfacher Sprache über WhatsApp, E-Mail oder Slack, ein KI-Agent setzt sie im Code der Website um, und ein Vorschau-Link kommt zu Ihrer Freigabe zurück. Nach der Prüfung durch einen erfahrenen Entwickler geht die Änderung live. Kein Admin-Panel, keine Plugin-Updates, kein Layout, das unbemerkt kaputtgeht.

Sie möchten WordPress schon länger verlassen, doch eine Frage hält Sie zurück: Wer ändert die Öffnungszeiten, wenn es kein Backend zum Einloggen mehr gibt?

Diese Sorge ist berechtigt, denn zwanzig Jahre lang bedeutete der Abschied vom CMS eine E-Mail an einen Entwickler und ein Stundenminimum für eine Korrektur von zwei Minuten. Dieser Artikel zeigt den genauen Update-Workflow, den webvise bei Kundenprojekten einsetzt, wie ein Änderungswunsch in der Praxis aussieht und wann ein headless CMS wie Sanity die bessere Wahl ist. Am Ende sollte die Frage der Bearbeitung kein Grund mehr sein, eine WordPress-Installation am Leben zu erhalten.

• Einfache Sprache ersetzt das Admin-Panel. Änderungswünsche kommen über WhatsApp, E-Mail oder Slack, in den Worten, die Sie auch mit einem Kollegen verwenden würden.
• Jede Änderung kommt als Vorschau-Link zurück: eine vollständige private Kopie der Website mit der umgesetzten Änderung, unter einer eigenen URL, bevor irgendetwas live geht.
• Zwei Prüfschritte statt keinem. Sie geben die Vorschau frei, und ein erfahrener Entwickler liest die tatsächliche Code-Änderung, bevor sie veröffentlicht wird.
• Jede Änderung wird in git versioniert, sodass sich jeder frühere Stand der Website wiederherstellen lässt.
• Bei hohem Bearbeitungsaufkommen bleibt ein CMS sinnvoll. Teams, die täglich veröffentlichen, bekommen stattdessen Sanity in den Build eingebunden.

Die Angst, die jede Migration blockiert

Die Frage, mit der fast jedes Migrationsgespräch bei webvise beginnt, lautet in irgendeiner Form: 'Kann ich meine Website danach noch selbst bearbeiten?' Sie kommt vor den Kosten, vor dem Zeitplan, manchmal vor SEO. Die FAQ zur Migration von WordPress zu Next.js beantwortet elf häufige Einwände, und das ist der, den man zuerst stellt.

Diese Angst hat eine Geschichte. Der Abschied vom CMS bedeutete früher, drei Tage auf einen Entwickler zu warten, nur um ein Foto auszutauschen, weshalb das Festhalten an einer aufgeblähten WordPress-Installation rational wirkte, selbst bei den tatsächlichen 1.500 bis 5.000 € pro Jahr, die sie kostet. Das Admin-Panel kaufte ein Gefühl von Kontrolle, und die Jahresrechnung war der Preis dieses Gefühls.

Zwei Entwicklungen beendeten diesen Tausch: KI-Agenten, die klar abgegrenzte Änderungen in einer echten Codebasis umsetzen können, und Vorschau-Deployments, die jede Änderung zeigen, bevor sie live geht. Der WordPress-Migrationsservice von webvise baut diesen Bearbeitungsworkflow in jeden Relaunch ein. Der Rest dieses Artikels zeigt, wie sich das aus Kundensicht darstellt.

Der Workflow: Nachricht rein, Vorschau-Link raus

Der Ablauf hat sechs Schritte, und Sie werden nur bei zweien davon gebraucht.

Der Vorschau-Link nimmt die Angst. Er zeigt die echte Website mit Ihrer umgesetzten Änderung, sodass genau das live geht, was Sie freigegeben haben. WordPress bot das nie: Sie bearbeiteten im Backend und hofften, dass das Frontend mitzog.

Das Code-Review zählt genauso viel. Ich lese jede Änderung, bevor sie gemerged wird, ein strengerer Maßstab, als ihn je ein CMS durchgesetzt hat. Ein Admin-Panel veröffentlicht, was auch immer die letzte Person mit einem Login eingetippt hat.

Wie das in der Praxis aussieht

Die Website, die Sie gerade lesen, läuft nach genau diesem Ablauf. webvise.io erscheint in 7 Sprachen, der dazugehörige Blog umfasst 124 Beiträge und 868 Content-Dateien in einem einzigen git-Repository, und jeder Artikel, jede Preisänderung und jede Textanpassung durchläuft einen Agenten, ein Vorschau-Deployment und ein Review vor dem Merge. Es gibt kein CMS irgendwo im Stack, und dieser Artikel hat Sie über genau diese Pipeline erreicht.

Kundenanfragen sind unspektakulär, und genau das ist der Punkt. Neue Öffnungszeiten, ein neues Teammitglied, frische Projektfotos, ein saisonales Banner, eine aktualisierte Preisliste: Jede davon ist eine Nachricht von zwei Zeilen statt eines Logins und einer Page-Builder-Sitzung, die das Layout unbemerkt zerstören kann. Die Durchlaufzeit hängt nicht mehr vom Kalender eines Entwicklers ab, weil die Umsetzung in dem Moment beginnt, in dem die Anfrage eingeht. Die beiden Menschen im Ablauf, Sie bei der Freigabe und ich bei der Prüfung, sind die einzige Wartezeit.

Alles, was über eine reine Inhaltsänderung hinausgeht, wird zuerst geplant. Eine neue Seite, ein Buchungsablauf, eine dritte Sprache: Das läuft über eine kurze Einschätzung, bevor irgendein Agent den Code berührt. Der Kanal ist für die laufenden Änderungen gedacht, die früher ein installiertes CMS rechtfertigten.

Update-Kanal vs. WordPress-Admin vs. Sanity CMS

Drei Bearbeitungsmodelle decken fast jede Unternehmenswebsite ab. Der ehrliche Vergleich sieht so aus:

Die entscheidende Variable ist das Bearbeitungsaufkommen. Eine Firma, die zweimal im Jahr Referenzen aktualisiert und einmal pro Quartal eine Stellenanzeige veröffentlicht, gewinnt von einer CMS-Lizenz außer den Sicherheitspatches nichts. Ein Redaktionsteam, das jeden Morgen veröffentlicht, braucht direkten Zugriff, und kein Nachrichtenkanal sollte dabei im Weg stehen.

Wann Sanity die richtige Antwort ist

webvise bindet Sanity in Next.js-Builds ein, wenn das Bearbeitungsaufkommen eine echte Redaktionsoberfläche rechtfertigt. Das Bearbeitungserlebnis fühlt sich WordPress ähnlich an, das Frontend bleibt statisch und schnell, und die Veröffentlichung braucht überhaupt keinen Freigabe-Ablauf. Was ein headless CMS ist, was es kostet und wo die Kompromisse liegen, steht im verständlichen Leitfaden zu headless CMS.

• Veröffentlichung nach Zeitplan. Blogbeiträge, News oder Case Studies, die wöchentlich oder häufiger erscheinen.
• Mehrere Redakteure. Marketing, HR und Vertrieb bearbeiten alle Inhalte, mit Entwürfen und Rollen.
• Strukturierte Inhalte. Produktkataloge, Standorte oder Kurse: Daten mit Feldern, keine Seiten.
• Veröffentlichung in derselben Minute, weil das Volumen einen Freigabe-Ablauf unpraktisch macht.

Beide Modelle laufen problemlos in einem einzigen Build. Eine Website kann ihre Produktseiten aus Sanity ausliefern, während Design- und Feature-Änderungen weiterhin über den Kanal laufen. Die beiden beantworten unterschiedliche Fragen: wer bearbeitet, und wie oft.

Was es kostet und wie es strukturiert ist

Update-Arbeit läuft innerhalb des laufenden Supportmodells von webvise: Monitoring, Fehlerbehebungen, kleine Verbesserungen und ein Support-Rhythmus, der vor Beginn der Zusammenarbeit vereinbart wird. Ein Retainer ist nie Pflicht, und für Websites, die sich zweimal im Jahr ändern, gibt es eine Regelung nach Bedarf. Was ein Wartungsbudget enthalten sollte und was nicht, wird im Leitfaden zu den Kosten der Website-Wartung aufgeschlüsselt.

Dem stehen die 1.500 bis 5.000 € pro Jahr gegenüber, die eine typische WordPress-Website für kleine Unternehmen im Betrieb kostet. Der Großteil dieser Ausgaben kauft nur Stillstand: Plugin-Verlängerungen, Hosting-Tarife, Sicherheitspatches. Ein Nachrichtenkanal verwandelt dasselbe Budget in sichtbare Änderungen an der Website.

Wenn die Frage der Bearbeitung der Grund war, WordPress zu behalten, beantwortet der Workflow oben genau das. webvise übernimmt den Relaunch über den WordPress-Migrationsservice und richtet anschließend den Update-Kanal, eine Sanity-Installation oder beides ein, passend zum Bearbeitungsaufkommen. Für alles andere erreichen Sie über webvise.io/#contact Sebastian direkt.