SEO automatiseren met AI: zo bouw je een zelfverbeterende cyclus

Waarom SEO automatiseren met AI nu logisch is

Een agent als Hermes kan een API bevragen, bestanden lezen en schrijven, een build draaien en het resultaat controleren. Voor terugkerende GSC-analyses combineer ik die tools met een apart serviceaccount: gcloud regelt de Cloud-setup, en in Search Console geef je dat account leesrechten op de property. De agent kan vervolgens data ophalen zonder te wachten tot ik opnieuw via een browser inlog.

SEO is daarvoor de ideale toepassing, om drie redenen:

• De brondata is objectief. Search Console toont letterlijk waarmee mensen je vinden: queries, vertoningen, kliks, posities. Dat geeft de agent brondata, maar voorkomt geen hallucinaties of verkeerde interpretaties. Controleer zijn conclusies tegen de export; geanonimiseerde queries en API-limieten maken de data onvolledig.
• De feedbackloop bestaat al. Na elke wijziging zie je dertig dagen later in dezelfde data of het effect had. Dat is een perfecte leerlus voor een stapsgewijs proces.
• Het werk is repetitief maar oordeelkundig. Data ophalen en ordenen is pure routine. Interpreteren en prioriteren vraagt juist oordeel. Precies die mix is waar een begeleide agent sterk in is.

Wie dit handmatig doet, pakt het vaak één keer per kwartaal op, met een spreadsheet en goede moed. De agent maakt er een vast ritme van — en ritme is in SEO de belangrijkste succesfactor die niemand wil horen.

Wat je nodig hebt: gcloud, GSC-toegang en een agent

Voor de geplande SEO-runs gebruik ik gcloud met een apart serviceaccount. De agent krijgt een eigen Google-identiteit die je als gebruiker met leesrechten toevoegt aan de Search Console-property. Hij is dus niet afhankelijk van mijn persoonlijke login. Je hebt nodig:

• Een Google Cloud-project en gcloud, met een beheerder die de Search Console API mag activeren en het serviceaccount mag aanmaken.
• Een eigenaar van de Search Console-property die dat account kan toevoegen onder Gebruikers en rechten.
• Een agent die tools kan gebruiken, zoals Hermes van Nous Research, Claude Code, Cursor-agents of een eigen toepassing rond een taalmodel.
• Een git-repository voor kleine, controleerbare websitewijzigingen, gescheiden van de Google-credentials.

Een apart serviceaccount maken met gcloud

Voer deze eenmalige instelcommando’s uit als menselijke beheerder met de benodigde Cloud-rechten. Vervang YOUR_PROJECT_ID door je bestaande project-ID; de voorbeeldnaam van het account is seo-reader:

gcloud services enable searchconsole.googleapis.com iam.googleapis.com \
  --project=YOUR_PROJECT_ID
gcloud iam service-accounts create seo-reader \
  --display-name="SEO read-only access" \
  --project=YOUR_PROJECT_ID

Het e-mailadres wordt seo-reader@YOUR_PROJECT_ID.iam.gserviceaccount.com. Geef dit account geen brede Cloud-rollen zoals Owner of Editor. Een Cloud IAM-rol geeft geen toegang tot je Search Console-property; die voeg je afzonderlijk toe. Heeft het account rechten nodig om het quota-project te gebruiken, geef het daar dan de beperkte rol Service Usage Consumer, geen projectbeheerrechten. Zie Googles uitleg over serviceaccounts aanmaken.

Het serviceaccount als beperkte GSC-gebruiker toevoegen

De eigenaar opent in Search Console de juiste property en gaat naar Instellingen → Gebruikers en rechten → Gebruiker toevoegen. Vul het volledige e-mailadres van het serviceaccount in, kies Beperkt en voeg het toe. Je hoeft het account geen eigenaar te maken of het domein opnieuw te verifiëren. Googles overzicht van gebruikersrechten bevestigt dat een beperkte gebruiker het prestatierapport kan lezen. Dat is de data die deze cyclus nodig heeft.

Stel de API-client in om https://www.googleapis.com/auth/webmasters.readonly aan te vragen, zoals beschreven bij Search Console-autorisatie. De propertyrol beperkt wat het account mag; de OAuth-scope beperkt wat het API-token mag. Die scope is niet aan één website gebonden. Voeg het account dus alleen toe aan properties die de workflow nodig heeft. Een domeinproperty gebruikt een identificatie zoals sc-domain:example.com; een URL-prefixproperty gebruikt haar exacte URL-prefix.

Draaien zonder terugkerende persoonlijke login

Gebruik een gekoppeld serviceaccount of Workload Identity Federation als de runtime en GSC-client dat ondersteunen. Zo hoef je geen langlevende privésleutel op te slaan. Heeft je lokale runner een JSON-sleutel nodig, maak die dan in Google Cloud aan onder het serviceaccount via Keys → Add key → Create new key. Volg het sleutelbeleid van je organisatie en bewaar het bestand buiten je repository. Onderstaand pad is een placeholder voor dat beveiligde bestand:

chmod 600 /secure/path/seo-reader.json
export GOOGLE_APPLICATION_CREDENTIALS="/secure/path/seo-reader.json"
export GOOGLE_CLOUD_QUOTA_PROJECT="YOUR_PROJECT_ID"

Zet deze variabelen in de omgeving die de agent of zijn GSC-koppeling werkelijk start, ook bij geplande runs. Een cron-job neemt de exports uit je interactieve shell niet automatisch over. Gebruik een client die Application Default Credentials (ADC) ondersteunt, met de bovenstaande lees-scope. ADC vindt de credentials, maar bepaalt de rechten niet voor je. ADC en de gcloud-CLI gebruiken bovendien afzonderlijke credentialconfiguraties: ingelogd zijn in gcloud stelt de credentials van de toepassing niet in.

Googles authenticatiebibliotheek vraagt voor het serviceaccount automatisch kortlevende toegangstokens aan en vernieuwt ze zonder interactieve browserlogin. Persoonlijke OAuth kan tokens ook vernieuwen, maar koppelt de taak aan de autorisatie van een persoon. Met een serviceaccount vervalt die afhankelijkheid, wat onbeheerde runs eenvoudiger te onderhouden maakt. Onderhoud blijft nodig: roteer sleutels, trek ongebruikte credentials in en controleer de rechten. Houd sleutels en tokens uit prompts, logs, Git en browsercode; Googles richtlijnen voor sleutelbeheer leggen de risico’s uit.

Voer vóór het inplannen een kleine query voor prestatiedata uit met dezelfde client en omgeving als de geplande taak. Controleer de bedoelde property en het serviceaccount. Stop bij een toegangsprobleem in plaats van terug te vallen op je persoonlijke credentials. Isoleer de runner ook van andere credentials. Websitewijzigingen blijven via je codebase en review-flow lopen; GSC-leesrechten geven geen toestemming om te publiceren.

Stap 0101

De cyclus: data ophalen

Elke run begint hetzelfde: de agent haalt verse Search Console-data op voor een afgebakende periode — bijvoorbeeld de laatste dertig dagen, of een vergelijking met de dertig dagen daarvoor. Hij vraagt per pagina de topqueries op, met vertoningen, kliks, CTR en gemiddelde positie, en schrijft dat weg als een gestructureerd bestand in de repo. Vanaf dat moment werkt hij niet meer met live API’s maar met een momentopname die je kunt nazien en vergelijken met vorige runs.

Belangrijk detail: Search Console-data is pas na een paar dagen definitief. Google zelf zegt over recente datapunten: “Each fresh data point will be replaced with the final data point after a few days” (Google Search Central Blog over datafreshheid). Wie te vroeg meet, trekt conclusies uit getallen die nog verschuiven. Daarom werkt de agent met afgeronde periodes en vergelijkt hij bij voorkeur maand tegen maand, nooit dag tegen dag.

Stap 0202

Prioriteren: waar zit de grootste winst?

Met de data op tafel zoekt de agent naar patronen die een beslissing waard zijn:

• Veel vertoningen, weinig kliks op een query waar je pagina al goed op scoort: vaak een title- of meta description-probleem, geen contentprobleem.
• Positie 8 tot 20 met dalende trend: de pagina is relevant genoeg om te ranken maar niet overtuigend genoeg om door te stoten. Hier helpen aanscherping van de zoekintentie en interne links.
• Queries waarvoor je geen goede pagina hebt: contentgaten. Die leiden tot een nieuw artikel of een uitbreiding van een bestaande pagina — niet tot keyword-stuffing op een willekeurige pagina.
• Meerdere pagina’s die op dezelfde query concurreren: cannibalisatie. Eén pagina versterken, de ander een eigen invalshoek geven.

De agent stelt per bevinding een hypothese: deze pagina, deze query, deze verwachte ingreep, dit verwachte effect. Niet meer dan één of twee per run. Wie tien dingen tegelijk verandert, weet achteraf niet wat werkte.

Stap 0303

Eén kleine verbetering doorvoeren

Dan komt het mensenmoment. De agent bereidt de wijziging voor — een herschreven intro die de echte zoekintentie voorop zet, een betere title-tag, een interne link vanaf een sterke pagina — en jij kijkt er voorlopig altijd na. De verandering is bewust klein: één pagina, één aspect, te beschrijven in één zin. “Deze intro belooft nu wat de zoeker daadwerkelijk vraagt.” Niet: “De hele pagina geoptimaliseerd.”

Vervolgens verifieert de agent zijn eigen werk. Voor een website in git betekent dat: de wijziging committen, de build draaien, de gewijzigde route opnieuw ophalen en controleren dat de beloofde tekst er echt staat. Een geslaagde tool-aanroep is nog geen geslaagde taak; pas als de gepubliceerde pagina klopt, is de run afgerond.

Stap 0404

Meten en vastleggen

Elke run eindigt in een log: wat zag de agent in de data, wat heeft hij gewijzigd, wat is het verwachte effect en wanneer mag je het checken? Idealiter in je issue-tracker, zodat er over dertig dagen een against-the-record vergelijking mogelijk is. Heeft de ingreep de CTR op die ene query verhoogd? Schoof de positie van 14 naar 9? Of gebeurde er niets — en waarom niet?

Dat vastleggen is geen administratieve luxe. Het is de enige manier om van de agent te leren én de agent te leren. Want elke keer dat een hypothese niet uitkomt, zegt dat iets over je instructies: was de prioritering fout, de ingreep te klein, of de verwachting te hoog gespannen?

Stap 0505

Elke 30 dagen herhalen

Eén run doet weinig. De kracht zit in de herhaling. Na zes cycli heb je zes geverifieerde verbeteringen, zes meetmomenten en een groeiend archief van wat wel en niet werkte. Je pagina’s zijn ondertussen stap voor stap beter afgestemd geraakt op de echte zoekintenties van je bezoekers — niet op je aanname van wat ze zoeken, maar op wat de data laat zien dat ze zoeken.

Waarom dertig dagen en niet elke week? Omdat Search Console-data pas na enkele dagen finaliseert en posities van week tot week te veel ruis vertonen. Dertig dagen geeft een signaal waar je iets mee kunt, en het past bij het tempo van contentwijzigingen: grondig genoeg om effect te hebben, traag genoeg om schoon te meten.

Van begeleiden naar automatisch: wees realistisch

Hier moet ik eerlijk over zijn: de eerste keer werkt dit niet. De eerste run van een nieuwe agent levert zelden iets publiceerbaars op. De data wordt verkeerd geïnterpreteerd, de prioritering slaat mis, de voorgestelde copy klinkt als een commissienota. Dat is geen falen van het concept — het is de inwerktijd.

Dit is een illustratieve planning in drie fasen, geen gemeten doorlooptijd of garantie. Automatiseer pas zodra herhaalde tests aantonen dat de workflow betrouwbaar genoeg is:

Hoe je die curve versnelt: geef de agent skills. Een agent als Hermes werkt met herbruikbare instructiepakketten — hoe je een page-audit opbouwt, hoe je zoekintentie interpreteert, hoe je een title herschrijft zonder clickbait. Die leer je hem één keer aan, waarna elke volgende run erop voortbouwt. Na een paar maanden zijn die skills het verschil tussen een stagiair en een collega: het proces zit in de vingers, jij kijkt alleen nog mee op de moeilijke gevallen.

Vanaf dat moment zet je de cyclus om in een cron-job: een geplande taak die de agent volgens schema laat draaien — bijvoorbeeld elke eerste van de maand. De run werkt volgens dezelfde regels als toen je zelf naast hem zat, alleen zonder dat jij erbij moet zijn. Moeilijke beslissingen (nieuwe pagina’s, grote herschrijvingen, alles wat geld of reputatie raakt) blijven expliciet menselijk.

Skills: de agent leren hoe hij SEO-audits doet

De snelste manier om die curve te beklimmen: geef de agent skills — herbruikbare instructiepakketten die één taak tot in detail beschrijven. Een skill voor een page-audit bevat bijvoorbeeld precies welke data wordt opgehaald (live HTML, Search Console-rijen, robots.txt), welke dimensies worden gescoord (zoekintentie, E-E-A-T, contentdiepte, on-page, structuur, techniek), met welke weging, en in welk formaat het rapport verschijnt. Zo’n pakket schrijf je één keer, of je leert het aan vanuit een bestaande verzameling. Daarna doet de agent elke volgende audit op exact dezelfde manier — ook op de cron-run midden in de nacht.

De historische audit hieronder laat zien hoe zo’n rapport eruitziet. Hij is vastgelegd op 2 september 2026, voordat dit artikel overstapte op de uitleg met een serviceaccount. Het eerdere authenticatieadvies blijft bewaard als onderdeel van de oorspronkelijke output; volg voor nieuwe runs de bijgewerkte setup hierboven.

De audit meldde dat de pagina op de publicatiedag nog geen Search Console-data had, in plaats van cijfers te verzinnen. De scores en baseline beschrijven dat moment, niet de huidige pagina. Elke bevinding krijgt een concrete oplossing. Leg bij latere wijzigingen een verse baseline vast en wacht minstens dertig dagen voordat je het effect beoordeelt.

Wat een agent wel en niet zelf mag doen

Automatisering zonder grenzen is een risico, zeker op iets zo zichtbaars als je website. Een paar vuistregels die in de praktijk werken:

• Leesrechten voor data, schrijfrechten via git. De agent leest Search Console, maar elke wijziging gaat door je codebase en review-flow.
• Kleine commits. Eén wijziging per run, met uitleg. Niet omdat de agent niet meer kan, maar omdat je anders het meeteffect kwijtraakt.
• Geen verzonnen cijfers. Alle metrics in copy komen uit de daadwerkelijke data-export, met periode en bron erbij. Een agent die getallen gladstrijkt of erbij verzint, is onbruikbaar voor dit werk.
• Menselijke beslissingen blijven menselijk. Pagina’s samenvoegen, belangrijke landingspagina’s herstructuren, prijzen of beloftes wijzigen: niet automatiseren.
• Nuttig blijft nuttig, ook als het snel gaat. Google benadrukt in haar richtlijn over AI-gegenereerde content dat automatisering niets verandert aan de eis dat content voor mensen gemaakt en daadwerkelijk behulpzaam moet zijn — ongeacht wie of wat hem schreef.

Voor een kijkje in hoe je zo’n agent breed inzet zonder de controle te verliezen, lees je best ook Wat is een AI-agent?. En voor het grotere kader rond terugkerend werk: Workflowautomatisering.

Waar de wijziging landt: MCP naar je CMS, of Git voor je Astro-site

Tot nu toe ging elke verbetering naar “je codebase”. Maar waar de agent precies schrijft, hangt af van hoe je website is gebouwd — en dat is minder ingewikkeld dan het klinkt. Er zijn grofweg twee routes.

Route één: je site draait op een CMS. Dan wil je agent rechtstreeks in dat CMS kunnen werken, en daarvoor gebruik je MCP: het Model Context Protocol, een open standaard die AI-toepassingen op een gestructureerde manier met externe systemen verbindt. Een MCP-server voor WordPress of Storyblok biedt de agent een beperkte, expliciete lijst functies aan — een concept aanmaken, een veld bijwerken, een pagina publiceren — met bijbehorende rechten. De agent kan zo zelfstandig een pagina aanpassen na een goedgekeurde analyse, maar alleen via de deuren die jij openzet. En omdat elk CMS-concept begint als concept en niet meteen live gaat, houd je een natuurlijke review-stap over.

Route twee: je site is statisch, zoals deze. Straffe Sites draait op Astro met Content Collections: alle pagina’s en artikelen zijn bestanden in een git-repository, met strikte schema’s als kwaliteitspoort. De agent bewerkt hier geen CMS maar de bestanden zelf — frontmatter bijwerken, een intro herschrijven, een interne link toevoegen — en loodst elke wijziging rechtstreeks door de schema- en buildcontroles. Elke run wordt een kleine commit die je kunt lezen, reverten of goedkeuren. Geen database, geen adminscherm; de repository ís het CMS.

Beide routes eindigen in hetzelfde: één kleine, geverifieerde wijziging per run, met een menselijke blik ernaar voor het live gaat.

Verder lezen per onderwerp:

• MCP-servers voor CMS-systemen — rechten, conceptstatus en readback als controleketen rond WordPress en Storyblok
• Wat is een headless CMS? — wanneer contentbeheer los van de frontend logisch is
• Een website zonder CMS — de Git-route in het lang, inclusief waarom bestanden volstaan
• Storyblok versus WordPress — de twee CMS-werelden naast elkaar
• WordPress onderhoud — wat periodiek onderhoud aan een CMS-site inhoudt

Plan B als de cyclus niet oppakt

Soms werkt het niet. De data is te dun (minder dan een paar honderd vertoningen per maand), de markt te competitief, of de agent blijft domme keuzes maken na maanden bijsturen. Dan is de eerlijke conclusie: automatisering is hier geen meerwaarde.

Maar ook dan win je. Want de agent functioneert dan nog altijd als analist: hij haalt maandelijks je data op, markeert de opvallende bewegingen en zet dat klaar in een vast rapport. Jij doet de interpretatie en de wijzigingen zelf, eens per kwartaal. Dat is geen zelfverbeterende cyclus, maar wel een retour op je inwerktijd — en soms is dat het realistische plaatje voor een kleine website. Begin klein, meet eerlijk, en laat de automatisering verdienen wat ze waard is. En wil je die cyclus liever begeleid opbouwen in plaats van zelf uitvogelen? Dan is AI-automatisering met menselijke controle waar wij mee helpen. Twijfel je aan de businesscase? In wat kost SEO in 2026 vergelijk je de agent-aanpak met wat freelancers en bureaus voor hetzelfde terugkerende werk rekenen.