De Claude Code tech stack voor een agentic website

Kort antwoord: Een agentic website is een marketingsite die AI-agents helpen bouwen, beheren en verbeteren, terwijl mensen de wijzigingen goedkeuren die ertoe doen. De stack die daarbij past, houdt alles wat een agent aanraakt in bestanden die hij kan lezen: een static site framework zoals Astro, een headless CMS met schema's in code zoals Sanity, een host met deploy previews en geplande functies zoals Netlify, en Claude Code dat via pull requests werkt.

De meeste B2B SaaS-teams gebruiken inmiddels AI om teksten te schrijven. Veel minder teams laten een agent de website zelf aanpassen, en wie het probeert, ontdekt vaak op de harde manier waarom: een platform dat is gemaakt om rond te klikken in een visuele editor geeft een agent niets om te lezen, niets om te testen en geen veilige plek om dingen uit te proberen. De oplossing is een stack en een set regels die vanaf het begin voor de agent zijn gemaakt.

Deze gids beschrijft die stack, de vangrails die een live site veilig houden en de agentworkflows die erop draaien. Hij is geschreven vanuit de rebuild van saas-hackers.com, die draait op Astro, Tailwind, Sanity en Netlify en is gebouwd met Claude Code. Weet je nog niet precies wat je website moet doen? Begin dan met onze gids voor B2B SaaS-websitestrategie en kom terug voor de bouw.

Wat is een agentic website?

Een agentic website is een site waarbij AI-agents een groot deel van het bouwen en onderhouden doen, binnen regels die mensen opstellen en controles die elke keer draaien. Agents schrijven pagina's, repareren links, verversen content en dienen codewijzigingen in. Mensen bepalen waar de site voor dient, keuren alles goed wat risicovol is en controleren de resultaten.

Dat is iets anders dan een AI-websitebuilder, die een site één keer genereert op basis van een prompt. Op een agentic website blijft de agent na de livegang doorwerken, zoals een developer en een contenteditor dat zouden doen, en elke wijziging die hij maakt doorloopt dezelfde review als die van een mens.

Drie dingen maken een site agentic in plaats van alleen AI-ondersteund:

• De agent kan alles lezen wat de site bepaalt. Paginatemplates, contenttypes, design tokens, redirects en de regels zelf staan in een coderepository, niet alleen in een dashboard.
• Elke wijziging kan worden getest voordat die live gaat, met een build die faalt bij een kapotte pagina, een previewlink voor elke wijziging en een dry run voor elk contentscript.
• Mensen houden de sleutels in handen die ertoe doen. Code mergen, gevoelige content publiceren en alles wat geld kost blijft bij een persoon met naam en toenaam.

Waarom is de stack belangrijker als agents het werk doen?

De stack is belangrijker omdat een agent alleen veilig kan werken met wat hij kan zien en controleren. Een mens ziet in een visuele editor dat een pagina er niet goed uitziet. Een agent heeft die kennis uitgeschreven nodig: als een schema dat een ontbrekend veld weigert, een check die de build laat falen of een regel in een bestand dat hij voor elke sessie leest.

Een stack die voor agents is gebouwd, heeft vier eigenschappen:

1. Tekst boven klikwerk. Configuratie, contentmodellen en stijlen zijn bestanden in de repository, zodat een agent ze kan lezen, aanpassen en uitleggen.
2. Snelle, eerlijke feedback. Een build of test die luid faalt, vertelt de agent dat hij het fout heeft voordat een bezoeker dat doet.
3. Een veilige plek om te proberen. Met branches, concepten en previewlinks kan een agent zijn werk laten zien zonder de live site aan te raken.
4. Eén reviewpoort. Elke codewijziging komt binnen als pull request die een persoon kan lezen en mergen of afwijzen.

Als dit op orde is, maakt de keuze van het model minder uit. Zonder dit breekt zelfs een zorgvuldige agent uiteindelijk iets, omdat niets hem vertelt dat het gebeurd is.

Wat is de Claude Code-techstack voor een agentic website?

De stack heeft vijf lagen: een static site framework, een headless CMS, een host, de agent en de reviewpoort ertussen. Elke laag is er omdat ze de agent iets geeft om te lezen of iets om te controleren.

Een static site framework: Astro

Astro bouwt pagina's vooraf. Standaard rendert het elke pagina, route en endpoint tijdens de build vooraf als statische HTML, en je kiest per route voor rendering op aanvraag als dat nodig is (Astro, 2026). Voor een agent is statische output een cadeautje: na een build bestaat de hele site als bestanden, zodat een script elke pagina kan controleren voordat er iets live gaat.

SaaS Hackers rendert elke pagina statisch. De enige pagina die op aanvraag wordt gerenderd is de conceptpreview, die editors vanuit het CMS openen om niet-gepubliceerde wijzigingen te zien. Al het andere wordt tijdens de build gecontroleerd en de content staat bij de eerste load in de HTML, inclusief elk item in een gefilterde lijst.

Een headless CMS met schema's in code: Sanity

Een headless CMS houdt content gescheiden van het ontwerp van de site en levert die via een API aan de site. Voor agents draait het om de plek waar het contentmodel staat. In Sanity beschrijft een schema de typen documenten en velden die editors mogen aanmaken, en dat staat in code in de configuratie van de Studio (Sanity, 2026).

Omdat de schema's code zijn, kan een agent precies lezen waaruit een blogpost of een profiel bestaat, via een pull request een veld toevoegen en content schrijven met scripts die het schema valideert. Editors houden gewoon een visuele editor. SaaS Hackers houdt elk schema in de repository en nooit alleen in het dashboard, een van de regels in het projectbestand.

Een host met previews en functies: Netlify

De host geeft de agent twee dingen: een preview van elke wijziging en een plek om kleine taken uit te voeren. Netlify bouwt automatisch een deploy preview als er een pull request wordt geopend in een gekoppelde repository, op een eigen adres, en voegt er een noindex-header aan toe zodat zoekmachines hem met rust laten (Netlify, 2026). Met die previewlink controleert een persoon de wijziging van een agent op een echte pagina voordat die wordt gemerged.

Geplande functies van Netlify draaien als een cronjob volgens een vast schema in UTC, alleen op de gepubliceerde productiedeploy, met een limiet van 30 seconden per run (Netlify, 2026). Korte, geplande taken passen goed bij agentic onderhoud: controleren of er iets is veranderd en dan beslissen of er opnieuw gebouwd moet worden.

Claude Code: CLAUDE.md, skills, hooks en MCP

Claude Code is de agent. Vier van de functies maken van een capabel model een betrouwbaar teamlid:

• CLAUDE.md. CLAUDE.md-bestanden zijn Markdown-bestanden die Claude blijvende instructies voor een project geven, en Claude leest ze aan het begin van elke sessie (Anthropic, 2026). Via versiebeheer gedeeld bevat het projectbestand de buildcommando's, standaarden en regels waaraan iedereen zich houdt.
• Skills. Een skill is een SKILL.md bestand met instructies dat Claude aan zijn gereedschapskist toevoegt en gebruikt wanneer het relevant is. In tegenstelling tot CLAUDE.md wordt de inhoud van een skill pas geladen als hij wordt gebruikt, dus lange procedures kosten vrijwel niets tot ze nodig zijn (Anthropic, 2026). Onze uitleg over Claude Skills voor marketingteams laat zien hoe ze werken voor copy.
• Hooks. Hooks zijn shellcommando's die Claude Code op vaste momenten uitvoert, waardoor je deterministische controle krijgt: bepaalde acties gebeuren altijd, in plaats van dat je erop vertrouwt dat het model ze kiest (Anthropic, 2026). Gebruik ze voor regels die nooit mogen buigen, zoals het blokkeren van wijzigingen in een bestand met geheimen.
• MCP-servers. Het Model Context Protocol is een opensourcestandaard om AI-tools met andere systemen te verbinden, en MCP-servers geven Claude Code toegang tot je tools, databases en API's (Anthropic, 2026). Zo leest een agent analytics, rankings of een CMS rechtstreeks uit in plaats van te werken met wat jij plakt. In onze gids over AI-marketingagents en MCP lees je welke marketingtools je kunt koppelen.

Cloudsessies en geplande taken

Een cloudsessie is een Claude Code-sessie die op cloudinfrastructuur draait in plaats van op je laptop, en blijft doorlopen als je de klep dichtdoet (Anthropic, 2026). Geplande en getriggerde runs starten elk als cloudsessie. Daardoor kan een agent om 01:43 uur een blogpost publiceren of op een dinsdagochtend rankings meten zonder dat iemand achter een toetsenbord zit.

GitHub pull requests als reviewpoort

Elke codewijziging die een agent doorvoert, komt op een branch terecht en wordt aangeboden als pull request. De deploy preview wordt daarvan gebouwd, de checks draaien erop, en een mens merget de pull request of niet. Bij SaaS Hackers is de regel simpel: agents openen pull requests, en Darren merget ze. Geen enkele agent merget zijn eigen werk.

Hoe voorkom je dat een agent een live website kapotmaakt?

Je voorkomt dat een agent een live site kapotmaakt door het veilige pad het enige pad te maken: een back-up vóór elke schrijfactie, een dry run die de wijziging laat zien, checks in elke build en grenzen aan wat de agent zelfstandig mag aanpassen. Geen van deze maatregelen hangt ervan af dat de agent eraan denkt voorzichtig te zijn. Ze zijn vastgelegd in scripts, schema's en de build.

Back-up, dry run, dan schrijven

Elk script dat gepubliceerde content op SaaS Hackers wijzigt, werkt op dezelfde manier:

1. Back-up. npm run backup exporteert de hele dataset naar een gedateerd bestand voordat er iets verandert.
2. Dry run. Het script draait zonder --write, controleert alles en schrijft een rapport van wat het zou wijzigen.
3. Lees de dry run. De agent of een mens leest dat rapport voordat er verder wordt gegaan.
4. Schrijven. Pas daarna draait hetzelfde script met --write.
5. Controleren. De site wordt gebouwd op basis van de gepubliceerde content en de route- en schemachecks draaien.

In de overdracht na elke klus staat welke back-up is gemaakt, zodat elke wijziging kan worden teruggezet.

Vergrendelingen in het CMS

Sommige fouten voorkom je goedkoper in het CMS dan dat je ze later opspoort. In de Studio van SaaS Hackers wordt een slug vergrendeld zodra het document is gepubliceerd, zodat een live adres niet per ongeluk kan veranderen. Een pagina kan niet worden gepubliceerd op een adres met een actieve redirect, en nieuwe afbeeldingen kunnen niet zonder alt-tekst worden gepubliceerd. Scripts depubliceren in plaats van te verwijderen en laten concepten van anderen met rust.

Checks in elke build

De build is de eerlijkste criticus van de agent. Bij SaaS Hackers npm run build stopt als een van deze checks faalt:

• verouderde design tokens, kleuren of groottes die buiten de tokens vallen, of tekst die de contrastcheck niet haalt;
• een sectieblok in het CMS zonder bijbehorende paginacomponent;
• gestructureerde data die niet te parsen is of het schema van het paginatype mist, of een pagina zonder precies één H1;
• taallinks (hreflang) die niet naar elkaar terugwijzen.

Na een build controleert de routecheck of elk live adres binnen de scope een 200 teruggeeft, en vergelijkt de pariteitscheck titels, beschrijvingen, canonicals, koppen en schema met de live site. Ook snelheid hoort bij de checks: ons handboekartikel over Core Web Vitals legt uit welke metingen het volgen waard zijn.

Geheimen blijven buiten de repository

Tokens en sleutels staan in een lokaal .env bestand dat git negeert, en in de omgevingsvariabelen van de host. De repository bewaart alleen een lijst met hun namen. Een agent kan een sleutel gebruiken die in zijn omgeving staat zonder die ooit in een bestand, commit of rapport te schrijven.

Grenzen aan wat een agent zelfstandig mag wijzigen

Bepaal vooraf wat een agent mag doen zonder te vragen, schrijf het op en dwing het af in code waar dat kan. Zo verdeelt SaaS Hackers het nu:

• Blogposts worden meteen gepubliceerd nadat de checks van het script zijn gehaald, en een mens bekijkt ze achteraf.
• Paginateksten, titels en interne links worden gewijzigd door de SEO-agent, binnen vaste grenzen per run.
• Codewijzigingen gaan naar een pull request die een mens merget.
• Profielverzoeken van bureaus wachten tot een mens in Slack op Approve tikt.
• Scores, reviews en rankings worden nooit door een agent of op verzoek gewijzigd.

Kostenlimieten

Agents kunnen snel geld uitgeven, dus kosten zijn ook een vangrail. SaaS Hackers bouwde ooit bij elke publicatie opnieuw, en elke productie-deploy kost 15 Netlify-credits. Rebuilds zijn nu beperkt tot één keer per dag: een geplande functie draait om 05:17 UTC en bouwt alleen opnieuw als er iets is gepubliceerd sinds de live build. In de briefing van de SEO-agent staat bovendien dat hij nooit zelf een deploy mag starten.

Welke agentworkflows draaien er op een agentic website?

Zodra de stack en de vangrails er staan, kunnen agents het terugkerende werk overnemen dat vaak blijft liggen: publiceren, meten, verversen en vertalen. Elke workflow heeft een schriftelijke briefing, een schema, grenzen en een rapport.

Om de twee dagen een blogpost publiceren

Een geplande taak schrijft en publiceert om de twee dagen om 01:43 UTC één post uit de contentbacklog, vóór de dagelijkse rebuild. Hij schrijft met een copywriting-skill en controleert het stuk met een contentaudit-skill. Daarna weigert een publicatiescript de post als het een em dash, een placeholder, een verkeerde slug, een te lange metabeschrijving, minder dan drie interne links of een interne link die niet live is aantreft. Hij maakt alleen nieuwe posts aan en past nooit een bestaande aan.

Een SEO-agent die twee keer per week meet en actie onderneemt

Op dinsdag en vrijdag om 06:41 UTC meet een verse sessie de rankings, scoort de site tegen de doelen en werkt een gerangschikte lijst met acties af. Elke run mag maximaal 8 pagina's wijzigen, 1 nieuwe lijst aanmaken en 30 interne links toevoegen, met plafonds voor betaalde data-aanroepen en vertaalkosten. Hij legt elke wijziging vast met een kopie van de oude versie zodat die kan worden teruggezet, stuurt codewijzigingen naar pull requests en rapporteert in het Slack-kanaal van het team. In onze vergelijking van Claude Code en AirOps voor contentteams lees je wanneer zo'n opzet beter werkt dan een no-code tool.

Bureauprofielen actueel houden

Een maandelijks script controleert de website van elk bureau en legt vast of die werkt, is verhuisd of stuk is. Een kwartaalcrawl leest de eigen site van elk bureau en slaat de feiten op die daar staan, waarbij hij service- en branchetags toevoegt die de site noemt, maar er nooit een verwijdert. Scores, reviews en rankings blijven door beide onaangeroerd.

Verzoeken goedgekeurd in Slack

Bureaus kunnen vragen hun profiel bij te werken of zich aan te melden voor een vermelding. Elk verzoek wordt per e-mail bevestigd, door Claude gecontroleerd aan de hand van de eigen website van het bureau, opgeslagen als CMS-concept en als kaart naar Slack gestuurd. Alleen een bevoegd persoon kan op Approve tikken, elke klik wordt gecontroleerd met de verzoekhandtekening van Slack, en over elk verzoek kan maar één keer worden beslist.

Elke pagina vertalen

Elke pagina op SaaS Hackers wordt ook gebouwd in het Duits, Frans, Spaans, Nederlands, Japans en Braziliaans Portugees. Claude Sonnet 5.5 vertaalde de site via de Batch API voor in totaal $91,35, en latere runs sturen alleen tekst die is gewijzigd. Citaten en wat bureaus op hun eigen website zeggen, blijven woordelijk in het Engels.

Hoe is SaaS Hackers op deze stack gebouwd?

SaaS Hackers is met Claude Code in fasen verbouwd van Webflow naar Astro, Tailwind, Sanity en Netlify, waarbij elke fase een pull request was die iemand van SaaS Hackers bekeek en mergede. Het projectbestand bepaalde de volgorde, de regels en de commando's, en een schriftelijke specificatie legde vast wat "klaar" betekende voor elke fase. De designkant van die verbouwing staat in onze gids over een website bouwen met Claude Code.

Bij de migratie gingen 233 posts en 172 expertprofielen eerst als concept naar Sanity, waarna ze werden vergeleken met de live pagina's voordat er iets werd gepubliceerd. In de SEO-fase kwamen een check of de gestructureerde data van elke pagina te parsen is en een pariteitscheck tegen de live site erbij. Toen de nieuwe site Webflow verving, gaf de routecheck 494 van de 494 live adressen terug, duurde een build van 3.936 pagina's (Engels, de Amerikaanse versie en zes talen) 8,5 minuten en scoorde Lighthouse mobiele performance 99 tot 100 op de pagina's die in productie zijn getest.

Dezelfde stack draagt nu de agentworkflows hierboven. Drie dingen maakten dat mogelijk: een projectbestand dat elke sessie leest, scripts die slechte invoer weigeren en een mens die de code merget. Wil je ook de marketing-operationskant van dit verhaal, dan behandelt onze gids over B2B SaaS marketing operations de data en tools rond de site.

Wat zijn de voordelen van een agentic website?

De voordelen komen voort uit terugkerend werk dat steeds op tijd wordt gedaan, met een verslag van wat er is veranderd:

• Onderhoud gebeurt op tijd. Kapotte links, verouderde feiten en ontbrekende metabeschrijvingen worden volgens schema opgelost in plaats van in een jaarlijkse opruimronde.
• Wijzigingen zijn terug te draaien. Back-ups, kopieën van de oude versie en pull requests zorgen dat elke wijziging van een agent te herleiden en ongedaan te maken is.
• Er zijn minder overdrachten. Eén agent kan content, templates en checks in dezelfde pull request wijzigen, in plaats van werk door te geven tussen een schrijver, een developer en een SEO-specialist.
• De lopende kosten kunnen laag zijn met de juiste stack. Uit de eigen kostenreview van SaaS Hackers bleek geen extra hostingabonnement nodig voor de nieuwe site, waarbij de belangrijkste kostenpost om in de gaten te houden de Netlify-credits voor deploys is.

Veelvoorkomende problemen met agentic websites en hoe je ze oplost

De agent maakt twee keer dezelfde fout. Hij onthoudt niets van de vorige sessie. Schrijf de regel in CLAUDE.md of in een skill zodra je de fout corrigeert, zodat elke volgende sessie ermee begint.

Wijzigingen zien er in de code goed uit, maar op de pagina klopt er iets niet. Zonder preview ziet niemand de pagina voordat die live staat. Eis in elke pull request een link naar een deploy preview en controleer de pagina zelf voordat je mergt.

De checks slagen, maar de site wijkt toch af. Checks vangen alleen op wat ze testen. Glipt er iets door, voeg dan een check ervoor toe aan de build, zodat het niet nog een keer kan gebeuren.

De kosten lopen op. Elke rebuild, elke crawl en elke API-call kost geld. Zet in de briefing van elke agent een limiet, bundel rebuilds en rapporteer de uitgaven in de overdracht na elke run.

Niemand weet wat de agent heeft aangepast. Vraag na elke klus om een overdracht: wat er is veranderd, welke back-up er is gemaakt, welke checks zijn uitgevoerd en wat de agent niet kon doen.

Waar je op let als je hulp inhuurt om er een te bouwen

Haal je een bureau of developer in om een agentic website te bouwen, vraag dan om de guard rails te zien, niet alleen het ontwerp. Een goede partner laat je het volgende zien:

• een projectinstructiebestand en de regels die erin staan;
• contentscripts met een dry run en een back-upstap;
• buildchecks die falen bij echte problemen, met de commando's om ze uit te voeren;
• een duidelijke scheiding tussen wat agents zelf mogen aanpassen en wat een mens goedkeurt;
• schriftelijk vastgelegde lopende kosten, inclusief deploys en API-gebruik.

Vergelijk specialisten op onze lijst met de beste webdesignbureaus voor B2B SaaS.

Over SaaS Hackers

SaaS Hackers is een community van B2B SaaS-specialisten die praktijkgerichte inzichten delen, gebouwd door de mensen achter de groei: marketeers, strategen en bouwers. Het publiceert gidsen, een handboek en toplijsten, en beheert een gids met B2B SaaS-marketingbureaus en -experts. SaaS Hackers wordt gerund door Team 4, een B2B SaaS-marketingbureau dat in de gids staat en is gerankt.