Migration von WordPress, Joomla und anderen dynamischen CMS zu statischen Webseiten
In diesem Artikel halte ich in gestraffter Form den Wechsel der Inhortas-Inhalte fest: von WordPress (dem verbreiteten CMS für dynamische Webseiten) hin zu einem CMS für statische Webseiten. Gemeint ist ein Editor für das gesamte Webprojekt: Die Seite entsteht lokal am Rechner und geht als fertige, unveränderliche HTML-Dateien online.
Der Unterschied zu dynamischen Webseiten: Dort setzt der Server die Seite bei jedem Aufruf zusammen – aus Datenbank, PHP und weiteren Programmen, die auf dem Server liegen. Bei statischen Seiten liegt bereits fertiges HTML bereit; der Server liefert es nur noch aus.
Dynamische CMS kamen Mitte der 2000er-Jahre in die Breite und lösten viele handgebaute statische Seiten ab. Seither wurden sie für meine Begriffe oft komplizierter, langsamer und störanfälliger (ich nenne das digitale Demenz). Das kann dazu führen, dass eine Seite auf dem Server mit Schadcode infiziert wird und der Hoster sie sperrt.
Genau das ist mir mit dem ersten Projekt derkleinegarten.de passiert (Joomla). Daraufhin habe ich das Gartenjournal mit Publii (Open-Source-CMS für statische Websites) neu aufgesetzt: minimalistisches Design (Theme Mono), praktisch ohne Cookies und Tracking-Skripte. Ohne diese kleinen Statistik- und Marketingprogramme entfällt in der Regel auch das Cookie-Banner. Das muss inzwischen so aufwendig programmiert werden, dass es oft komplexer und fehleranfälliger ist als die eigentliche Seite – und die Abmahnindustrie miternährt.
Kurzum, so gehe ich vor:
Voraussetzung: WordPress erzeugt sogenannte Pretty Permalinks – lesbare Adressen wie /beitragstitel/ statt ?p=123. Die Endung .html in der Browserzeile ist dabei kein Muss; Pretty Permalinks verbergen die technische Dateiendung. Publii kann dieselbe Art von URLs erzeugen (Pretty URLs an: Ordner mit index.html darin).
Die Beitrags-URLs lassen sich so angleichen, dass sich alte und neue Struktur nicht beißen. Vollständig identisch ist die Ordnerstruktur trotzdem nicht: WordPress-Exporte enthalten typischerweise wp-content (Bilder, Uploads) und wp-includes (CSS, Skripte). Publii legt Medien und Theme-Dateien anders ab. Übersichten (Kategorien, Schlagworte, Archive) weichen oft leicht ab. In Publii gibt es vor allem Tags statt klassischer WordPress-Kategorien; das Tag-Präfix in der URL ist einstellbar, etwa /tags/schlagwort/ statt /tag/schlagwort/ oder /category/….
Erster Schritt: Die vorhandenen WordPress-Seiten testweise in statische HTML-Dateien umwandeln – etwa mit dem Plugin Simply Static. Hochladen auf eine Test-Domain:
- Startseite (index)
- Ordner der einzelnen Beiträge und Seiten
- Ordner der Navigations-Übersichten
- Ordner der Schlagwort-Übersichten
- wp-content (Bilder usw.)
- wp-includes (CSS usw.)
Das ergibt bereits eine prüfbare statische Kopie der alten Seite – noch kein Publii-Projekt, sondern ein Zwischenstand zum Testen von Links, Bildern und Weiterleitungen.
Zweiter Schritt: Das Erscheinungsbild angleichen. In Publii bleibt Theme Mono. In WordPress stelle ich parallel das ebenfalls knappe Theme „Days From Blog“ ein, teste es und schalte es scharf – damit der Altbestand optisch näher an das Zielsystem rückt.
Als Nächstes habe ich für das Publii-Projekt eine vereinfachte Navigation mit einer KI erarbeitet. Das ist wichtig, weil ich kurz vor dem „Einfrieren“ der bisher auf Inhortas veröffentlichten 525 Beiträge diese neue Navigation schon im Altbestand einbaue. Der Altbestand wandert erst nach und nach ins neue System; die alte Navigation würde in dieser Übergangszeit nur irritieren.
[TJ.33.18][]Stand: Thomas Jacob, 13.9.2026 – Es folgen weitere Beschreibungen nach Fortschritt.
—
- Bereits auf Publii seit 28. Juli 2026: derkleinegarten.de (im Mono-Design)
- Publii – Open-Source CMS for Static Websites
- Das Mono-Theme von Publii (Seitendesign)
