WordPress, individueller Code oder Page Builder? Eine Perspektive aus der Praxis

Zuerst die Aufgabe, dann die Technologie

Diskussionen über Website-Technologie beginnen häufig am falschen Ende. Der eine empfiehlt WordPress, der andere baut alles mit Next.js, während ein Dritter behauptet, Webflow oder Framer hätten beide Ansätze überflüssig gemacht.

Das sagt meist mehr über den Arbeitsprozess des Dienstleisters aus als über die Anforderungen Ihres Unternehmens.

Bevor ich eine Plattform empfehle, brauche ich Antworten auf praktischere Fragen:

• Was muss die Website in den ersten sechs bis zwölf Monaten leisten?
• Handelt es sich primär um eine Marketing-Website, Content-Plattform, einen Onlineshop oder ein digitales Produkt?
• Wie häufig ändern sich die Inhalte, und wer wird sie bearbeiten?
• Welche Integrationen und Arbeitsabläufe sind unverzichtbar?
• Wie schnell muss die erste Version veröffentlicht werden?
• Wer kümmert sich nach dem Launch um Sicherheit, Performance und technische Probleme?
• Was passiert, wenn der ursprüngliche Entwickler oder Dienstleister nicht mehr verfügbar ist?
• Welche Teile müssen übertragbar sein, falls Sie später die Plattform wechseln?

Ohne diese Antworten ist die Behauptung über die „beste Plattform“ meist eine persönliche Vorliebe, die als technische Gewissheit präsentiert wird.

Die richtige Lösung ist nicht diejenige, die im Angebot am fortschrittlichsten wirkt. Es ist diejenige, die den geschäftlichen Auftrag erfüllt, ohne später unverhältnismäßige Kosten oder Abhängigkeiten zu erzeugen.

WordPress: flexibel, wenn jemand Verantwortung übernimmt

WordPress passt weiterhin gut zu vielen Marketing-Websites, Blogs, Publishern und Unternehmen, die ein etabliertes CMS benötigen, das auch Nicht-Entwickler bedienen können.

Es eignet sich häufig, wenn:

• Redakteure Inhalte ohne Supportanfrage für jede Kleinigkeit erstellen und ändern müssen
• die Website content-lastig und nicht anwendungsorientiert ist
• das Projekt mehrere Seitentypen, Kategorien, Sprachen oder redaktionelle Abläufe umfasst
• das Budget eher zu einem ausgereiften Ökosystem als zur Entwicklung jeder Funktion von Grund auf passt
• wichtige Integrationen bereits stabile WordPress-Unterstützung bieten
• das Team mit der Bearbeitungsoberfläche vertraut ist
• SEO-Struktur und regelmäßige Content-Pflege wichtig sind

WordPress verfügt außerdem über ein großes Ökosystem aus Entwicklern, Dokumentation und Werkzeugen. Das reduziert das Risiko, dass nur eine einzige Person die Lösung verstehen und betreuen kann.

Dieselbe Flexibilität kann jedoch zur Schwäche werden. WordPress entwickelt sich leicht zu einem System, in dem jede neue Anforderung mit einem weiteren Plugin beantwortet wird.

Probleme entstehen häufig, wenn:

• Plugins ohne technische Steuerung anwachsen
• mehrere Page Builder oder Bearbeitungssysteme parallel eingesetzt werden
• Themes und Erweiterungen nicht mehr gepflegt werden
• Updates aus Angst vor Fehlern verschoben werden
• individueller Code ohne Dokumentation direkt in einem Drittanbieter-Theme landet
• ähnliche Inhalte von Seite zu Seite unterschiedlich aufgebaut werden
• niemand Backups, Updates, Tests und Wiederherstellung verantwortet

WordPress ist nicht automatisch langsam oder unsicher. Eine schlecht aufgebaute und vernachlässigte WordPress-Installation kann beides sein.

Ich habe mit Installationen gearbeitet, die mehr als dreißig Plugins, überlappende Funktionen und mehrere visuelle Builder für dieselben Layouts verwendeten. Sie waren langsam, riskant zu aktualisieren und teuer zu reparieren. Ich habe ebenso deutlich schlankere WordPress-Systeme mit durchdachtem Theme, strukturierten Inhaltsfeldern und kontrollierten Abhängigkeiten betreut, die stabil blieben, weil jemand Wartung als festen Teil des Projekts behandelte.

Den Unterschied machte nicht das WordPress-Logo. Entscheidend waren Umsetzung und Verantwortung nach dem Launch.

Individuelle Entwicklung: mehr Kontrolle und mehr Verantwortung

Vue und Nuxt, React und Next.js sowie andere moderne Frameworks ermöglichen es, die Lösung eng am Produkt auszurichten.

Sie können kontrollieren:

• Komponentenarchitektur
• Verhalten der Benutzeroberfläche
• Datenflüsse und Integrationen
• Rendering und Caching
• Performance-Budgets
• Barrierefreiheitsmuster
• Designsystem
• Tests und Deployment

Diese Kontrolle wird wertvoll, wenn die Website mehr leistet als die Präsentation eines Unternehmens.

Individuelle Entwicklung ist oft gerechtfertigt, wenn:

• Nutzer Accounts, Profile oder personalisierte Ansichten haben
• die Lösung Dashboards, Rechner oder komplexe Logik enthält
• Daten aus mehreren externen Systemen stammen
• sich die Oberfläche abhängig von Nutzer oder Daten verändert
• das Produkt kontinuierlich weiterentwickelt werden soll
• besondere Anforderungen an Performance, Barrierefreiheit oder Sicherheit bestehen
• die Organisation Budget und technische Kapazität für die Pflege der Codebasis besitzt

Der Vorteil ist Kontrolle. Der Preis dafür ist dauerhafte Verantwortung.

Ein individuelles Projekt benötigt gewöhnlich:

• Versionsverwaltung
• Build- und Deployment-Prozesse
• eine Staging-Umgebung
• Monitoring
• Updates für Abhängigkeiten und Sicherheit
• automatisierte und manuelle Tests
• Dokumentation
• jemanden, der die Architektur bei Änderungen versteht

Individuelle Entwicklung ist häufig die falsche Standardwahl, wenn:

• eine einfache Marketing-Website innerhalb weniger Wochen online gehen muss
• fast alle Anforderungen gut von einem CMS abgedeckt werden
• das Team keinen Plan für langfristige technische Betreuung hat
• Redakteure weitgehend selbstständig arbeiten müssen
• das Unternehmen sein Angebot noch am Markt prüft
• technische Eleganz mehr kostet, als sie an Geschäftswert erzeugt

Ich habe individuelle Entwicklung empfohlen, wenn ein Unternehmen seine bestehende Plattform tatsächlich überholt hatte. Ebenso habe ich zu einer einfacheren Lösung geraten, wenn sie einen schnelleren Launch und eine risikoärmere Validierung des Angebots ermöglichte.

Eigener Code ist nicht automatisch ein Zeichen höherer Qualität. Manchmal ist er die richtige Investition. Manchmal ist er eine teure Lösung für ein gewöhnliches Problem.

Page Builder sind keine einheitliche Kategorie

Der Begriff „Page Builder“ wird häufig so verwendet, als funktionierten alle visuellen Werkzeuge gleich. Das tun sie nicht.

Es gibt mindestens zwei gängige Kategorien:

• Builder innerhalb eines CMS, beispielsweise Elementor und Divi in WordPress
• gehostete visuelle Plattformen, beispielsweise Webflow und Framer

Beide bieten mehr visuelle Kontrolle, ohne dass jedes Layout von Grund auf programmiert werden muss. Sie unterscheiden sich jedoch erheblich bei Hosting, Content-Modell, Erweiterungen, Export, Eigentum und der Schwierigkeit eines späteren Umzugs.

Diese Unterscheidung ist wichtig.

Eine Elementor-Website bleibt eine WordPress-Website mit WordPress-Hosting, Datenbank, Plugins und Software-Updates. Eine Website in Webflow oder Framer ist stärker an das Veröffentlichungsmodell, die Funktionen und die Preisgestaltung der jeweiligen Plattform gebunden.

Page Builder und gehostete visuelle Plattformen passen häufig, wenn:

• das Marketingteam Layouts ohne Entwickler ändern muss
• eine Kampagne oder erste Version schnell veröffentlicht werden soll
• die Website überwiegend aus bekannten Content- und Landingpage-Mustern besteht
• visuelle Flexibilität wichtiger als komplexe Anwendungslogik ist
• das Budget begrenzt ist
• ein größerer Plattformwechsel kurzfristig unwahrscheinlich ist
• das Team die Grenzen der Plattform versteht und akzeptiert

Für Landingpages, Portfolios, Kampagnen und kleinere Marketing-Websites kann dieses Tempo einen echten Wert darstellen.

Sie geraten häufig an Grenzen, wenn:

• jeder Abschnitt zu einer individuellen Ausnahme wird
• generiertes HTML, CSS und JavaScript unnötig umfangreich werden
• Animationen und Drittanbieter-Skripte ohne Performance-Budget hinzukommen
• Inhalte zwischen Seiten kopiert statt strukturiert wiederverwendet werden
• spätere Funktionen mehr Individualentwicklung erfordern, als die Plattform sinnvoll unterstützt
• Lizenz- und Plattformkosten mit weiteren Funktionen oder Redakteuren steigen
• ein Wechsel große Teile der Website zum Neuaufbau zwingt
• das Team visuelle Bearbeitung mit dem Wegfall technischer Wartung verwechselt

Ich habe Builder-Websites mit guten Core Web Vitals gesehen, weil jemand Bilder, Schriften, Skripte und Komponenten diszipliniert verwaltet hat. Ich habe auch Seiten erlebt, die viele Sekunden bis zur Nutzbarkeit benötigten, weil verschachtelte Elemente, Animationen und Ressourcen ohne Begrenzung anwuchsen.

Das Werkzeug allein entschied nicht über das Ergebnis. Die Umsetzung tat es.

Headless ist eine Option, kein automatisches Upgrade

Ein häufiger Mittelweg ist eine Headless-Architektur: Inhalte werden in einem CMS gepflegt, während ein separates Frontend sie den Nutzern anzeigt.

So lassen sich redaktionelle Kontrolle und eine individuelle Nutzererfahrung kombinieren. Das kann sinnvoll sein, wenn dieselben Inhalte mehrere Kanäle bedienen, das Frontend produktähnliche Anforderungen hat oder die Organisation bereits über technische Kapazitäten verfügt.

Der Ansatz erzeugt jedoch zusätzliche bewegliche Teile:

• CMS und Frontend müssen getrennt gepflegt werden
• Vorschau und Veröffentlichung benötigen eine bewusste Umsetzung
• Formulare, Suche, Weiterleitungen und SEO-Daten müssen geplant werden
• Redakteure können die unmittelbare visuelle Verbindung zwischen Inhalt und Seite verlieren
• Hosting und Fehlersuche werden komplexer
• zwei Systeme können zwei getrennte Kostenbereiche bedeuten

Headless ist deshalb nicht automatisch „moderneres WordPress“. Es ist eine Architekturentscheidung, die ein konkretes Problem lösen sollte. Fehlt dieses Problem, haben Sie vor allem zusätzliche Komplexität geschaffen.

Das Content-Modell ist wichtiger als die Optik des Editors

Beim Plattformvergleich konzentrieren sich viele auf das Aussehen der Bearbeitungsoberfläche. Ein angenehmer Editor ist hilfreich. Wichtiger ist jedoch die Frage, wie die Inhalte strukturiert sind.

Stellen Sie sich ein Unternehmen mit fünfzig Leistungsseiten vor. Ist jede Seite eine freie visuelle Fläche, kann der Redakteur fast alles ändern. Er kann aber auch fünfzig unterschiedliche Überschriftenstile, CTA-Varianten und Inhaltsstrukturen erzeugen.

Ein stärker strukturiertes Modell kann für jede Leistung definierte Felder anbieten:

• Hauptbotschaft
• Zielgruppe
• Vorteile
• Prozess
• häufige Fragen
• Belege
• CTA

Das bietet auf jeder einzelnen Seite weniger visuelle Freiheit, schafft jedoch mehr Konsistenz, einfachere Aktualisierungen und weniger unbeabsichtigte Fehler.

Die richtige Balance hängt vom Team ab. Ein erfahrenes Design- und Marketingteam kann größere Freiheit verantwortungsvoll nutzen. Ein kleines Unternehmen ohne interne Webkompetenz profitiert häufig von klareren Leitplanken.

Das beste Redaktionssystem ist nicht zwingend dasjenige, das alles erlaubt. Es macht häufige Aufgaben einfach und kostspielige Fehler schwieriger.

Eigentum und die Möglichkeit, den Dienstleister zu wechseln

Die Wahl der Technologie ist auch eine Entscheidung über Kontrolle.

Vor Projektbeginn sollte klar sein, wer Folgendes besitzt und administriert:

• Domain
• DNS
• Hosting
• CMS-Konto
• Plattformabonnements
• Analytics
• Designdateien
• Quellcode und Repositorys
• Drittanbieterkonten und API-Schlüssel

Fragen Sie außerdem, was tatsächlich umgezogen werden kann.

Die Möglichkeit, HTML zu exportieren, bedeutet nicht automatisch, dass die vollständige Website mitsamt CMS, Formularen, Animationen, Suche und Redaktionsablauf übertragbar ist. Der Zugang zu einem Code-Repository genügt ebenfalls nicht, wenn niemand anders das Projekt installieren, verstehen und veröffentlichen kann.

Eine seriöse Übergabe sollte umfassen:

• Konten unter Kontrolle des Unternehmens
• Dokumentation wichtiger Abhängigkeiten
• Anweisungen für Veröffentlichung und Wiederherstellung
• Übersicht über Lizenzen und laufende Kosten
• einen klaren Weg, wie ein anderer Dienstleister übernehmen kann

Die Abhängigkeit von einem Anbieter ist nicht immer falsch. Fast jedes System erzeugt irgendeine Form von Abhängigkeit. Entscheidend ist, dass sie sichtbar, vertretbar und bewusst akzeptiert wird.

Die tatsächlichen Kosten sind höher als der Angebotspreis

Ein günstiger Launch kann teuer werden, wenn jede kleine Änderung Spezialisten benötigt. Eine kostspieligere Individuallösung kann wirtschaftlich sinnvoll sein, wenn sie manuelle Arbeit ersetzt oder einen zentralen Geschäftsprozess unterstützt.

Vergleichen Sie deshalb nicht nur die Angebote für die erste Version. Berücksichtigen Sie außerdem:

• Hosting- und Plattformabonnements
• Premium-Plugins und Lizenzen
• Sicherheits- und Versionsupdates
• technischen Support
• Entwicklungszeit für neue Funktionen
• Zeit der Redakteure
• Schulung und Dokumentation
• Kosten einer späteren Migration
• das Risiko eines früher als geplanten Neuaufbaus

Eine Plattform mit höherer Monatsgebühr kann insgesamt günstiger sein, wenn das Team mehr selbst erledigen kann. Eine Lösung ohne Lizenzkosten kann teurer werden, wenn jede wichtige Änderung Entwicklung erfordert.

Die relevante Kennzahl ist deshalb nicht nur der Erstellungspreis, sondern die Gesamtkosten für Besitz, Betrieb und Weiterentwicklung.

Wartung entscheidet über den langfristigen Erfolg

Der Launch erhält die Aufmerksamkeit. Zwei Jahre später zeigt sich Qualität in den weniger glamourösen Bereichen:

• Sicherheitsupdates wurden installiert
• Backups wurden getestet
• Formulare funktionieren weiterhin
• Analytics erfasst noch die richtigen Ereignisse
• Inhalte sind aktuell
• alte Kampagnen und Weiterleitungen wurden bereinigt
• neue Bilder haben die Performance nicht zerstört
• das Team weiß, wer bei einem Ausfall verantwortlich ist

Schreiben Sie vor der Technologiewahl einen einfachen Wartungsplan:

• Wer veröffentlicht und prüft Inhalte?
• Wer installiert und testet Updates?
• Wer verantwortet Backups und Wiederherstellung?
• Wer repariert Formulare, Tracking und Integrationen?
• Wer überwacht Performance und Barrierefreiheit?
• Wie wird Support geleistet, und was kostet er?
• Was geschieht, wenn Traffic oder Content-Menge wachsen?

Ein einfacheres System, das das Team sicher betreiben kann, schlägt häufig eine „perfekte“ Architektur, die niemand anfassen möchte.

Was ich in der Praxis tatsächlich empfehle

Ich nutze WordPress, visuelle Plattformen und individuelle Frameworks nach Projektanforderung, nicht weil eine Option in jeder Situation moralisch oder technisch überlegen wäre.

Einige typische Ausgangspunkte:

• Content-getriebene Marketing-Website mit kleinem internem Team: häufig WordPress mit schlankem Theme, strukturierten Feldern und wenigen bewusst gewählten Plugins.
• Kampagne oder Landingpage für einen schnellen Messaging-Test: eine visuelle Plattform kann sinnvoll sein, wenn ihre Grenzen akzeptabel sind.
• Kleinere Unternehmenswebsite, die das Marketingteam visuell bearbeiten möchte: Webflow, Framer oder ein diszipliniert eingesetzter CMS-Builder können gut passen.
• Website mit Accounts, Daten und komplexen Abläufen: häufig individuelles Frontend und Backend.
• SaaS-Marketing und Produktoberfläche mit gemeinsamem Designsystem: individuelles Frontend, gegebenenfalls verbunden mit einem Headless-CMS.
• Onlineshop: in der Regel eine etablierte Commerce-Plattform statt eines ohne zwingenden Grund individuell entwickelten Checkouts.

Das sind Ausgangspunkte, keine universellen Regeln.

Die Antwort findet sich selten im Plattformmarketing oder in den Logos einer Präsentation. Sie hängt davon ab, wer nach Projektende mit der Website arbeiten muss.

Für die kommenden drei Jahre wählen

Einen universellen Gewinner gibt es nicht. Es gibt nur eine bessere oder schlechtere Passung zwischen Zielen, Budget, Zeitplan, Fähigkeiten und Wartungskapazität.

Schlecht gepflegtes WordPress verliert gegen eine gut betriebene Builder-Website. Überentwickelter Individualcode verliert gegen ein CMS, das das Team tatsächlich nutzt. Ein visuell beeindruckender Launch, den niemand aktualisiert, verliert gegen eine einfachere Website, die schnell, verständlich und aktuell bleibt.

Fragen Sie nicht nur, welche Technologie die Website bauen kann. Fragen Sie auch:

• Kann das Team sie sicher bedienen?
• Kann ein anderer Dienstleister übernehmen?
• Kann sich die Lösung ohne ständige Neuaufbauten weiterentwickeln?
• Bleiben die laufenden Kosten vertretbar?
• Passen die Einschränkungen zu den Plänen des Unternehmens?

Technologie ist wichtig. Wie die Website nach dem Launch genutzt und gepflegt wird, ist meist noch wichtiger.

Bevor Sie entscheiden, wie Sie Ihre Website erstellen, legen Sie fest, was sie für Ihr Unternehmen leisten muss.

Wenn Sie unsicher sind, welcher Ansatz zu Ihrem Projekt passt, starten Sie ein Gespräch. Jedes Projekt hat andere Anforderungen, und die richtige Antwort hängt von Ihren Zielen, Ressourcen und Plänen ab, nicht von der Technologie, die gerade die meiste Aufmerksamkeit erhält.