Ich bin in das offizielle Bricks Builder Expert Directory aufgenommen worden.

Darüber freue ich mich sehr. Ein digitaler Ritterschlag wäre vielleicht etwas übertrieben, aber eine schöne Anerkennung meiner bisherigen WordPress-Projekte ist es allemal.

Mein Profil im offiziellen Directory findest du hier: Nattawan Worachat – Bricks Expert

Und das ist ein guter Anlass, einmal zu erklären, warum ich mit Bricks arbeite.

Was der Expert-Status aussagt

Wer ins Directory möchte, bewirbt sich direkt mit Projekten, Leistungen und Referenzen. Bricks prüft anschließend Erfahrung, Qualifikation und Portfolio. Für mich zeigt der Status vor allem, dass ich das Werkzeug nicht nur ausprobiert, sondern in echten Projekten eingesetzt habe.

Für Auftraggeber ist das eine zusätzliche Orientierung, mehr aber nicht. Wichtiger bleiben die Projekte selbst: Funktioniert die Website auf unterschiedlichen Geräten? Lässt sie sich später sinnvoll erweitern? Und ist sie schnell genug, dass niemand beim Laden über sein Leben nachdenken muss?

Ein Badge beantwortet diese Fragen nicht automatisch.

Die eigentliche Arbeit bleibt dieselbe.

Was ist Bricks und warum arbeite ich damit?

Bricks ist ein visueller Website-Builder für WordPress. Seiten und Templates baue ich direkt in einer visuellen Oberfläche auf, gestalte sie und passe sie responsiv an.

Das klingt zunächst nach einem klassischen Page Builder wie Elementor. Interessant wird Bricks für mich aber dort, wo die visuelle Oberfläche aufhört.

Der Workflow orientiert sich stark an klassischer Webentwicklung. Ich arbeite mit globalen Klassen, CSS-Variablen, Flexbox und CSS Grid, verwende semantische HTML-Tags und baue wiederkehrende Elemente als Components auf. Farben, Typografie und Abstände steuere ich zentral, statt auf jeder Seite einzeln herumzuschrauben.

Das spart im laufenden Betrieb viel Zeit und verhindert kreatives Chaos.

Gleichzeitig kann ich tief in die technische Umsetzung eingreifen. Eigener CSS- und JavaScript-Code lässt sich ebenso einbinden wie PHP und HTML. Dazu kommen Hooks, Filter und die Möglichkeit, eigene Builder-Elemente zu entwickeln.

Ich gestalte also visuell und kann bei Bedarf jederzeit eine Ebene tiefer gehen.

Auch die vergleichsweise überschaubare Auswahl an fertigen Templates stört mich wenig. Ich baue ohnehin lieber ein eigenes System auf, als ein fertiges Design so lange umzubauen, bis es irgendwann nicht mehr nach Template aussieht.

Ein Page Builder mit ziemlich viel Technik darunter

Besonders stark wird Bricks bei dynamischen Websites.

Mit Query Loops lassen sich Beiträge, Custom Post Types, Taxonomien oder andere strukturierte Daten abfragen und anschließend frei gestalten. Auch externe Datenquellen und eigene Queries können eingebunden werden.

So entstehen Eventlisten, Teamverzeichnisse, dynamische Projektarchive oder Inhalte aus externen Systemen, ohne für jede Anforderung sofort ein zusätzliches Plugin zu brauchen.

Genau hier liegt für mich auch der Unterschied zu vielen klassischen Drag-and-drop-Buildern: Bricks nimmt einem die Webentwicklung nicht ab.

Ein Grundverständnis von HTML, CSS, Responsive Design und WordPress hilft enorm. Wer weiß, wie Klassen, Flexbox, Grid und semantisches HTML funktionieren, findet sich schneller zurecht und holt deutlich mehr aus dem System heraus.

Die Lernkurve ist dadurch etwas höher.

Dafür habe ich mehr Kontrolle.

Und wenn Kund sehr spezielle Wünsche haben, muss man irgendwann eben doch programmieren.

Bricks und KI: Anbindung per MCP

Inzwischen lässt sich Bricks auch mit KI-Werkzeugen verbinden. Über MCP können kompatible Clients wie Claude, Cursor oder Codex auf freigegebene Funktionen einer Bricks-Website zugreifen und beispielsweise bei Seiten, Inhalten oder dem Designsystem unterstützen.

Welche Aktionen erlaubt sind, lässt sich im WordPress-Backend steuern. Bricks bringt dabei keinen eigenen KI-Chatbot mit. Man verbindet stattdessen ein Werkzeug, mit dem man ohnehin arbeitet.

Das ist optional, aber ziemlich spannend.

Ich würde einer KI trotzdem nicht als erstes die Produktionswebsite eines Kunden zum Spielen geben. Dafür gibt es Staging.

Wie ich KI sonst in meinem Arbeitsalltag nutze, steht in Design und KI 2026: Womit ich gerade arbeite.

Ziemlich schnell. Und ziemlich clean.

Ein weiterer Grund, warum ich bei Bricks gelandet bin, ist die technische Grundlage.

Bricks erzeugt im Vergleich zu vielen klassischen Page-Builder-Workflows relativ schlankes Markup und ich kann selbst beeinflussen, welche HTML-Tags, Klassen und Styles zum Einsatz kommen. Das gefällt mir deutlich besser als ein System, das hinter einem einfachen Element mehrere Schichten aus Wrappern versteckt.

Automatisch schnell wird eine Website dadurch trotzdem nicht.

Zu große Bilder, externe Skripte, schlecht konfigurierte Plugins und unnötige Animationen interessieren sich herzlich wenig dafür, welches Logo auf dem Page Builder steht.

Bricks schafft eine sehr gute Basis. Performance bleibt trotzdem Arbeit.

Mehr dazu gibt es in Website Performance verbessern.

WordPress bleibt ein Werkzeug, nicht die Antwort auf alles

Meine eigene Portfolio-Website lief 2025 noch mit WordPress und Bricks. Inzwischen nutze ich dafür React, Next.js und ein Headless CMS. Kundenprojekte setze ich weiterhin häufig mit WordPress und Bricks um.

Das ist für mich kein Widerspruch.

Ein technisch freieres System eignet sich für meine eigenen Experimente und individuellen Anforderungen. WordPress ist für viele Unternehmen dagegen vertraut, redaktionell gut pflegbar und bei sauberem Aufbau sehr flexibel.

Wenn ich heute eine flexible und gut pflegbare Website auf WordPress-Basis entwickle, ist Bricks weiterhin meine erste Wahl.

Der Builder ist mir über die Jahre ziemlich ans Herz gewachsen. Ich kenne seine Stärken, seine Eigenheiten und seine Lernkurve.

Umso mehr freue ich mich über den Expert-Status.