SEO automatiseren met AI: zo bouw je een zelfverbeterende cyclus
Verbind een AI-agent via gcloud met Google Search Console en laat hem elke 30 dagen je pagina's afstemmen op echte zoekintenties. Zo werkt de cyclus.
Door Seppe · 12 min. leestijd
Korte versie
Kort samengevat: geef een AI-agent zoals Hermes leesrechten op je Search Console-data via gcloud, laat hem elke 30 dagen één kleine, geverifieerde verbetering per pagina doorvoeren en leg elke run vast in een issue of log. In het begin begeleid je elke stap; na een paar maanden draait de cyclus automatisch via een cron-job.
SEO automatiseren met AI betekent in de praktijk: een AI-agent met leesrechten op je Google Search Console die elke dertig dagen de echte zoekvragen uit je data haalt en daarvoor één kleine, geverifieerde verbetering aan je pagina’s doorvoert. Dat is geen robot die je website hoger in Google zet terwijl jij koffie drinkt — die bestaat niet. Het is een cyclus: data ophalen, prioriteren, verbeteren, meten, en dertig dagen later opnieuw. Niet alles tegelijk, niet op gevoel — één ding per run, gemeten en vastgelegd.
Die aanpak werkt omdat SEO geen eenmalig project is maar een gewoonte. Wie elke maand tegen dezelfde data aankijkt en telkens één gerichte ingreep doet, ziet zijn pagina’s op den duur beter aansluiten op wat mensen écht zoeken. De agent maakt die gewoonte betaalbaar: hij doet het zware werk — data ophalen, prioriteren, voorbereiden — terwijl jij de beslissingen neemt. In het begin begeleid je elke run. Na een paar maanden draait het grootste deel automatisch via een cron-job.
Waarom SEO automatiseren met AI nu logisch is
Twee dingen zijn veranderd ten opzichte van twee jaar geleden. Eén: agents kunnen vandaag écht tools gebruiken. Waar een chatmodel vroeger alleen tekst kon produceren, kan een agent als Hermes nu een API bevragen, bestanden lezen en schrijven, een build draaien en het resultaat teruglezen. Twee: die toegang is gestandaardiseerd. Met gcloud geef je een agent via Application Default Credentials veilig leesrechten op je Google Search Console-property, zonder tokens te kopiëren of wachtwoorden te delen.
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. Een agent die daarop werkt, hallucineert geen marktcijfers — hij leest echte zoekgedragingen.
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
De opzet valt mee. Je hebt vier dingen nodig:
Een Google-account met toegang tot de Search Console-property die je wilt optimaliseren. De API werkt met elke property die je in de interface kunt openen.
gcloud met Application Default Credentials. Na een eenmalige gcloud auth application-default login kan de agent de Search Console API bevragen onder jouw leesrechten. Je geeft niets meer vrij dan nodig is: alleen lezen, alleen deze API.
Een agent die tools kan gebruiken. Denk aan Hermes van Nous Research — een open agent die op je eigen machine draait, bestanden en shell-commando’s aankan en vaardigheden (skills) meekrijgt of aanleert. Vergelijkbare opties: Claude Code, Cursor-agents of een eigen script rond een taalmodel met API-toegang.
Een plek waar de wijzigingen leven. Een git-repository is ideaal: elke run wordt een kleine, controleerbare commit met een beschrijving van waarom.
Het tweede punt verdient nadruk, want hier zit het verschil tussen een veilige en een roekeloze setup. Je wilt géén service-account met brede rechten, géén API-sleutels in configuratiebestanden en géén agent die rechtstreeks in productie kan schrijven. Alleen-lezen toegang tot Search Console via ADC, en alle wijzigingen via je eigen codebase met een review-stap eromheen. Zo blijft de agent een medewerker die advies geeft en werk voorbereidt — geen anonieme automaat die ’s nachts je website ombouwt.
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 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.
Reken op een leercurve in drie fasen:
Fase
Wat jij doet
Wat de agent doet
Maand 1–2
Elke run begeleiden, elke wijziging bijsturen, instructies herschrijven
Data ophalen, analysevoorstellen doen, fouten maken
Maand 3–4
Resultaten reviewen, randgevallen aanreiken
Volledige runs voorbereiden, verbeteringen voorstellen met onderbouwing
Maand 5+
Af en toe meekijken, escalaties beoordelen
Zelfstandig draaien op schema, menselijke tussenkomst vragen bij twijfel
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.
Zo’n rapport ziet er in de praktijk zo uit. Onderstaande output is de letterlijke page-audit die de agent op deze pagina draaide op de publicatiedatum, één op één overgenomen — scores, prioriteiten, E-E-A-T-beoordeling, alles:
Let op wat erin zit: de audit weet dat de pagina nog geen Search Console-data heeft (gepubliceerd op de dag zelf) en zegt dat eerlijk in plaats van cijfers te verzinnen. Precies dat soort disciplinering zit niet in het model maar in de skill — en het is het verschil tussen een rapport dat je vertrouwt en een dat je tegen moet lichten. Elke bevinding komt met een concrete fix; de GSC-baseline van vandaag is over dertig dagen de meetlat voor de eerste hermeting.
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 loodt 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.
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.
Veelgestelde vragen
Werkt SEO automatiseren met AI vanaf de eerste keer?
Nee, en dat is normaal. De eerste runs moet je de agent voortdurend begeleiden en bijsturen: verkeerde prioriteiten, te grote ingrepen, hallucinaties in de analyse. Na elke run stel je de instructies bij. Na een paar maanden zijn de regels stabiel genoeg om de cyclus via een cron-job automatisch te laten draaien, met menselijke controle op de moeilijkste beslissingen.
Is het veilig om een AI-agent op mijn Search Console-data te zetten?
Ja, mits je leesrechten gebruikt. Met gcloud geef je de agent via Application Default Credentials toegang tot uitsluitend de Search Console API, zonder schrijfrechten op je property. De agent kan data lezen en analyseren, maar niets in je Google-account wijzigen. Wijzigingen aan je website gaan altijd via je eigen codebase en reviews, niet via Google.
Welke AI-agent is geschikt om SEO te automatiseren?
Je hebt een agent nodig die bestanden kan lezen en schrijven, shell-commando's kan uitvoeren en met geplande taken werkt. Hermes van Nous Research is zo'n agent: hij leest je codebase, verbindt via gcloud met Google APIs en draait op een schema zodra je de workflow goedkeurt. Vergelijkbare opties zijn Claude Code, Cursor-agents of een eigen script rond een taalmodel.
Wat kost het om SEO met AI te automatiseren?
De investering zit vooral in tijd: de eerste maanden begeleid je elke run en stel je instructies bij. Daarnaast betaal je per API-call voor het taalmodel en eventueel voor de server die de cron-job draait. De Search Console API zelf is gratis. Hoe complexer je website, hoe meer begeleiding de agent in het begin nodig heeft.
