Laravel oder WordPress? Entscheidungshilfe für den Mittelstand

Wenn du diesen Artikel liest, hast du wahrscheinlich die falsche Frage gestellt.

„Laravel oder WordPress?” ist keine technische Frage. Es ist eine Projekt-Frage, die als technische Frage getarnt ist. Und die Antwort hängt fast nie davon ab, welche der beiden Technologien „besser” ist – sondern davon, was du eigentlich vorhast.

Wir bauen seit über 20 Jahren beides. WordPress-Sites, WooCommerce-Shops, Custom-Plugins. Laravel-Webanwendungen, Multi-Tenant-Plattformen, APIs. Manchmal beides für denselben Kunden. Dieser Artikel ist die Entscheidungshilfe, die wir uns selbst gegeben hätten, bevor wir den ersten Pitch erlebt haben.

Kurz vorweg: Wir haben kein Interesse daran, dir eine Technologie aufzudrücken. Wir verdienen Geld mit beiden. Was wir nicht ausstehen können, sind teure Fehlentscheidungen.

Die zwei Klassen von Web-Projekten

Bevor wir über Tech reden, sortieren wir die Frage richtig ein. Praktisch jedes Web-Projekt fällt in eine von zwei Klassen.

Klasse A: Eine Site mit Inhalten und Standard-Funktionen.

Eine Marketing-Website, ein Blog, ein Karriere-Portal, ein Shop mit überschaubaren Anforderungen. Die Logik ist gut verstanden: Inhalte erstellen, Inhalte zeigen, Formulare absenden, vielleicht etwas verkaufen. Niemand baut hier ein neues Bezahlsystem oder eine neue Buchungs-Engine. Es geht darum, etabliertes Verhalten gut umzusetzen.

Klasse B: Eine Anwendung mit Custom-Logik und Workflow.

Ein Kundenportal mit individuellen Rechte-Strukturen. Eine Buchungsplattform, die mit einem internen System spricht. Ein Konfigurator, der aus 47 Parametern ein Angebot baut. Eine Multi-Tenant-Lösung, bei der jeder Mandant seine eigene Datenwelt hat. Hier ist die Frage nicht „wie zeigen wir Inhalte” – sondern „wie modellieren wir die Geschäftslogik sauber”.

Wenn dein Projekt eindeutig in Klasse A fällt: WordPress ist fast immer die richtige Antwort. Wenn es eindeutig in Klasse B fällt: Laravel oder ein anderes Framework. Schwierig wird’s, wenn das Projekt irgendwo dazwischen liegt – und das ist überraschend oft der Fall.

Das Entscheidungs-Framework: drei Heuristiken

Statt eines Pro-Contra-Listings hier drei Wenn-Dann-Regeln, die du in 5 Minuten durchgehen kannst. Wenn zwei der drei klar in eine Richtung zeigen, hast du eine belastbare Antwort.

Heuristik 1: Wer pflegt die Inhalte?

Frag dich: Wer wird nach dem Launch täglich oder wöchentlich Inhalte ändern?

Redakteure, Marketing-Leute, Geschäftsführer ohne Code-Kenntnisse → WordPress. Punkt.
Niemand, weil die Anwendung dynamisch aus Daten gespeist wird → Laravel ist möglich.
Entwickler, die ohnehin Code anfassen → entweder, oft ohne Unterschied.

Die meisten Mittelstands-Sites scheitern langfristig an genau diesem Punkt. Sie werden auf einer Tech aufgesetzt, die das Redaktionsteam nicht bedienen kann. Folge: jede Änderung wird zur Agentur-Anfrage, die Site veraltet, das Vertrauen in die Investition bröckelt.

WordPress ist nicht „besser” als Laravel. WordPress ist gebaut für Inhalts-Pflege durch Nicht-Techniker. Laravel ist gebaut für Entwickler, die saubere Anwendungslogik brauchen. Wer das verwechselt, zahlt drauf.

Heuristik 2: Wie zentral ist Custom-Logik?

Frag dich: Was ist das Herz deines Projekts?

Inhalte zeigen, Standard-Shop, übliches Tracking, normales Lead-Formular → WordPress, eventuell mit Plugin.
Custom-Berechnungen, Workflows, eigene Datenmodelle, Schnittstellen zu internen Systemen → Laravel.
Beides, mit klarem Schwerpunkt auf Inhalt → WordPress mit Custom-Plugin.
Beides, mit klarem Schwerpunkt auf Logik → Laravel mit Inhalts-Modul.

Hier wird’s konkret. Ein paar reale Beispiele aus unseren Projekten:

Tekath Headhunting wollte 130 Stellenanzeigen automatisch aus HR4You importieren, mit Custom-Filterlogik über 9 hierarchische Stellenkategorien, zweisprachig DE/EN. Klingt nach Custom-Logik. Ist es auch. Aber: Das Marketing-Team von Tekath pflegt die Karriere-Inhalte und das Employer Branding selbst. Die Schnittstelle ist eine abgekoppelte Komponente, die im Hintergrund läuft. Antwort: WordPress mit Custom-Schnittstelle.

Die Vulkaneifel-Therme wollte einen Online-Shop, der drei Produktarten verkauft (Reservierungen, Service-Gutscheine, Wertgutscheine), mit Live-Anbindung an das interne Kassensystem über TCP-Sockets und eigener VRPay-Integration. Klingt nach Inhalts-Pflege. Ist es nicht. Das Herz ist die Reservierungs- und Buchungslogik. Antwort: Laravel von Grund auf.

Rentlytics ist eine Plattform, die Mietspiegelrechner für mehrere Kommunen unter eigener Subdomain bereitstellt. Multi-Tenant, eigene Modul-Architektur, iframe-fähige Web Components. Hier gibt es keine „Redaktion”. Es gibt eine Engineering-Aufgabe. Antwort: Laravel mit eigener Plattform-Architektur.

Drei Projekte, drei verschiedene Antworten. Keine ist „richtig” oder „falsch”. Sie passen jeweils zur tatsächlichen Aufgabe.

Heuristik 3: Wo wird das Projekt in 3 Jahren stehen?

Frag dich: Was wächst, was bleibt stabil?

Mehr Inhalte, mehr Marketing-Kampagnen, mehr Landing-Pages → WordPress skaliert problemlos.
Mehr Anwender, mehr Mandanten, mehr Rechte-Stufen, mehr Datenfluss → Laravel skaliert besser.
Eine MVP-Idee, die als Anwendung wachsen soll → Laravel von Anfang an. Migrationen sind teuer.
Eine Marketing-Site, die irgendwann „ein bisschen Anwendung” werden soll → Vorsicht, hier passieren die teuersten Fehler.

Letzter Punkt verdient eine Warnung. Wir haben mehr als einmal Projekte übernommen, die als „WordPress mit ein bisschen Custom” gestartet sind und drei Jahre später in einer unwartbaren Mischung aus Plugin-Hacks, externen Services und improvisierten Workarounds endeten. Wenn du erkennst, dass dein Projekt langfristig Anwendung wird – starte es als Anwendung. Das Geld, das du in den ersten Monaten sparst, zahlst du im dritten Jahr drei- bis fünffach zurück.

Die typischen Fehlentscheidungen

Drei Muster, die wir immer wieder sehen.

„WordPress, weil günstiger”

WordPress ist günstiger im Start. Eine Standard-Site mit 5–10 Seiten kostet 3.000–8.000 €. Wenn die Anforderungen Standard bleiben, bleibt es günstig.

Sobald die Anforderungen nicht-Standard werden, dreht sich das Verhältnis. Ein Custom-WordPress-Plugin kostet schnell 6.000–18.000 € – plus laufende Wartung, weil das Plugin bei jedem WordPress-Major-Update mit-aktualisiert werden muss. Eine vergleichbare Laravel-Komponente kostet ähnlich viel im Bau, ist aber kompakter wartbar.

Faustregel: Wenn du im Briefing schon drei oder mehr „Custom-…”-Punkte hast, ist WordPress vermutlich nicht günstiger – sondern teurer als Laravel.

„Laravel, weil moderner”

Laravel ist nicht moderner als WordPress. Laravel ist ein Framework, WordPress ist ein CMS. Das ist eine Kategorie-Verwechslung. Beide werden aktiv entwickelt, beide haben starke Communities, beide laufen in 2026 produktiv.

„Moderner” ist meist Entwickler-Geschmack, nicht Projekt-Anforderung. Wenn deine Marketing-Site mit Laravel gebaut wird, weil dein Entwickler darauf Lust hatte, zahlst du die Inhalts-Pflege später durch ein eigens gebautes Admin-Panel – das WordPress dir geschenkt hätte.

„Headless WordPress” als Mittelweg

Headless WordPress mit React-, Vue- oder Astro-Frontend wird gern als „das Beste aus beiden Welten” beschrieben. Was du tatsächlich bekommst, hängt stark vom Ausgangspunkt ab.

Der Ansatz: WordPress läuft im Backend als Inhalts-CMS, ein modernes Frontend rendert die Site separat und holt Inhalte über die WP REST API oder WPGraphQL. Vorteil: Du behältst den Redaktions-Workflow von WordPress, gewinnst aber Performance und Flexibilität eines modernen Frontends.

Sinnvoll ist das vor allem dann, wenn du ein etabliertes WordPress-Setup mit umfangreichem Redaktions-Workflow hast und gezielt das Frontend modernisieren willst. Auch wenn Marketing und Tech-Team getrennt arbeiten – Redaktion in WP, Frontend-Engineering in einer eigenen Pipeline – kann der Aufwand gerechtfertigt sein.

Weniger sinnvoll ist es, wenn dein Projekt klein ist oder du keine starke Frontend-Engineering-Kapazität hast. Du betreibst dann effektiv zwei Systeme parallel – WordPress-Backend mit Updates und Plugin-Pflege, plus eine eigene Frontend-Pipeline mit Build, Deployment und Wartung. Wenn die Performance- oder Flexibilitäts-Anforderung das nicht rechtfertigt, fährst du mit klassischem WordPress oder einem vollständig Framework-basierten Setup einfacher.

Was wir konkret empfehlen

Wir nehmen kein Geld dafür, dass wir dich auf eine Technologie festlegen. Im Erstgespräch hören wir uns dein Projekt an und sagen ehrlich, was passt. In den letzten Monaten waren das ungefähr diese Verhältnisse:

Etwa 70 % der Anfragen → WordPress mit Standard- oder Custom-Setup
Etwa 25 % → Laravel-Webanwendung
Etwa 5 % → Multi-Tenant- oder SaaS-Plattform auf Laravel-Basis

Ein paar Beispiele dafür, was wir konkret empfehlen würden:

Projekt	Unsere Empfehlung	Begründung
Unternehmens-Website mit Blog und Karriere-Bereich	WordPress	Inhalts-getrieben, redaktionspflegbar
WooCommerce-Shop mit DATEV-Anbindung	WordPress + Custom-Schnittstelle	Standard-Shop, aber Schnittstelle nötig
Kundenportal mit Login, Dokumenten und Rechnungen	Laravel	Anwendungslogik, keine Inhalts-Pflege
SaaS-MVP für eine neue Geschäftsidee	Laravel	Wachstumspfad, Custom-Logik
Multi-Mandanten-Plattform	Laravel	Architektur-Frage, kein CMS-Job
Personal-Site mit Portfolio	WordPress oder Astro	Beides geht – Astro wenn du selbst tüftelst
Magazin-Site mit redaktionellem Workflow	WordPress	Klassischer WP-Anwendungsfall
Konfigurator-Tool mit komplexer Logik	Laravel	Logik im Vordergrund, Inhalt nebensächlich

Das ist kein Algorithmus. Es ist Erfahrung. Im echten Projekt kommen Faktoren dazu, die in keiner Tabelle stehen: bestehende Infrastruktur, Team-Kenntnisse, Budget-Verlauf über die Jahre, regulatorische Anforderungen.

Kosten ehrlich verglichen

Statt „kommt drauf an” hier konkrete Hausnummern für 2026:

WordPress:

Standard-Unternehmens-Site mit 5–10 Seiten: 3.000–8.000 €
WordPress + Custom-Plugin für ein spezifisches Feature: 6.000–18.000 €
WooCommerce-Shop mit Custom-Anpassungen und Schnittstelle: 10.000–25.000 €
Wartungsvertrag: 80–300 €/Monat

Laravel:

Einfache Webanwendung (1–2 Hauptansichten, Login, eine Datenstruktur): 10.000–25.000 €
Mittlere Webanwendung mit mehreren Modulen: 20.000–60.000 €
Multi-Tenant-Plattform: ab 20.000 €, abhängig von Modulen
Schnittstellen-Heavy-Anwendung mit externen Systemen: 25.000–75.000+ €
Wartungsvertrag: 150–500 €/Monat

Drei Dinge dazu:

Die Spannen sind ehrlich. Wir geben dir nach einem Erstgespräch einen konkreten Punkt innerhalb der Spanne.
Wartung ist kein Luxus. Sicherheit, Updates und kleine Anpassungen kosten in beiden Technologien Geld. Wer das einspart, zahlt es als Notfall-Reparatur dreifach zurück.
„Günstiger” ist ein Trugschluss, wenn die Anforderungen nicht passen. Ein 5.000-€-WordPress-Projekt, das später 15.000 € Workarounds braucht, ist nicht günstig.

Häufige Folgefragen

Können wir später wechseln?

Theoretisch ja. Praktisch ist eine Migration von WordPress zu Laravel oder umgekehrt fast immer ein Neubau. Inhalte lassen sich migrieren, aber Funktionalität wird neu gebaut. Plane besser eine Technologie-Entscheidung pro Jahrzehnt, nicht pro Jahr.

Was, wenn wir beides brauchen?

Geht. Wir haben Kunden, die WordPress als Marketing-Site fahren und parallel eine Laravel-Anwendung als Kundenportal. Wichtig: klare Domain- oder Subdomain-Trennung, keine kreativen Hybride. Beide Systeme leben getrennt, sind aber visuell als eine Marke erkennbar.

Was kostet ein Tech-Audit, bevor wir entscheiden?

500–2.000 €, je nach Umfang. Bei uns bekommst du danach eine Empfehlung schriftlich, inklusive Kosten-Spanne und einer ehrlichen Einschätzung, ob du das Projekt mit uns oder besser mit jemand anderem startest. Manchmal sagen wir „passt nicht zu uns” – das spart allen Beteiligten Zeit.

Wenn du immer noch unsicher bist

Vier Fragen, die du dir kurz selbst beantwortest:

Wer pflegt die Inhalte nach dem Launch?
Was ist die zentrale Funktion – Inhalte zeigen oder Workflow abbilden?
Wo wird das Projekt in drei Jahren stehen?
Gibt es bestehende Systeme, mit denen wir uns verbinden müssen?

Wenn du nach diesen vier Fragen immer noch unschlüssig bist: ruf uns an oder schreib uns. Im Erstgespräch sortieren wir das. Du musst dich nicht entscheiden, bevor du mit uns redest – das ist ja unser Job.