Een slechte publicatie van een statische website begint vaak klein. De homepage blijft wit. CSS laadt niet. Een afbeelding geeft 404. Een PDF wijst naar het verkeerde bestand. Een landingspagina staat live met tekst die nog niet was goedgekeurd.
Het echte risico ontstaat wanneer het team in de live versie blijft sleutelen terwijl de link al bij klanten, recruiters, studenten, campagnebezoekers of interne reviewers ligt.
Voor een statische website is de veiligste route vaak eenvoudiger: zet eerst de laatste werkende versie terug, en onderzoek daarna rustig waarom de nieuwe publicatie stukging.
Rollback is voor echte impact op de openbare link
Niet elke fout vraagt om rollback. Een kleine typefout kan meestal met een nieuwe upload worden opgelost.
Herstel wordt de eerste optie wanneer de huidige live versie duidelijk slechter is dan de vorige.
| Probleem | Waarom terugzetten helpt |
|---|---|
| Witte pagina | Bezoekers zien weer een werkende versie terwijl u de build controleert. |
| CSS, afbeeldingen of fonts ontbreken | De vorige versie heeft assetpaden die al waren getest. |
| Routes of diepe links breken | QR-codes, campagnelinks en oude URL's kunnen weer werken. |
| Verkeerde campagnetekst staat live | De goedgekeurde boodschap komt terug terwijl u de update corrigeert. |
| AI-export is onvolledig | Placeholdertekst, verzonnen links of onafgewerkte secties verdwijnen uit de live site. |
| PDF of download is verkeerd | De openbare link wijst niet langer naar een fout of ontbrekend bestand. |
De praktische grens is dit: als de live versie toegang, vertrouwen, klantreview of conversie raakt, herstel eerst een bekende goede staat.
Waarom statische websites goed terug te zetten zijn
Een statische website bestaat uit een complete set bestanden: HTML, CSS, JavaScript, afbeeldingen, fonts, PDF's en andere assets.
Dat maakt versiegericht publiceren mogelijk. In plaats van één live map telkens te overschrijven, kan elke publicatie een apart pakket zijn. Als een fout pakket live gaat, hoeft het platform niet te raden hoe de oude staat eruitzag. De vorige versie bestaat nog.
| Laag | Wat bewaard moet blijven | Waarom het telt |
|---|---|---|
| Build-output | Exacte bestanden van die versie | U hoeft de oude site niet uit geheugen opnieuw te bouwen. |
| Publicatierecord | Welke versie actief was en wanneer | U kunt een gecontroleerde staat kiezen. |
| Domeinkoppeling | Welke versie de openbare URL bedient | Herstel kan een wissel van actieve versie zijn. |
| Context | Wie publiceerde en wat veranderde | Debuggen begint nadat de publieke impact is beperkt. |
Cloudflare Pages beschrijft rollbacks als teruggaan naar een eerdere productie-deployment. Vercel gebruikt Instant Rollback om productiedomeinen naar een eerdere deployment te wijzen. Netlify laat een eerder deploy opnieuw als productie publiceren. De interface verschilt, maar het model is vergelijkbaar: de vorige versie moet nog bestaan als publiceerbare bestemming.
Bouw de oude site niet opnieuw tijdens een incident
Als rollback betekent dat iemand een oude ZIP zoekt, lokaal opnieuw buildt, opnieuw uploadt en hoopt dat het klopt, is het eigenlijk een noodredeploy.
Dat kan werken, maar het voegt risico toe op het slechtste moment:
- De oude broncode is niet altijd gelijk aan de bestanden die live stonden.
- Dependencies kunnen intussen zijn veranderd.
- Buildvariabelen of instellingen kunnen ontbreken.
- Iemand kan de verkeerde map uploaden.
- De nieuwe upload kan een tweede kapotte staat introduceren.
Een betere herstelroute bewaart succesvolle publicaties en verandert welke versie actief is.
Een korte beslissing, geen eindeloze discussie
Rollback moet geen theoretisch debat worden. Een paar vragen zijn genoeg.
| Vraag | Als ja | Als nee |
|---|---|---|
| Is de live site stuk voor echte bezoekers? | Herstel een stabiele versie. | Een normale correctie kan genoeg zijn. |
| Gaat het alleen om kleine copy? | Overweeg een nieuwe upload. | Blijf de impact beoordelen. |
| Is de vorige versie gecontroleerd? | Gebruik die als doel. | Zoek de laatste echt goedgekeurde versie. |
| Hingen er API's of externe data aan deze wijziging? | Controleer compatibiliteit. | Statisch herstel is waarschijnlijk genoeg. |
| Loopt er een campagne, klantreview of lancering? | Beperk eerst publieke schade. | Er is meer ruimte om vooruit te fixen. |
Deze vragen voorkomen dat het team blijft sleutelen terwijl bezoekers de kapotte versie blijven zien.
Controleer direct na herstel
Een teruggezette versie is pas nuttig als de openbare ervaring weer klopt.
Controleer direct:
- De homepage opent via de openbare link.
- Belangrijke subpagina's en diepe links werken.
- CSS, JavaScript, afbeeldingen, fonts en PDF's laden.
- Het eigen domein en HTTPS blijven actief.
- QR-codes, UTM-links en campagne-URL's wijzen niet naar een kapotte route.
- Recente statistieken laten zien dat bezoekers weer pagina's openen.
Gebruik bij domein- of certificaatvragen een externe check. DeployPages heeft een DNS-check en een SSL-checker voor die kant van de lancering.
Wat rollback niet oplost
Rollback van een statische website herstelt de bestanden die worden uitgeleverd. Het draait geen hele productomgeving terug.
| Probleem | Waarom rollback alleen niet genoeg is |
|---|---|
| Backend-API is veranderd | Een oude frontend kan nog steeds een nieuwe of incompatibele API aanroepen. |
| Database is gemigreerd | Statische bestanden herstellen geen datamodel. |
| Externe scriptprovider faalt | De oude versie kan dezelfde externe afhankelijkheid laden. |
| DNS staat verkeerd | Een werkende versie helpt niet als het domein niet goed wijst. |
| Certificaatprobleem | Bestanden terugzetten lost geen SSL-configuratie op. |
| Tracking- of cookieconfiguratie is fout | De privacy- en scriptlaag moet apart worden gecontroleerd. |
Dat maakt rollback niet minder waardevol. Het maakt de grens duidelijk: het is herstel van de statische publicatiestatus, niet van databases, API's of externe diensten.
Browserupload, Git en CLI: hetzelfde herstelidee
Het invoerkanaal kan verschillen. De herstelgedachte blijft gelijk.
| Publicatiemethode | Wat fout kan gaan | Wat u nodig hebt voor herstel |
|---|---|---|
| Browserupload | Verkeerde map, ontbrekende assets, oude ZIP | Vorige upload als aparte versie |
| Git-publicatie | Build gelukt, output bevat verkeerde paden | Vorige deployment of build-output |
| CLI-publicatie | Verkeerde buildvariabelen of map | Publicatiegeschiedenis en versiecontext |
| AI-export | Placeholdertekst, verzonnen links, kapotte assets | Laatste gecontroleerde export |
| Documentatie of portfolio | Navigatie of deep links breken | Eerdere goedgekeurde publicatie |
Git helpt, maar een commit is niet altijd hetzelfde als het artefact dat bezoekers kregen. Een rebuild kan anders uitvallen als dependencies, omgevingsvariabelen of buildinstellingen zijn veranderd.
Daarom is versiegeschiedenis op publicatieniveau belangrijk.
Hoe DeployPages hierin past
DeployPages is gebouwd voor statische projecten die klein kunnen beginnen en later serieuzer worden.
Een project kan starten met een browserupload van een HTML-bestand, map, ZIP, PDF, framework-build of AI-export. Daarna kan hetzelfde project groeien naar vorige versie herstellen, statistieken, eigen domeinen, wachtwoordbescherming en CLI-publicatie.
Het belangrijkste idee is dat herstel bij de publicatie hoort. Een fout in de live versie hoeft niet te betekenen dat iemand onder druk oude bestanden bij elkaar zoekt.
Minimaal playbook voor de volgende lancering
Gebruik rollback niet pas wanneer er paniek is. Leg vooraf een lichte routine vast.
- Publiceer eerst naar een voorbeeldlink.
- Controleer homepage, subpagina's, assets, formulieren, PDF's en mobiel.
- Noteer welke versie is goedgekeurd.
- Koppel pas daarna het eigen domein of deel de campagne-URL breed.
- Houd de vorige goede versie beschikbaar.
- Bepaal wie een herstelactie mag uitvoeren.
- Controleer na elke nieuwe versie de belangrijkste pagina's en statistieken.
Voor een kleine studentenpagina is dit misschien overdreven. Voor een portfolio, klantpreview, documentatiesite of campagnepagina is het precies de discipline die een slechte upload klein houdt.
Wanneer rollback onmisbaar wordt
Rollback wordt belangrijk zodra een statische website meer is dan een wegwerplink.
Dat moment komt sneller dan verwacht:
- De website heeft een eigen domein.
- Recruiters, klanten of stakeholders gebruiken dezelfde link.
- Een campagne of QR-code verwijst ernaar.
- Meerdere mensen kunnen nieuwe versies publiceren.
- De pagina bevat PDF's, downloads of belangrijke conversiecopy.
- De site wordt regelmatig bijgewerkt.
Een volwassen publicatieproces belooft niet dat er nooit iets misgaat. Het zorgt dat een fout niet langer zichtbaar blijft dan nodig.