janraap.de auf Nuxt 4

Diese Fallstudie beschreibt den Wechsel meiner eigenen Website von Nuxt 4 zu Grav 2. Sie lief bis September 2026 zweisprachig: 98 Markdown-Dateien im Inhaltsordner, Deutsch ohne Präfix, Englisch unter /en/. Gebaut habe ich sie auch deshalb, weil ich einen Stack im eigenen Projekt kennen will, bevor ich ihn jemandem anbiete.

Der Umweg über Cwicly

Vor Nuxt lief bei mir längst ein Migrationsprojekt. Die alte Website steckte in WordPress, und der Neubau sollte mit Cwicly entstehen, einem Gutenberg-Builder, der ab November 2021 als der weitest entwickelte seiner Art galt. Ich hatte mich eingearbeitet, Vorlagen gebaut und auf dieses Werkzeug gesetzt.

Am 3. März 2024 kündigte der Entwickler im eigenen Forum die Einstellung an und begründete sie öffentlich mit Angriffen aus der WordPress-Szene. Erstattet wurde nur, wer ab dem 1. Januar 2024 gekauft hatte. Forum und Facebook-Gruppe gingen auf read-only, die Erklärung verschwand später wieder von der Website, die Community sammelte sich in einer inoffiziellen Gruppe. Im Juli 2024 gab es die Kehrtwende: Das Plugin wurde kostenlos. Quelloffen wurde es nie, im WordPress-Verzeichnis steht es bis heute nicht. Übrig ist eine eingefrorene Version 1.4.4 ohne Forum.

Meine Arbeit steckte damit in einem Werkzeug ohne Zukunft, und meine Inhalte in einem Blockformat, das ohne dieses Werkzeug niemand mehr sinnvoll öffnet. Die Lehre war nicht, dass das Plugin schlecht gewesen wäre. Es war technisch stark. Die Lehre war, dass ich meine eigene Website an ein geschlossenes Produkt gehängt hatte, dessen Weiterbestand an einem kleinen Team hing. Danach wollte ich zwei Dinge: Inhalte, die auch ohne das System noch lesbarer Text sind, und einen Stack, den ich selbst zusammensetze. So bin ich bei Markdown und Nuxt 4 gelandet.

Warum die Wahl auf Nuxt fiel

Nuxt rendert Seiten auf dem Server und übergibt sie im Browser an Vue. Das ergibt Adressen, die Suchmaschinen lesen können, und Komponenten, die sich wie eine Anwendung verhalten. Für eine Seite mit Preisrechner, Sprachumschalter und Kartenrastern passte das.

Was ich mir selbst gebaut habe

Damit die Seite lief, mussten drei Erweiterungen zusammenspielen: Nuxt Content für die Inhalte, Nuxt i18n für die Sprachen, Nuxt SEO für Sitemap, Canonicals und hreflang. Jede davon ist für sich gut gebaut. Die Arbeit entsteht an den Nähten, und die Nähte waren mein Teil.

Nuxt Content kennt in Version 3 keine Sprachen. Der Vorschlag für eingebaute Mehrsprachigkeit liegt seit März 2026 als offener Pull Request im Projekt. Bis dahin galt der Behelf, den ich mir zurechtgelegt habe: Jede Sammlung existiert zweimal, referenzen und references, projekte und projects, pakete und plans. Welche deutsche Datei zu welcher englischen gehört, stand in zwei selbst erfundenen Frontmatter-Feldern, slugde und slugen. Aus diesen beiden Feldern baute eine eigene Schnittstelle die Sprachpaare für die Sitemap, sortierte Doppelte aus und setzte x-default von Hand, gut siebzig Zeilen. Das hat funktioniert. Es war aber Code, den ich selbst schreiben, selbst prüfen und nach jedem Update selbst nachziehen musste.

Dazu kam der Schrägstrich am Adressende, gepflegt in vier Konfigurationen, die verschiedenen Modulen gehören. Wer eine davon vergisst, merkt es erst an den Adressen, die Google findet: Vierzehn meiner alten Weiterleitungen zeigten auf Ziele mit Sprungmarke und Schrägstrich, etwa /leistungen/webdesign/#wartung-support/, sieben davon führt Google bis heute als eigene Treffer. Beim Umzug musste die neue Seite deshalb dieselben Sprungmarken tragen, sonst wären die Treffer ins Leere gelaufen.

Behoben wurde in diesem Bereich viel, und zwar fortlaufend. Genau das war das Problem: Jeder Fix bedeutete ein Update, ein Update bedeutete Nachbau meiner Umgehungen und eine Runde Nachmessen.

Warum meine Seite heute auf Grav läuft

Im September 2026 bin ich auf Grav umgezogen: 76 Seiten neu aufgebaut, 42 Weiterleitungsregeln für die alten Adressen, der englische Zweig mit seinen vierzig Dateien ist dabei entfallen, weil es keine Verweise darauf gab. Grav liest Markdown direkt aus dem Verzeichnis, rendert mit Twig und braucht keinen Build. Für eine Seite, die ich selbst pflege und an der ich täglich Kleinigkeiten ändere, ist das die ruhigere Wahl.

Hell Dunkel

Was von Nuxt bleibt

Reichlich, und Nuxt bleibt in meinem Angebot. Wenn eine Seite mehr können muss als zeigen und verlinken, wenn es um Zustand, Formularlogik und echte Interaktion geht, ist sie dort richtig: Frontend-Entwicklung mit Vue und Nuxt buchen Agenturen bei mir weiterhin.

Tailwind setze ich in eigenen Projekten nicht mehr ein. Der Grund steht in meinen eigenen Notizen aus dem Nuxt-Projekt: Klassennamen mit Tippfehler fallen stillschweigend durch, kein Fehler in der Konsole, kein Warnhinweis im Build, die Seite sieht nur falsch aus. Diese Fehlerklasse kostet mich mehr Suchzeit als das Schreiben von CSS. In Agenturprojekten arbeite ich weiter damit, wenn der Stack es vorgibt.

Was ich mitnehme

• Das Werkzeug darf verschwinden, die Inhalte nicht. Markdown im Dateisystem übersteht den Umzug, Blöcke aus einem eingestellten Builder nicht.
• Wer drei Erweiterungen kombiniert, pflegt die Nähte zwischen ihnen, und diese Pflege steht in keiner Featureliste. Sie ist die eigentliche Arbeit.
• Mehrsprachigkeit gehört in die Grundentscheidung für ein System, weil ich sie sonst ein zweites Mal daneben baue, in eigenen Feldern und eigenem Code.
• Fixes sind nur dann ein Gewinn, wenn das Projekt sie auch einspielen kann. Zwei Hauptversionen im Jahr sind Aufwand, kein Fortschritt.
• Herausgefunden habe ich das am eigenen Projekt, auf eigene Rechnung.