Gisteren werd bekend dat er twee grote lekken in PHP zijn gevonden. Na een snelle inventarisatie bleek dat ook WordPress op PHP leunt, en de website dus kwetsbaar was.
De keuze was: wachten op fixes, en dan updates draaien. We waren al een tijdje ontevreden over WordPress. Het is best bewerkelijk, best verouderd, en de site laadt niet echt snel. Ook was de SEO niet zoals we wilden, net als meertaligheid.
Het moderniseren van de site stond sowieso al op de planning. In plaats van WordPress oplappen hadden we er al voor gekozen om de site om te zetten naar een statische site. Een groot project, maar nu moest het binnen een paar uur gebeuren.
Old school static HTML
Ooit, en dan hebben we het over 1993, leerde ik HTML programmeren. Websites werden in die tijd met de hand gecodeerd. Later, in 1996 ontwikkelden we met Iprecom, het eerste webbureau in het Noorden, een CMS dat WebMake heette. Collega Arnoud ontwikkelde het. Op basis van documenten en een sitemap document werden alle HTML's statisch gegenereerd. Het versnelde het proces van het beheren van een site, en gegenereerde statische HTML laadt bloedsnel.
Later werden dynamische CMS-en populair. Van gedrochten van Microsoft en Adobe, tot en met de meer gangbare CMS-en zoals WordPress, waar ruim 40% van alle websites ter wereld momenteel op draait. Die maken beheer makkelijk, maar het nadeel is dat er allerlei software achter een site moet draaien, en die software kan lek raken, fouten maken, en sites worden er langzaam van: de HTML is niet gewoon een bestandje dat kan worden gedownload maar moet worden gegenereerd, en zit vaak vol met overbodige code.
Stap 1: SiteSucker
We hebben de gehele WordPress-site daarom eerst volledig gedownload met SiteSucker, een handig tooltje dat de complete website binnenhaalt. Je hebt dan een lokale kopie van de gehele site, die in tegenstelling tot een WordPress-site volledig statisch is: geen CMS, geen software, maar old school HTML, afbeeldingen en wat ondersteunende zaken zoals CSS.
Prio op uptime en veiligheid
We hebben uit voorzorg daarna meteen de WordPress-site uitgezet. De website had een lagere prioriteit dan het nalopen, dichttimmeren en patchen van al onze core systemen. Een website kun je best een paar uur missen, een gat in je infrastructuur kan jou en je klanten veel meer kosten. We deden een risicoanalyse, timmerden de zwakste punten zoveel mogelijk dicht, haalden de GUI en API tijdelijk offline. Zo hielden we alle video's en streams in de lucht. Klanten konden alleen tijdelijk geen aanpassingen doen, uit voorzorg om hun gegevens te beschermen. Dit past bij ons protocol: de content moet up zijn, aanpassingen zijn van lagere prioriteit, en dat was een afweging tussen kritische serviceverlening en kritische beveiliging. Zodra we voldoende bescherming hadden, werden GUI en API weer aangezet, en daarna was het tijd voor permanente fixes.
Stap 2: De LLM als CMS
Ervaring met een LLM als 'CMS' hadden we al, waarbij je samen met de LLM de site ontwerpt en de architectuur maakt, jij de teksten en afbeeldingen levert en de LLM de pagina's en alles wat erbij hoort genereert, inclusief sitemap, rss, robots, en alle andere hulpbestanden. De site die je nu bezoekt is zo gemaakt, en is vanaf nul zo opgebouwd.
Maar een bestaande WordPress-site even omzetten was nieuw. De LLM kreeg de opdracht om de gedownloade site te scannen op missende onderdelen en gebroken links, en die te repareren. Daarna hebben we opdracht gegeven om alle overbodige WordPress-code eruit te halen, en de site na te lopen op SEO-fouten, die meteen hersteld werden.
Onze video's werken gewoon, en de formulieren zijn vervangen door mail-links, zodat de site geen enkel script meer nodig heeft om te functioneren. Een grondige sanity check dus, en het resultaat stond als frisse kopie op de desktop: een volledig werkende statische site.
Stap 3: Menselijke check
Er was haast bij maar vergeet niet dat een LLM fouten kan maken. Een eerste menselijke scan op de lokaal gehoste site werd uitgevoerd: pagina's werken, het design staat, de content klopt, de links werken, video's werken, mensen kunnen contact opnemen.
Stap 4: De hostingomgeving
De LLM adviseerde ook hoe de hostingomgeving aan te passen om de nieuwe site te kunnen hosten, inclusief de kant-en-klare configuratie. Die uiteraard ook door een mens werd gecontroleerd. De site werd geüpload en klaar.
Het resultaat
Het resultaat is jet-stream.com: een site die visueel niet te onderscheiden is van de oude, maar extreem veel sneller laadt, geoptimaliseerd is en geen software meer nodig heeft. Willen we iets aanpassen, dan vragen we dat aan de LLM, want dat scheelt zoveel tijd, zo blijkt ook al bij onze andere sites.
Omdat er geen CMS achter draait, valt er ook weinig te hacken.
Maar nog belangrijker: omdat er geen CMS achter draait, valt er ook weinig te hacken. Het volgende WordPress- of PHP-lek gaat vooralsnog aan ons voorbij.
De komende periode gaan we de site verder scannen en zowel technisch als inhoudelijk verbeteren. Met een LLM. Dat gaat verder dan alleen: 'hier is een nieuw blog, doe je ding'. Opdrachten worden ook: 'scherp de gehele site aan rond technische benchmarking, en benchmarking rond compliance', en 'hier zijn de wetten, onze compliance resultaten, verwerk ze in de site', en 'dit zijn onze innovaties, doe een voorstel hoe we de site herstructureren, leg ons keuzes voor en voer dan alles in één keer uit, en valideer dan of alles klopt en werkt.'
Nu jouw site?
Afhankelijk van hoe complex je site is, kun je hier snel mee aan de slag. Volg simpelweg het stappenplan. De details maken het verschil: welke onderdelen je kopie mist, wat je doet met formulieren, zoekfuncties en andere dynamische onderdelen, hoe je je SEO behoudt en hoe je de site daarna veilig beheert. Wil je sparren over jouw site? Neem contact met me op.