Lange Zeit kam ich mit einer einseitigen Lebenslauf-Website aus. Als die Projekte sich häuften, war kein Platz mehr, sie zu präsentieren, und die Seite spiegelte nicht mehr die Arbeit wider, die ich tatsächlich mache. Dieser Beitrag ist eine kurze Zusammenfassung der Entscheidungen, die ich beim Neuaufbau von Grund auf getroffen habe.
Warum statischer Export?
Die Seite liegt auf klassischem Shared Hosting ohne Node.js-Laufzeitumgebung. Der output: "export"-Modus von Next.js ist genau für dieses Szenario gemacht: npm run build erzeugt reines HTML, CSS und JavaScript. Die Ausgabe per FTP hochzuladen reicht aus.
Das hat natürlich seinen Preis: keine serverseitigen Funktionen, keine Bildoptimierung, keine API-Routen. Für ein persönliches Portfolio brauche ich davon nichts. Statt eines Kontaktformulars verwende ich einen einfachen E-Mail-Link.
Der zweisprachige Aufbau
Das eingebaute i18n-Routing von Next.js funktioniert nicht mit statischem Export. Die Lösung ist einfach: Die Sprache wird Teil der Route.
app/[locale]/page.tsx → /tr/ und /en/
app/[locale]/projects/... → /tr/projects/ und /en/projects/
generateStaticParams erzeugt die Seiten für alle Sprachen zur Build-Zeit. Die Root-Adresse leitet je nach Browsersprache über eine kleine statische HTML-Datei weiter. Für Suchmaschinen deklariert jede Seite ihre hreflang-Alternativen.
Wo liegt der Inhalt?
Projekt- und Lebenslaufdaten liegen in TypeScript-Dateien, Blogbeiträge in MDX. Es gibt keine Datenbank und kein CMS; Inhalte werden zusammen mit dem Code versioniert. Ein neuer Beitrag bedeutet: eine .mdx-Datei anlegen und einen Build ausführen.
Mein liebster Teil dieses Aufbaus: Die gesamte Seite ist ein Git-Repository. Text, Design und Code laufen durch dieselbe Historie.