Brauche ich für diesen Blog überhaupt WordPress und Kubernetes? Ein Hugo-Experiment, echte Zahlen und was eine Migration wirklich kostet

Update vom 6. November 2026: Inzwischen ist es entschieden und umgesetzt: Dieser Blog läuft jetzt auf Hugo. Was dabei passiert ist, steht hier.

Kurz gesagt: Dieser Blog besteht im Kern aus Text und Bildern, läuft aber auf Kubernetes mit Datenbank, PHP-Pool, Cache und zehn Plugins. Also habe ich einen Teil davon als statische Seite mit Hugo nachgebaut und beides verglichen. Das Ergebnis hat mich in beide Richtungen überrascht: Für die Leser ist der Tempogewinn kleiner als gedacht, für den Betrieb ist der Gewinn deutlich größer. Entschieden ist nichts. Dieser Blog läuft weiter auf WordPress.

In der Vergangenheit war mir Hugo zu umständlich, zu aufwendig und zu wenig benutzerfreundlich, sowohl in der Nutzung als auch beim Umbau von WordPress. Mit schneller KI-Unterstützung sieht das heute komplett anders aus: Umwandlung, Theme und Prüfskripte für diesen Test entstanden in kurzer Zeit. Deshalb stelle ich mir die Frage jetzt neu.

Dieser Beitrag sammelt alles, was ich vor einer Entscheidung wissen möchte: Messwerte, klar gekennzeichnete Schätzungen, die Folgen für jede Ansible-Rolle, Grafana, SELinux, die Frage nach einem neuen Repository, den echten Aufwand und eine Checkliste für den Fall, dass ich es wirklich mache.

🧒 Für Nicht-ITler: Was ist der Unterschied?

WordPress baut eine Seite, wenn jemand sie aufruft: Ein Programm liest den Text aus einer Datenbank und setzt die Seite zusammen, ein Cache hebt das fertige Ergebnis eine Weile auf. Hugo baut alle Seiten einmal im Voraus auf meinem eigenen Rechner. Der Server gibt danach nur noch fertige Dateien aus. Für einen Besucher läuft kein Programm, es gibt keine Datenbank und keine Login-Seite, die jemand angreifen könnte.

Der Preis: Es gibt keinen bequemen Editor im Browser mehr. Ein Beitrag ist eine Textdatei, und Veröffentlichen heißt bauen und hochladen.

Was man mitnimmt: WordPress ist ein laufendes Programm, das Seiten ausliefert. Hugo ist ein Werkzeug, das Dateien erzeugt. Fast jeder Unterschied in diesem Beitrag folgt daraus.

🧪 Das Experiment: drei Beiträge, alle Seiten, vier Sprachen

Ich habe die drei neuesten Beiträge und alle statischen Seiten auf Englisch, Deutsch, Französisch und Spanisch nach Markdown umgewandelt und ein kleines Theme mit denselben Farben, Schriften und demselben Seitenaufbau geschrieben. Ein Beitrag sieht auf der Platte jetzt so aus:

---
title: 'HTTP/3 für Blog und Nextcloud'
slug: http-3-fur-blog-und-nextcloud
date: '2026-11-03T19:59:27+01:00'
translationKey: wp3277
categories: [DevSecOps]
image: img/2026_11_no_http3.webp
---

**Update vom 4. November 2026:** HTTP/3 ist auf allen meinen Servern wieder aus.

Für Leser verhält sich die Seite gleich: gleiches Menü, Sprachflaggen, Laufband, Slider, Beitragsliste, Seitenleiste, Inhaltsverzeichnis und Suche. Die kleinen Unterschiede sieht man nur im direkten Vergleich. Das Theme ist ein eigener Nachbau und keine Kopie des WordPress-Themes, deshalb weichen einzelne Pixel ab.

Ähnliches Aussehen beweist wenig. Deshalb hat ein Skript jede Seite mit dem Original verglichen:

Der Test hat auch die Fehler gefunden, für die er gedacht ist. Hugo ersetzte tel:-Links in meinem Impressum stillschweigend durch #ZgotmplZ. Monatsarchive in den anderen Sprachen landeten im englischen Pfad. Meine erste Fassung zeigte die Meta-Beschreibung statt des echten Einleitungstextes. Und das Logo war gespiegelt. Den ersten Fehler fand nur das Vergleichsskript; einen Telefon-Link hätte ich nie angeklickt.

Was man mitnimmt: Eine Migration ist nur so gut wie ihr automatischer Vergleich. Eine Seite, die richtig aussieht, kann trotzdem kaputten Inhalt haben.

⚡ Tempo: was ich gemessen habe und was ich nur schätze

Zuerst die Messwerte. Sie liefen von meinem Heimserver gegen den echten Blog, 14 Anfragen pro Zeile, gemessen wurde die Zeit bis zum ersten Byte. Eine statische Datei auf dem Live-Server steht dabei stellvertretend für das, was eine Hugo-Seite liefern würde.

Das ist die Überraschung: Eine gecachte WordPress-Seite ist so schnell wie eine statische Datei. Der Cache macht seine Arbeit bereits. Der Unterschied zeigt sich erst, wenn der Cache nicht greift.

Klarer ist der Gewinn bei der Menge, die ein Browser laden muss, ohne Bilder und Schriften:

Jetzt die Schätzungen. Das sind meine Erwartungen, keine Messungen. Einen echten Browser-Test unter realistischen Bedingungen habe ich noch nicht gemacht.

Was man mitnimmt: Tempo allein würde eine Migration nicht rechtfertigen. Ein gut gecachtes WordPress ist bereits schnell. Leser gewinnen vor allem durch weniger Code zum Herunterladen, am meisten auf dem Handy.

🖥️ Hardware: was der Server wirklich bräuchte

Das sind die heutigen Werte des Blog-Servers und meine Schätzung für eine statische Seite. Grafana und das gesamte Monitoring bleiben in beiden Fällen, weil ich sie behalten will.

Wohin der Speicher heute geht, nach belegtem Speicher pro Prozess. Die Werte überschneiden sich, ihre Summe liegt also über dem echten Verbrauch:

Was man mitnimmt: Die Website selbst bräuchte fast nichts. Das Monitoring wäre mit rund 1 GB der größte Posten auf dem Server und bestimmt dann die Mindestgröße.

📅 Täglicher Aufwand und Patchen

Seit dem 1. September gab es in diesem Repository 256 Commits, 76 davon berührten die drei großen Blog-Rollen. Das ist nicht alles Wartung, denn vieles war Aufbau. Es zeigt aber, wohin die Aufmerksamkeit geht. Der Update-Tag und die zwei PHP-Lücken an einem Tag zeigen gut, was das praktisch bedeutet.

Die Nextclouds bleiben auf K3s, mein Update-Tag verschwindet also nicht. Er wird nur kürzer.

Was man mitnimmt: Das ist der eigentliche Gewinn. Ganze Klassen von Updates, Notfällen und Alarmen verschwinden, weil die Software auf dem Server nicht mehr existiert.

🔐 Sicherheit: eine ehrliche Bewertung

Diese Bewertung ist meine Einschätzung, keine Messung. „Hoch“ bedeutet hier hohes Risiko.

Zwei unbequeme Punkte. Erstens heißt „statisch“ nicht „sicher“: Server, SSH, nginx und DNS brauchen dieselbe Sorgfalt, und meine neun Schutzschichten werden nicht überflüssig. Zweitens ist der Host mit Grafana eben nicht rein statisch. Dort gibt es weiterhin einen Login, und der verdient die größte Aufmerksamkeit.

Was man mitnimmt: Die Angriffsfläche schrumpft deutlich, weil mehrere Angriffsklassen nichts mehr treffen. Die verbleibenden Risiken wandern zum Deploy-Schlüssel und zu Grafana.

🧱 Brauche ich auf dem Blog-Server noch K3s?

Technisch nein. Warum ich es gewählt habe, erklären der K3s-Deep-Dive und der Beitrag zu WordPress auf Kubernetes. Ein einzelnes nginx mit einem Ordner voller Dateien braucht keinen Orchestrator. K3s hat aber Vorteile, die ich wirklich verlieren würde:

Die Nextclouds sind ein anderer Fall: PHP, Collabora, Push und Cron-Jobs sind dort wirklich mehrere zusammenarbeitende Dienste.

Was man mitnimmt: Auf dem Blog rechtfertigt sich K3s nicht mehr durch technische Notwendigkeit, sondern durch Einheitlichkeit, Testen und Lernen. Das sind legitime Gründe, man sollte sie aber ehrlich so nennen.

📝 Welche Daseinsberechtigung WordPress weiterhin hat

Es wäre leicht, WordPress hier abzuschreiben. Das wäre falsch, denn es löst echte Probleme, die Hugo nicht löst:

Das würde aus den heutigen Plugins:

Dazu kommt ein persönlicher Punkt. Die meisten meiner letzten Beiträge entstehen mit KI-Unterstützung, der bequeme Editor zählt für mich also weniger als für die meisten Blogger. Für eine Markdown-Datei und einen Git-Commit wäre die Arbeit mit einem KI-Assistenten sogar einfacher als heute. Abhängig wäre ich trotzdem nicht: Markdown lässt sich mit jedem Texteditor bearbeiten.

Was man mitnimmt: WordPress bleibt die richtige Wahl, wenn andere Menschen schreiben, wenn man unterwegs veröffentlicht oder wenn die Seite mehr tut, als Inhalte anzuzeigen. Das falsche Werkzeug ist es nur, wenn nichts davon zutrifft.

📈 Wie viele WordPress-Seiten, wie viele Hugo-Seiten?

Hugo ist am Markt eine kleine Nische. Laut W3Techs, Stand 5. November 2026:

Diese Zahlen sind mit Vorsicht zu lesen. W3Techs nennt Anteile und keine absoluten Zahlen und erkennt statische Seiten nicht zuverlässig, Hugo ist also vermutlich untererfasst. Sterne messen das Interesse unter Entwicklern, nicht laufende Websites, und das WordPress-Repository ist nur ein Spiegel. Direkt vergleichen sollte man die beiden Werte nicht.

Etwas zeigen die Zahlen trotzdem: Millionen Menschen nutzen WordPress, ohne je ein Git-Repository gesehen zu haben, während Hugo gemessen an seinem Marktanteil eine ungewöhnlich große Anhängerschaft hat. Mein Eindruck, ohne harte Daten: Diesen Weg gehen vor allem die Nerds, und zwar aus Gründen, die zu diesem Beitrag passen: kein PHP, keine Datenbank, kein Login, wenig Angriffsfläche, Markdown und Git statt einer Weboberfläche. Eine schnelle Seite ist ein schöner Nebeneffekt. Bei vielen ist es vermutlich auch einfach die Freude an einem Aufbau, den man ganz versteht.

Was man mitnimmt: WordPress ist der sichere Mainstream mit dem größten Ökosystem, Hugo eine bewusst gewählte Nische. In der Minderheit zu sein ist in keine Richtung ein Argument.

🛡️ Würde SELinux einfacher?

Ja, im Web-Teil deutlich, verschwinden wird es aber nicht. Der SELinux-Deep-Dive zeigt, wie viel Arbeit darin steckt.

Auf FreeBSD stellt sich die Frage ganz anders, denn dort gibt es kein SELinux. An seine Stelle treten Jails und das MAC-Framework.

Was man mitnimmt: Der schwierigste SELinux-Teil, Container samt ihrem Paket, fällt weg. Der Enforcing-Modus bleibt, und auch die Pflicht, die tatsächliche Domäne jedes Dienstes zu prüfen.

📊 Grafana bleibt. Was bedeutet das?

Grafana läuft heute als normaler Systemdienst, ist aber über den K3s-Ingress erreichbar. Das ist die wichtigste Abhängigkeit:

Eine frühere Lehre gilt hier direkt: Entferne ich Metriken und vergesse eine Regel, meldet sie vielleicht nichts mehr und sieht für immer grün aus. Nach einer Migration würde ich deshalb den Zustand jeder Regel prüfen, nicht das Ausbleiben von Mails.

Eine Alternative wäre ein zentrales Grafana zu Hause, das von allen Servern sammelt. Das nähme den letzten Login vom Blog-Host, ist aber eine eigene Entscheidung mit eigenen Risiken.

Was man mitnimmt: Grafana zu behalten ist kein Hindernis. Es bedeutet aber, dass Reverse Proxy, Geo-Filter und ein Login auf dem Host bleiben und dass das Monitoring auf nginx statt auf Pods umgebaut werden muss.

🎭 Die Ansible-Rollen im Einzelnen

Meine erste Annahme war, dass kaum Rollen übrig bleiben. Das war falsch. Die meisten Rollen schützen den Host und nicht WordPress, also bleiben die meisten auch. Das sind die 29 Rollen in blog.yml, mit der Zahl der Zeilen, die sich auf Kubernetes beziehen:

In Zeilen gerechnet, würden von den rund 16.600 Zeilen, die der Blog heute durchläuft, etwa 6.200 dort nicht mehr gebraucht, also 37 %. Nur rund 4.400 davon verschwänden wirklich aus dem Repository, denn den Rest brauchen die Nextclouds. Die Ansible-Tour zum Blog würde zum historischen Dokument.

Natürlich müsste auch einiges neu entstehen:

Was man mitnimmt: Die teuren Rollen fallen weg, die Sicherheitsbasis bleibt. Das ist eine gute Nachricht: Die über Monate aufgebaute Härtung geht mit.

📦 Ein neues Repository?

Mein Repository enthält derzeit beide Stacks. Die gemeinsamen Rollen entscheiden über die Play-Variable stack, und meine Regel lautet, dass jede Änderung für beide funktionieren muss. Ein Umstieg auf Hugo wirft die Frage auf, wie man das aufteilt:

Ich würde Möglichkeit B wählen. Beiträge, Bilder, Theme und Build-Skripte kämen in ein neues Repository. Der Server bleibt im Ansible-Repository mit einem dritten Wert, stack: static. Die Rollen bleiben an einem Ort, und die Härtung muss nicht doppelt gepflegt werden. Zum Veröffentlichen reicht dann ein eingeschränkter Deploy-Schlüssel statt Zugriff auf den Ansible-Code und seinen Vault.

Der Preis ist aber real: Aus der Regel „funktioniert für beide Stacks“ wird „funktioniert für drei“. Umgekehrt verschwinden in vielen Rollen die WordPress-Zweige.

Was man mitnimmt: Inhalt und Infrastruktur ändern sich unterschiedlich schnell und tragen unterschiedliche Geheimnisse, gehören also in getrennte Repositories. Gemeinsame Härtung sollte man nicht kopieren.

🐡 Und auf FreeBSD?

Ich bin seit Jahren von FreeBSD begeistert, auch wenn es neben Linux eher ein Nischendasein führt. Es ist ein komplettes System aus einem Guss, mit sehr guter Dokumentation, Jails, ZFS und pf. Für diesen Blog hatte es trotzdem nie eine Chance, denn K3s hängt an Funktionen des Linux-Kernels und läuft dort nicht produktionsreif.

Genau das ändert Hugo. Ohne K3s, Container, PHP und Datenbank schrumpfen die Anforderungen auf nginx, einen ACME-Client, rsync und das Monitoring, und all das ist auf FreeBSD gewöhnliche Software. Die Komplexität, die mich an Linux gebunden hat, ist weg. Hier alle drei Varianten im Vergleich:

Die entscheidende Frage ist, ob sich dieser Aufbau ähnlich gut absichern lässt wie der heutige. Ich habe das Schicht für Schicht bewertet. Das ist eine Bewertung auf dem Papier: Auf FreeBSD habe ich es weder gebaut noch getestet.

Meine Einschätzung: Ja, für eine statische Seite ließe sich FreeBSD insgesamt ähnlich gut absichern, nur mit anderen Mitteln. Wirklich verlieren würde ich die feine Kontrolle von SELinux pro Prozess. Bei einem WordPress mit PHP und Plugins täte das weh. Bei einem nginx, das aus einer Jail nur lesend Dateien ausliefert, fällt es weit weniger ins Gewicht, weil ein Angreifer dort schlicht viel weniger tun kann. Dafür sind Jails einfach genug, um sie mit bloßem Auge zu prüfen. Die zwei echten Schwachstellen sind Grafana, das weiterhin einen Login braucht, und meine fehlende Praxis: Mein AlmaLinux-Aufbau ist durch Monate echter Fehler gegangen, ein FreeBSD-Aufbau wäre das noch nicht.

Ein offener Punkt: Die Pakete für Grafana, Prometheus, Loki und node_exporter gibt es meines Wissens in den FreeBSD-Ports, Alloy und die aktuellen Versionen müsste ich aber erst prüfen. Andernfalls bräuchte es einen anderen Log-Sammler.

Was man mitnimmt: Der große Gewinn kommt von Hugo, nicht vom Betriebssystem. Aber erst Hugo macht FreeBSD überhaupt möglich: Ist K3s weg, ist die Wahl keine technische mehr. Sie wäre eine Überzeugungsfrage, und für eine statische Seite eine vertretbare.

💶 Kosten und Nutzen

Einen Serverpreis kann ich hier nicht sinnvoll nennen, das hängt vom Anbieter ab. Die Ersparnis ist in jedem Fall überschaubar. Die eigentliche Währung ist hier Aufmerksamkeit.

Was man mitnimmt: Man bezahlt diese Migration nicht mit Geld und bekommt sie auch nicht in Geld zurück. Es ist ein Tausch: Bequemlichkeit beim Schreiben gegen deutlich weniger Betriebsarbeit.

⏱️ Wie viel Arbeit wäre das?

Der Blog hat 143 Beiträge in je vier Sprachen, insgesamt 572, dazu 16 statische Seiten und rund 1.400 Mediendateien. Die folgenden Werte sind Schätzungen. Das Experiment lief mit KI-Unterstützung an etwa einem Abend, die Umwandlung ist also vermutlich der kleinste Teil.

Echte Läufe auf den Produktivservern, die Durchsicht jedes Diffs und die Entscheidungen bleiben bei mir. KI macht das Tippen schneller, nimmt aber nicht die Pflicht zum Prüfen ab.

Was man mitnimmt: Die meiste Arbeit steckt nicht in der Umwandlung, sondern in Ansible, Monitoring und Prüfung. Dort sollte man die Zeit einplanen.

✅ Was ich tun müsste, wenn ich mich für Hugo entscheide

1. Anforderung klären: Kann ich ohne Browser-Editor und Handy-Workflow leben? Ohne diese Antwort ist alles andere egal.
2. Plattform wählen: AlmaLinux als Standard, FreeBSD nur als bewusste Entscheidung.
3. Vollständig sichern: Datenbank, Dateien und Medien. Die WordPress-Installation mehrere Wochen verfügbar halten.
4. Inhalts-Repository anlegen mit Beiträgen, Medien, Theme und festgelegter Hugo-Version. Vor dem ersten Push alles auf Geheimnisse scannen.
5. Alles umwandeln und jede Seite automatisch vergleichen: Text, Code-Blöcke samt Backslashes, Tabellen, Links, Alt-Texte, Titel und Beschreibungen.
6. Jede Adresse behalten: Beiträge, Sprachen, Kategorien, Tags und auch /wp-content/uploads/, weil Bilder von außen verlinkt sind. Gegen die heutige Sitemap vergleichen.
7. Weiterleitungen einrichten: Der RSS-Feed zieht ohne Konfiguration von /feed/ nach /index.xml. Auch ?p=-Links und die alte Suchadresse prüfen.
8. Datenschutzerklärung neu schreiben und das Impressum prüfen. Der heutige Text beschreibt WordPress und seine Plugins. Auch den KI-Hinweis und die Lizenzen aller Downloads prüfen.
9. Theme und SEO fertigstellen, samt Open-Graph-Bildern unter dem WhatsApp-Limit und noindex für die rechtlichen Seiten.
10. Den Ansible-Teil auf einer Test-VM bauen: stack: static, die neue Rolle, die angepassten Rollen. Zweimal laufen lassen; der zweite Lauf muss changed=0 zeigen.
11. SELinux wirklich prüfen: Domänen mit ps -eZ, versteckte Verweigerungen mit semodule -DB und das eigene Log jedes Dienstes.
12. Monitoring umbauen: Grafana hinter nginx mit Geo-Filter und fail2ban, neuer Exporter, alte Regeln entfernen, dann den Zustand jeder Regel prüfen.
13. Den Deploy-Weg absichern: eingeschränkter Schlüssel, atomarer Wechsel, letzte Releases behalten und ein Alarm, wenn der Deploy fehlschlägt.
14. Eine Wiederherstellung testen: einen sauberen Server nur aus den Repositories bauen, bevor Produktion angefasst wird.
15. Alles drumherum anpassen: Backup-Skripte, Prüfung von außen, Update-Check, Drift-Check, Betriebshandbücher in drei Sprachen und ein Hinweis an den älteren Deep Dives.
16. Die Umstellung planen: DNS-TTL senken, ruhige Zeit wählen, Rückweg bereithalten und danach Suchmaschinen und Logs auf 404-Fehler prüfen.
17. Zwei Wochen beobachten und erst dann WordPress und K3s vom Host entfernen.

Was man mitnimmt: Die meisten Punkte haben gar nichts mit Hugo zu tun. Es geht darum, keine Adressen zu verlieren, rechtlich korrekt zu bleiben, das Monitoring zu erhalten und einen Rückweg zu haben.

🌐 Würde HTTP/3 einfacher?

Teilweise. Wie im HTTP/3-Beitrag beschrieben, habe ich es abgeschaltet, weil Verbindungen nach einem Reload hingen. Mit nginx direkt auf dem Host wäre die Einrichtung einfacher, weil der Umweg über den Ingress wegfällt. Die Ursache bleibt aber: Alte Worker halten die UDP-Sockets fest. Das ist eine Sache von nginx, nicht von K3s, und deshalb habe ich Issue #1937 eröffnet. Weniger lange Verbindungen und seltene Reloads würden das Problem abmildern. Getestet habe ich das nicht. Auf einer statischen Seite wäre der Nutzen ohnehin klein, ich würde es also vorerst auslassen.

Was man mitnimmt: Eine einfachere Einrichtung behebt keinen Fehler in der Schicht darunter.

🎯 Die Lehren

1. Erst messen, dann glauben. Ich habe einen großen Tempogewinn erwartet. Ein gecachtes WordPress antwortete in 58 ms, eine statische Datei in 57 ms.
2. Der meiste Nutzen liegt im Betrieb. Software, die es nicht mehr gibt, braucht keinen Patch, keinen Alarm und keinen Notfall.
3. Härtung überlebt. Meine Annahme, dass kaum Rollen bleiben, war falsch: 24 von 29 bleiben zumindest teilweise, weil sie den Host schützen.
4. „Statisch“ ist nicht automatisch „einfach“. Grafana, Deploy und Build-Kette bleiben, und das Risiko wandert zum Deploy-Schlüssel.
5. Eine Migration braucht ein Vergleichswerkzeug. Ohne es hätte ich die kaputten Telefon-Links im Impressum übersehen.

🤔 Wo ich gerade stehe

Ich habe mich nicht entschieden. K3s und WordPress sind für diesen Blog technisch nicht mehr nötig, so viel ist klar. Ebenso klar ist, dass sie mich Aufmerksamkeit kosten, die Leser aber nichts. Auf der anderen Seite stehen der Editor, das K3s-Testfeld für die Nextclouds und ein Aufbau, der funktioniert und den ich sehr gut kenne.

Wenn ich es mache, dann mit Hugo und einem getrennten Inhalts-Repository, das Monitoring bleibt. AlmaLinux ist die vernünftige Wahl, weil fast alles mitgeht. FreeBSD ist die Wahl, die mich begeistert, und zum ersten Mal wäre sie auf diesem Blog eine realistische. Und wenn es so weit ist, gibt es einen zweiten Teil mit den echten Zahlen, einschließlich allem, was diese Schätzungen falsch vorhergesagt haben.