Elementor und Bricks sind beides Page-Builder für WordPress, doch sie hinterlassen sehr unterschiedliche Websites. Der Unterschied zeigt sich nicht im Editor, sondern in dem, was am Ende im Browser ankommt: wie viel Markup ausgeliefert wird, wie das CSS strukturiert ist und an wie vielen Stellen eine Änderung nachgezogen werden muss. JFconcept baut in beiden Systemen und richtet sie so ein, dass sie auch nach Jahren Redaktionsarbeit noch tragen.
Der Builder verfällt nicht, der Aufbau darunter verfällt
Der typische Verfall einer Builder-Website hat wenig mit dem Werkzeug zu tun und viel mit der Art, wie es benutzt wurde. Abstände werden direkt am Element gesetzt statt über eine Klasse. Eine Sektion wird kopiert, weil das schneller geht, als sie sauber wiederzuverwenden. Irgendwann existiert dieselbe Karte in einem halben Dutzend Varianten, und eine Farbänderung im Corporate Design wird zur Suchaktion durch alle Seiten.
Dazu kommt die Ausgabe. Jeder Page-Builder muss aus flexiblen Bausteinen HTML erzeugen, und je nach Bauart entstehen dabei zusätzliche Verschachtelungen, die im Layout nichts bewirken. Bricks ist von Haus aus auf schlanke Struktur ausgelegt, Elementor auf Breite an Bausteinen. Bei einer schlanken Unterseite fällt der Unterschied kaum auf. Bei einer langen Startseite mit vielen Sektionen summiert er sich zu mehr Daten, mehr CSS und einem trägeren Aufbau auf dem Handy.
Zuerst das System, dann die erste Seite
Vor dem ersten Element steht bei uns das System. Wir legen die Design-Grundlagen an: Farben, Schriftgrößen, Abstände und Rundungen als Variablen, dazu einen Satz globaler Klassen für die wiederkehrenden Bausteine. Erst danach wird gebaut. Direkte Formatierung am einzelnen Element ist die Ausnahme und braucht einen Grund.
In Bricks ist das der vorgesehene Weg: globale Klassen und Variablen sind fester Bestandteil des Systems, Komponenten lassen sich einmal bauen und über Eigenschaften variieren. In Elementor führen globale Einstellungen, Vorlagen und wiederverwendbare Blöcke zum selben Ziel, dafür ist das Ökosystem an Erweiterungen größer. Der Unterschied liegt im Weg, nicht im Ergebnis.
Zum Abschluss folgt der Teil, den viele Builder-Projekte auslassen. Wir räumen ungenutzte Plugins und Widgets ab und übergeben eine kurze Anleitung, welcher Baustein für welchen Inhaltstyp gedacht ist. Ohne diese Übergabe zerfällt jedes noch so saubere System wieder, weil im Team niemand weiß, welcher Weg der vorgesehene war.
Ein Builder-Wechsel ist ein Neubau der Oberfläche
Der Wechsel von einem Page-Builder zum anderen ist kein Umschalten. Layouts, Einstellungen und viele Plugin-Funktionen sind an das jeweilige System gebunden und lassen sich nicht übertragen. Die Inhalte bleiben in WordPress erhalten, das Aussehen muss neu entstehen. Wer damit rechnet, den Builder zu tauschen und danach bleibe alles beim Alten, kalkuliert falsch.
Wir raten deshalb ab, wenn die bestehende Seite sauber gebaut ist, die Ladezeiten stimmen und nur der Wunsch nach einem moderneren Werkzeug im Raum steht. Sinnvoll wird der Wechsel, wenn ohnehin ein Relaunch ansteht, wenn die Seite technisch am Ende ist oder wenn die Pflege so mühsam geworden ist, dass Inhalte deshalb liegenbleiben. Dann fällt die Oberfläche ohnehin neu an und der Wechsel geht darin auf. Welche Basis ein Projekt insgesamt braucht, klärt unsere Seite zu WordPress als Website-Basis.
Die Probe: eine Änderung, eine Stelle
Ob ein Builder-Aufbau taugt, lässt sich in einem Versuch prüfen. Eine zentrale Design-Entscheidung ändern, etwa die Akzentfarbe oder den Standardabstand zwischen zwei Sektionen. Passiert das an einer Stelle und wirkt überall, stimmt das Fundament. Muss dafür jede Seite einzeln geöffnet werden, ist nicht der Builder das Problem, sondern der Aufbau darunter.
Aus dieser einen Eigenschaft folgt der Rest: Redaktionelle Änderungen sind eine Sache von Minuten, neue Landingpages für Kampagnen entstehen aus vorhandenen Blöcken statt jedes Mal von vorn, und die Seite bleibt schlank, weil kein Wildwuchs an Einzelformatierungen mitgeliefert wird. Dieses Fundament legen wir aus Menden im Sauerland, für neue Projekte ebenso wie für gewachsene Bestandsseiten. Wo ein Builder die Anforderung nicht mehr trägt, endet die Standard-Basis und Webengineering übernimmt mit individueller Entwicklung.
Ein Auftritt, der verkauft
Pascal ist seit 2017 bei JFconcept und verantwortet seit 2023 das Webdesign. Du siehst deinen Entwurf als klickbaren Prototyp, bevor wir bauen, nicht als PDF zum Vorstellen. Datenschutz denken wir von Anfang an mit, statt die Seite hinterher DSGVO-fähig zu machen, und das technische SEO-Fundament gehört zu jedem Projekt: saubere Struktur, Sitemap, schnelle Ladezeiten.
