Dezelfde druk kan ontstaan door functies die er op het eerste gezicht heel anders uitzien. AI-zoekfuncties, productaanbevelingen, gepersonaliseerde content, redactietools en agent-integraties werken elk op hun eigen manier samen met WordPress. Als je weet of ze in het dashboard, aan de front-end of via een API draaien, en of hun verzoeken gecachet kunnen worden, kun je beter inschatten welke serverresources ze nodig hebben.<\/p>\n
Hoe AI in WordPress er in de praktijk uitziet op een live site<\/h2>\n
AI op WordPress is niet \u00e9\u00e9n workload. Waar de functie draait, wanneer die draait en of een bezoeker hem activeert: het bepaalt allemaal het infrastructuurprofiel.<\/p>\n
AI-chatbots en supportassistenten<\/h3>\n
Dit is de meest zichtbare categorie. Plugins als AI Engine<\/a> (met meer dan 100.000 actieve installaties), MxChat<\/a> en Tidio<\/a> brengen conversatie-interfaces naar de front-end.<\/p>\n Elk bericht kan een dynamisch verzoek starten, context ophalen, een extern model aanroepen en gespreksgegevens opslaan. Anders dan bij een contactformulier kan \u00e9\u00e9n gesprek meerdere van die verzoeken kort achter elkaar genereren.<\/p>\n Personalisatie, aanbevelingen en AI-zoekfuncties draaien meestal aan de front-end. In een WooCommerce-winkel betekent dat bijvoorbeeld productsuggesties aanpassen op basis van wat een klant al heeft bekeken, of een zoekopdracht interpreteren in plaats van exact op de bewoording matchen. De rest van de pagina komt vaak nog uit de cache, maar die resultaten moeten alsnog per verzoek worden gegenereerd.<\/p>\n Denk aan tools als Jetpack AI<\/a>, Rank Math Content AI<\/a>, Divi AI<\/a> en GetGenie<\/a>. Deze draaien vooral binnen het WordPress-dashboard.<\/p>\n Omdat deze tools vooral in het WordPress-dashboard draaien, vertragen ze het laden van front-end-pagina\u2019s meestal niet. Ze kunnen wel merkbare druk op de server geven als meerdere redacteuren ze tegelijk gebruiken.<\/p>\n MCP-integraties<\/a> wachten niet tot iemand de site bezoekt. Met de MCP-ondersteuning van AI Engine en de offici\u00eble WordPress MCP-adapter<\/a> kan een externe tool verbinding maken met WordPress en goedgekeurde taken uitvoeren, zoals sitegegevens lezen of een artikel bijwerken. Elke taak komt binnen als een geauthenticeerd API-verzoek: weer een bron van serveractiviteit om rekening mee te houden.<\/p>\n Twee sites kunnen allebei AI gebruiken en toch heel verschillende hoeveelheden hostingresources nodig hebben. De ene gebruikt het af en toe in de editor om koppen voor te stellen, de andere genereert voor elke bezoeker productaanbevelingen. Kijk voor een inschatting van de impact naar waar de functie draait en hoe vaak die een WordPress-verzoek activeert.<\/p>\n De kosten van een AI-functie zitten in het werk rondom het antwoord van het model. WordPress moet nog steeds het verzoek ontvangen, de plugincode uitvoeren, de benodigde gegevens ophalen, contact leggen met de externe provider en het resultaat terugsturen. Vier onderdelen van dat proces hebben de meeste invloed op de prestaties.<\/p>\n Gecachete content kan worden geserveerd zonder PHP-thread. Een dynamisch AI-verzoek moet wel door een thread worden verwerkt, en elke thread verwerkt \u00e9\u00e9n verzoek tegelijk. Wacht een chatbot twee seconden op een externe provider, dan kan de PHP-thread die dat gesprek afhandelt die twee seconden bezet blijven. Zodra gelijktijdige gesprekken alle beschikbare threads bezetten, belanden andere niet-gecachete verzoeken in een wachtrij.<\/p>\n Qua opbouw lijkt dit op de botverkeerspatronen uit het AI & Botverkeer Rapport van Kinsta<\/a>. Bots die zoekpagina\u2019s, winkelwagens en andere dynamische endpoints bezoeken, reserveren PHP-threads en dwingen verwerking op de originserver af. AI-functies doen hetzelfde, maar bewust en idealiter productief. De infrastructuurkosten per verzoek blijven vergelijkbaar.<\/p>\n Veel AI-antwoorden zijn specifiek voor de persoon die het verzoek doet, dus je kunt ze niet zomaar hergebruiken voor de volgende bezoeker. De productpagina zelf laadt misschien nog uit de cache, maar een aanbevelingspaneel of een AI-zoekresultaat moet apart worden gegenereerd. Hoe vaker dat tijdens een bezoek gebeurt, hoe meer verzoeken de originserver moet verwerken.<\/p>\n Voordat een prompt de deur uit gaat, moet een plugin soms productdetails, eerdere berichten of gebruikersinformatie uit WordPress halen. Omdat die gegevens per verzoek verschillen, zijn ze lastiger te cachen dan een gewone pagina-query. Komen veel van die verzoeken tegelijk binnen, dan levert dat extra databaseactiviteit op, precies op het moment dat de afreken- en accountpagina\u2019s hun eigen werk proberen te doen.<\/p>\n AI-plugins moeten vaak wachten op een externe dienst voordat ze een verzoek kunnen afronden. Heeft OpenAI drie seconden nodig om te antwoorden, dan wacht WordPress ook, en bij een synchrone call geldt dat net zo goed voor de PHP-thread die hem afhandelt. De plugin hoort een time-out te hebben, zodat een vastgelopen call niet eindeloos open blijft staan. Sommige taken kun je in de wachtrij zetten of cachen, al moet een live chatbot meestal gewoon op de provider wachten.<\/p>\n WordPress 7.0 zelf is een goed voorbeeld<\/a>. Het core-team haalde realtime samenwerking uit de release nadat tests zorgen opriepen over serverbelasting, geheugengebruik en race conditions. De functie was nog steeds waardevol, maar nog niet klaar om uit te brengen binnen de prestatielimieten waaraan WordPress core moet voldoen.<\/p>\n AI-workloads zijn dynamisch, piekerig en vaak afhankelijk van diensten buiten je hostingomgeving. Drie hostingkenmerken bepalen of die verzoeken beheersbaar en te diagnosticeren blijven, of dat ze de rest van de site gaan raken.<\/p>\n Dat kan een probleem zijn bij gedeelde hosting, waar jouw site niet de enige is op de server. Piekt de AI-activiteit plotseling, dan gaat dat ten koste van de CPU-, geheugen- en databaseresources die beschikbaar zijn voor andere sites op dezelfde machine.<\/p>\n Kinsta draait elke WordPress site in een eigen ge\u00efsoleerde Linux-container met een speciale softwarestack die Nginx<\/a>, PHP<\/a> en MySQL<\/a> bevat. Elke site krijgt daarnaast een eigen PHP-thread en geheugentoewijzing. Handelt een AI-chatbot ineens tientallen gesprekken tegelijk af, dan blijft die belasting binnen de container van die site, in plaats van dat er resources worden gebruikt die aan een andere site zijn toegewezen.<\/p>\n Die isolatie is vooral waardevol voor bureaus<\/a>. Een slecht geconfigureerde AI-plugin op de site van \u00e9\u00e9n klant kan die site nog steeds vertragen, maar het probleem verspreidt zich niet over de rest van het portfolio.<\/p>\n PHP 7.4 draait WordPress 7.0 prima, maar het is niet de versie die je kiest voor prestaties. PHP 8.x<\/a> verwerkt WordPress code sneller, waardoor het werk rondom een AI-verzoek minder tijd kost en de PHP-thread eerder weer vrijkomt.<\/p>\n Een nieuwere PHP-versie maakt OpenAI of Anthropic niet sneller, maar beperkt wel het werk dat WordPress voor en na die externe call moet doen. Kinsta ondersteunt PHP-versies tot en met 8.5 en je kunt via MyKinsta de versie per live- of testomgeving aanpassen<\/a>. Test de wijziging eerst in de testomgeving, dan vang je compatibiliteitsproblemen in de AI-plugin, het thema of custom code op tijd af.<\/p>\n Prestatieproblemen met AI<\/a> kunnen op verschillende plekken ontstaan: in de PHP code van de plugin, bij een databasequery, bij de externe modelprovider of door te weinig threadcapaciteit. Zonder gegevens op verzoekniveau lijken alle vier op een algemene hostingvertraging.<\/p>\n De APM-tool van Kinsta<\/a> haalt die componenten uit elkaar.<\/p>\n Een praktisch onderzoek ziet er bijvoorbeeld zo uit:<\/p>\n Zodra je ziet waar de tijd is gebleven, heb je een bruikbaar startpunt. Een trage WordPress-transactie vraagt om een andere oplossing dan een volgelopen database of een model-API die er seconden over doet.<\/p>\n AI verhoogt de vraag naar infrastructuur in twee richtingen. Je WordPress site stuurt meer verzoeken naar modelproviders, terwijl geautomatiseerde systemen meer verzoeken naar jouw site sturen.<\/p>\n AI-ondersteund publiceren vergroot het crawloppervlak van een site snel. Verhoogt een mediateam de output van vijf artikelen per week naar twintig, dan komen er URL\u2019s, interne links, archieven en paginering bij die crawlers kunnen verkennen. Crawlers weten niet per se dat AI heeft geholpen bij het maken van die content, en het interesseert ze ook niet. Ze zien een grotere, vaker bijgewerkte bibliotheek en komen terug om die te crawlen.<\/p>\n Een miljoen verzoeken om gecachete pagina\u2019s belasten een server heel anders dan een miljoen verzoeken naar dynamische URL\u2019s. Uit Kinsta\u2019s analyse van meer dan 10 miljard verzoeken<\/a> blijkt dat crawlers herhaaldelijk zoekresultaten, gefilterde productpagina\u2019s, \u2018toevoegen aan winkelwagen\u2019-links en soortgelijke endpoints bezoeken. Elk van die verzoeken kan de cache omzeilen en werk naar PHP en de database sturen.<\/p>\n Daarmee concurreert geautomatiseerd verkeer met de AI-functies van je eigen site. Een chatbotverzoek en een crawler die een dynamisch productfilter<\/a> bezoekt hebben totaal verschillende doelen, maar allebei bezetten ze PHP-threads. Gebruiken crawlers een flink deel van de beschikbare capaciteit, dan blijft er minder ruimte over voor legitieme chatbot-, zoek- en aanbevelingsverzoeken.<\/p>\n Een AI-gestuurde site heeft genoeg ruimte nodig voor de verzoeken die je bezoekers echt doen. Botbeperkingen houden die ruimte vrij. Googlebot heeft nog steeds toegang nodig tot pagina\u2019s die je ge\u00efndexeerd wilt hebben, en je kunt besluiten dat sommige AI-crawlers het waard zijn om toe te laten. Wat je wilt beperken, is herhaalde activiteit op dynamische endpoints die niets oplevert en toch PHP-threads bezet houdt.<\/p>\n Kinsta Botbescherming<\/a> biedt instellingen op omgevingsniveau om geautomatiseerd verkeer toe te laten, te challengen of te blokkeren, met een aparte optie voor AI-crawlers. De analyses laten zien hoe verzoeken worden geclassificeerd en afgehandeld.<\/p>\n Botanalyses zijn maar een deel van het plaatje. Zet ze naast APM-traces, cache-bypassrapporten en de Top IP’s in MyKinsta. Zo zie je makkelijker of de belasting van je eigen AI-functies komt of van externe crawlers, en of die crawlerverzoeken de resources waard zijn die ze verbruiken.<\/p>\n Test hoe een AI-functie zich gedraagt op je bestaande infrastructuur voordat je hem in productie neemt. Begin met deze vijf vragen.<\/p>\n Het verzoekpad is hier bepalend. Schrijf- en bewerktools blijven meestal binnen wp-admin. Tools voor klanten delen PHP-capaciteit met de rest van de front-end, inclusief de afreken- en accountpagina\u2019s. Een agent kan beide paden overslaan en via de API binnenkomen. Bekijk de verzoekstroom van de plugin voordat je inschat hoeveel capaciteit hij nodig heeft.<\/p>\n Zoek uit wat de plugin precies uitsluit van de cache. Het antwoord zelf moet misschien dynamisch blijven, omdat het meebeweegt met de prompt of de gebruiker, maar gerelateerde gegevens zoals gespreksstatus, zoekresultaten of aanbevelingen zijn soms kort te hergebruiken. Een apart, niet-gecachet API-endpoint is een stuk goedkoper dan een plugin die de hele productpagina dynamisch maakt.<\/p>\n Test ook een mislukte call, niet alleen een trage. Verbreek de verbinding tijdelijk in de testomgeving en kijk wanneer het verzoek afloopt. Sommige plugins proberen het meteen opnieuw, andere blijven openstaan tot PHP ze afkapt. Doen meerdere chatbotverzoeken dat tegelijk, dan moeten afreken- en accountverzoeken wachten op een PHP-thread.<\/p>\n Installeer de plugin in een testomgeving<\/a> en schakel de APM-tool van Kinsta<\/a> in tijdens het testen. Simuleer typische gesprekken, zoekopdrachten of contentworkflows, inclusief gelijktijdige activiteit waar dat relevant is. Bekijk de tabbladen Transacties<\/strong>, Extern<\/strong> en Database<\/strong> om vast te stellen hoe lang verzoeken duren en waar die tijd naartoe gaat.<\/p>\n Leg vast hoe de testomgeving zich gedraagt voordat je PHP aanpast. MyKinsta laat zien of de PHP-threadlimiet al wordt bereikt, plus gegevens over responstijd en geheugengebruik. Zet de testomgeving over naar een actuele PHP 8.x-release, herhaal dezelfde workflows en controleer of de plugin nog werkt voordat je de wijziging in productie doorvoert.<\/p>\n Een testomgeving is nooit een exacte kopie van productie. Toch zie je er wel of de plugin te veel verzoeken langs de cache stuurt, te lang op een externe API wacht, dure queries uitvoert of te weinig PHP-capaciteit overlaat voor de rest van de site.<\/p>\n WordPress 7.0 geeft ontwikkelaars een standaardmanier om te integreren met AI-providers en modellen aan te roepen vanuit WordPress. Zodra de functie live staat, moet de server die verzoeken alsnog verwerken.<\/p>\n Open een paar APM-traces voordat je je hostingsetup aanpast. De pluginlijst laat niet zien hoeveel werk de site verzet, en het aantal PHP-threads verklaart niet waarom een verzoek traag is. Een trace laat zien of het verzoek de cache omzeilde, hoe lang PHP erover deed en of de vertraging uit de database of de model-API kwam. Op basis daarvan bepaal je of de plugin werk nodig heeft of de site meer capaciteit.<\/p>\n Een AI-plugin kan perfect werken en toch slecht passen bij de huidige capaciteit van de site. Draai APM eerst in de testomgeving voordat je de plugin op de site van een klant zet, en kijk hoe lang de externe API-calls duren, welke verzoeken de cache missen en welke PHP-versie de omgeving gebruikt. Controleer die cijfers na de lancering nog een keer, als er echt verkeer over de site gaat.<\/p>\n Met die paar controles vang je thread-druk, trage dependencies en dure query’s op voordat ze uitmonden in een trage site, of in een lastig gesprek met de klant.<\/p>\n","protected":false},"excerpt":{"rendered":" Stel je het volgende voor. Je nieuwe WooCommerce-chatbot doorstaat elke test die je op hem afvuurt. Hij beantwoordt vragen over je producten, helpt klanten opties te …<\/p>\n","protected":false},"author":36,"featured_media":66741,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[],"topic":[960,898],"class_list":["post-66740","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","topic-botverkeer","topic-wordpress-prestaties"],"yoast_head":"\n![\"AI](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/ai-engine.png\")
AI-personalisatie, aanbevelingen en zoeken<\/h3>\n
AI-contentgeneratie en redactionele tools<\/h3>\n
![\"Jetpack](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/jetpackai.png\")
AI-agents en MCP-integraties<\/h3>\n
Wat AI-functies daadwerkelijk met je server doen<\/h2>\n
PHP-threads blijven langer bezet<\/h3>\n
Meer verzoeken omzeilen de cache<\/h3>\n
Databaseactiviteit wordt complexer<\/h3>\n
Vertraging bij externe API\u2019s wordt onderdeel van je siteprestaties<\/h3>\n
De drie hostingkenmerken die het belangrijkst zijn voor AI in WordPress<\/h2>\n
1. Ge\u00efsoleerde containerarchitectuur<\/h3>\n
2. Een actuele PHP-versie en de juiste configuratie<\/h3>\n
3. Inzicht in het volledige verzoek<\/h3>\n
![\"Kinsta](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/enabling-apm.png\")
\n
![\"Screenshot](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/kinsta-apm-tool.png\")
AI-functies veranderen ook je verkeersprofiel<\/h2>\n
![\"Kinsta](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/bot-protection.png\")
Wat je moet controleren voordat je een AI-functie aan een WordPress site toevoegt<\/h2>\n
1. Waar in de verzoekcyclus draait deze plugin?<\/h3>\n
2. Wat kan de plugin cachen?<\/h3>\n
3. Wat gebeurt er als de externe API traag is?<\/h3>\n
4. Test eerst in de testomgeving, met de APM-tool aan<\/h3>\n
![\"Screenshot](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/08\/apm-duration.png\")
5. Is PHP klaar voor het extra werk?<\/h3>\n
Beschouw elke AI-lancering als een infrastructuurwijziging<\/h2>\n