Laravel und Statamic für eine große Content-Website: Erfahrungsbericht aus 309 Seiten

Die meisten CMS-Vergleiche drehen sich um Websites mit zwanzig Seiten. Da ist die Wahl fast egal – jedes System schafft das. Interessant wird es erst, wenn eine Website dreistellig wird, wenn Inhalte nicht nur Text sind, sondern Zahlen mit einem Prüfdatum, und wenn ein Rechner auf der Seite ein Ergebnis ausspuckt, für das jemand geradesteht. Genau an dem Punkt haben wir für unser eigenes Projekt Statamic auf Laravel gewählt – und dabei ein paar Dinge gelernt, die in keinem Feature-Vergleich stehen.

Kurz gesagt: Statamic auf Laravel lohnt sich für große Content-Websites dann, wenn neben den Texten eigene Fachlogik läuft – Rechner, strukturierte Anbieterdaten, geprüfte Zahlen. Für eine reine Textseite ist der Aufwand nicht gerechtfertigt. Der anspruchsvolle Teil ist nie das Redigieren, sondern das Datenmodell dahinter.

Das Projekt: 309 Seiten, 14 Rechner, 26 Anbieterprofile

Damit klar ist, worüber ich rede: Das Beispiel in diesem Artikel ist Viovenia Direkt, unser eigenes Ratgeberprojekt zu gesetzlicher und privater Krankenversicherung und zu Finanzthemen. Es ist unsere Seite, kein Kundenprojekt – deshalb kann ich offen über die Entscheidungen und die Fehltritte schreiben.

Die Größenordnung in Zahlen:

Verteilt sind die Seiten auf gesetzliche Krankenversicherung (149), Finanzen (61), ein Glossar mit 37 Begriffen, private Krankenversicherung (33) und die 14 Rechnerseiten – dazu Rechts- und Redaktionsseiten. Der Stack ist bewusst schlank: Statamic auf Laravel, Assets über Vite, Interaktion über Alpine.js, Styling mit Tailwind CSS. Kein Livewire, kein Inertia, keine SPA. Jede Seite wird auf dem Server gerendert und geht als fertiges HTML raus.

Warum überhaupt Laravel als Unterbau? Weil ein Teil der Seite eben keine Redaktion ist, sondern Software: Rechner mit jährlich wechselnden Parametern, ein Anbietervergleich mit Prüfständen, ein Änderungsprotokoll. Das sind Dinge, die man in einem klassischen CMS über Plugins zusammenstückeln müsste. In Laravel schreibt man sie einfach – die ausführliche Begründung, warum wir bei nicht-trivialen Projekten fast immer dort landen, steht in Warum wir auf Laravel setzen.

Die wichtigste Entscheidung: Wo endet der Text und wo beginnt der Datensatz?

Das ist die Frage, an der große Content-Projekte scheitern – und sie fällt in Woche eins, nicht in Monat sechs.

Ein Ratgebertext ist ein CMS-Eintrag: Überschrift, Fließtext, ein paar Abschnitte, eine Kategorie. Dafür sind Statamics Collections, Taxonomien und Blueprints gemacht, und dafür funktionieren sie hervorragend. Ein Anbieterprofil ist etwas völlig anderes. 26 Krankenkassen mit jeweils Zusatzbeitrag, Zusatzleistungen und Servicebewertung sind kein Text – das ist eine Tabelle mit einem Schema.

Der verlockende Fehler ist, beides gleich zu behandeln: Man legt für jede Kasse eine Seite an und schreibt den Zusatzbeitrag in den Fließtext. Das funktioniert genau so lange, bis jemand fragt: „Zeig mir alle Kassen unter einem bestimmten Zusatzbeitrag." Oder bis sich zum Jahreswechsel zwanzig Beiträge ändern und jemand zwanzig Texte einzeln aufmachen muss. Dann sitzt du in der Falle, und der Weg heraus ist eine Migration.

Die Faustregel, die sich für uns bewährt hat:

• Alles, was man vergleichen, sortieren oder filtern will, ist ein Datenfeld. Auch wenn es nur eine Zahl in einem Satz ist.
• Alles, was ein Mensch am Stück liest, ist ein Eintrag. Der Text darf das Datenfeld anzeigen, aber nicht speichern.
• Ein Wert lebt an genau einer Stelle. Steht der Zusatzbeitrag im Vergleich, im Ratgebertext und im Rechner, hast du drei Wahrheiten und irgendwann drei verschiedene Zahlen.

Diese Trennung ist der eigentliche Unterschied zwischen einer Website mit 30 und einer mit 300 Seiten. Bei 30 Seiten kannst du inkonsistente Daten von Hand aufräumen. Bei 300 nicht mehr.

Ein Prüfdatum je Feld – warum updated_at nicht reicht

Auf unserer Methodik-Seite steht ein Satz, der harmlos klingt und technisch erstaunlich viel Konsequenzen hat: „Der Stand ist der der ältesten Prüfung". Übersetzt heißt das: Wenn eine Vergleichstabelle acht Werte zeigt und sieben davon gestern geprüft wurden, einer aber vor vier Monaten, dann ist der ausgewiesene Stand der von vor vier Monaten. Nicht der freundlichere.

Technisch bedeutet das: Ein Zeitstempel auf Seitenebene reicht nicht. Das übliche updated_at eines Eintrags sagt nur, wann jemand zuletzt gespeichert hat – und das wird auch durch einen korrigierten Tippfehler ausgelöst. Es ist ein Speicherdatum, kein Prüfdatum. Wer damit „Stand: heute" auf eine Seite schreibt, behauptet etwas, das er nicht belegen kann.

Sauber wird es erst, wenn jedes einzelne Datenfeld sein eigenes Prüfdatum trägt und die Anzeige das Minimum daraus bildet. Praktisch heißt das: Neben dem Wert selbst hängen mindestens ein Prüfdatum, die Quelle und wer geprüft hat. Das bläht das Datenmodell auf – ein Feld wird zu einem kleinen Objekt –, aber es ist die einzige Variante, bei der die Angabe auf der Seite auch nach zwei Jahren noch stimmt.

Das ist übrigens ein Punkt, an dem sich klassische CMS und ein Laravel-Unterbau spürbar unterscheiden. In einem CMS mit fixem Beitragsschema baut man so etwas mühsam nach. In einer eigenen Anwendung ist es schlicht eine Tabelle mehr.

Rechenparameter gehören ins Datenmodell, nicht in den Code

Die 14 Rechner sind der Teil, bei dem am meisten schiefgehen kann – vom Kassenwechsel-Rechner über Brutto-Netto 2026 bis zu Abfindung, Baufinanzierung und E-Dienstwagen. Die Eingabe läuft clientseitig über Alpine.js, das ist der unkomplizierte Teil. Der heikle Teil sind die Zahlen dahinter.

Beitragsbemessungsgrenzen, Sozialversicherungssätze, Steuertabellen: Die ändern sich zum Jahreswechsel, jedes Jahr, verlässlich. Wenn diese Werte als Konstanten im Code stehen, passieren zwei Dinge. Erstens braucht jede Anpassung ein Deployment – im Januar, wenn alle anderen auch etwas wollen. Zweitens, und das ist schlimmer: Die alten Werte sind weg. Der Rechner rechnet dann rückwirkend falsch, weil er einen Sachverhalt aus 2025 mit den Sätzen von 2026 bewertet.

Deshalb: Rechenparameter sind Daten, keine Logik. Sie gehören versioniert und mit Gültigkeitszeitraum ins Datenmodell – Wert, gültig ab, gültig bis, Quelle. Der Rechner fragt dann nicht „Wie hoch ist der Satz?", sondern „Wie hoch war der Satz am Stichtag X?". Der Code bleibt stabil, die Zahlen ändern sich, und alte Berechnungen bleiben nachvollziehbar. Jede Rechnerseite bei uns hat aus genau diesem Grund einen eigenen Abschnitt „Berechnungsgrundlage und Datenstand" – der ist keine Deko, der liest die Werte aus, mit denen tatsächlich gerechnet wurde.

Zwei Augenpaare und ein sichtbares Änderungsprotokoll

In unserer Redaktionsleitlinie stehen zwei Regeln, die auf den ersten Blick nach Organisation klingen und in Wahrheit Anforderungen an die Software sind: Schreiben und Prüfen sind zwei getrennte Schritte – und Korrekturen bleiben sichtbar.

Der erste Punkt lässt sich mit Statamic gut abbilden. Revisions und ein Publish-Workflow trennen den Arbeitsstand vom veröffentlichten Stand, sodass eine Änderung erst live geht, wenn sie freigegeben wurde. Wichtig ist dabei weniger die Funktion als die Konsequenz: Sobald es einen zweiten Schritt gibt, muss die Software auch den Zustand „geschrieben, aber noch nicht geprüft" darstellen können – im Backend und in jeder Übersicht, die jemand nutzt, um den Überblick zu behalten.

Der zweite Punkt ist der härtere. Ein Änderungsprotokoll, das öffentlich bleibt, ist keine Frage der Disziplin, sondern eine Frage des Datenmodells. Wenn du Korrekturen im Nachhinein sichtbar machen willst, musst du sie von Anfang an als Datensatz erfassen: Was wurde geändert, wann, warum. Wer das nachträglich einbauen will, stellt fest, dass die interessantesten Änderungen längst überschrieben und damit für immer verloren sind. Das ist eine Entscheidung, die man nur einmal treffen kann – nämlich am Anfang.

Interne Verlinkung, wenn es 300 Seiten sind

Bei 37 Glossarbegriffen und 300 Inhaltsseiten ist von Hand gepflegte interne Verlinkung keine Option. Nicht, weil es zu viel Arbeit wäre, sondern weil sie unweigerlich veraltet: Ein neuer Begriff kommt dazu, und niemand geht durch 300 alte Texte, um ihn nachzutragen.

Der naheliegende Reflex – jedes Vorkommen eines Begriffs automatisch verlinken – ist allerdings genauso falsch. Das Ergebnis ist eine Linkwüste, in der jeder dritte Satz blau ist und niemand mehr klickt. Was in der Praxis trägt:

1. Nur das erste Vorkommen je Seite verlinken. Danach kennt der Leser den Begriff.
2. Eine Obergrenze pro Seite. Ein paar Glossarlinks helfen, zwanzig sind Lärm.
3. Nicht auf sich selbst verlinken. Klingt banal, passiert bei automatischer Verlinkung ständig – die Glossarseite zum Begriff verlinkt sonst fleißig auf sich selbst.
4. Kuratierte Querverweise getrennt halten. Die redaktionell gesetzten „Das könnte dich auch interessieren"-Verweise sind etwas anderes als automatische Begriffserklärungen und sollten sich nicht ins Gehege kommen.

Ganz nebenbei ist das auch der Punkt, an dem sich Struktur und Auffindbarkeit treffen: Eine Seitenarchitektur, die man automatisch verlinken kann, ist meistens auch eine, die Suchmaschinen verstehen. Strukturierte Daten – bei uns JSON-LD für Organization, WebSite und FAQPage – kommen dann fast von allein, weil die Informationen schon sauber getrennt im Datenmodell liegen und nicht aus Fließtext gefischt werden müssen.

Flat File oder Datenbank – Statamics eigentliche Architekturfrage

Statamic legt Inhalte standardmäßig als Dateien ab, nicht in einer Datenbank. Das ist ein echter Vorteil: Inhalte liegen im Repository, Änderungen sind versioniert, ein Deployment bringt Code und Inhalt gemeinsam mit, und lokale Entwicklung braucht keinen Datenbank-Dump.

Für Ratgebertexte ist das ideal. Für strukturierte Daten wird es ab einer bestimmten Größe unhandlich – nicht weil es nicht funktioniert, sondern weil du irgendwann Dinge willst, für die eine Datenbank gebaut ist: sortieren, filtern, aggregieren, Beziehungen zwischen Datensätzen. Statamic lässt dir hier bewusst die Wahl und kann Inhalte auch über Eloquent in der Datenbank verwalten.

Die eigentliche Frage ist aber eine organisatorische: Wer ändert was, und wo landet die Änderung? Wenn Inhalte im Repository liegen, ist eine Redaktionsänderung ein Commit – das ist wunderbar nachvollziehbar, kollidiert aber mit dem Wunsch, mal eben eine Zahl zu korrigieren, ohne ein Deployment auszulösen. Unsere Aufteilung: redaktioneller Text als Datei, strukturierte und häufig aktualisierte Daten in der Datenbank. Damit bleibt der Redaktionsalltag frei von Technik, und die Inhalte, die selten wechseln, behalten ihre Git-Historie.

Wer die Abwägung „CMS-Datenhaltung vs. eigene Anwendung" grundsätzlicher lesen will, findet sie in Headless CMS vs. WordPress – die Argumente sind dieselben, nur eine Ebene abstrakter.

Performance: ehrlich bleiben

Ein Punkt, bei dem ich nicht schönreden will. Server-gerenderte Seiten mit umfangreicher Navigation, langen Ratgebertexten, Vergleichstabellen und Rechnern sind schlicht große Seiten. Das ändert kein Framework.

Was hilft, ist unspektakulär und wirkt trotzdem am stärksten:

• Statisches Caching. Statamic kann fertige Seiten ausliefern, statt sie bei jedem Aufruf neu zu bauen. Bei einer Content-Seite, die sich täglich ändert und stündlich tausendfach gelesen wird, ist das der größte Hebel überhaupt.
• Bilder als Hauptthema behandeln. In der Praxis stecken die meisten überflüssigen Kilobytes nicht im JavaScript, sondern in Bildern in falscher Größe und falschem Format.
• Alpine.js statt SPA. Ein Rechner braucht Interaktivität, eine Ratgeberseite nicht. Alpine bringt die paar Kilobyte mit, die für ein Eingabeformular reichen, und lässt den Rest der Seite in Ruhe. Für einen Klick auf „Berechnen" ein komplettes Frontend-Framework auszuliefern, wäre schlicht Verschwendung.

Die Messlatte sind am Ende die Core Web Vitals, und die sind bei textlastigen Seiten überraschend gut erreichbar – vorausgesetzt, man liefert nicht mehr aus als nötig. Was dabei konkret zu tun ist, haben wir in Core Web Vitals verbessern aufgeschrieben.

Wann sich Statamic auf Laravel lohnt – und wann nicht

Ehrliche Entscheidungshilfe, ohne Werbeblock:

Dafür spricht, wenn deine Website neben Inhalten auch eigene Logik braucht: Rechner, Vergleiche, strukturierte Datensätze, Prüfstände, Schnittstellen zu anderen Systemen. Dann bekommst du ein ordentliches CMS und eine echte Anwendung im selben Projekt, ohne zwei Systeme zusammenzukleben. Auch wenn dir Inhalte im Git-Repository wichtig sind, ist Statamic stark.

Dagegen spricht, wenn deine Seite im Kern aus Texten und Bildern besteht und absehbar auch dabei bleibt. Dann bezahlst du für Möglichkeiten, die du nie nutzt, und brauchst für jede Änderung jemanden mit Laravel-Kenntnissen. Ebenso, wenn im Unternehmen niemand ist, der die Anwendung langfristig pflegen kann – ein Laravel-Projekt will gewartet werden.

Der Punkt, an dem es kippt, liegt in unserer Erfahrung nicht bei der Seitenzahl, sondern beim ersten Satz „Können wir das nicht automatisch berechnen?". Ab da ist es keine Website mehr, sondern eine Anwendung mit Inhalten.

Fazit

Die spannende Arbeit an einer großen Content-Website steckt nicht im CMS. Statamic macht seinen Job unauffällig gut – Collections, Blueprints, Revisions, statisches Caching, alles da. Anspruchsvoll ist die Ebene darunter: die Grenze zwischen Text und Datensatz, Prüfdaten je Feld, versionierte Rechengrößen, Änderungen, die man später noch nachvollziehen kann. Das sind Entscheidungen, die man am Anfang trifft und später nur unter Schmerzen korrigiert. Laravel ist dabei nicht der Grund, warum es funktioniert – aber der Grund, warum man diese Dinge überhaupt sauber bauen kann, statt sie um ein System herumzuwursteln.

Du stehst gerade vor einer Website, die aus dem Rahmen eines normalen CMS herauswächst – viele Seiten, strukturierte Daten, vielleicht ein Rechner oder ein Vergleich? Wir schauen als Laravel-Agentur gern gemeinsam drauf, bevor du dich auf ein System festlegst. Im kostenlosen Erstgespräch klären wir die Fragen, die später teuer werden: Was ist bei euch Text, was ist Datensatz, was ändert sich jedes Jahr – und braucht ihr dafür wirklich einen Laravel-Unterbau oder tut es ein einfacheres System? Wenn Letzteres, sagen wir dir das genauso deutlich. Melde dich einfach, unverbindlich und ohne Verkaufsdruck.

Häufige Fragen