Über 40 Prozent aller Websites weltweit laufen auf WordPress. Wenn ein Kunde bei uns anfragt, ist WordPress fast immer die erste Option, die er selbst schon in Betracht gezogen hat – meistens, weil sie ihm jemand empfohlen hat oder weil eine frühere Website darauf lief. Trotzdem bauen wir standardmäßig kein WordPress. Kein Ideologie-Grund, kein "wir hassen CMS" – sondern eine nüchterne Abwägung, die wir hier einmal ausschreiben, statt sie nur auf der Startseite in einem Satz zu behaupten.

Was WordPress gut kann

Fangen wir ehrlich an: WordPress ist aus gutem Grund so verbreitet. Wer selbst regelmäßig Inhalte veröffentlichen will – ein Redaktionsteam, ein Blog mit mehreren Autoren, häufige News-Updates – bekommt mit WordPress ein Editor-Interface, das seit über 20 Jahren verfeinert wird. Das Plugin-Ökosystem ist riesig, für fast jedes Standardproblem gibt es eine fertige Lösung, und die meisten Agenturen und Freelancer kennen sich damit aus. Das ist kein kleiner Vorteil.

Wo es für unsere Kunden nicht passt

Der Kompromiss liegt in dem, was WordPress mitbringt, um all das zu ermöglichen: eine generische Plugin-Architektur, die jedes zusätzliche Feature als zusätzlichen Code, zusätzliche Datenbankabfragen und zusätzliche Angriffsfläche einbaut. Ein Theme mit zehn aktiven Plugins lädt oft spürbar langsamer als eine Seite, die exakt für ihren Zweck gebaut wurde – nicht weil WordPress schlecht programmiert ist, sondern weil generische Lösungen naturgemäß mehr mitschleppen als eine, die nur eine Sache kann.

Dazu kommt: Plugins brauchen Updates, Updates brechen manchmal etwas, und irgendjemand muss das laufend im Blick behalten. Für ein Redaktionsteam, das ohnehin täglich im Backend ist, fällt das kaum ins Gewicht. Für einen Handwerksbetrieb oder ein B2B-Beratungsunternehmen, dessen Website sich nach dem Launch kaum noch ändert, ist es reine Wartungslast ohne Gegenwert.

Und dann ist da noch die Optik. Die meisten WordPress-Sites laufen auf einem von wenigen tausend verbreiteten Themes. Das lässt sich mit genug Aufwand individualisieren – aber ab einem gewissen Punkt ist es günstiger, von Grund auf neu zu bauen, als ein fremdes Theme so lange zurechtzubiegen, bis es wie etwas Eigenes aussieht.

WordPress Handgeschriebener Code
Passt für Redaktionsteams mit häufigen, eigenständigen Updates Websites, die nach dem Launch selten strukturell geändert werden
Ladezeit / Core Web Vitals Abhängig von Theme und aktiven Plugins Volle Kontrolle, nur Code, der für dieses Projekt existiert
Wartung Laufende Plugin- und Theme-Updates nötig Keine Plugin-Abhängigkeiten, kein Update-Wettlauf
Design Meist auf Basis eines von tausenden Themes Individuell, für jedes Projekt neu konzipiert
Abhängigkeit An Update-Politik und Ökosystem der Plugins gebunden Code gehört vollständig dem Kunden, keine CMS-Lizenzgebühren

Was das für Suchmaschinen bedeutet

Ladezeit ist längst kein reines Komfort-Thema mehr, sondern ein direkter Ranking-Faktor. Core Web Vitals – Googles Messwerte für Ladegeschwindigkeit, visuelle Stabilität und Reaktionsfähigkeit – fließen sichtbar in die Suchergebnisse ein. Eine WordPress-Seite mit vielen aktiven Plugins hat es hier strukturell schwerer als eine schlank gebaute Seite, einfach weil mehr Skripte geladen und ausgeführt werden müssen, bevor die Seite tatsächlich nutzbar ist. Das lässt sich mit genug Aufwand optimieren – Caching-Plugins, Bild-Kompression, ein vorgeschaltetes CDN – aber jede dieser Maßnahmen behebt ein Problem, das bei einer von Grund auf schlank gebauten Seite gar nicht erst entsteht. Mehr dazu, wie wir Ladezeit und technisches SEO angehen: SEO & Performance.

Was wir stattdessen bauen

Je nach Projekt schreiben wir React, Next.js oder pures HTML, CSS und JavaScript von Hand. Kein Page-Builder, kein Theme. Das gibt uns volle Kontrolle über Ladezeit, Sicherheit und jedes einzelne Pixel – und es bedeutet, dass jede Zeile Code tatsächlich für dieses eine Projekt existiert, nicht für zehntausend andere Websites gleichzeitig. Mehr dazu auf unserer Webentwicklung-Seite.

Das bedeutet auch: Sie sind nicht von der Update-Politik eines Drittanbieter-Plugins abhängig, das morgen eingestellt werden könnte. Der Code gehört vollständig Ihnen, läuft ohne laufende Lizenzgebühren für ein CMS, und lässt sich erweitern, ohne dabei auf einen bestimmten Plugin-Markt angewiesen zu sein.

Bei E-Commerce-Projekten heißt das nicht, dass wir bewährte Backend-Systeme wegwerfen. Rum4You zum Beispiel behält sein WooCommerce-Backend für Produktpflege und Bestellungen – nur das Frontend, das Kunden tatsächlich sehen, ist ein eigenständiges, handgeschriebenes System. Details dazu in der Rum4You Case Study.

Und die häufigste Rückfrage, die uns dieser Beitrag einbringt – "aber wie ändere ich dann selbst meine Texte?" – hat inzwischen eine Antwort: unser eigenes Content-System, ganz ohne WordPress.

Wann WordPress trotzdem Sinn macht

Wenn ein Unternehmen ein Redaktionsteam hat, das mehrmals wöchentlich neue Inhalte selbst veröffentlichen will, ohne jedes Mal eine Agentur einzuschalten – dann ist ein echtes CMS oft die richtige Wahl, und WordPress ist eine solide Option dafür. Wir sagen das lieber ehrlich, als jedem Kunden dieselbe Lösung zu verkaufen, egal ob sie passt oder nicht.

Für die meisten kleinen und mittleren Unternehmen, mit denen wir arbeiten, überwiegt aber das Gegenteil: eine Website, die einmal gebaut wird, danach selten strukturelle Änderungen braucht, und bei der Ladezeit und individuelles Design den Unterschied machen. Genau dafür bauen wir handgeschriebenen Code statt eines Baukastens.

Unsicher, welche Variante für Ihr Projekt passt? Im kostenlosen Erstgespräch schauen wir uns das ehrlich an.