Unsere Firmenwebsite lief jahrelang auf WordPress mit dem Divi Theme. Es funktionierte. Seiten luden, das Kontaktformular verschickte Mails, der Blog hatte Beiträge. Aber jedes Mal, wenn ich PageSpeed Insights öffnete, wurden die Zahlen unangenehm. CLS von 0,81. Ein Seitengewicht, das für eine Seite, die hauptsächlich aus Text und ein paar Bildern besteht, keinen Grund hatte, so groß zu sein.
Also haben wir die Seite abgerissen und mit Kronk CMS auf Hugo neu gebaut.
Warum Kronk und Hugo
Ich wollte eine statische Seite. Keine Datenbank, kein PHP, keine Plugin-Updates, keine Sicherheitspatches für ein CMS, das ich als besseren Texteditor benutze. Hugo baut die komplette Seite in unter zwei Sekunden. Das Ergebnis ist reines HTML, CSS und ein bisschen JavaScript. Caddy liefert es aus. Es gibt nichts zu hacken, weil nichts läuft.
Aber Hugo allein ist ein Build-Tool, kein Content-Management-System. Es kennt keine SEO-Regeln, keine Accessibility-Vorgaben, und es kann einen AI Coding Agent nicht davon abhalten, beim Template-Bearbeiten die Seite zu zerschießen. Genau dafür ist Kronk da. kronk init hat das Hugo-Projekt erkannt, Guardrail-Dateien angelegt, die Claude Code automatisch lädt, und uns Qualitätschecks für Titellängen, Heading-Struktur, Alt-Texte, Kontrast und ein Dutzend andere Dinge gegeben, die man bei 77 Seiten leicht falsch machen kann.
Die Migration selbst begann mit kronk migrate wordpress. Das Tool hat den XML-Export gezogen, die Divi-Shortcodes entfernt, nach Markdown konvertiert und die Bildpfade gemappt. Einige Seiten brauchten manuelle Nacharbeit, weil Divi jeden Absatz in drei verschachtelte Divs gewickelt hatte, ohne dass irgendjemand erklären konnte, warum. Aber der Großteil der Konvertierung lief automatisch.
Der andere Grund war die Zweisprachigkeit. Unsere Seite läuft auf Deutsch und Englisch. WordPress hat das mit einem Übersetzungs-Plugin gehandhabt, das bei jedem Seitenaufruf Overhead erzeugte und alle paar Monate auf kreative Art und Weise kaputt ging. Hugo hat eingebaute Mehrsprachigkeit. Zwei Content-Verzeichnisse, eine Konfigurationsdatei, fertig.
77 Seiten, null fehlende URLs
Die Migration umfasste 77 Seiten. Jede URL der alten Seite funktioniert weiterhin - gleiche Pfade, gleiche Slugs, keine Redirects nötig. Ich habe mehr Zeit für die URL-Parität aufgewendet als für das eigentliche Design. Einen Redirect falsch zu setzen bedeutet einen toten Link in jemandes Lesezeichen oder ein Suchergebnis, das ins Leere führt. Das Risiko lohnt sich nicht.
Die Zahlen
Vorher und nachher, gleiche Seiten, gleicher Content:
- CLS: 0,81 auf 0. Die alte Seite hatte Layout Shifts durch ladende Web Fonts, durch Bilder ohne Maßangaben, durch Divis JavaScript, das nach dem Laden das DOM umbaute. Hugo liefert das fertige HTML aus. Nichts bewegt sich.
- Seitengewicht: ungefähr halbiert. Hauptsächlich durch den Wegfall von jQuery, Divis Framework-JavaScript und die Konvertierung der Bilder zu WebP über Hugos Asset Pipeline.
- Time to First Byte: von 400-600ms (WordPress mit MySQL-Abfrage, PHP-Ausführung, Seitenaufbau) auf unter 50ms (Caddy liefert eine statische Datei von der Festplatte).
Die Seite sieht gleich aus. Das war Absicht. Wir haben die visuelle Identität nicht neu gestaltet. Gleiches Layout, gleiche Farben, gleiche Struktur. Die Änderung steckt unter der Haube.
Was ich anders machen würde
Ich habe das Kontaktformular unterschätzt. WordPress hat Contact Form 7. Hugo hat nichts, weil es ein Static Site Generator ist. Am Ende habe ich einen kleinen Endpoint geschrieben, der den Form-POST empfängt, ein Cloudflare Turnstile Token validiert und die Mail verschickt. Es funktioniert, aber es hat länger gedauert als erwartet, weil ich den Spam-Schutz von Grund auf selbst bauen musste, anstatt ein Plugin zu installieren.
Ich habe auch zu lange am Cookie-Consent-Banner gesessen. Die alte Seite nutzte ein WordPress-Plugin. Die neue Seite verwendet eine schlanke Consent-Lösung, die GTM und Chatwoot erst nach einem expliziten Opt-in freigibt. Das Timing so hinzubekommen, dass Analytics erst nach Consent lädt, die Seite dabei aber nicht flackert oder springt, hat mehrere Iterationen gebraucht.
Der Blog, den ihr gerade lest
Dieser Blog läuft auf der gleichen Hugo-Instanz, verwaltet über Kronk. Markdown-Dateien in einem Content-Verzeichnis, ein Reading-Progress-Balken, verwandte Beiträge unten, Social Cards beim Build generiert. Einen Beitrag zu schreiben bedeutet, eine .md-Datei anzulegen und auf den Production Branch zu pushen. Kein WordPress-Editor, kein Browser, kein Login. Kronks Guardrails fangen SEO- und Accessibility-Fehler ab, bevor der Push rausgeht.
Der Quellcode ist versioniert. Jede Änderung hat eine Commit Message. Ich kann zwei Versionen einer Seite genauso diffen wie Code. Für ein Unternehmen, das Software baut, macht es einfach Sinn, die Website im selben Workflow zu haben wie alles andere.
Falls ihr darüber nachdenkt, von WordPress wegzugehen und eure Seite hauptsächlich Content ist - keine Webanwendung, kein Online-Shop, einfach Seiten und ein Blog - dann schaut euch Kronk an. Es übernimmt den CMS-Teil, damit Hugo das tun kann, was es am besten kann: schnell bauen.