Wir haben unsere eigene Seite von WordPress weggeholt
Kein Rundumschlag gegen WordPress, dafür gibt es keinen Grund. Ein Bericht darüber, was auf unserer alten Seite wirklich das Problem war, was der Wechsel gebracht hat und wann wir heute weiter zu WordPress raten.
Vorweg, damit die Richtung klar ist: WordPress ist ein gutes Stück Software. Es läuft laut W3Techs auf 40,7 Prozent aller Websites und auf 58,9 Prozent aller Seiten mit bekanntem Redaktionssystem (Stand 7. September 2026). Das wird es nicht durch Zufall. Wir bauen weiter WordPress-Seiten für Kunden, bei denen es passt.
Trotzdem läuft unsere eigene Seite seit Juli 2026 nicht mehr darauf. Warum, und was das gebracht hat, steht hier. Mit den unangenehmen Teilen.
Was auf unserer alten Seite wirklich falsch war
Bevor wir umgezogen sind, haben wir den Bestand aufgenommen. Das Ergebnis war ernüchternd, und der interessante Teil daran ist: fast nichts davon war die Schuld von WordPress.
| Befund | War es WordPress? |
|---|---|
| 10 von 14 Seiten ohne Beschreibung für Suchmaschinen | Nein, nie eingetragen |
| 3 Seiten ohne H1-Überschrift | Nein, Aufbau der Seite |
| 2 Testseiten öffentlich und in der Sitemap | Nein, vergessen |
| Eine themenfremde Seite im Index | Nein, vergessen |
| Kein hreflang, obwohl es eine spanische Fassung gab | Teilweise, WordPress kann es ohne Erweiterung nicht |
Spanische Seiten mit lang="de" im Quelltext |
Teilweise, dasselbe |
| Sechs Kundenlogos mit demselben Alternativtext | Nein, beim Einpflegen passiert |
| Zwei Fremdschriften und zwei Symbolschriften als Ballast | Ja, Reste aus Theme und Erweiterungen |
Acht Befunde, und sechs davon hätten wir in WordPress genauso beheben können wie anderswo. Wer sich eine neue Software kauft, um ein Pflegeproblem zu lösen, hat danach ein Pflegeproblem und eine neue Software.
Das ist der ehrlichste Satz dieses Beitrags, und er gilt für die meisten Wechsel, von denen wir hören.
Was dann trotzdem den Ausschlag gab
Zwei Dinge, und beide haben mit dem Alltag zu tun, nicht mit dem Bauen.
Die Zahl der beweglichen Teile
Unsere alte Seite lief auf einem gekauften Theme mit einem eigenen Baukasten, einem Child-Theme, einer Erweiterung für den Baukasten und mehreren weiteren Erweiterungen. Jedes dieser Teile bekommt Aktualisierungen, jedes kann brechen, und jedes kann eine Lücke haben.
Die Zahlen dazu sind eindeutig. Patchstack zählt für 2025 11.334 neue Schwachstellen im WordPress-Umfeld, ein Anstieg von 42 Prozent gegenüber dem Vorjahr. Davon entfielen:
| Woher | Anteil |
|---|---|
| Erweiterungen | 91 % |
| Themes | 9 % |
| WordPress-Kern | 6 Stück insgesamt, alle mit niedriger Einstufung |
Der Kern ist also nicht das Problem. Das Problem ist der Baukasten drumherum, und der wächst mit jedem Wunsch, den man sich schnell erfüllt. Dazu kommt eine Zahl, die den Zeitdruck erklärt: 46 Prozent der Lücken hatten zum Zeitpunkt der Veröffentlichung noch keine Korrektur, und bei den stark angegriffenen liegt die Zeit bis zum ersten Angriff im Mittel bei fünf Stunden.
Das ist beherrschbar. Man braucht dafür automatische Aktualisierungen, Sicherungen, die man auch zurückspielen kann, und jemanden, der hinschaut. Für eine Kundenseite mit Budget für Wartung ist das der normale Weg. Für unsere eigene Seite wollten wir die Aufgabe lieber ganz loswerden.
Bauen statt bedienen
Der zweite Grund ist Geschmack, und wir schreiben ihn als solchen hin. Bei einem Baukasten-Theme steckt die Gestaltung in einer Oberfläche und in einer Datenbank. Wer etwas ändern will, klickt. Wer wissen will, warum etwas so aussieht, klickt sich durch Ebenen.
Wir wollten die Gestaltung im Klartext haben, versioniert, mit einem Änderungsverlauf. Das ist unsere eigene Anforderung. Für jemanden, der seine Seite selbst zusammenklicken möchte, ist es genau der falsche Weg.
Was der Wechsel gebracht hat
Gewechselt haben wir auf ein Flat-File-System, das die Inhalte in Textdateien ablegt statt in einer Datenbank. Was dabei messbar herauskam, heute nachgemessen an der Startseite:
| Wert | Heute |
|---|---|
| HTML, komprimiert | 17 KB |
| Stylesheets | 1 aus dem Theme, 114 KB unkomprimiert, 39 KB übertragen |
| Schriftdateien | 1, 27 KB |
| JavaScript-Dateien | 0 |
| Datenbank | keine |
Die letzten beiden Zeilen sind die eigentliche Veränderung. Keine einzige JavaScript-Datei, alles, was die Seite an Verhalten hat, steckt in drei kurzen Blöcken im Quelltext. Und keine Datenbank bedeutet: keine Datenbanksicherung, kein Datenbankserver, keine Wiederherstellung im Notfall, kein Datenbankbenutzer, der falsche Rechte hat.
Die Schriftdatei ist ein gutes Beispiel dafür, was sich nebenbei ändert. Die alte Seite lud vier Schriften: die Markenschrift, zwei Fremdschriften aus Erweiterungsresten und zwei Symbolschriften. Heute ist es eine, verkleinert auf die Zeichen, die drei Sprachen brauchen.
Der Betrieb sieht seitdem so aus: Änderungen gehen über Git auf den Server, es gibt keine Aktualisierungen von Erweiterungen, und die Sicherung ist eine Kopie eines Ordners.
Was schlechter geworden ist
Diesen Abschnitt lassen andere Berichte gern weg.
Der Markt an fertigen Lösungen ist winzig. Für WordPress gibt es über 60.000 Erweiterungen. Was uns fehlte, mussten wir bauen: die Suchmaschinen-Anbindung, die Verwaltung der Formulareingänge. Das war Arbeit, die bei WordPress zwei Klicks gewesen wäre.
Die Auswahl an Leuten ist kleiner. Wer eine WordPress-Seite hat, findet überall jemanden, der sie übernimmt. Bei einem selteneren System ist der Kreis deutlich enger. Das ist ein echtes Risiko, und wer für einen Kunden entscheidet, muss es ansprechen.
Es gibt keinen visuellen Baukasten. Neue Abschnitte entstehen im Code, nicht per Klick. Texte, Bilder und alle Inhalte lassen sich weiterhin im Redaktionsbereich pflegen, das Layout selbst aber nicht.
Ein Umzug kostet ungefähr so viel wie ein Neubau. Jede Seite wird einmal angefasst, jede Adresse braucht eine Weiterleitung. Was dabei zu tun ist, steht in unserem Beitrag zum Website-Relaunch.
Wann WordPress die richtige Wahl bleibt
| Situation | Empfehlung |
|---|---|
| Mehrere Leute pflegen Inhalte, mit verschiedenen Rechten | WordPress |
| Onlineshop mit WooCommerce | WordPress |
| Regelmäßig neue Funktionen ohne eigene Entwicklung | WordPress |
| Im Unternehmen kann bereits jemand WordPress | WordPress |
| Fünf bis fünfzehn Seiten, die sich selten ändern | Beides geht, das schlankere gewinnt |
| Möglichst wenig laufender Aufwand ist das Hauptziel | Flat-File oder statisch |
| Kein Budget für Wartung | Flat-File oder statisch |
| Mehrsprachig von Anfang an | Prüfen, was das System ohne Erweiterung kann |
Die Zeile mit dem fehlenden Wartungsbudget ist uns die wichtigste. Eine WordPress-Seite ohne Pflege ist auf Sicht die teuerste Variante von allen, weil der Aufwand sich sammelt und irgendwann als Störung zurückkommt.
Die vier Fragen, die wirklich zählen
Nach diesem Umzug würden wir die Frage anders stellen. Statt „welches Redaktionssystem" lieber:
- Wie viele Teile hat die Seite, die eigene Aktualisierungen bekommen? Jedes Teil ist ein Termin und ein Risiko.
- Wer schaut hin, und wie oft? Wenn die Antwort niemand lautet, muss die Bauart das ausgleichen.
- Was passiert, wenn ein Teil ausfällt? Steht die Seite dann, oder fehlt nur eine Kleinigkeit?
- Wer kann sie in drei Jahren übernehmen? Je seltener das System, desto wichtiger ist eine saubere Dokumentation.
Wer diese vier Fragen beantwortet, kommt bei WordPress oder woanders heraus, und beides ist dann eine Entscheidung statt einer Gewohnheit.
Wenn du gerade überlegst, ob sich ein Wechsel bei dir lohnt: Schreib uns kurz, mit der Adresse deiner Seite. Wir sehen uns an, wie viele bewegliche Teile darin stecken, und sagen dir ehrlich, ob es sich rechnet. Häufig lautet die Antwort nein.
Quellen
Stand dieses Beitrags
Seit der Veröffentlichung inhaltlich unverändert.
Häufige Fragen zum Wechsel
Ist WordPress unsicher?
Der Kern von WordPress ist gut gepflegt. Im Jahr 2025 entfielen laut Patchstack nur sechs von 11.334 gemeldeten Schwachstellen im WordPress-Umfeld auf den Kern selbst, 91 Prozent auf Erweiterungen. Das Risiko liegt also im Baukasten drumherum und wächst mit jeder zusätzlichen Erweiterung. Eine WordPress-Seite mit fünf gepflegten Erweiterungen ist etwas ganz anderes als eine mit dreißig.
Was ist ein Flat-File-CMS?
Ein Redaktionssystem, das die Inhalte in Textdateien auf der Festplatte ablegt statt in einer Datenbank. Jede Seite ist eine Datei mit Text und ein paar Angaben im Kopf. Der Vorteil ist die geringe Zahl beweglicher Teile: keine Datenbank, kein Datenbankserver, keine Sicherung, die daran hängt. Der Nachteil ist der kleinere Markt an fertigen Erweiterungen und die geringere Zahl an Leuten, die sich damit auskennen.
Lohnt sich ein Wechsel bei einer bestehenden Seite?
Meistens nicht als eigenes Vorhaben. Ein Systemwechsel kostet ungefähr so viel wie ein Neubau, weil jede Seite einmal angefasst wird. Sinnvoll ist er, wenn ohnehin ein Relaunch ansteht oder wenn der laufende Aufwand für Aktualisierungen und Störungen erkennbar über dem liegt, was die Seite einbringt. Läuft die Seite und macht keine Arbeit, ist der beste Zeitpunkt für einen Wechsel: gar nicht.
Kann ich meine Inhalte selbst pflegen, ohne WordPress?
Ja. Auch andere Systeme bringen einen Redaktionsbereich mit, in dem Texte und Bilder ohne Technikkenntnisse geändert werden. Der Unterschied liegt weniger im Bearbeiten als im Erweitern: Bei WordPress installierst du eine neue Funktion mit zwei Klicks, anderswo braucht es dafür jemanden, der etwas baut.
Wann würdet ihr weiter zu WordPress raten?
Wenn viele verschiedene Leute Inhalte pflegen, wenn ein Shop mit WooCommerce betrieben wird, wenn regelmäßig neue Funktionen dazukommen sollen, oder wenn im Unternehmen bereits jemand WordPress kann. In diesen Fällen ist das große Ökosystem genau der Vorteil, für den es gemacht ist.
Wie viele Erweiterungen sind zu viele?
Eine feste Zahl gibt es nicht, aber eine gute Prüffrage: Kannst du zu jeder Erweiterung sagen, was sie tut und wann sie zuletzt aktualisiert wurde? Wenn nicht, sind es zu viele. Erweiterungen, die seit über einem Jahr keine Aktualisierung bekommen haben, gehören überprüft und im Zweifel ersetzt.