{"id":66315,"date":"2026-07-22T15:20:06","date_gmt":"2026-07-22T13:20:06","guid":{"rendered":"https:\/\/kinsta.com\/nl\/?p=66315&preview=true&preview_id=66315"},"modified":"2026-07-28T11:38:04","modified_gmt":"2026-07-28T09:38:04","slug":"wordpress-ai","status":"publish","type":"post","link":"https:\/\/kinsta.com\/nl\/blog\/wordpress-ai\/","title":{"rendered":"AI-integratie en WordPress: een diepgaande analyse van de architectuur en een praktijkvoorbeeld"},"content":{"rendered":"

V\u00f3\u00f3r WordPress 7.0<\/a> moest elke plugin die AI-features toevoegde<\/a> zelf een API-sleutel opvragen en beheren om met een AI-provider te kunnen communiceren.<\/p>\n

Dat kostte onnodig veel code en onderhoud. Je nam zware SDK-bibliotheken van providers op in je plugins en schreef cURL-verzoeken die per provider verschilden.<\/p>\n

Met de native AI-integratie in WordPress 7.0<\/a> is die versnippering verleden tijd. WordPress heeft nu \u00e9\u00e9n centraal scherm waarin je de inloggegevens van verschillende AI-providers instelt, plus een nieuwe PHP-API. Daarmee stuur je prompts, instructies, mediabestanden en datastructuren door, terwijl WordPress Core de verzoeken afhandelt.<\/p>\n

De nieuwe architectuur levert zowel sitebeheerders als plugin-ontwikkelaars flinke voordelen op.<\/p>\n

Beheerders stellen AI niet langer per plugin apart in. Vanaf WordPress 7.0 installeer en activeer je je connector-plugins, voer je je API-sleutels in in het Connectors-scherm en zijn ze meteen beschikbaar voor elke plugin met AI-features op je site. Je houdt het AI-gebruik bij, wisselt van model of trekt de toegang van een provider voor alle plugins in met \u00e9\u00e9n klik.<\/p>\n

Voor plugin-ontwikkelaars is de winst n\u00f3g groter: betere gegevensbeveiliging, overdraagbare code en een stuk minder technische schuld<\/a>.<\/p>\n

Tijd om de nieuwe AI-architectuur van WordPress van dichtbij te bekijken.
\n

<\/div><\/kinsta-auto-toc><\/p>\n

De drie lagen van de WordPress AI-architectuur<\/h2>\n

Je WordPress-sites zijn tegenwoordig standaard klaar voor AI. Niet met kant-en-klare AI-features, maar met de basis waarop je AI-functionaliteit bouwt.<\/p>\n

De nieuwe architectuur bestaat uit drie lagen:
\n

<\/div><\/kinsta-auto-toc><\/p>\n

AI-connector<\/h3>\n

V\u00f3\u00f3r WordPress 7.0<\/a> had elke plugin met AI-features een eigen systeem nodig om je API-sleutels op te slaan en te beheren. Je inloggegevens stonden hardcoded in de plugin of werden beheerd via een custom instellingenpagina. Geen van beide is een prettige manier om met gevoelige gegevens om te gaan.<\/p>\n

\"Het
Het centrale AI Connectors-scherm in het WordPress-dashboard.<\/figcaption><\/figure>\n

In \u00e9\u00e9n centraal scherm stel je al je AI-providers in. Dat levert een paar duidelijke voordelen op voor het beheer van je site.<\/p>\n

Voor beheer en beveiliging is het grootste voordeel dat je je providers \u00e9\u00e9n keer instelt in het Connectors-scherm en er daarna geen omkijken meer naar hebt, hoeveel plugins er ook gebruik van maken. Moet je je API-sleutels wijzigen? Dan werk je ze in \u00e9\u00e9n keer bij in het Connectors-scherm, in plaats van plugin voor plugin.<\/p>\n

Centrale opslag van inloggegevens maakt je site ook veiliger: gevoelige gegevens liggen niet langer verspreid over plugins van derden die slecht geschreven of onbetrouwbaar kunnen zijn.<\/p>\n

Daarnaast wordt je code overdraagbaar. Je plugins hoeven niet te weten welke AI-provider je gebruikt, want de nieuwe architectuur trekt authenticatie los van de pluginlogica. Wissel je van AI-provider, dan blijft je plugin gewoon werken zonder dat je \u00e9\u00e9n regel code aanpast.<\/p>\n

De echte doorbraak zit erin dat sitebeheerders meerdere connectors tegelijk kunnen instellen. Stuurt een plugin een verzoek, dan kiest WordPress zelf de meest geschikte AI-provider en het meest geschikte model voor het antwoord, op basis van de configuratie van de plugin<\/a> en de mogelijkheden van de beschikbare modellen.<\/p>\n

AI Client<\/h3>\n

Waar het Connectors-scherm de configuratie van AI-providers regelt, geeft de AI Client<\/a> ontwikkelaars de tool om met AI-modellen te werken.<\/p>\n

Het is een native interface die de communicatie met AI-modellen standaardiseert via de globale functie wp_ai_client_prompt()<\/code> en een vaste set PHP-methoden.<\/p>\n

Minder technische schuld<\/h4>\n

Voor ontwikkelaars zit het grootste voordeel in minder technische schuld en minder afhankelijkheden. V\u00f3\u00f3r WordPress 7.0 betaalde je voor AI-features een hoge prijs in onderhoud. Je bundelde SDK’s van derden (zoals de offici\u00eble bibliotheken van OpenAI<\/a> of Anthropic<\/a>) en hield doorlopend de versies in de gaten. Dat maakte je plugin zwaar en compatibiliteitsproblemen waarschijnlijk.<\/p>\n

Daar kwamen nog eens veel regels code bij voor de netwerklogica en het parsen van antwoorden. Die code was bovendien providerspecifiek: wisselde je van AI-provider, dan herschreef je de complete netwerklaag van je plugin.<\/p>\n

De AI Client haalt dat probleem bij de wortel weg door het zware werk naar WordPress Core te verplaatsen. Je code wordt volledig providerneutraal: je schrijft je instructies \u00e9\u00e9n keer en WordPress vertaalt ze naar het ‘dialect’ van het model.<\/p>\n

Intelligente modelselectie<\/h4>\n

Een sterk punt van de fluent interface van de AI Client is dat je voorkeursmodellen instelt met de methode using_model_preference()<\/code>, beschikbaar via de builderfunctie wp_ai_client_prompt()<\/code>. Daarmee geef je een geordende lijst met modellen op voor de specifieke taak van je plugin. De code hieronder vraagt bijvoorbeeld tekstgeneratie aan met drie voorkeursmodellen:<\/p>\n

$text_result = wp_ai_client_prompt( 'Convert the following transcript into a concise, blog-ready draft.' )\n\t->using_model_preference(\n\t\t'gemini-2.5-flash',\n\t\t'claude-3-5-sonnet',\n\t\t'gpt-4o'\n\t)\n\t->generate_text();<\/code><\/pre>\n
WordPress kijkt naar de providers in het Connectors-scherm, loopt de modellen uit je plugincode af en pakt de eerste connector die ook op de site beschikbaar is. Is geen van je opgegeven modellen beschikbaar onder de actieve Connectors, dan negeert WordPress je voorkeurslijst en valt het terug op het eerste compatibele model dat op de site is ingesteld.<\/p>\n
Zo blijft je plugin werken, ook als de sitebeheerder overstapt naar een andere AI-provider.<\/p>\n
AI-provider<\/h3>\n
Een AI-provider is het bedrijf dat de large language models (LLM’s) die we dagelijks gebruiken bezit, traint en host. OpenAI, Google Gemini en Anthropic zijn de bekendste AI-providers waarvoor WordPress 7.0 aparte connectors ondersteunt, maar ontwikkelaars kunnen ook zelf extra custom providers registreren.<\/p>\n
Roept je plugincode de methode generate_text()<\/code> aan, of een andere generatiemethode, dan bundelt WordPress de gegevens en stuurt die via het endpoint van de connector naar de AI-provider. Achter de schermen gebeurt dit:<\/p>\n