AI-agent koppelen aan Google Search Console: 6 methoden

Er zijn zes praktische manieren om een AI-agent toegang te geven tot je Google Search Console-data: een gehoste OAuth-connector, een community-MCP-server, rechtstreeks de Search Console API, een bulkexport naar BigQuery, een spreadsheet als tussenstation, of de ingebouwde AI-configuratie van Search Console zelf, zonder agent. De opzet kost je van twee minuten tot het grootste deel van een dag, en welke je kiest hangt vooral af van één vraag: heb je historie nodig van meer dan 16 maanden?

Die vraag bepaalt de rest, dus begin daar. De Search Analytics API geeft maximaal 25.000 rijen per request terug en bewaart 16 maanden historie. Daarna is de data weg: niet verborgen, maar verwijderd. Wil je een langere historie, dan helpt maar één methode uit dit lijstje je daaraan, en die moet je starten vóórdat je hem nodig hebt.

Methode 1: een gehoste OAuth-connector

Opzet: 2 tot 5 minuten. Geen code.

Je geeft een SEO-agentproduct toestemming via je Google-account, kiest de property, en de koppeling wordt aan de serverkant opgeslagen en bij elke vraag hergebruikt. Dit is wat de meeste marketeers zouden moeten gebruiken. Niet uit gemakzucht, maar omdat de valkuilen voor je worden afgevangen. Een goed gebouwde connector merkt het als er geen koppeling is en vraagt erom in plaats van te gokken, bepaalt welke property hij moet gebruiken als je er meerdere hebt, en pagineert voorbij het plafond van 25.000 rijen zonder dat jij erover hoeft na te denken.

In onze eigen implementatie is de Search Console-tool gemarkeerd als alleen-lezen. Bij de eerste aanroep controleert hij of er een actieve koppeling is. Zo niet, dan krijg je een interactieve koppelprompt met een deeplink naar het integratiescherm, en zodra je terug bent gaat het gesprek verder.

Afweging: je krijgt de toolset die de leverancier heeft gebouwd. Wil je een type query dat zij niet hebben geïmplementeerd, dan heb je pech.

Methode 2: een Search Console MCP-server

Opzet: 15 tot 45 minuten. Je moet een beetje developer zijn.

Het Model Context Protocol is een open client/server-standaard om AI-assistenten aan externe systemen te koppelen. Elke client die MCP ondersteunt (Claude Desktop, Claude Code, Cursor en andere) kan dus rechtstreeks een Search Console-server aanroepen.

Belangrijke kanttekening: anders dan bij GA4, waarvoor Google een eigen MCP-server publiceert, bestaat er geen officiële MCP-server van Google voor Search Console. Wat er wel is, is een flinke reeks community-implementaties, zoals mcp-server-gsc. Die haalt zoekanalysedata op tot het plafond van 25.000 rijen, ondersteunt regex-filters en is alleen-lezen.

De configuratie is een JSON-blok in je MCP-client dat met je inloggegevens naar de server verwijst:

{
  "mcpServers": {
    "search-console": {
      "command": "npx",
      "args": ["-y", "mcp-server-gsc"],
      "env": { "GOOGLE_APPLICATION_CREDENTIALS": "/path/to/service-account.json" }
    }
  }
}

Afweging: je vertrouwt een communitypakket de inloggegevens van je zoekdata toe. Lees de broncode, kies waar mogelijk alleen-lezen-scopes en zet de versie vast. Controleer ook of de protocolversie die de server implementeert past bij wat je client verwacht.

Methode 3: de Search Console API met een serviceaccount

Opzet: 1 tot 3 uur. Je schrijft zelf code.

De meeste controle, en het meeste werk. De stappen:

1. Maak een Google Cloud-project aan, of gebruik een bestaand project.
2. Schakel daarin de Search Console API in.
3. Maak een serviceaccount aan en download de JSON-sleutel.
4. Voeg het e-mailadres van het serviceaccount toe als gebruiker op de Search Console-property zelf, met beperkte (alleen-lezen) rechten.
5. Authenticeer je agent met de sleutel en roep searchanalytics.query aan.

Stap 4 vergeet iedereen. Een credential aanmaken in Cloud geeft hem nog geen toegang tot een property: dat zijn twee aparte rechtensystemen. Sla je de tweede over, dan krijg je een generieke 403 die eruitziet als een probleem met het inschakelen van de API, terwijl het om property-toegang gaat. Reken erop dat je hier één keer twintig minuten aan kwijt bent.

Een minimale query-body met paginering ziet er zo uit:

{
  "startDate": "2026-04-01",
  "endDate":   "2026-06-30",
  "dimensions": ["query", "page"],
  "rowLimit":  25000,
  "startRow":  0
}

Verhoog startRow per pagina met 25.000 en stop zodra een response minder rijen teruggeeft dan je vroeg. Al het andere (quota, retries, tokens verversen) moet je nu zelf bouwen.

Afweging: volledige flexibiliteit, maar quotabeheer, paginering, retries en het verversen van tokens liggen nu bij jou. Kies dit als de agent een type query nodig heeft dat geen enkele connector biedt, of als de data binnen je eigen infrastructuur moet blijven.

Methode 4: bulkexport naar BigQuery

Opzet: ongeveer een uur, plus maximaal 48 uur voordat de eerste export binnenkomt.

Dit is de enige methode die het 16-maandenprobleem oplost. Zet hem vandaag op, ook als je hem nu nog niet nodig hebt, want hij bouwt historie op vanaf het moment dat je begint, niet met terugwerkende kracht.

Volgens Googles documentatie over bulkexport werkt het zo:

1. Maak of kies een Google Cloud-project met facturering ingeschakeld. Dat is niet optioneel.
2. Schakel in dat project de BigQuery API en de BigQuery Storage API in.
3. Geef het Search Console-serviceaccount twee rollen op het project: BigQuery Job User en BigQuery Data Editor.
4. Open in Search Console de instellingen, kies Bulk data export en vul de Cloud-project-ID en een datasetlocatie in.
5. Wachten. De eerste export komt binnen 48 uur binnen, daarna draaien de exports dagelijks.

Twee details die je moet weten voordat je begint. Geanonimiseerde zoekopdrachten worden om privacyredenen uitgesloten van de export, dus de totalen in BigQuery sluiten nooit precies aan op de Search Console-interface. Dat is verwacht gedrag, geen bug, maar een agent die de twee vergelijkt meldt anders een afwijking die niet bestaat. En de datasetlocatie kun je later niet wijzigen zonder opnieuw te beginnen, dus kies die bewust.

Staat de data eenmaal in BigQuery, dan bevraagt je agent SQL in plaats van de Search Console API. Daarmee ben je in één klap af van het rijenplafond én van de bewaartermijn. Voor kleine sites blijven de kosten binnen het gratis tier van BigQuery, voor grote sites worden ze echt. Laat de agent dus filteren op de partitiedatumkolom in plaats van de hele tabel te scannen: een agent die een onbegrensde SELECT * loslaat op drie jaar data van een grote property, levert je een factuur op die je niet snel vergeet.

Afweging: het kost geld, het vraagt de meeste infrastructuur van alle opties, en op dag één heb je er niets aan. Het is ook de enige route naar analyses over meerdere jaren.

Methode 5: een spreadsheet als tussenstation

Opzet: 10 tot 20 minuten. Geen code.

Exporteer Search Console-data volgens een schema naar Google Sheets met een add-on of Apps Script, en laat een agent met toegang tot Sheets die sheet lezen. Dit is de pragmatische optie als je agent al spreadsheets leest en je de data vanmiddag nog voor hem wilt hebben.

Afweging: de data is zo vers als de laatste export, alles is voorgefilterd door degene die de sheet heeft ingericht, en de agent kan geen vervolgvraag stellen die niemand had voorzien. En dat is nou net waarvoor je een agent hebt. Zie het als noodoplossing.

Methode 6: helemaal geen koppeling

Opzet: geen.

Search Console heeft zelf AI aan boord. Met Googles AI-powered configuration beschrijf je in gewone taal welke analyse je wilt, en Search Console vertaalt dat naar rapportfilters, vergelijkingen en geselecteerde statistieken. „Vergelijk het verkeer van mijn pagina's met /blog dit kwartaal met hetzelfde kwartaal vorig jaar" stelt zichzelf in.

Ken de grenzen, die Google zelf duidelijk noemt: het werkt alleen op prestatierapporten voor zoekresultaten, niet voor Discover of Google Nieuws; het stelt filters, vergelijkingen en statistieken in, maar kan geen tabellen sorteren en geen data exporteren; en Google waarschuwt dat de AI een verzoek verkeerd kan begrijpen, dus controleer de toegepaste filters voordat je de analyse vertrouwt. Het is bovendien puur configuratie: het redeneert niet over GA4 en Search Console samen en zoekt geen oorzaken uit.

Los daarvan heeft Search Console nu prestatierapporten voor generatieve AI voor verkeer uit de AI-onderdelen van Google. Gaat je vraag over zichtbaarheid in die AI-onderdelen, dan is dit de gezaghebbende bron, en geen enkele schatting van een derde partij kan die vervangen.

Welke methode kies je?

Methode	Opzet	Meer dan 16 maanden	Ideaal voor
Gehoste connector	2-5 min	Nee	Marketeers die vandaag antwoorden willen
MCP-server	15-45 min	Nee	Developers die al een MCP-client gebruiken
Directe API	1-3 uur	Nee	Eigen querytypes, data blijft in huis
BigQuery-export	1 uur + 48 uur	Ja	Analyses over meerdere jaren, grote sites
Spreadsheet als tussenstation	10-20 min	Nee	Tijdelijke oplossing
Ingebouwde AI-configuratie	Geen	Nee	Sneller rapporten bouwen, geen onderzoek

De meeste teams komen uit op een combinatie: een gehoste connector voor de dagelijkse vragen, plus een BigQuery-export die stilletjes op de achtergrond draait, zodat ze over een jaar historie hebben die verder niemand heeft. Die twee bijten elkaar niet.

Is het veilig om een agent toegang te geven tot Search Console?

Redelijk veilig, onder drie voorwaarden. Geef alleen leesrechten. Search Console-rechten omvatten ook sitemaps indienen en verwijderingen aanvragen, en daar heeft een agent niets te zoeken. Kies liever een afgebakend serviceaccount dan een persoonlijke OAuth-toestemming, zodat intrekken niet afhangt van het account van één medewerker. En houd schrijftools gescheiden van tools die webpagina's ophalen: een agent die een pagina van een concurrent leest, haalt tekst van buitenaf binnen in hetzelfde contextvenster als jouw instructies. Staan op die pagina geïnjecteerde opdrachten, dan kan een naïeve agent die uitvoeren. Onze runtime schermt opgehaalde content af als onbetrouwbaar, markeert de beurt als besmet en weigert de rest van die beurt elke tool met een schrijflabel, tenzij een mens toestemming geeft. Search Console-query's hebben een leeslabel, dus die zijn hoe dan ook veilig.

Veelvoorkomende fouten bij de opzet, en wat ze echt betekenen

Symptoom	Gebruikelijke oorzaak	Oplossing
403 bij elke query, terwijl de API is ingeschakeld	Het serviceaccount is nooit als gebruiker aan de property toegevoegd	Voeg het e-mailadres toe in de property-instellingen van Search Console, met beperkte rechten
Lege resultaatset, geen foutmelding	Property-URL klopt niet: domeinproperty versus URL-voorvoegselproperty, of een ontbrekende slash aan het eind	Kopieer de property-string precies zoals Search Console hem toont
Agent meldt verdacht ronde totalen	Resultaat afgekapt op het plafond van 25.000 rijen en behandeld als compleet	Pagineer met startRow, of laat de agent afkapping expliciet melden
Cijfers wijken af van de Search Console-interface	Geanonimiseerde zoekopdrachten uitgesloten van de BigQuery-export, of een andere datumgrens	Verwacht bij BigQuery; controleer anders tijdzone en absolute datums
Bulkexport ingesteld maar er verschijnt geen dataset	Je zit nog binnen de 48 uur, of facturering staat niet aan op het project	Wacht, en controleer daarna facturering en de twee IAM-rollen
MCP-server start maar biedt geen tools	Verkeerd pad naar de inloggegevens, of een protocolversie die niet aansluit op de client	Controleer of het env-pad klopt en welke specversie de server ondersteunt

Twee dingen die je bij elke methode goed moet doen

Ga eerlijk om met paginering. Een agent die 25.000 rijen opvraagt, er precies 25.000 terugkrijgt en een totaal rapporteert, rapporteert een afgekapt resultaat. Laat hem pagineren of expliciet melden dat het resultaat het plafond raakte.

Gebruik absolute datums. Een relatieve omschrijving als „vorige maand" wordt uitgerekend op basis van de tijdzone van de property en het moment waarop de query draaide. Dat is de meest voorkomende oorzaak van een Search Console-analyse die zelfverzekerd en logisch klinkt, maar gewoon fout is.

Staat de koppeling eenmaal, dan lees je in wat een agent echt kan vinden in Search Console-data welke analyses de moeite waard zijn, en Autopilot implementeert de route met een gehoste connector uit methode 1.