// stack · cms
WordPress ist das meistgenutzte CMS im Web — und genau deshalb gibt es so viele langsame, zugeklickte WordPress-Seiten. siteway baut es anders: ein schlankes eigenes Theme statt Elementor oder Divi, eine kurze und begründete Plugin-Liste, Updates und Härtung als fester Prozess. Hier steht, wie wir das konkret machen — und wo die Grenzen des Systems liegen.
// definition
WordPress ist ein quelloffenes Content-Management-System, mit dem Inhalte einer Website ohne Code gepflegt werden — Seiten, Beiträge, Bilder, Menüs. Technisch läuft es auf PHP und einer MySQL- oder MariaDB-Datenbank. Die Software ist freie Software unter der GPL, gestartet 2003 als Blog-System und heute das meistgenutzte CMS im Web.
Drei Bausteine bestimmen, wie eine WordPress-Seite aussieht und was sie kann: Inhalte entstehen im Block-Editor, das Aussehen liefert ein Theme, zusätzliche Funktionen kommen über Plugins. Genau an diesen drei Stellen entscheidet sich, ob eine Website schnell und wartbar bleibt — oder zur Baustelle wird.
Zwei Namen werden dabei oft verwechselt: WordPress.org ist die freie Software, die auf einem Server deiner Wahl läuft — mit vollem Zugriff auf Code, Datenbank und Hosting. WordPress.com ist ein kommerzieller Hosting-Dienst desselben Ökosystems mit Tarifen und Einschränkungen. Wir bauen ausschließlich auf der selbst gehosteten Variante, weil nur dort ein eigenes Theme, eigene Deployments und eigene Härtung möglich sind.
Der Ruf des Systems leidet unter seiner eigenen Verbreitung: Weil jeder WordPress installieren kann, gibt es sehr viele schlecht gebaute Installationen. Das ist kein Argument gegen das CMS, sondern eines für saubere Umsetzung. Wie WordPress in unsere CMS-Auswahl neben TYPO3 und Statamic passt, steht im Hub — hier geht es um das System selbst.
// praxis
sauber gebaut · nicht zusammengeklickt
Der wichtigste Unterschied liegt im Theme. Wir schreiben es selbst — schlankes, semantisches HTML, Styles über Tailwind, Interaktion in Vanilla-JavaScript. Kein Elementor, kein Divi. Page-Builder bauen ihr Layout aus tief verschachtelten Containern und liefern dafür eigene CSS- und JS-Pakete mit: Das Markup wächst, die Ladezeit steigt, und das Projekt hängt an einem Fremdsystem. Wer den Builder später wechseln will, baut die Seiten neu. Ein eigenes Theme ist am Anfang mehr Arbeit und danach jahrelang weniger.
Die Redaktion arbeitet trotzdem komfortabel: Wir definieren im Block-Editor eigene Blöcke und Muster, die genau die Bausteine des Designs abbilden — Teaser, Zitat, Tabelle, Bildstrecke. Was nicht ins System gehört, geht auch nicht: Farben, Abstände und Schriftgrößen sind gesetzt, statt frei einstellbar zu sein. So kann niemand das Layout kaputtklicken, und die Seite bleibt konsistent, auch nach dem hundertsten Beitrag. Wo Inhalte mehr sind als Seiten und Beiträge, modellieren wir sie über Custom Post Types und eigene Felder.
Bei Plugins gilt: so wenige wie möglich, jedes mit Begründung. Wenn wir eine bestehende Installation übernehmen, ist der erste Schritt fast immer eine Inventur — eine lange Plugin-Liste, in der niemand mehr weiß, was wofür da ist, und in der sich drei Werkzeuge dieselbe Aufgabe teilen. Wir konsolidieren, bevor etwas Neues dazukommt. Kontaktformular, Bildergalerie oder eigene Felder lassen sich meist sauberer im Theme lösen als über ein weiteres Add-on. Und Tempo entsteht beim Bau, nicht durch ein Cache-Plugin am Ende: wenige Assets, lokale Fonts, Bilder in AVIF und WebP über unsere sharp-Pipeline.
Betrieb ist kein Nachgedanke. Der Code liegt in Git und geht über GitHub Actions live, Updates laufen planmäßig statt anlassbezogen, und die Installation wird gehärtet: Login absichern, Datei-Rechte setzen, Security-Header ausliefern, ungenutzte Endpunkte schließen. Der WordPress-Kern selbst ist gut gepflegt — die Angriffsfläche wächst mit dem Fremdcode drumherum. Genau deshalb halten wir ihn klein.
// bausteine · 6 details
jeder mit klarer entscheidung
WordPress lässt fast alles zu — das ist seine Stärke und sein Problem. Diese sechs Bausteine entscheiden in der Praxis darüber, ob eine Seite in drei Jahren noch schnell, sicher und pflegbar ist.
// d-01theme
Handgeschrieben statt gekauft: semantisches HTML, Tailwind für Styles, Vanilla-JS für Interaktion. Kein fremder Layout-Motor zwischen Inhalt und Ausgabe — und keine Abhängigkeit von einem Builder, den irgendwann niemand mehr pflegt.
ergebnis: schlankes markup
// d-02redaktion
Wir bauen die Design-Bausteine als eigene Blöcke und Muster nach — Teaser, Zitat, Tabelle, Bildstrecke. Farben, Abstände und Schriftgrößen sind gesetzt statt frei. Die Redaktion kombiniert, statt zu gestalten.
ergebnis: konsistentes layout
// d-03inhaltsmodell
Nicht jeder Inhalt ist eine Seite oder ein Beitrag. Referenzen, Produkte, Stellenanzeigen, Termine bekommen einen eigenen Typ mit eigenen Feldern und Taxonomien — sauber modelliert statt in Freitext-Blöcke gepresst.
ergebnis: strukturierte inhalte
// d-04plugins
Jedes Plugin ist Fremdcode mit eigenem Update-Zyklus und eigener Angriffsfläche. Wir inventarisieren, streichen Doppelungen und lösen den Rest im Theme, wo es sauberer geht. Was bleibt, ist dokumentiert und begründet.
ergebnis: kleine angriffsfläche
// d-05tempo
Wenige CSS- und JS-Dateien, lokale Fonts, Bilder in AVIF und WebP über unsere sharp-Pipeline, Lazy-Loading mit gesetzten Maßen. Core Web Vitals prüfen wir während der Umsetzung, nicht als Nacharbeit nach dem Launch.
ergebnis: ladezeit im bau
// d-06betrieb
Kern, Theme und Plugins werden planmäßig aktualisiert, Backups laufen automatisch, der Code liegt in Git. Dazu Härtung: Login absichern, Datei-Rechte setzen, Security-Header ausliefern, ungenutzte Endpunkte schließen.
ergebnis: planbare wartung
// beleg
gemessen · nicht behauptet
Unsere eigene Startseite erreicht bei PageSpeed Insights 100/100/100/100 auf Mobil — Performance, Barrierefreiheit, Best Practices, SEO. Sie läuft nicht auf WordPress, aber sie zeigt, welchen Maßstab wir an ein Frontend anlegen: wenige Assets, lokale Fonts, Bilder in modernen Formaten, kein Tracking. Denselben Maßstab nehmen wir mit ins WordPress-Theme. Ein Page-Builder mit zwanzig Plugins schafft ihn nicht, egal welches Cache-Plugin dahinter läuft.
Umgekehrt wählen wir WordPress nicht aus Gewohnheit. Der Konzern-Auftritt von Spelsberg läuft auf TYPO3, in 13 Sprachen, seit 2018 von uns betreut — dort wäre WordPress das falsche Werkzeug. Das Karten-Portal der Garbe-Gruppe ist eine eigene Anwendung, kein CMS-Projekt. Welches System ein Projekt bekommt, entscheiden wir vorher, nicht nachträglich. Alle Referenzen unter Cases.
Das ist der ganze Grund für unsere kurze Plugin-Liste: Der WordPress-Kern ist nicht das Problem — der Code drumherum ist es. Wer die Zahl der Erweiterungen klein hält, verkleinert die Angriffsfläche direkt, ohne ein einziges Sicherheits-Plugin zu installieren.
quelle: Patchstack, „State of WordPress Security in 2026“ (Daten für 2025)
// entscheidung
beratung statt systemtreue
WordPress ist ein gutes Werkzeug für einen klar umrissenen Bereich — und ein schlechtes, sobald man es darüber hinaus zwingt. Diese drei Punkte sprechen dafür; darunter steht, wohin wir stattdessen greifen.
// p-01redaktion
Viele Teams kennen das Backend schon aus einem früheren Projekt. Diese Vertrautheit ist bares Geld wert: kürzere Einarbeitung, weniger Rückfragen, Inhalte, die tatsächlich gepflegt werden statt zu veralten.
geringe einstiegshürde
// p-02inhalte
Regelmäßige Beiträge, Kategorien, Autoren, Archive: Dafür ist WordPress gebaut worden, und dort ist es unschlagbar direkt. Eine Unternehmens-Website mit Blog, Referenzen und Landingpages liegt genau in diesem Bereich.
content im zentrum
// p-03ökosystem
Für fast jede Standardaufgabe gibt es eine erprobte Lösung — Formulare, Shop, Newsletter, Mehrsprachigkeit. Wir nutzen das dosiert: wenige geprüfte Bausteine, die wirklich Arbeit sparen, statt eines Plugins pro Idee.
erprobte bausteine
Und wann nicht? Bei mehrsprachigen Konzern-Auftritten mit vielen Rollen, Freigaben und Sprachbäumen raten wir zu TYPO3 — dort ist die Mehrsprachigkeit im Kern gelöst, nicht per Plugin. Für sehr schlanke, wartungsarme Seiten ohne Datenbank ist Statamic die robustere Wahl, weil Inhalte als Dateien in Git liegen. Und wenn nicht Inhalte, sondern eigene Fachlogik der Kern sind — Buchungen, Rollen, Berechnungen, ein Portal —, gehört das in eine eigene Anwendung mit Laravel statt in ein CMS mit angebauten Plugins.
// faq
WordPress ist ein quelloffenes Content-Management-System, mit dem Inhalte einer Website ohne Code gepflegt werden — Seiten, Beiträge, Bilder, Menüs. Es läuft auf PHP und einer MySQL- oder MariaDB-Datenbank, erschien 2003 als Blog-Software und ist heute das meistgenutzte CMS im Web. Inhalte entstehen im Block-Editor, das Aussehen liefert ein Theme, zusätzliche Funktionen kommen über Plugins. siteway baut damit Business-Sites und Blogs — mit einem eigenen schlanken Theme statt eines Page-Builders.
Die Software selbst ist freie Software unter der GPL und kostet nichts. Geld kosten die Dinge drumherum: Hosting, Domain, die Entwicklung von Theme und Funktionen, gegebenenfalls Lizenzen für einzelne Plugins und vor allem der laufende Betrieb — Updates, Backups, Monitoring. Wer bei WordPress nur die Lizenz rechnet, rechnet den teuersten Posten nicht mit: die Wartung. siteway kalkuliert diesen Posten von Anfang an mit ein.
Page-Builder wie Elementor oder Divi erzeugen ihr Layout über tief verschachtelte Container und liefern dafür eigene CSS- und JavaScript-Pakete aus. Das kostet Ladezeit, bläht das Markup auf und bindet das Projekt an ein Fremdsystem: Wer den Builder wechselt, baut die Seiten neu. siteway schreibt stattdessen ein eigenes Theme mit klarem, semantischem HTML — kleineres Markup, bessere Core Web Vitals, saubere Überschriftenstruktur und ein Frontend, das sich Jahre später noch anfassen lässt.
Der WordPress-Kern wird von einem großen Team gepflegt und bekommt automatische Sicherheitsupdates. Die bekannten Lücken stammen fast nie aus dem Kern, sondern aus Plugins und Themes: Laut dem Patchstack-Report „State of WordPress Security in 2026“ entfielen von 11.334 neuen Schwachstellen des Jahres 2025 rund 91 Prozent auf Plugins und 9 Prozent auf Themes — auf den Kern selbst sechs. Je mehr Fremdcode installiert ist, desto größer die Angriffsfläche. Deshalb hält siteway die Plugin-Liste kurz, aktualisiert planmäßig statt anlassbezogen und härtet die Installation: Login absichern, Datei-Rechte setzen, Security-Header ausliefern, XML-RPC und ungenutzte Endpunkte schließen.
So wenige wie möglich, und jedes mit Begründung. Jedes Plugin ist Code von jemand anderem, der gepflegt, aktualisiert und abgesichert werden muss und der bei einem Update brechen kann. Viele Funktionen — Custom Post Types, eigene Felder, ein Kontaktformular, eine Bildergalerie — lassen sich sauberer im Theme lösen als über ein weiteres Add-on. siteway prüft bei Übernahmen zuerst die Plugin-Liste und konsolidiert sie, bevor irgendetwas Neues dazukommt.
Ja — wenn die Ladezeit beim Bau entsteht und nicht später über ein Cache-Plugin nachgerüstet wird. Tempo kommt aus schlankem Markup, wenigen CSS- und JavaScript-Dateien, lokalen Fonts und Bildern in AVIF und WebP über eine sharp-Pipeline. Ein Page-Builder plus zwanzig Plugins lässt sich mit keinem Cache reparieren. siteway misst Core Web Vitals als Teil der Umsetzung, nicht als Nacharbeit.
Bei mehrsprachigen Konzern-Auftritten mit vielen Rollen, Freigabe-Workflows und Sprachbäumen — dort trägt TYPO3 weiter, etwa beim Case Spelsberg mit 13 Sprachen. Bei sehr schlanken, wartungsarmen Seiten, die ohne Datenbank auskommen sollen, ist Statamic die robustere Wahl. Und wenn nicht Inhalte, sondern eigene Fachlogik der Kern sind — Buchungen, Rollen, Berechnungen, ein Portal — gehört das in eine eigene Anwendung mit Laravel. siteway klärt diese Weiche im Konzept, bevor gebaut wird.
// womit das zusammenhängt
kategorie, nachbar & leistung
// stack · kategorie
Die Ebene darüber: Wie wir zwischen TYPO3, WordPress und Statamic auswählen — und was für alle drei gilt.
zum hub →
// stack · nachbar
Das Enterprise-CMS für viele Rollen, Freigaben und Sprachen. Der Weg, wenn WordPress an der Redaktionsgröße scheitert.
zum system →
// leistung · buchen
Hier steht die Technik, dort das Angebot: Umsetzung, Redaktionsschulung und laufende Pflege — buchbar.
zur leistung →
// WordPress, sauber gebaut?
Projekt anfragen