Von WordPress zu einer KI-gestützten statischen Website: Wiederaufbau, ohne die Vergangenheit zu verlieren

Meine alte WordPress-Website hatte ihren Job gemacht. Es hatte über viele Jahre Artikel, Bilder und Fragmente der Berufsgeschichte angesammelt. Aber die Pflege eines datenbankgestützten Content-Management-Systems für eine persönliche Website fühlte sich langsam an, als würde man einen Motor laufen lassen, nur um eine Schreibtischlampe anzuzünden.

Ich wollte etwas, das schneller, einfacher zu bedienen und viel persönlicher ist. Ich wollte auch herausfinden, wie weit mir ein KI-Programmierpartner bei der Migration helfen kann — nicht durch Drücken der mythischen Schaltfläche „Website konvertieren“, sondern indem er mit mir die echten technischen Entscheidungen durcharbeitet.

Das Ergebnis ist die Website, die Sie gerade lesen: ein handgefertigtes, Cloud-natives Portfolio, das als statische Dateien über Amazon S3 und CloudFront bereitgestellt wird. Die alte Schrift bleibt verfügbar, während die neue Website Fotos, Zertifizierungen, Trainingsdaten, kleine Spiele und einen vollständigeren Bericht über meine Arbeit hinzufügt.

Der erfolgreiche Teil war nicht, WordPress durch KI zu ersetzen. Es ging darum, den Inhalt, den es wert war, aufbewahrt zu werden, von den Maschinen zu trennen, die ihren Platz nicht mehr verdient haben.

Definieren Sie zunächst, was „KI-basiert“ eigentlich bedeutet

Die Produktionswebsite benötigt kein Sprachmodell, um eine Seite bereitzustellen. Das würde die Latenz, Komplexität und Abhängigkeit erhöhen, ohne dass normale Besucher davon profitieren würden. Es ist eine statische Seite und das ist eine Funktion.

KI war Teil des Engineering-Prozesses. Es half, das alte Material zu überprüfen, eine Informationsarchitektur vorzuschlagen, Texte zu entwerfen und zu überarbeiten, Code zu generieren und zu überarbeiten, Inkonsistenzen aufzudecken, das Reaktionsverhalten zu verbessern und wiederholte manuelle Arbeiten in Skripten umzuwandeln. Ich blieb der Produktbesitzer: Ich habe das Material ausgewählt, Annahmen korrigiert, das visuelle Ergebnis bewertet und Produktionsänderungen genehmigt.

„KI-unterstützt“ ist daher die genaue Beschreibung. Die Intelligenz wurde beim Aufbau und der Wartung der Website verwendet; das gelieferte System bleibt einfach.

1. Inventar vor der Neugestaltung

Eine Migration sollte mit Beweisen beginnen, nicht mit einer neuen Farbpalette. Bevor ich die Präsentation änderte, sammelte ich die WordPress-Beiträge, Seiten, Kategorien und Medienreferenzen. Der Originalinhalt wurde in strukturiertes JSON exportiert, während die zugehörigen Dateien in ein lokales Archiv kopiert wurden.

Dadurch entstanden zwei wichtige Sicherheitsnetze:

• ein maschinenlesbares Inhaltsarchiv, das transformiert werden könnte, ohne die Live-Website wiederholt zu durchsuchen;
• eine konservierte Mediathek mit den Originalbildern, Dokumenten und Zertifikaten.

Ich habe auch URLs, Titel, Veröffentlichungsdaten, interne Links und Inhalte überprüft, die niemals versehentlich veröffentlicht werden sollten. Ein vollständiges Backup ist nicht dasselbe wie eine öffentliche Website: Exporte können Entwürfe, veraltete Dateien, persönliche Informationen und Anmeldeinformationen enthalten. Aufbewahrung und Veröffentlichung müssen getrennte Entscheidungen bleiben.

2. Trennen Sie den Inhalt von WordPress

Das wertvollste WordPress-Asset war nicht das Theme, die Plugins oder das Datenbankschema. Es war der Inhalt. Sobald Beiträge als JSON dargestellt wurden und Medien in einem normalen Dateibaum lebten, wurde die Präsentationsebene ersetzbar.

Auf der Homepage liest JavaScript die kuratierten Artikeldaten und erstellt die Field Notes-Karten. Jeder Artikel hat auch seine eigene statische HTML-Seite. Das gibt der Oberfläche die Flexibilität strukturierter Inhalte und behält gleichzeitig normale, crawlbare URLs für Suchmaschinen und Leser bei, die über einen direkten Link zu uns kommen.

Dieser Ansatz „zuerst bewahren, dann kuratieren“ verhinderte einen häufigen Migrationsfehler: die Historie zu verwerfen, weil das neue Design keinen offensichtlichen Ort hat, um ihn auszudrücken. Das Archiv hat zuerst überlebt; die redaktionellen Entscheidungen wurden danach getroffen.

3. Entwerfen Sie die neue Website rund um die Person, nicht um das CMS

WordPress ermuntert eine Website natürlich dazu, wie eine Abfolge von Beiträgen auszusehen. Meine neue Website brauchte einen anderen Schwerpunkt: eine Einführung, professionelle Arbeit, eine Reise durch meine Karriere, Zertifizierungen, Fotos, Trainingsfortschritte, technische Hinweise und ein bisschen Spaß.

Wir haben diese Struktur direkt in semantischem HTML, CSS und JavaScript gebaut. Es gibt kein Allzweck-Theme, das versucht, Tausende von möglichen Websites abzudecken. Die Navigation, die Typografie, das mobile Menü, der Bildrahmen und die interaktiven Details existieren für dieses eine Portfolio.

Die Neugestaltung war iterativ. Ich könnte mir eine lokale Vorschau ansehen, sagen, dass ein Terminal meinen Arm bedeckt hat, dass sich ein Porträt abgeschnitten anfühlt oder dass eine Überschrift bei einem unangenehmen Wort gebrochen ist — und die Implementierung könnte sofort angepasst werden. In dieser kurzen Feedback-Schleife war die Zusammenarbeit mit KI besonders nützlich: Das visuelle Urteilsvermögen blieb menschlich, während die Übersetzung in funktionierendes CSS viel schneller wurde.

4. Behandeln Sie alte URLs und Suchsichtbarkeit als Produktionsdaten

Eine Neugestaltung ist nicht erfolgreich, wenn die neue Homepage ausgezeichnet aussieht, aber jahrelanges durchsuchbares Material verschwindet. Jede ausgewählte Notiz erhielt eine eigenständige URL, einen beschreibenden Titel, eine Metabeschreibung und eine kanonische Adresse. Die Seiten enthalten auch Open Graph- und Twitter-Metadaten zum Teilen sowie strukturierte Schema.org-Daten, die den Inhalt als technischen Artikel identifizieren und ihn mir als Autor zuordnen.

Die Sitemap listet sowohl die Kernseiten als auch die archivierten Notizen auf. Die Seite identifiziert mich durchweg als „Bernd Kuhlen“ und enthält „Bernhard Kuhlen“ als alternativen Namen. Roboter erhalten eine explizite Anleitung zum Crawlen, während Menschen und Suchmaschinen normalen Links weiterhin folgen können, ohne die interaktive Homepage auszuführen.

Wenn ein alter Permalink Backlinks oder einen Suchverlauf hat, sollte er entweder gültig bleiben oder dauerhaft zu seinem Nachfolger umleiten. Die URL-Zuordnung gehört in den Migrationsplan, nicht in die Bereinigungsliste nach dem Start.

5. Machen Sie die Infrastruktur langweilig — auf eine gute Art

Die endgültigen Dateien werden in einem privaten, verschlüsselten und versionierten S3-Bucket gespeichert. CloudFront ist der öffentliche Einstiegspunkt und greift über Origin Access Control auf den Bucket zu, sodass der Speicher selbst nicht als öffentliche Website angezeigt wird. HTTPS wird durchgesetzt, modernes TLS ist erforderlich, und eine Response-Headers-Richtlinie liefert die wichtigsten Sicherheitsheader des Browsers.

Die Infrastruktur wird in CloudFormation beschrieben und nicht nur durch Anklicken der AWS-Konsole zusammengestellt. Das Bereitstellungsskript aktualisiert den Stack, synchronisiert eine explizite Zulassungsliste von öffentlichen Dateien und macht den CloudFront-Cache ungültig. Das macht eine Veröffentlichung wiederholbar und gibt zukünftigen Änderungen eine überprüfbare Implementierung.

Statisches Hosting entfernt die WordPress-Datenbank, PHP-Runtime, Theme-Updates und Plugin-Patches aus dem Anforderungspfad. Es entzieht nicht der operativen Verantwortung, es macht daraus ein kleineres und besser beobachtbares Problem.

6. Zuerst Vorschau, Sekunde überschneiden

Während der gesamten Arbeit lief die Seite lokal in einem Container hinter Nginx. Diese Vorschauumgebung ermöglichte es, Desktop- und Telefon-Layouts zu testen, archivierte Dokumente zu öffnen, die eingebetteten Spiele zu spielen und die Trainingstabellen zu überprüfen, bevor irgendetwas in Produktion ging.

Ein sicherer Umstellungsplan sollte Folgendes beinhalten:

1. ein Einfrieren der Inhalte oder ein klar definierter Endexport;
2. ein vollständiges Datenbank- und Medien-Backup;
3. lokale und temporale Validierung wichtiger URLs;
4. DNS-Einträge und Zertifikate, die vor dem Wechsel vorbereitet wurden;
5. ein Rollback-Pfad zum vorherigen Ursprung;
6. Überprüfungen nach der Veröffentlichung von außerhalb der Entwicklungsmaschine.

S3-Versionierung und Infrastructure as Code helfen bei der Wiederherstellung, aber sie ersetzen kein absichtliches Rollback-Verfahren.

7. Fügen Sie Observability hinzu, nachdem Sie den Anwendungsserver entfernt haben

Eine statische Website kann trotzdem ausfallen, Bots anziehen oder unerwarteten Traffic erzeugen. CloudFront-Zugriffsprotokolle zeichnen Anfragen, Statuscodes, Benutzeragenten und Edge-Standorte auf. Diese Protokolle werden in ein CloudWatch-Dashboard eingespeist, das Zugriffsvolumen und HTTP-Statusfamilien anzeigt, mit einer definierten Aufbewahrungsdauer und nicht mit unbegrenzter Akkumulation.

Geografische Ansichten helfen dabei, herauszufinden, woher der Verkehr zu stammen scheint, obwohl ein Edge-Standort, ein IP-abgeleitetes Land oder eine Stadt niemals mit einer verifizierten Person verwechselt werden sollte. Betriebsdaten beantworten Fragen zu Anfragen; sie belegen selten die Identität.

Diese Beobachtbarkeit schafft auch eine nützliche Ausgangsbasis. Anstatt darauf zu warten, dass jemand einen defekten Link meldet, kann ich Fehlertrends sehen und überprüfen, welche Pfade angefordert werden.

8. Verwenden Sie die Migration, um Dinge zu erstellen, die WordPress nie empfohlen hat

Sobald die Website nicht mehr von einem traditionellen Blog-Thema geprägt war, wurde es einfacher, Funktionen hinzuzufügen, die meinen tatsächlichen Interessen entsprechen. Apple Health-Exporte wurden in aggregierte tägliche, wöchentliche und monatliche Trainingsansichten umgewandelt. Zertifikate wurden zu einem speziellen, durchsuchbaren Archiv. Persönliche Fotos wurden mit Bildunterschriften versehen. Zwei kleine Spiele — Snake und Galaga — haben im Bereich Spaß ein Zuhause gefunden.

Diese werden immer noch als statische Assets und clientseitiger Code geliefert. Die wichtige Änderung bestand nicht darin, eine schwerere Plattform hinzuzufügen, sondern eine Struktur zu schaffen, in der kleine, fokussierte Funktionen nebeneinander existieren konnten.

Welche KI hat gut funktioniert — und wo sie beaufsichtigt werden musste

KI war besonders effektiv bei wiederholten Inspektionen, dem Vorschlagen von Transformationen, dem Erstellen erster Implementierungen, der Überprüfung der Sprache und dem Einbringen von detailliertem Feedback über mehrere Dateien hinweg. Es könnte die Beziehung zwischen einem Inhaltsdatensatz, seiner Artikelseite, der Sitemap und dem Bereitstellungspaket verfolgen.

Es war immer noch eine Bestätigung erforderlich. Ein plausibler Link kann falsch sein. Ein technisch gültiges Layout kann auf einem echten Telefon komisch aussehen. Generierte Texte können generisch klingen oder mehr beanspruchen, als das System tatsächlich tut. Infrastrukturbefehle können Konsequenzen haben, die weit über einen Tippfehler in einem Absatz hinausgehen.

Der produktivste Arbeitsablauf war dialogorientiert, aber diszipliniert: das reale System inspizieren, eine begrenzte Änderung vornehmen, eine Vorschau anzeigen, testen und erst dann veröffentlichen. Die KI hat diese Schleife beschleunigt; sie hat sie nicht eliminiert.

Eine wiederholbare Migrationscheckliste

1. Sichern Sie die WordPress-Datenbank, Uploads und Konfiguration.
2. Exportieren Sie Beiträge, Seiten, Taxonomien, Daten, Autoren und Medienreferenzen.
3. Klassifizieren Sie Inhalte als öffentlich, privat, veraltet oder unsicher.
4. Erstellen Sie ein URL-Inventar und eine Umleitungskarte.
5. Wählen Sie die einfachste Zielarchitektur, die den tatsächlichen Anforderungen entspricht.
6. Erstellen Sie ein kleines Designsystem und wiederverwendbare Inhaltsvorlagen.
7. Generieren Sie eigenständige, semantische Seiten für Material, das durchsuchbar bleiben sollte.
8. Fügen Sie Metadaten, kanonische URLs, strukturierte Daten, Roboter-Regeln und eine Sitemap hinzu.
9. Testen Sie Barrierefreiheit, responsive Layouts, Links, Dokumente und Fehlerseiten.
10. Beschreiben Sie Infrastruktur und Bereitstellung als Code.
11. Abschalten mit Backups, Überwachung und einer getesteten Rollback-Route.
12. Bewahren Sie das Archiv auf, bis sich die neue Website bewährt hat.

Der Kompromiss

Eine statische Website ist nicht automatisch der richtige Ersatz für jede WordPress-Installation. Ein Newsroom mit vielen Redakteuren, komplexen Workflows, Kommentaren oder sich häufig ändernden serverseitigen Daten kann immer noch von einem ausgereiften CMS profitieren — oder von einem Headless-CMS mit statischem Frontend.

Für ein persönliches Portfolio, das per Code verwaltet wird, ist der Saldo anders. Ich habe die Bequemlichkeit, Beiträge in einem Browser zu bearbeiten, gegen eine kleinere Angriffsfläche, vorhersehbare Bereitstellung, versionierte Änderungen und vollständige Kontrolle über das Erlebnis eingetauscht. KI reduzierte die Reibung dieses codebasierten Workflows genug, um den Handel attraktiv zu machen.

Letzter Imbiss

Die alte WordPress-Seite wurde nicht weggeworfen. Es wurde sorgfältig demontiert: Der Inhalt wurde bewahrt, die nützlichen Teile wurden beworben, die Präsentation wurde neu aufgebaut und die Infrastruktur wurde vereinfacht.

Das ist die Lektion über Migration, die ich wiederholen würde. Fragen Sie zunächst nicht, welches KI-Produkt WordPress ersetzen soll. Fragen Sie zunächst, was überleben muss, was die Website wirklich leisten muss und welche Komplexität beseitigt werden kann. Dann nutzen Sie KI als kompetenten technischen Partner — neugierig, schnell und hilfreich, arbeitet aber immer mit echten Dateien, echten Tests und menschlichem Urteilsvermögen.