Einfach mal statisch lassen
WordPress installieren, Theme einrichten, ein paar Plugins dazu, Seiten anlegen und los geht’s. Für viele Webprojekte ist das seit Jahren ein ziemlich normaler Ablauf. TYPO3, Joomla oder andere Content-Management-Systeme funktionieren nach demselben Grundprinzip: Die Inhalte liegen in einem System, aus dem bei Bedarf die eigentliche Website erzeugt wird.
Das ist sinnvoll, wenn dieses System gebraucht wird.
Ich habe aber immer häufiger Websites vor mir, bei denen ich mich frage, warum im Hintergrund überhaupt ein CMS läuft.
Nehmen wir eine kleine Arztpraxis. Startseite, Leistungen, Team, Sprechzeiten, Anfahrt, Kontakt, Impressum und Datenschutz. Vielleicht noch ein paar Unterseiten zu einzelnen Leistungen. An diesen Inhalten ändert sich über Monate praktisch nichts. Zweimal im Jahr werden die Sprechzeiten angepasst, irgendwann kommt eine neue Mitarbeiterin dazu und vor Weihnachten soll ein Hinweis auf den Betriebsurlaub auf die Startseite.
Dafür läuft 365 Tage im Jahr ein komplettes Content-Management-System.
Muss das wirklich sein?
Ein CMS ist kein Bestandteil von HTML
Das klingt banal, gerät aber erstaunlich schnell in Vergessenheit. Eine Website braucht kein WordPress, um eine Website zu sein.
Wenn am Ende zehn oder zwanzig Seiten mit weitgehend unveränderten Inhalten ausgeliefert werden sollen, kann der Webserver auch einfach fertige HTML-Dateien ausliefern. Dazu kommen CSS, JavaScript, Bilder und Schriften. Mehr braucht eine klassische Unternehmenswebsite technisch häufig gar nicht.
Natürlich hat ein CMS Vorteile. Ein Kunde kann Inhalte selbst ändern, mehrere Redakteure können arbeiten, News lassen sich veröffentlichen und Funktionen können über Plugins ergänzt werden. Wenn das alles genutzt wird, stellt sich die Frage nach einer statischen Website meistens gar nicht.
Wenn sich aber seit drei Jahren niemand außer mir im WordPress-Backend angemeldet hat, wird die Sache interessanter.
Dann betreibe ich möglicherweise eine Datenbank, PHP, Benutzerverwaltung, Backend und eine Reihe von Plugins, damit ich zweimal im Jahr eine Telefonnummer und eine Öffnungszeit ändern kann.
Was nicht läuft, muss ich auch nicht aktualisieren
Für mich ist Sicherheit eines der stärksten Argumente, bei kleinen Websites wieder häufiger über eine statische Umsetzung nachzudenken.
Ein aktuelles WordPress mit gepflegten Plugins ist nicht per se unsicher. Das möchte ich ausdrücklich nicht behaupten. WordPress lässt sich vernünftig und sicher betreiben.
Es muss aber eben betrieben werden.
WordPress selbst bekommt Updates. Plugins bekommen Updates. Themes bekommen Updates. PHP bekommt neue Versionen. Komponenten erreichen ihr Support-Ende. Und bei jeder zusätzlichen Erweiterung kommt ein weiteres Stück Software hinzu, das über Jahre gepflegt werden muss.
Im Sommer dieses Jahres wurde beispielsweise eine Schwachstellenkette im WordPress-Core bekannt, über die unter bestimmten Voraussetzungen Remote Code Execution möglich war. Sicherheitsstellen beobachteten anschließend auch automatisierte Scans und Exploit-Versuche.
Das bedeutet nicht, dass jede WordPress-Seite unmittelbar gefährdet ist. Es zeigt aber sehr schön das grundsätzliche Problem: Eine öffentlich erreichbare Software muss gepflegt werden, auch wenn auf der Website selbst seit einem Jahr niemand einen Inhalt verändert hat.
Bei einer statischen Website sieht die Ausgangslage anders aus. Es gibt kein öffentlich erreichbares WordPress-Backend, keine WordPress-Benutzerkonten und keine Datenbank, aus der für jeden Seitenaufruf Inhalte zusammengesetzt werden müssen. Wenn auf dem Server für diese Website kein PHP benötigt wird, fällt auch diese Ebene weg.
Eine statische Website ist deshalb nicht automatisch unangreifbar. Auch der Webserver kann falsch konfiguriert sein, Zugangsdaten können gestohlen werden und eingebundene externe Dienste bringen ihre eigenen Risiken mit.
Aber die Angriffsfläche wird erheblich kleiner.
Was nicht vorhanden ist, muss ich auch nicht patchen.
Gerade bei kleinen Praxis-Websites denke ich darüber häufiger nach
Arztpraxen sind dafür ein gutes Beispiel, weil hier zwei Dinge zusammenkommen: häufig sehr überschaubare Websites und gleichzeitig ein Umfeld, in dem IT-Sicherheit eine besondere Rolle spielt.
Damit meine ich nicht, dass eine statische Website die Praxis-IT schützt. Wenn ein Rechner in der Praxis mit Ransomware infiziert wird oder Zugangsdaten für das E-Mail-Postfach gestohlen werden, hilft es wenig, dass die Startseite aus einer HTML-Datei besteht.
Die Website ist nur ein Teil der Infrastruktur.
Aber warum sollte ich ausgerechnet bei einem Teil, der eigentlich kaum Dynamik benötigt, zusätzliche Angriffsfläche schaffen?
Wenn eine Praxiswebsite lediglich über Leistungen, Sprechzeiten und Kontaktdaten informiert, brauche ich dafür nicht zwangsläufig eine Datenbank und ein Redaktionssystem.
Das gilt genauso für kleine Kanzleien, Handwerksbetriebe, Restaurants, Landingpages, Veranstaltungsseiten oder kleinere Unternehmensauftritte. Entscheidend ist nicht die Branche, sondern die Frage, wie die Website tatsächlich genutzt wird.
„Aber der Kunde muss seine Inhalte selbst ändern können“
Das ist wahrscheinlich das häufigste Argument für ein CMS.
Und es ist grundsätzlich richtig.
Nur sollte man sich vorher fragen, ob der Kunde seine Inhalte tatsächlich selbst ändern wird.
Ich habe genug Websites gesehen, bei denen diese Möglichkeit bei der Planung enorm wichtig war und anschließend jahrelang nicht genutzt wurde. Wenn eine Änderung notwendig ist, kommt dann doch eine E-Mail: „Kannst du bitte unsere neuen Öffnungszeiten eintragen?“
Daran ist auch nichts auszusetzen.
Bei einer Website, die vielleicht drei oder vier Änderungen im Jahr benötigt, kann es wirtschaftlicher sein, diese Änderungen einfach durchführen zu lassen, anstatt dauerhaft ein CMS nur für die theoretische Möglichkeit der Selbstpflege zu betreiben.
Wenn dagegen jede Woche neue Inhalte erscheinen, Stellenanzeigen gepflegt werden, mehrere Mitarbeiter Änderungen vornehmen oder regelmäßig neue Landingpages entstehen, sieht die Rechnung natürlich anders aus.
Dann erfüllt das CMS eine Aufgabe.
Mir geht es nicht darum, WordPress abzuschaffen. Mir geht es darum, wieder öfter zu fragen, warum ich es bei diesem konkreten Projekt eigentlich brauche.
Der Aufwand war lange ein gutes Gegenargument
Ein Grund, warum ich selbst bei kleinen Projekten häufig zu WordPress gegriffen habe, ist ziemlich banal: Es geht schnell.
WordPress installieren, Grundkonfiguration erledigen, ein vorhandenes Setup verwenden und darauf aufbauen. Viele Dinge, die jede Website braucht, sind bereits gelöst.
Eine komplett individuelle statische Website kann dagegen erstaunlich viel Fleißarbeit verursachen. Navigation, wiederkehrende Elemente, responsive Varianten, Meta-Angaben, Formulare, verschiedene Seitentypen – nichts davon ist besonders schwierig, aber in Summe kostet es Zeit.
Und genau an diesem Punkt verändert KI für mich inzwischen die Rechnung.
Ausgerechnet KI macht Handarbeit wieder interessanter
Das klingt zunächst etwas widersprüchlich.
KI automatisiert immer mehr Entwicklungsarbeit – und sorgt bei mir gleichzeitig dafür, dass ich wieder häufiger darüber nachdenke, Websites individueller und mit weniger fertigen Systemen zu bauen.
Der Grund ist einfach: Viel von der Fleißarbeit lässt sich heute schneller erledigen.
Wenn die Struktur feststeht, kann KI bei wiederkehrenden HTML-Elementen helfen, Varianten vorbereiten, vorhandenen Code nach einem klaren Muster umbauen oder bei kleineren CSS-Problemen unterstützen. Ich beginne bei vielen Aufgaben nicht mehr mit einer leeren Datei.
Dadurch sinkt die Hürde, eine alte Website nicht einfach auf die nächste WordPress-Installation umzuziehen, sondern einmal grundsätzlich zu fragen, was davon überhaupt noch benötigt wird.
Das finde ich gerade bei älteren Websites interessant.
Da läuft vielleicht ein WordPress oder TYPO3, das vor vielen Jahren eingerichtet wurde. Das damalige Theme ist längst überholt, Erweiterungen wurden mehrfach ausgetauscht und ein Teil des Systems existiert eigentlich nur noch deshalb, weil er schon immer da war.
Wenn ohnehin ein Relaunch ansteht, muss die Antwort nicht automatisch wieder dasselbe CMS sein.
Manchmal ist der bessere Relaunch auch eine Reduktion.
Statisch bedeutet nicht, zwanzig HTML-Dateien von Hand zu pflegen
Bei „statischer Website“ entsteht schnell das Bild eines Ordners voller HTML-Dateien, in denen bei jeder Änderung Navigation und Footer einzeln angepasst werden müssen.
So muss man natürlich nicht arbeiten.
Auch eine statische Website kann Komponenten, Templates und einen Build-Prozess haben. Navigation und Footer müssen deshalb nicht zwanzigmal kopiert werden. Je nach Projekt kann ein Static Site Generator sinnvoll sein oder eine kleine eigene Struktur völlig ausreichen.
Entscheidend ist für mich nicht, ob irgendwo während der Entwicklung ein Generator läuft.
Entscheidend ist, was anschließend auf dem Webserver passiert.
Wenn dort am Ende fertiges HTML liegt, das ohne Datenbank und serverseitige Anwendung ausgeliefert werden kann, habe ich einen großen Teil der Komplexität aus dem Produktivbetrieb entfernt.
Die Entwicklungsumgebung darf ruhig komfortabel sein. Der Webserver muss davon möglichst wenig wissen.
Und was ist mit Kontaktformularen?
Spätestens an diesem Punkt wird aus der komplett statischen Website häufig doch wieder etwas Dynamisches.
Ein Kontaktformular muss seine Daten schließlich irgendwohin schicken.
Das bedeutet aber nicht, dass deshalb die komplette Website dynamisch sein muss. Für ein Formular kann eine kleine serverseitige Lösung oder ein geeigneter externer Dienst ausreichen. Dass fünf Seiten einer Website ein Kontaktformular enthalten, ist für mich kein überzeugendes Argument dafür, auch die restlichen 95 Prozent über ein CMS auszuliefern.
Dasselbe gilt für andere Funktionen.
Man sollte nicht fragen: „Ist diese Website statisch oder dynamisch?“
Die bessere Frage ist: Welche Teile müssen tatsächlich dynamisch sein?
Wenn die Antwort „das Kontaktformular“ lautet, dann löse ich das Kontaktformular.
Dafür brauche ich nicht automatisch WordPress.
Performance gibt es fast nebenbei
Ein angenehmer Nebeneffekt ist die Geschwindigkeit.
Natürlich kann man WordPress sehr schnell machen. Mit vernünftigem Hosting, Caching und einer sauberen Umsetzung sind hervorragende Ladezeiten möglich.
Es ist nur interessant, welchen Aufwand wir teilweise betreiben, damit eine dynamisch erzeugte Seite möglichst selten dynamisch erzeugt werden muss.
Wir installieren Caches, erzeugen vorgenerierte Seiten, optimieren Datenbankabfragen und setzen möglicherweise noch einen Reverse Proxy davor.
Am Ende versuchen wir damit häufig, möglichst schnell fertiges HTML auszuliefern.
Eine statische Website beginnt bereits an diesem Punkt.
Das macht sie nicht automatisch schneller als jede WordPress-Installation, aber die Ausgangslage ist angenehm simpel. Eine Datei liegt auf dem Server und wird ausgeliefert.
Für eine kleine Unternehmenswebsite ist das häufig alles, was ich brauche.
Auch statische Websites haben Nachteile
Natürlich erkauft man sich diese Einfachheit an anderer Stelle.
Wenn ein Kunde plötzlich jeden Dienstag selbst einen neuen Artikel veröffentlichen möchte, wird eine Website ohne Redaktionssystem schnell unbequem. Wenn mehrere Mitarbeiter Inhalte bearbeiten sollen, Freigabeprozesse notwendig sind oder ständig neue Seiten entstehen, möchte ich das ebenfalls nicht über irgendwelche improvisierten Abläufe lösen.
Auch Funktionen wie Suche, Benutzerkonten, personalisierte Inhalte oder umfangreiche Schnittstellen können die Sache verändern.
Dann ist ein CMS oder eine andere dynamische Anwendung wahrscheinlich die bessere Lösung.
Genau deshalb geht es mir nicht um eine neue Regel wie „statisch ist besser als WordPress“.
Die Regel sollte eigentlich viel einfacher sein:
So viel System wie nötig und so wenig wie möglich.
Vielleicht sollten wir wieder öfter mit einer leeren Datei anfangen
Über Jahre ist es sehr bequem geworden, für fast jedes Projekt zuerst ein CMS aufzusetzen und sich anschließend Gedanken über die eigentliche Website zu machen.
Ich nehme mich davon ausdrücklich nicht aus.
WordPress ist schnell installiert, ich kenne das System und für viele Projekte ist es weiterhin genau die richtige Lösung. Aber diese Routine sollte nicht dazu führen, dass aus zehn weitgehend unveränderlichen Seiten automatisch ein dauerhaft zu wartendes Softwaresystem wird.
Gerade bei einem Relaunch einer älteren WordPress- oder TYPO3-Seite lohnt es sich deshalb, die Anforderungen noch einmal ohne Blick auf das bisherige System aufzuschreiben.
Wer muss Inhalte ändern?
Wie häufig passiert das wirklich?
Welche Funktionen benötigen serverseitige Logik?
Was davon könnte wesentlich einfacher gelöst werden?
Wenn am Ende herauskommt, dass WordPress die beste Lösung ist, bekommt die Website WordPress.
Wenn die Antwort aber lautet, dass zweimal im Jahr die Öffnungszeiten geändert werden und ansonsten eigentlich nur HTML ausgeliefert werden muss, darf die Lösung auch genau so einfach sein.
Durch KI ist die Hürde dafür für mich niedriger geworden. Nicht weil ich eine komplette Website generieren lasse und ungeprüft online stelle, sondern weil viele der kleinen, strukturierten Arbeiten, die eine individuelle Umsetzung früher unnötig teuer gemacht haben, schneller von der Hand gehen.
Vielleicht führt ausgerechnet mehr Automatisierung deshalb dazu, dass wir an anderer Stelle wieder einfacher bauen können.
Und wenn eine Website keine Datenbank, kein Backend und keine zwanzig regelmäßig zu aktualisierenden Komponenten braucht, nur um Öffnungszeiten und eine Telefonnummer anzuzeigen, ist das für mich keine technische Einschränkung.
Es ist möglicherweise einfach die passendere Architektur.