Van WordPress naar een statische site met AI-hulp: opnieuw bouwen zonder het verleden te verliezen

Mijn oude WordPress-website had zijn werk gedaan. In de loop der jaren waren er artikelen, afbeeldingen en fragmenten uit mijn professionele geschiedenis bijgekomen. Maar een databasegestuurd contentmanagementsysteem onderhouden voor een persoonlijke site begon te voelen als een motor laten draaien alleen om een bureaulamp te laten branden.

Ik wilde iets snellers, eenvoudiger te beheren en veel persoonlijkers. Ook wilde ik ontdekken hoe ver een AI-programmeerpartner me bij de migratie kon helpen: niet met een denkbeeldige knop ‘website omzetten’, maar door samen de echte technische keuzes te doorlopen.

Het resultaat is de site die je nu leest: een met de hand vormgegeven, cloudnative portfolio dat via Amazon S3 en CloudFront als statische bestanden wordt aangeboden. De oude artikelen blijven beschikbaar, terwijl de nieuwe site fotografie, certificeringen, trainingsgegevens, kleine spellen en een vollediger beeld van mijn werk toevoegt.

Het geslaagde deel was niet WordPress door AI vervangen. Het was de inhoud die het bewaren waard was losmaken van de techniek die zijn plek niet meer verdiende.

Bepaal eerst wat ‘AI-gebaseerd’ werkelijk betekent

De productiewebsite heeft geen taalmodel nodig om een pagina te tonen. Dat zou latentie, complexiteit en een afhankelijkheid toevoegen zonder voordeel voor gewone bezoekers. Het is een statische site, en dat is juist een kwaliteit.

AI maakte deel uit van het ontwikkelproces. Het hielp oud materiaal onderzoeken, een informatiearchitectuur voorstellen, teksten schrijven en herzien, code genereren en herstructureren, inconsistenties vinden, responsief gedrag verbeteren en terugkerend handwerk omzetten in scripts. Ik bleef de producteigenaar: ik koos het materiaal, corrigeerde aannames, beoordeelde het uiterlijk en keurde productiewijzigingen goed.

‘AI-ondersteund’ is daarom de juiste omschrijving. De intelligentie is gebruikt tijdens het bouwen en onderhouden; het opgeleverde systeem blijft eenvoudig.

1. Inventariseren vóór het herontwerp

Een migratie moet beginnen met bewijs, niet met een nieuw kleurenpalet. Voordat ik de presentatie veranderde, verzamelde ik de WordPress-berichten, pagina’s, categorieën en mediaverwijzingen. De oorspronkelijke inhoud werd naar gestructureerde JSON geëxporteerd en de bijbehorende bestanden werden naar een lokaal archief gekopieerd.

Dit leverde twee belangrijke vangnetten op:

• een machineleesbaar inhoudsarchief dat kon worden omgezet zonder de live-site steeds opnieuw te scrapen;
• een bewaarde mediabibliotheek met de oorspronkelijke afbeeldingen, documenten en certificaten.

Ik controleerde ook URL’s, titels, publicatiedatums, interne links en inhoud die nooit per ongeluk gepubliceerd mag worden. Een volledige back-up is niet hetzelfde als een openbare website: exports kunnen concepten, verouderde bestanden, persoonlijke informatie en toegangsgegevens bevatten. Bewaren en publiceren moeten afzonderlijke beslissingen blijven.

2. Maak de inhoud los van WordPress

Het waardevolste bezit van WordPress was niet het thema, de plugins of het databaseschema. Het was de inhoud. Zodra berichten als JSON waren vastgelegd en media in een gewone bestandsstructuur stonden, werd de presentatielaag vervangbaar.

Op de homepage leest JavaScript de samengestelde artikelgegevens en bouwt daarmee de Field Notes-kaarten. Elk artikel heeft daarnaast een eigen statische HTML-pagina. Dat geeft de interface de flexibiliteit van gestructureerde inhoud, met behoud van gewone, crawlbare URL’s voor zoekmachines en lezers die via een directe link binnenkomen.

Deze aanpak van ‘eerst bewaren, dan selecteren’ voorkwam een veelgemaakte migratiefout: geschiedenis weggooien omdat het nieuwe ontwerp er geen duidelijke plek voor heeft. Eerst overleefde het archief; redactionele keuzes kwamen daarna.

3. Ontwerp de nieuwe site rond de persoon, niet het CMS

WordPress stuurt een site vanzelf richting een reeks berichten. Mijn nieuwe site had een ander zwaartepunt nodig: een introductie, professioneel werk, mijn loopbaan, certificeringen, foto’s, trainingsvoortgang, technische notities en wat plezier.

We bouwden die structuur rechtstreeks in semantische HTML, CSS en JavaScript. Er is geen algemeen thema dat duizenden mogelijke sites probeert te bedienen. Navigatie, typografie, mobiel menu, beeldkaders en interactieve details zijn gemaakt voor dit ene portfolio.

Het herontwerp verliep in stappen. Ik kon een lokaal voorbeeld bekijken, zeggen dat een terminal mijn arm bedekte, dat een portret afgesneden leek of dat een kop op een onhandig woord afbrak, en de implementatie kon meteen worden aangepast. In die korte feedbacklus was samenwerken met AI bijzonder nuttig: het visuele oordeel bleef menselijk, terwijl de vertaling naar werkende CSS veel sneller ging.

4. Behandel oude URL’s en vindbaarheid als productiegegevens

Een herontwerp is niet geslaagd als de nieuwe homepage er prachtig uitziet maar jaren aan vindbaar materiaal verdwijnen. Elke gekozen notitie kreeg een eigen URL, beschrijvende titel, metabeschrijving en canoniek adres. De pagina’s bevatten ook Open Graph- en Twitter-metadata om te delen, plus gestructureerde Schema.org-data die de inhoud als technisch artikel aanduidt en mij als auteur eraan verbindt.

De sitemap vermeldt zowel de kernpagina’s als de gearchiveerde notities. De site identificeert mij consequent als ‘Bernd Kuhlen’ en vermeldt ‘Bernhard Kuhlen’ als alternatieve naam. Robots krijgen expliciete crawlinstructies, terwijl mensen en zoekmachines gewone links kunnen blijven volgen zonder de interactieve homepage uit te voeren.

Als een oude permalink backlinks of zoekgeschiedenis heeft, moet die geldig blijven of permanent doorverwijzen naar zijn vervanger. URL-mapping hoort in het migratieplan, niet op de opruimlijst na de lancering.

5. Maak de infrastructuur saai — op een goede manier

De definitieve bestanden staan in een privé-, versleutelde S3-bucket met versiebeheer. CloudFront is het openbare toegangspunt en benadert de bucket via Origin Access Control, zodat de opslag zelf niet als openbare website wordt aangeboden. HTTPS is verplicht, moderne TLS is vereist en een responseheadersbeleid levert de belangrijkste browserbeveiligingsheaders.

De infrastructuur is vastgelegd in CloudFormation, in plaats van alleen bij elkaar geklikt in de AWS-console. Het deploymentscript werkt de stack bij, synchroniseert een expliciete toegestane lijst met openbare bestanden en invalideert de CloudFront-cache. Zo wordt een release herhaalbaar en krijgen toekomstige wijzigingen een beoordeelbare implementatie.

Statische hosting haalt de WordPress-database, PHP-runtime, thema-updates en pluginpatches uit het verzoekpad. Operationele verantwoordelijkheid verdwijnt niet; ze verandert in een kleiner, beter inzichtelijk probleem.

6. Eerst lokaal bekijken, dan omschakelen

Tijdens het werk draaide de site lokaal in een container achter Nginx. In die voorbeeldomgeving kon ik desktop- en telefoonlayouts testen, gearchiveerde documenten openen, de ingebedde spellen spelen en de trainingsgrafieken bekijken voordat iets productie bereikte.

Een veilig omschakelplan hoort het volgende te bevatten:

1. een inhoudsstop of een duidelijk afgebakende laatste export;
2. een volledige back-up van database en media;
3. lokale en stagingcontroles van belangrijke URL’s;
4. DNS-records en certificaten die vóór de omschakeling klaarstaan;
5. een terugweg naar de vorige origin;
6. controles na de release, vanaf buiten de ontwikkelmachine.

S3-versiebeheer en Infrastructure as Code helpen bij herstel, maar vervangen geen doordachte terugdraaiprocedure.

7. Voeg observability toe nadat de applicatieserver is verwijderd

Ook een statische website kan uitvallen, bots aantrekken of onverwacht verkeer veroorzaken. CloudFront-toegangslogs leggen verzoeken, statuscodes, user agents en edgelocaties vast. Die logs voeden een CloudWatch-dashboard met verkeersvolume en HTTP-statusgroepen, met een vastgestelde bewaartermijn in plaats van onbeperkte opeenstapeling.

Geografische weergaven helpen zichtbaar te maken waar verkeer vandaan lijkt te komen. Toch mag een edgelocatie of een uit een IP-adres afgeleid land of stad nooit voor een geverifieerd persoon worden aangezien. Operationele gegevens beantwoorden vragen over requests; ze bewijzen zelden identiteit.

Die waarneembaarheid levert ook een bruikbare uitgangsmeting op. In plaats van te wachten tot iemand een kapotte link meldt, kan ik fouttrends zien en onderzoeken welke paden worden opgevraagd.

8. Gebruik de migratie om dingen te bouwen waar WordPress niet toe uitnodigde

Toen de site niet meer door een traditioneel blogthema werd bepaald, werd het eenvoudiger functies toe te voegen die mijn echte interesses weerspiegelen. Apple Health-exports werden samengevoegde dagelijkse, wekelijkse en maandelijkse trainingsoverzichten. Certificaten kregen een eigen doorbladerbaar archief. Persoonlijke foto’s kregen bijschriften. Twee kleine spellen, Snake en Galaga, vonden een plek bij Plezier.

Dit alles wordt nog steeds geleverd als statische bestanden en code in de browser. De belangrijkste verandering was niet een zwaarder platform, maar een structuur waarin kleine, gerichte functies naast elkaar kunnen bestaan.

Waar AI goed in was en waar toezicht nodig bleef

AI was vooral effectief bij herhaalde inspecties, het voorstellen van omzettingen, het maken van eerste implementaties, taalcontroles en het toepassen van gedetailleerde feedback in meerdere bestanden. Het kon de samenhang bewaken tussen een inhoudsrecord, de artikelpagina, de sitemap en het deploymentpakket.

Verificatie bleef nodig. Een aannemelijke link kan verkeerd zijn. Een technisch geldige indeling kan er op een echte telefoon onhandig uitzien. Gegenereerde tekst kan algemeen klinken of meer beloven dan het systeem werkelijk doet. Infrastructuuropdrachten kunnen gevolgen hebben die veel verder reiken dan een tikfout in een alinea.

De productiefste werkwijze was een gesprek met discipline: onderzoek het echte systeem, verander één afgebakend onderdeel, bekijk het resultaat, test het en publiceer het pas daarna. AI versnelde die cyclus; het verving hem niet.

Een herhaalbare migratiechecklist

1. Maak een back-up van de WordPress-database, uploads en configuratie.
2. Exporteer berichten, pagina’s, taxonomieën, datums, auteurs en mediaverwijzingen.
3. Deel inhoud in als openbaar, privé, verouderd of onzeker.
4. Maak een URL-inventaris en een omleidingskaart.
5. Kies de eenvoudigste doelarchitectuur die aan de werkelijke eisen voldoet.
6. Bouw een klein ontwerpsysteem en herbruikbare inhoudssjablonen.
7. Genereer zelfstandige, semantische pagina’s voor materiaal dat vindbaar moet blijven.
8. Voeg metadata, canonieke URL's, gestructureerde gegevens, robotsregels en een sitemap toe.
9. Test toegankelijkheid, responsieve indelingen, links, documenten en foutpagina’s.
10. Beschrijf infrastructuur en uitrol als code.
11. Schakel over met back-ups, monitoring en een geteste terugweg.
12. Bewaar het archief totdat de nieuwe site zich heeft bewezen.

De afweging

Een statische site is niet automatisch de juiste vervanger voor elke WordPress-installatie. Een redactie met veel niet-technische redacteuren, complexe workflows, reacties of vaak veranderende servergegevens kan nog steeds baat hebben bij een volwassen CMS — of een headless CMS met een statische frontend.

Voor een persoonlijk portfolio dat via code wordt onderhouden, ligt de afweging anders. Ik ruilde het gemak van berichten bewerken in een browser in voor een kleiner aanvalsoppervlak, voorspelbare levering, versiebeheer en volledige controle over de ervaring. AI maakte die codegerichte werkwijze soepel genoeg om de ruil aantrekkelijk te maken.

De belangrijkste les

De oude WordPress-site is niet weggegooid. Hij is zorgvuldig uit elkaar gehaald: de inhoud bleef bewaard, bruikbare delen kregen een betere plek, de presentatie werd herbouwd en de infrastructuur vereenvoudigd.

Die migratieles zou ik herhalen. Begin niet met de vraag welk AI-product WordPress moet vervangen. Vraag eerst wat moet blijven bestaan, wat de site werkelijk moet doen en welke complexiteit weg kan. Gebruik AI daarna als een bekwame technische partner: nieuwsgierig, snel en behulpzaam, maar altijd werkend met echte bestanden, echte tests en menselijk oordeel.