Als ich vor einiger Zeit KleinSite gebaut habe – eine schlanke, dateibasierte Content-Engine, die Markdown und Twig-Templates verarbeitet – war das genau das, was ich brauchte: kein CMS-Overhead, volle Kontrolle, schnell gebaut. Für eine Handvoll Artikel funktionierte das gut. Aber irgendwann kippt jedes selbstgebaute System von “praktisch” zu “Baustelle”, und genau da war ich mit KleinSite angekommen.
Der eigentliche Auslöser war keine technische Grenze
Man könnte die Geschichte technisch erzählen: KleinSite konnte dies nicht, jenes nicht, also musste ein Wechsel her. Das wäre aber nicht ehrlich. Die eigentliche Frage war eine andere: Will ich meine Zeit in die Pflege einer eigenen Content-Engine stecken – oder in Content selbst?
Als Software-Entwickler ist die Versuchung groß, jedes fehlende Feature als Gelegenheit zum Weiterbauen zu sehen. Genau das wollte ich diesmal nicht. markob.de soll in erster Linie ein Publishing-Werkzeug sein, kein Nebenprojekt, das mir Zeit vom eigentlichen Schreiben abzieht. Diese Priorisierung – Fokus auf Publishing statt auf Tooling-Perfektion – war am Ende die eigentliche Entscheidung. Hugo war nur die logische Konsequenz daraus.
Warum Hugo
Sobald feststand, dass ich nicht selbst weiterbauen wollte, lag der Blick auf etablierte Static-Site-Generatoren nahe. Hugo hat sich für mich vor allem über zwei Dinge durchgesetzt: Reife und Geschwindigkeit. Kein Rumbasteln an Rendering-Performance, keine Sorge, ob ein Community-Projekt in zwei Jahren noch gepflegt wird. Entscheidend war dabei auch, dass ich meine vorhandenen Markdown-Inhalte weitgehend übernehmen konnte und den kompletten Build ohne zusätzliche Laufzeitumgebung – Hugo kommt als einzelne ausführbare Datei – sauber in die GitLab-CI-Pipeline einbinden ließ.
Für die Evaluation habe ich KI-Tools gezielt für schnelle Machbarkeitschecks eingesetzt – “Kann Hugo dies?”, “Unterstützt Hugo das?” – und so in kurzer Zeit ein realistisches Bild bekommen, ohne mich durch endlose Dokumentation zu graben. Das hat die Vorauswahl deutlich beschleunigt, ersetzt aber nicht den eigentlichen Blick in den Code und die Doku, wenn es konkret wird.
Migration: mehr redaktionelle Arbeit als technischer Umzug
Der aufwendigste Teil der Migration war nicht das Theme – dazu gleich mehr – sondern etwas, das ich vorher unterschätzt hatte: Ich habe jeden einzelnen Artikel noch einmal angefasst. Gelesen, das Frontmatter angepasst, teilweise Kleinigkeiten korrigiert. Statt die Markdown-Dateien einfach per Skript von A nach B zu kopieren, habe ich jeden Artikel bewusst noch einmal durchgesehen.
Im Rückblick war das kein Umweg, sondern ein Gewinn: Eine Migration ist eine seltene Gelegenheit, das eigene Archiv noch einmal bewusst durchzugehen. Man sieht, welche Artikel noch tragen, wo Metadaten fehlen oder inkonsistent sind, was inhaltlich nachgeschärft werden könnte. Wer nur technisch migriert, verschenkt diesen Nebeneffekt.
Der zweite große Brocken war das Theme: teilweise klassisches Pixelschieben, teilweise die Übertragung der Templating-Logik von Twig auf Hugos Template-System. Kein Hexenwerk, aber Detailarbeit, die Zeit braucht, wenn man es richtig machen will.
Der eigentliche Komfortgewinn: die GitLab-CI-Pipeline
Wenn ich ehrlich bin, ist der Teil, der sich im Alltag am meisten auszahlt, nicht Hugo selbst, sondern die Automatisierung drumherum. Vorher: Artikel schreiben, Build lokal anstoßen, FTP-Client öffnen, Dateien hochladen, hoffen, dass nichts vergessen wurde. Jetzt: git push, fertig. Die GitLab-CI-Pipeline übernimmt Build und Deployment automatisch.
Natürlich hätte ich eine solche Pipeline auch für KleinSite bauen können – technisch spricht nichts dagegen. Der Unterschied ist, dass das wieder zusätzliche Infrastruktur gewesen wäre, die ich selbst hätte entwickeln und dauerhaft pflegen müssen. Bei Hugo ist der Build-Schritt bereits ein gelöstes Problem, ich musste nur noch die Pipeline drumherum bauen, nicht auch noch den Generator selbst.
Das klingt nach einer Kleinigkeit, ist es aber nicht. Jede Reibung zwischen “ich habe eine Idee” und “der Artikel ist online” ist eine Gelegenheit, den Artikel doch nicht zu schreiben. Weniger Reibung heißt mehr Publizieren – und genau darum ging es bei der ganzen Umstellung ursprünglich.
Fazit
Technisch war der Wechsel unspektakulär – Static-Site-Generatoren sind ein gelöstes Problem. Geblieben sind davon vor allem drei Dinge: ein aufgeräumtes Archiv, weil ich jeden Artikel noch einmal bewusst durchgesehen habe; eine Pipeline, die Publizieren auf git push reduziert; und ein Werkzeug mehr im Kasten, denn Hugo war für mich Neuland – markob.de war mein erstes Projekt damit.
Der stärkste Gedanke bleibt aber der aus dem zweiten Abschnitt: Eine selbst entwickelte Lösung kann technisch weiterhin funktionieren und trotzdem nicht mehr die richtige sein, wenn ihre Pflege vom eigentlichen Ziel ablenkt.