Een website bijwerken zonder CMS werkt zo: u stuurt de wijziging in gewone taal via WhatsApp, e-mail of Slack, een AI-agent voert die door in de codebase van de site, en een previewlink komt terug ter goedkeuring. Nadat een senior developer de wijziging heeft beoordeeld, gaat deze live. Geen adminpaneel, geen plugin-updates, geen layout die stiekem breekt.
U wilt al een tijdje van WordPress af, maar één vraag houdt u telkens tegen: wie past de openingstijden aan als er geen backend is om op in te loggen?
Die angst is terecht, want twintig jaar lang betekende het CMS verlaten dat u een developer moest e-mailen en een uurtarief met minimum moest betalen voor een reparatie van twee minuten. Dit artikel loopt de exacte update-workflow van webvise op klantsites langs, laat zien hoe een wijzigingsverzoek er in de praktijk uitziet, en bespreekt wanneer een headless CMS zoals Sanity de betere keuze is. Aan het eind hoeft de bewerkingsvraag niet langer de reden te zijn om een WordPress-installatie in leven te houden.
- Gewone taal vervangt het adminpaneel. Wijzigingsverzoeken gaan via WhatsApp, e-mail of Slack, in de woorden die u ook tegen een collega zou gebruiken.
- Elke wijziging komt terug als previewlink: een volledige private kopie van de site met de wijziging verwerkt, op een eigen URL, voordat er iets live gaat.
- Twee controlemomenten in plaats van nul. De klant keurt de preview goed, en een senior developer leest de daadwerkelijke codewijziging voordat deze wordt uitgerold.
- Elke wijziging wordt bijgehouden in git, zodat elke eerdere staat van de site kan worden hersteld.
- Bij een hoog bewerkingsvolume blijft een CMS nodig. Teams die dagelijks publiceren krijgen in plaats daarvan Sanity in de build.
De angst die elke migratie tegenhoudt
De vraag waarmee bijna elk migratiegesprek bij webvise begint, is een variant van 'kan ik mijn site daarna nog zelf bewerken?' Die vraag komt eerder dan de kosten, eerder dan de planning, soms zelfs eerder dan SEO. De FAQ over de migratie van WordPress naar Next.js beantwoordt elf veelvoorkomende bezwaren, en dit is degene die het eerst wordt gesteld.
Die angst heeft een geschiedenis. Het CMS verlaten betekende vroeger drie dagen wachten tot een developer een foto verving, dus een opgeblazen WordPress-installatie aanhouden voelde rationeel, zelfs tegen de € 1.500 tot € 5.000 per jaar die het werkelijk kost. Het adminpaneel kocht een gevoel van controle, en de jaarlijkse factuur was de prijs van dat gevoel.
Twee dingen maakten een einde aan die afweging: AI-agents die scoped wijzigingen in een echte codebase kunnen doorvoeren, en preview-deployments die elke wijziging tonen voordat ze wordt uitgerold. De WordPress-migratieservice van webvise bouwt deze bewerkingsworkflow in elke rebuild in. De rest van dit artikel laat zien hoe dat er voor de klant uitziet.
De workflow: bericht erin, previewlink eruit
De cyclus telt zes stappen, en u bent maar bij twee daarvan nodig.
| Stap | Wie | Wat er gebeurt |
|---|---|---|
| 1. Stuur de wijziging | U | Een bericht in gewone taal via WhatsApp, e-mail of Slack. Screenshots en foto's werken ook. |
| 2. Implementatie | AI-agent | De agent voert de wijziging door in de codebase van de site, volgens het bestaande designsysteem. |
| 3. Preview-deploy | Automatisch | Een volledige kopie van de site met de wijziging verwerkt gaat live op een eigen private URL. |
| 4. Goedkeuring | U | Open de link op uw telefoon en reageer met een OK of met correcties. Correcties gaan terug naar stap 2. |
| 5. Codereview | webvise | Een senior developer leest de daadwerkelijke wijziging voor de merge. Niets wordt uitgerold op basis van agentoutput alleen. |
| 6. Live | Automatisch | De wijziging wordt uitgerold naar de productiesite. De vorige staat blijft herstelbaar vanuit de git-historie. |
De previewlink is wat de angst wegneemt. Het is de echte site met uw wijziging verwerkt, dus wat u goedkeurt is precies wat live gaat. WordPress bood dat nooit: u bewerkte in de backend en hoopte dat de frontend meewerkte.
De codereview weegt net zo zwaar. Ik lees elke wijziging voordat deze wordt samengevoegd, een strengere maatstaf dan enig CMS ooit heeft gehanteerd. Een adminpaneel publiceert alles wat de laatste persoon met een inlog erin heeft getypt.
Hoe dit er in de praktijk uitziet
De site die u nu leest, draait op precies deze cyclus. webvise.io verschijnt in 7 talen, de blog erachter bestaat uit 124 posts en 868 contentbestanden in één git-repository, en elk artikel, elke prijsupdate en elke copywijziging loopt via een agent, een preview-deployment en een review voor de merge. Er zit nergens een CMS in de stack, en dit artikel heeft u via diezelfde pipeline bereikt.
Verzoeken van klanten zijn alledaags, en dat is precies het punt. Nieuwe openingstijden, een nieuw teamlid, verse projectfoto's, een seizoensbanner, een bijgewerkte prijslijst: elk daarvan is een bericht van twee regels in plaats van een login en een page-buildersessie die de layout stiekem kan breken. De doorlooptijd hangt niet langer af van de agenda van een developer, omdat de implementatie begint zodra het verzoek binnenkomt. De twee mensen in de cyclus, u die goedkeurt en ik die controleer, zijn de enige wachttijd.
Alles dat groter is dan een contentwijziging wordt eerst afgebakend. Een nieuwe pagina, een boekingsflow, een derde taal: die doorlopen eerst een korte inschatting voordat een agent de codebase aanraakt. Het kanaal is voor de routinematige wijzigingen die vroeger een reden waren om een CMS te blijven installeren.
Updatekanaal versus WordPress-admin versus Sanity CMS
Drie bewerkingsmodellen dekken bijna elke zakelijke site. De eerlijke vergelijking ziet er zo uit:
| WordPress-admin | Sanity CMS (headless) | Updatekanaal | |
|---|---|---|---|
| Wie maakt de wijziging | U, in een page builder | U, in een gestructureerde editor | U beschrijft het, een agent voert het door |
| Layout kan breken | Ja, regelmatig | Nee, content staat los van vormgeving | Nee, elke wijziging is gereviewde code |
| Review voor live | Geen | Optionele concepten | Previewlink plus codereview |
| Versiegeschiedenis | Alleen posts, met plugins | Per document | De hele site, in git |
| Sterk in | Gewoonte | Dagelijks publiceren, gestructureerde content | Een handvol wijzigingen per maand |
| Doorlopende kostenpost | Plugins, hosting, patches | CMS-abonnement plus de build | Supportabonnement |
De beslissende factor is het bewerkingsvolume. Een bedrijf dat twee keer per jaar referenties bijwerkt en elk kwartaal een vacature plaatst, heeft aan een CMS-licentie niets anders dan de beveiligingspatches. Een contentteam dat elke ochtend publiceert heeft directe toegang nodig, en geen berichtenkanaal moet daarbij in de weg staan.
Wanneer Sanity het juiste antwoord is
webvise koppelt Sanity aan Next.js-builds wanneer het bewerkingsvolume een echte redactionele interface rechtvaardigt. De bewerkingservaring voelt dicht bij WordPress aan, de frontend blijft statisch en snel, en publiceren heeft helemaal geen goedkeuringscyclus nodig. Wat een headless CMS is, wat het kost, en waar de afwegingen liggen, staat in de headless-CMS-gids in gewone taal.
- Publiceren volgens een schema. Blogposts, nieuws of cases die wekelijks of vaker verschijnen.
- Meerdere redacteuren. Marketing, HR en sales werken allemaal aan content, met concepten en rollen.
- Gestructureerde content. Productcatalogi, locaties of cursussen: data met velden, geen pagina's.
- Publiceren binnen de minuut, omdat het volume een reviewcyclus onpraktisch maakt.
Beide modellen draaien prima naast elkaar in één build. Een site kan zijn productpagina's uit Sanity serveren terwijl ontwerp- en functiewijzigingen via het kanaal blijven lopen. De twee beantwoorden verschillende vragen: wie bewerkt, en hoe vaak.
Wat het kost en hoe het is opgebouwd
Updatewerk valt binnen de doorlopende supportvorm van webvise: monitoring, fixes, kleine verbeteringen, en een supportritme dat wordt afgesproken voordat de samenwerking start. Een abonnement is nooit verplicht, en er bestaat een regeling naar behoefte voor sites die twee keer per jaar veranderen. Wat een onderhoudsbudget wel en niet zou moeten bevatten, staat uitgewerkt in de gids over website-onderhoudskosten.
Vergelijk dat met de € 1.500 tot € 5.000 per jaar die het in leven houden van een gemiddelde WordPress-site voor een klein bedrijf kost. Het grootste deel van dat budget koopt stilstand: plugin-verlengingen, hostingtiers, beveiligingspatches. Een berichtenkanaal zet datzelfde budget om in zichtbare veranderingen op de site.
Als de bewerkingsvraag de reden was om WordPress aan te houden, beantwoordt de workflow hierboven die vraag. webvise verzorgt de rebuild via de WordPress-migratieservice, en zet vervolgens het updatekanaal, een Sanity-installatie, of beide op, afgestemd op uw bewerkingsvolume. Voor al het overige bereikt u Sebastian rechtstreeks via webvise.io/#contact.
De werkwijzen van webvise zijn afgestemd op de ISO 27001- en ISO 42001-normen.