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 weit verbreiteten CMS für dynamische Webseiten) hin zu einem System für statische Webseiten. Gemeint ist ein lokaler Editor für das gesamte Webprojekt: Die Seite entsteht auf dem Rechner und geht als fertiges Paket aus unveränderlichen HTML-Dateien online.
Der Unterschied zu dynamischen Webseiten: Dort setzt der Server die Seite bei jedem Aufruf neu zusammen – aus Datenbank, PHP und weiteren Server-Skripten. Bei statischen Seiten liegt das HTML bereits fertig vor; der Server liefert es nur noch aus.
Dynamische CMS kamen Mitte der 2000er-Jahre in der Breite auf und lösten viele handgebaute statische Seiten ab. Seither wurden sie jedoch – zumindest für meine Begriffe – immer komplizierter, langsamer und störanfälliger. Das kann dazu führen, dass eine Seite auf dem Server leichter mit Schadcode infiziert wird und der Hoster sie wegen dieser Schadsoftware sperrt. Genau das ist mir mit dem ersten Projekt derkleinegarten.de passiert (damals unter Joomla).
Daraufhin habe ich das Gartenjournal (derkleinegarten.de) wieder – wie schon vor 2012 – als statische Website auf den Server geladen. Das heißt: Ich generiere die Inhalte auf dem eigenen Rechner und lade sie als fertige HTML-Seiten inklusive Bildern hoch.
Ein mögliches Werkzeug und Editor für diese Zwecke ist das Open-Source-CMS Publii. Was das Online-Journal derkleinegarten.de betrifft, so ist es jetzt absolut minimalistisch neu aufgesetzt:
- minimalistisches Design (Theme Mono),
- ohne jegliche Sonderfunktionen,
- praktisch ohne Cookies und Tracking-Skripte.
Ohne diese kleinen Statistik- und Marketingprogramme entfällt in der Regel auch das lästige Cookie-Banner. Dieses muss inzwischen so aufwendig programmiert werden, dass es oft fehleranfälliger ist als die eigentliche Seite – und die Abmahnindustrie miternährt. Automatisierte Werbung (AdSense) wurde ebenfalls entfernt.
Das neue System und Design haben sich bewährt. Deshalb ziehe ich nun auch mit dem Inhortas-Projekt um, das aktuell noch auf dem dynamischen Prinzip von WordPress aufbaut. Hier führe ich eine vollständige Migration von WordPress zu Publii durch.
Logbuch & Anleitung zur Migration
13.09.2026: Konzeption und Vorbereitung der Umsetzung [1].
18.09.2026: Recherche zum Migrationspfad:
Publii bietet ein eingebautes Import-Werkzeug für WordPress-Exporte im WXR-Format (eine .xml-Datei). Dafür ist in WordPress kein Extra-Plugin nötig. Der Wechsel ist ein vorgesehener Anwendungsfall, aber kein vollständiger 1:1-Umzug der gesamten WordPress-Site.
Der Ablauf ist zweistufig:
1. Standard-Export in WordPress
- Im WordPress-Backend zu Werkzeuge → Daten exportieren gehen.
- Alle Inhalte wählen (oder gezielt nur Beiträge, falls nicht alles benötigt wird).
- Auf Export-Datei herunterladen klicken.
- Es entsteht eine normale .xml-Datei im WXR-Format.
Hinweise:
Die Datei sollte gültiges XML sein und vollständig heruntergeladen werden.
Sehr große Sites können eine große XML-Datei erzeugen; dann ggf. nach Inhaltstyp oder Zeitraum aufteilen.
2. Import in Publii
- Publii öffnen und die Ziel-Website auswählen (am besten eine neue bzw. leere Site).
- In der linken Seitenleiste auf Tools gehen und WP Import wählen.
- Die heruntergeladene .xml-Datei auswählen.
- Publii prüft die Datei und zeigt eine Übersicht (Beiträge, Bilder, Tags, Kategorien, Autoren).
Die Import-Optionen setzen:
Inhaltstypen: Beiträge, Seiten und ggf. Custom Post Types (werden in Publii jeweils als Beiträge/Inhalte angelegt).
Taxonomie: Entweder WordPress-Kategorien oder WordPress-Tags als Publii-Tags übernehmen – nicht beides.
Autoren: alle Inhalte dem bestehenden Publii-Autor zuweisen oder WordPress-Autoren mitimportieren.
Optional Content formatting aktivieren, damit fehlende Absatz- und Zeilenumbrüche ergänzt werden.
Auf Import Data klicken. Publii importiert die Inhalte und versucht, verknüpfte Bilder herunterzuladen.
Nach dem Import Thumbnails neu generieren.
Was danach noch zu prüfen ist
Der Import übernimmt vor allem Beiträge/Seiten, Autoren, gewählte Taxonomie und Bilder. Nicht automatisch 1:1 kommen u. a.:
- Themes, Plugins, Widgets, Menüs
- Kommentare
- Shortcodes und viele Custom Fields
- die exakten WordPress-Permalinks/Slugs
Deshalb nach dem Import prüfen: interne Links, Featured Images, Bildpfade, Navigation, Seitenstruktur und ggf. 301-Weiterleitungen von alten URLs.
Kurzfassung
WordPress exportiert WXR/XML → Publii importiert über Tools → WP Import → Taxonomie und Autoren festlegen → importieren → Thumbnails regenerieren → Inhalte nacharbeiten.
(Weitere Schritte folgen je nach Fortschritt.)
[TJ.33.18][]Stand: Thomas Jacob, 13.9.2026
—
- 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)
—
[1] Ursprünglicher Migrationsansatz (Zwischenstand): Vor Entdeckung des WP to Publii Converters war die schrittweise Umstellung über eine statische HTML-Kopie geplant, nun aber wieder verworfen:
URL-Anpassung: Nutzung von Pretty Permalinks in WordPress (z. B. /beitragstitel/), um die Struktur an die Pretty URLs von Publii (Ordner mit index.html) anzugleichen. Abweichungen bestehen vor allem in den Ordnerpfaden (wp-content, wp-includes) sowie den Tag- und Kategorie-Präfixen.
Statische Test-Kopie: Umwandlung der bestehenden WordPress-Instanz in statische Dateien mittels des Plugins Simply Static und Deployment auf einer Test-Domain zur Überprüfung von Links, Bildern und Weiterleitungen.
Optische Angleichung: Umstellung der WordPress-Seite auf das schlichte Theme Days From Blog, um das Erscheinungsbild an das Publii-Ziel-Theme Mono anzunähern.
Navigations-Restrukturierung: Einbau einer verschlankten, neu konzipierten Navigation direkt im WordPress-Altbestand (525 Beiträge), um Verwirrung während des phasenweisen Umzugs zu vermeiden.
