WordPress-Alternativen: wann sich der Wechsel lohnt
WordPress betreibt einen großen Teil des Webs, und für viele Projekte ist das die richtige Wahl. Für manche nicht. Woran Sie erkennen, zu welcher Gruppe Sie gehören — und was die Alternativen tatsächlich anders machen.
Wofür WordPress nach wie vor die richtige Wahl ist
Wenn regelmäßig Inhalte gepflegt werden, wenn mehrere Personen ohne technische Kenntnisse damit arbeiten sollen und wenn es für Ihre Anforderung wahrscheinlich schon eine Erweiterung gibt — dann ist WordPress schwer zu schlagen. Die Verbreitung ist ein echter Vorteil: Sie finden Leute, die es können, und Sie sind nicht von einem einzigen Dienstleister abhängig.
Wie groß diese Verbreitung ist, zeigen die Messungen von W3Techs: Mit Stand vom 6. Oktober 2026 läuft WordPress auf 40,1 Prozent aller Websites und auf 58,6 Prozent der Websites, deren Redaktionssystem sich erkennen lässt. Das offizielle Verzeichnis führt rund 74.000 kostenlose Erweiterungen. Für fast jede Standardaufgabe — Kontaktformular, Mehrsprachigkeit, Terminbuchung — gibt es damit eine fertige Lösung, und für die verbreiteten Erweiterungen auch Menschen, die sie kennen.
Wer von WordPress abrät, ohne diese Punkte zu nennen, verkauft meist die eigene Lösung. Das gehört zur ehrlichen Einordnung dazu.
Die drei Gründe, aus denen Projekte trotzdem wechseln
Der erste ist Wartungsaufwand. WordPress ist wegen seiner Verbreitung ein bevorzugtes Ziel automatisierter Angriffe. Eine gepflegte Installation ist sicher, eine ungepflegte wird übernommen — das ist keine Frage des Ob. Wer die regelmäßige Pflege nicht leisten will oder kann, hat mit einer Alternative ohne Erweiterungsökosystem weniger Angriffsfläche.
Der zweite ist Geschwindigkeit unter Last. Viele WordPress-Seiten sind langsam, aber nicht wegen WordPress, sondern wegen zwanzig Erweiterungen, die alle mitgeladen werden. Das lässt sich in den Griff bekommen — nur ist der Aufwand dafür manchmal höher als ein Neubau.
Der dritte ist Individualität. Sobald Ihre Anwendung eigene Abläufe abbildet — Konfiguratoren, Kundenportale, Anbindungen an Warenwirtschaft —, arbeiten Sie gegen ein System, das für Beiträge und Seiten gebaut wurde. Dann ist ein Framework die ehrlichere Grundlage.
Was eine WordPress-Installation an Pflege tatsächlich verlangt
Eine WordPress-Installation verlangt Pflege auf drei Ebenen: den Kern, jede einzelne Erweiterung samt Theme und die Serverumgebung darunter. Automatische Updates für Erweiterungen und Themes gibt es seit WordPress 5.5, sie müssen laut offizieller Dokumentation aber für jede Erweiterung und jedes Theme einzeln eingeschaltet werden. Danach prüft WordPress zweimal täglich, ob neue Versionen vorliegen.
Bequem ist das nur auf den ersten Blick. Die Dokumentation empfiehlt selbst, vor dem Einschalten sicherzustellen, dass sich die Website auf einen früheren Stand zurücksetzen lässt — denn ein automatisches Update kann eine Erweiterung mit einer anderen in Konflikt bringen, und das bemerkt dann niemand, bis ein Kunde anruft. Automatik ersetzt also nicht die Pflege, sie verschiebt sie auf die Kontrolle danach.
Die dritte Ebene wird am häufigsten übersehen: die PHP-Version auf dem Server. WordPress empfiehlt aktuell PHP 8.3 oder neuer und läuft zwar noch auf älteren Versionen, weist aber ausdrücklich darauf hin, dass diese ihr Lebensende erreicht haben und die Website Sicherheitslücken aussetzen können. Wer die Website vor Jahren eingerichtet und seitdem nur Inhalte gepflegt hat, sollte genau hier zuerst nachsehen — vor jeder Entscheidung über einen Wechsel.
Was die Alternativen tatsächlich anders machen
Kopflose Redaktionssysteme trennen Inhalt und Darstellung: Die Inhalte liegen in einem System, die Website holt sie über eine Schnittstelle. Das lohnt sich, wenn dieselben Inhalte an mehreren Stellen ausgespielt werden — Website, App, Anzeigetafel. Bei einer einzelnen Website ist es Mehraufwand ohne Gegenwert.
Vorab erzeugte Seiten werden nicht bei jedem Aufruf berechnet, sondern einmal als fertige Dateien gebaut. Das Ergebnis ist sehr schnell und praktisch nicht angreifbar, weil zur Laufzeit nichts ausgeführt wird. Der Preis: Nach jeder Änderung muss neu erzeugt werden.
Anwendungs-Frameworks wie Laravel mit Vue sind der Weg, wenn die Website vor allem Abläufe abbilden soll und Inhaltspflege nur ein Teilaspekt ist. Sie bekommen volle Freiheit und geben dafür die fertigen Bausteine auf, die ein Redaktionssystem mitbringt.
Baukasten, anderes Redaktionssystem oder Eigenbau: die Optionen im Überblick
Neben kopflosen Systemen, vorab erzeugten Seiten und Frameworks gibt es zwei weitere Wege: Website-Baukästen und andere klassische Redaktionssysteme. Baukästen wie Wix und Squarespace sind nach W3Techs die nächstgrößeren Systeme nach WordPress und Shopify, mit 4,2 beziehungsweise 2,4 Prozent aller Websites. Sie nehmen Ihnen Server, Updates und Sicherheit vollständig ab — im Tausch gegen die Bindung an einen Anbieter, dessen Funktionsumfang die Grenzen Ihrer Website festlegt.
Für eine Visitenkarten-Website mit wenigen Seiten ist dieser Tausch oft vernünftig. Er wird teuer, sobald Sie etwas brauchen, das der Baukasten nicht vorsieht, oder sobald Sie ihn verlassen wollen. Prüfen Sie deshalb vor der Wahl, welche Exportwege der Anbieter dokumentiert: Was sich nicht vollständig exportieren lässt, muss beim Wechsel von Hand übertragen werden.
Ein anderes klassisches Redaktionssystem statt WordPress zu wählen, löst selten das Problem, das zum Wechsel geführt hat. Wer wegen des Pflegeaufwands wechselt, hat ihn bei jedem System mit Erweiterungen wieder. Sinnvoll ist ein solcher Wechsel vor allem dann, wenn ein bestimmtes System eine Fachanforderung von Haus aus abdeckt — etwa einen Onlineshop, der im Beitrag „Shopify oder eigener Shop" eigens behandelt wird.
Die Entscheidungsfrage, auf die es hinausläuft
Wie viel Prozent Ihrer Website ist Inhaltspflege, und wie viel ist Anwendungslogik? Bei überwiegend Inhalt bleiben Sie bei einem Redaktionssystem. Bei überwiegend Abläufen nehmen Sie ein Framework. Bei einer echten Mischung ist die kopflose Variante einen Blick wert.
Was Sie in keinem Fall tun sollten: wechseln, weil das neue System moderner klingt. Ein Wechsel kostet Umzug, Einarbeitung und ein Risiko für die Sichtbarkeit. Er braucht einen Grund aus der Liste oben, nicht aus einem Vortrag.
Eine zweite Frage hilft beim Abwägen: Wer pflegt die Website in drei Jahren? Liegt die Antwort bei einer einzelnen Person im Haus, zählt eine einfache, vertraute Oberfläche mehr als jede technische Eleganz. Liegt sie bei einem Dienstleister, zählt, dass das System dokumentiert und verbreitet genug ist, um diesen Dienstleister auch wechseln zu können.
Wenn gewechselt wird: worauf es beim Umzug ankommt
Beim Umzug entscheiden zwei Dinge über den Erfolg: dass die Inhalte vollständig mitkommen und dass jede alte Adresse auf die passende neue zeigt. Für die Inhalte bringt WordPress ein eigenes Werkzeug mit. Der Export unter „Werkzeuge" erzeugt eine XML-Datei im sogenannten WXR-Format mit Beiträgen, Seiten, eigenen Inhaltstypen, Kommentaren, eigenen Feldern, Kategorien, Schlagworten und Benutzern. Bilder und Einstellungen von Erweiterungen stecken darin nicht vollständig und müssen gesondert übertragen werden.
Für die Adressen empfiehlt Google dauerhafte, serverseitige Weiterleitungen mit den Statuscodes 301 oder 308 und rät, sie mindestens ein Jahr, besser unbegrenzt beizubehalten. Grundlage ist eine vollständige Liste aller bisherigen Adressen, nicht nur der Menüpunkte — Blogbeiträge, Kategorieseiten und Bilddateien werden oft von außen verlinkt und gehen sonst verloren.
Auch bei sauberer Arbeit bleibt eine Übergangszeit. Google weist darauf hin, dass nach wesentlichen Änderungen Schwankungen im Ranking auftreten können, solange die Website neu erfasst wird, bei mittelgroßen Websites über einige Wochen oder länger. Ein Wechsel kurz vor dem umsatzstärksten Monat ist deshalb eine schlechte Idee. Mehr zum Zeitpunkt steht im Beitrag zum Website-Relaunch.
Was ein Systemwechsel nicht löst
Ein Systemwechsel löst keine Probleme, die nicht im System liegen. Inhalte, die niemand sucht, werden auf einem anderen Unterbau nicht gefunden; Seiten, die nie aktualisiert wurden, veralten auch dort. Wenn die eigentliche Ursache fehlende Zeit für die Pflege ist, verlagert ein neues System das Problem nur.
Auch Sicherheit ist kein Zustand, den man mit einem System kauft. Ein Framework ohne Erweiterungsökosystem hat weniger Angriffsfläche, bekommt aber ebenfalls Sicherheitsupdates, die eingespielt werden müssen — nur seltener und von jemandem, der den Code kennt. Wer heute keine Pflege eingeplant hat, wird sie auch nach dem Wechsel nicht haben.
Die ehrlichste Prüfung vor einem Wechsel ist deshalb eine Bestandsaufnahme der heutigen Installation: welche Erweiterungen wirklich gebraucht werden, welche PHP-Version läuft, wann zuletzt aktualisiert wurde. Oft zeigt sich dabei, dass ein Aufräumen genügt. Und wenn nicht, ist die Liste die beste Grundlage für die Entscheidung.