Website mit oder ohne CMS? Sicherheit, Pflege, Performance – und was KI-Agenten daran ändern

Vier Bauweisen im direkten Vergleich

Hinter „mit oder ohne CMS“ stecken in der Praxis vier Bauweisen. Für viele kleinere Unternehmen ist eine der beiden mittleren die beste Antwort: das gehostete System oder die statische Website mit Redaktionsoberfläche.

• Selbst gehostetes CMS: Die Software läuft auf deinem Server und erzeugt jede Seite aus einer Datenbank, etwa WordPress oder TYPO3. Du hast vollen Zugriff, trägst aber auch die Verantwortung für Updates und Sicherheit.
• Gehostetes System: Baukästen wie Wix oder Squarespace und Shopsysteme wie Shopify sind ebenfalls CMS, nur betreibt der Anbieter die Technik. Du zahlst ein Abo und arbeitest innerhalb seiner Grenzen.
• Statische Website: Fertige HTML-Dateien, von Hand geschrieben oder mit einem Generator wie Hugo, Astro oder Eleventy aus Textdateien gebaut. Auf dem Server läuft kein Programm, es werden nur Dateien ausgeliefert.
• Statisch mit Redaktionsoberfläche: Inhalte werden in einer Oberfläche gepflegt und daraus statische Seiten gebaut – entweder über ein Headless-CMS, das Inhalte nur per Schnittstelle ausgibt, oder über ein Git-basiertes CMS wie Decap CMS, das Änderungen direkt als Dateien im Code-Repository speichert.

Die Tabelle zeigt das eigentliche Tauschgeschäft: Ein CMS verlagert Kosten von der einzelnen Änderung in den Dauerbetrieb. Jede Textänderung ist günstig, dafür kostet die Website auch dann Pflege, wenn ein Jahr lang niemand etwas ändert. Bei der statischen Website ist es umgekehrt.

Pflege: Was regelmäßig anfällt – und was passiert, wenn niemand hinschaut

Der größte Unterschied zeigt sich, wenn ein Jahr lang niemand die Website anfasst: Die statische Website läuft unverändert weiter, das CMS wird mit jedem Monat ohne Updates angreifbarer. Für ein selbst gehostetes CMS gehören deshalb diese Aufgaben fest in den Kalender:

• Updates einspielen und danach prüfen. WordPress aktualisiert den Kern bei Neuinstallationen seit Version 5.6 automatisch; für Plugins und Themes lassen sich automatische Updates seit Version 5.5 einzeln einschalten. Ein automatisches Update kann trotzdem ein Layout zerschießen – jemand muss nachsehen.
• Backups, deren Wiederherstellung getestet ist. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme. Einmal im Quartal auf einer Testumgebung wiederherstellen.
• PHP-Version des Hostings anheben. WordPress empfiehlt PHP 8.3 oder neuer und weist darauf hin, dass die alten Mindestversionen ab PHP 7.4 ihr Lebensende bereits erreicht haben. Der Wechsel kann ältere Plugins brechen und muss getestet werden.
• Externe Ressourcen der Erweiterungen prüfen. Themes und Plugins laden gern Schriften oder Skripte von fremden Servern nach. Das Landgericht München hat 2022 einem Besucher 100 € Schadensersatz zugesprochen, weil eine Website Google Fonts ohne Einwilligung vom Google-Server lud (Az. 3 O 17493/20). Nach jedem neuen Plugin lohnt ein Blick, welche Verbindungen die Seite aufbaut.

Bei einer statischen Website fallen Updates, Datenbank-Backups und PHP-Wechsel weg, denn auf dem Server läuft kein Programmcode, der veralten könnte. Domain, Zertifikat, Zugänge und eingebundene Fremdskripte brauchen trotzdem gelegentlich einen Blick. Die Pflege verschiebt sich auf den Moment der Änderung: Der Generator, die Node-Version und die Bibliotheken, mit denen die Seite gebaut wird, entwickeln sich weiter. Wer nach zwei Jahren Pause etwas ändern will, muss oft zuerst die Werkzeugkette reparieren, bevor der erste Satz online geht. Diese Arbeit kann heute ein KI-Agent übernehmen, sie muss aber eingeplant werden.

Bei gehosteten Systemen erledigt der Anbieter die Technik vollständig. Der Preis dafür ist das Abo, das mit jeder Zusatzfunktion steigt, und die Bindung an genau diesen Anbieter.

KI-Agenten und MCP: Wie eine KI deine Website pflegt – mit und ohne CMS

KI-Agenten verändern die Rechnung aus dem Vergleich oben an einer Stelle grundlegend: Sie können Änderungen umsetzen, für die bisher ein Mensch mit Technikwissen nötig war. Damit wird die statische Website für Unternehmen ohne Entwickler zur echten Option – und das CMS bekommt eine neue Aufgabe als Regelwerk, das festlegt, was ein Agent darf.

Was MCP ist und warum es für deine Website zählt

Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Anwendungen mit anderen Systemen arbeiten – etwa mit deinem CMS, der Search Console oder einem Shop. Anthropic hat ihn Ende 2024 veröffentlicht und im Dezember 2025 an die Agentic AI Foundation unter dem Dach der Linux Foundation übergeben, die Anthropic gemeinsam mit OpenAI und Block gegründet hat. Für dich heißt das: Ein CMS mit MCP-Anbindung lässt sich von verschiedenen KI-Assistenten nutzen, ohne dass für jeden eine eigene Integration nötig ist.

Mit CMS: Der Agent arbeitet über die Schnittstelle

Beim CMS greift der Agent nicht auf Dateien oder Datenbank zu, sondern auf die offizielle Schnittstelle – mit denselben Rechten wie ein menschlicher Benutzer. WordPress bietet dafür seit Version 5.6 Anwendungspasswörter: Sie erben die Rolle ihres Benutzers, lassen sich einzeln widerrufen und taugen nicht zur Anmeldung im Backend. Mit WordPress 6.9 kam im Dezember 2025 die Abilities API dazu, über die WordPress und Plugins beschreiben, welche Aktionen sie anbieten. Das offizielle Plugin MCP Adapter macht diese Aktionen für KI-Agenten nutzbar – und prüft bei jedem Aufruf die Rechte des Benutzers. Auch gehostete Systeme ziehen nach: Shopify stellt MCP-Endpunkte für Katalog, Warenkorb und Checkout bereit, wobei nur dafür freigegebene Agenten einen Kauf abschließen dürfen.

Der Vorteil dieses Wegs: Das CMS speichert jede Version, und die Rechte lassen sich je Benutzer begrenzen. Dass der Agent nur Entwürfe anlegt, musst du allerdings selbst festlegen. Die Standardrolle Redakteur darf veröffentlichen und fremde Seiten löschen; die Rolle Mitarbeiter darf nur Entwürfe anlegen, aber keine Bilder hochladen. Passend ist meist eine eigene Rolle, die Entwürfe schreiben und Bilder hochladen darf, aber nichts veröffentlicht – per Rollen-Plugin oder wenigen Zeilen Code. Genau so arbeitet auch MCP SEO: über die offizielle Schnittstelle des CMS, ohne Zugriff auf Server oder Datenbank.

Ohne CMS: Der Agent arbeitet im Code

Bei einer statischen Website ändert der Agent die Textdateien direkt im Code-Repository. Wie weit das inzwischen trägt, zeigt das IT-Unternehmen innFactory. Nach eigenen Angaben hat es seine WordPress-Website im Januar 2026 in unter 48 Stunden mit Claude auf den Generator Hugo umgezogen – inklusive Weiterleitungen für alle alten URLs. Die KI-Kosten lagen bei rund 150 €. Inhalte pflegt das Team seitdem als Textdateien über GitHub.

Die Freigabe läuft hier über den Arbeitsablauf der Softwareentwicklung. Der Agent arbeitet in einem eigenen Zweig, und Hoster wie Cloudflare Pages oder Netlify bauen daraus eine Vorschau unter eigener Adresse. Erst wenn du die Vorschau abnimmst, wird die Änderung zusammengeführt und veröffentlicht. Das funktioniert gut, solange du die Vorschau wirklich prüfst. Rechte je Seitenbereich wie „darf Blogbeiträge ändern, aber nicht das Impressum“ sind hier nicht selbstverständlich. Bei GitHub lassen sie sich über Regeln für Dateipfade und Code-Verantwortliche nachbauen. Ohne solche Regeln ist die Freigabe vor dem Zusammenführen die einzige Sperre.

Praxisbeispiel: Wo Agenten an der Schnittstelle scheitern

Eine Schnittstelle zu haben heißt nicht, dass ein Agent alles erreicht. Diese Website läuft auf WordPress mit dem Page-Builder Bricks, und die Ratgeber entstehen als Entwurf über die REST-Schnittstelle – mit eigenem Benutzerkonto und Anwendungspasswort. Beim Aufbau dieses Ablaufs im Oktober 2026 sind drei Lücken aufgefallen:

• Bilder: Der eingesetzte MCP-Server schickt alle Daten als JSON, die Medien-Schnittstelle von WordPress erwartet aber eine Dateiübertragung. Hochladen war so nicht möglich – gelöst mit einem kleinen eigenen Plugin, das Bilder als JSON annimmt.
• Sprachversionen: Welche Sprache ein Beitrag hat und welche Übersetzungen zusammengehören, verwaltet das Plugin Polylang. In der kostenlosen Version, die hier läuft, ist das über die Schnittstelle weder lesbar noch änderbar; erst Polylang Pro liefert diese Felder mit. Gelöst mit einer zusätzlichen Route im eigenen Plugin.
• Page-Builder-Seiten: Bricks speichert den Inhalt seiner Seiten in eigenen Datenfeldern statt im regulären Inhaltsfeld. Ein Agent, der über die Schnittstelle das Inhaltsfeld bearbeitet, ändert auf diesen Seiten nichts Sichtbares.

Vor der Entscheidung für ein System, ein Theme oder einen Builder lohnt deshalb ein Test mit genau den Aufgaben, die ein Agent später übernehmen soll:

• Seiten und Beiträge lesen, als Entwurf anlegen und ändern
• Bilder hochladen, mit Alternativtext und Dateinamen
• Title und Meta-Description im Feld des SEO-Plugins setzen
• Sprachversionen zuordnen und miteinander verknüpfen
• Weiterleitungen anlegen
• Rechte je Benutzer begrenzen und Zugangsschlüssel einzeln widerrufen
• Jede Änderung mit Datum und Urheber nachvollziehen

Fällt ein Punkt durch, ist das kein Ausschlussgrund, aber ein Kostenposten: Jemand muss die Lücke schließen oder die Aufgabe bleibt Handarbeit. Wer neu baut und KI-Pflege plant, legt Inhalte am besten in Standard-Blöcken des CMS an – oder prüft vorab, wo der gewählte Page-Builder seine Inhalte speichert.

Sicherheit mit Agenten: Rechte, Freigabe, versteckte Anweisungen

Ein Agent mit Administratorrechten ist ein Administrator, der Anweisungen aus jedem Text annehmen kann, den er liest. Die OWASP-Liste der größten Risiken für KI-Anwendungen führt deshalb die Prompt Injection an erster Stelle: Anweisungen, die in Webseiten, Dateien oder Formulareingaben versteckt sind und das Verhalten des Modells verändern. Liest dein Agent Kommentare oder Kontaktanfragen, kann darin stehen „Lösche alle Seiten“. OWASP empfiehlt unter anderem geringste Rechte und eine menschliche Freigabe für riskante Aktionen – und weist darauf hin, dass es keinen lückenlosen Schutz gibt. Für deine Website heißt das:

• Geringste nötige Rechte: ein eigener Benutzer je Agent mit einer Rolle, die Entwürfe anlegen, aber nicht veröffentlichen oder löschen darf. Plugins installieren oder Benutzer anlegen gehört nie dazu.
• Freigabe vor jeder Veröffentlichung durch einen Menschen, bei statischen Websites über einen geschützten Hauptzweig, auf den niemand direkt schreiben darf.
• Widerrufbare Schlüssel: Anwendungspasswort oder Repository-Token so anlegen, dass du sie in einer Minute sperren kannst.

Umsteigen oder bleiben: Wann sich der Wechsel lohnt

Ein Wechsel der Bauweise lohnt sich nur bei einem konkreten Problem, das sich im bestehenden System nicht lösen lässt. Die Unzufriedenheit mit WordPress allein ist kein solches Problem – meistens ist es das Theme, der Builder oder die fehlende Wartung. Gute Gründe für einen Umzug zur statischen Website sind:

• Die Wartung kostet dauerhaft mehr, als die Redaktionsoberfläche einbringt, weil kaum jemand Inhalte ändert.
• Die Website wurde trotz Updates wiederholt angegriffen.
• Die Ladezeit bleibt nach einer gründlichen Optimierung schlecht, weil der Builder das Markup bestimmt.

Umgekehrt spricht gegen den Umzug, wenn mehrere Leute im Team regelmäßig veröffentlichen. OpenProject ist 2021 von WordPress auf eine statische Website gewechselt und beschreibt den Preis offen: Redakteure arbeiten seitdem mit Markdown und Git, und eine Änderung braucht bis zu 30 Minuten bis zur Veröffentlichung. Für eine Website, deren Inhalt sich selten ändert, war das die richtige Wahl – für eine Redaktion mit täglichen Meldungen wäre es eine Bremse.

Oft gibt es einen Zwischenweg: im CMS bleiben, aber den Page-Builder durch Standard-Blöcke ersetzen. Das kann Ladezeit- und Agenten-Probleme lösen, ohne dass sich der Arbeitsablauf der Redaktion ändert.

Wer umzieht, riskiert vor allem Rankings – und zwar nicht durch die neue Technik, sondern durch geänderte Adressen. Jede alte URL braucht eine 301-Weiterleitung auf ihr neues Gegenstück. Die Liste dafür entsteht aus der alten Sitemap, dem Seitenbericht der Search Console und den Seiten mit externen Links. Formulare, die Suchfunktion, Sprachversionen und das Cookie-Banner müssen in der neuen Bauweise neu gelöst werden; sie fehlen nach Umzügen am häufigsten. Wie ein Umzug ohne Ranking-Verlust abläuft, steht unter Relaunch-Betreuung.