Op zekerheid kun je niet wachten<\/h2>\n
Een scenario dat zomaar kan gebeuren: je ontwikkelaar is net diensten aan het vergelijken als een andere leverancier met een nieuw zoekproduct komt. De opdrachtgever stuurt de aankondiging door: \u201cMoeten we hierop wachten?\u201d<\/p>\n
Ondertussen blijft de support dezelfde artikellink rondsturen.<\/p>\n
Voordat je iets koopt, kan je bureau eerst uitzoeken waarom de huidige zoekfunctie de handleiding niet vindt. Misschien staan de artikelen in een custom post type dat de zoekconfiguratie overslaat. Of het artikel heeft het over \u201cseriebeheer\u201d, een woord dat klanten zelden gebruiken.<\/p>\n
Dat vraagt natuurlijk om verschillende oplossingen. Ontwikkelaars kunnen nagaan of de WordPress zoekfunctie<\/a> de artikelen uit het helpcentrum wel meeneemt. Een redacteur kan de woorden van klanten toevoegen en duidelijk maken welke instructies bij de huidige softwareversie horen.<\/p>\n Testvragen heb je al: die staan in je recente supporttickets. En het supportteam weet al welke handleiding bij welke vraag hoort, wat handig is. Probeer je die vragen uit op de site, dan zie je precies waar de zoekfunctie tekortschiet, zonder te hoeven raden wat klanten intypen.<\/p>\n Semantisch zoeken is een andere manier om dit te verbeteren. Machine learning zoekt dan naar content die hetzelfde betekent als de zoekopdracht, ook als de woorden verschillen. Zo vindt \u201cmijn boekingen van vrijdag verplaatsen\u201d aansluiting bij \u201cterugkerende afspraken verzetten\u201d.<\/p>\n De documentatie eronder blijft belangrijk. Gaan twee handleidingen over verschillende versies van de boekingssoftware, dan heeft de zoekdienst genoeg informatie nodig om ze uit elkaar te houden.<\/p>\n Die contentproblemen kan je bureau oplossen terwijl de aankoopbeslissing nog openstaat. Ga je daarna AI-zoeken testen, dan heb je een opgeruimdere bibliotheek en een reeks vragen om mee te vergelijken.<\/p>\n Zegt de opdrachtgever het zoekabonnement op, dan mag er geen enkele handleiding van de WordPress site verdwijnen. Redacteuren blijven simpelweg in WordPress werken. De zoekprovider bewaart alleen een ge\u00efndexeerde kopie van de content die de integratie hem stuurt.<\/p>\n Dat onderscheid telt zodra je een vervanging plant. Je bureau moet de zoekindex opnieuw kunnen opbouwen vanuit de originele artikelen, en niet afhankelijk zijn van een vertrekkende provider die de enige kopie moet teruggeven.<\/p>\n In dit helpcentrum kunnen custom post types<\/a> de handleidingen gescheiden houden van blogberichten. Met een custom field of taxonomie geef je aan over welke versie van de boekingssoftware een handleiding gaat. Die informatie hoort bij het artikel in WordPress, waar redacteuren haar kunnen bijhouden.<\/p>\n De indexeringscode stuurt de relevante tekst en metadata naar de zoekdienst en bewaart een verwijzing naar de WordPress post ID. Zo leidt een zoekresultaat altijd terug naar de juiste handleiding.<\/p>\n Let ook op wat je bij de provider moet exporteren. Misschien stelt je team synoniemen of rankingregels in op het dashboard van de dienst. Die instellingen moet je mogelijk apart exporteren of documenteren voordat je het account sluit. En dat dashboard mag niet de enige plek zijn waar staat welke handleidingen bij de huidige software horen.<\/p>\n Wijzigingen moeten ook de index bereiken. Vervangt een redacteur verouderde instructies, dan moet de integratie de bijbehorende ge\u00efndexeerde content bijwerken of verwijderen. Gebeurt dat niet, dan blijft de zoekfunctie een antwoord tonen dat allang niet meer in de bibliotheek staat.<\/p>\n Met openbare handleidingen blijft de eerste proef eenvoudig. Komt er later documentatie bij die alleen voor leden is, dan moet de integratie eerst de toegangsregels van de site handhaven, voordat ze afgeschermde resultaten toont of fragmenten naar een antwoordmodel stuurt. Dat iemand is ingelogd, zegt nog niets over de artikelen die hij of zij met dat lidmaatschap mag lezen.<\/p>\n Het zoekvak kan in het WordPress thema blijven staan, terwijl een plugin de API van de provider afhandelt. Het thema geeft de zoekopdracht door aan de plugin, en die verstuurt de request en zet het antwoord om naar het formaat dat de site verwacht.<\/p>\n De plugin kan bijvoorbeeld de document-ID\u2019s van de provider koppelen aan WordPress post ID\u2019s. Het thema toont dan de bijbehorende handleidingen met hun WordPress titels en permalinks. Stap je over op een nieuwe provider, dan heb je werk aan de integratie, maar de lay-out van het helpcentrum kan grotendeels blijven zoals die is.<\/p>\n Voordat je dat werk inschat, moet ook duidelijker worden wat \u201cAI-zoeken\u201d precies inhoudt.<\/p>\n In een systeem op basis van embeddings zet een model artikeltekst om in getallen, embeddings genoemd. Die komen in een zoekindex terecht. De zoekopdracht van een bezoeker wordt op dezelfde manier omgezet, waarna het systeem zoekt naar relevante content.<\/p>\n Een groot taalmodel kan met de opgehaalde fragmenten vervolgens een antwoord schrijven, als de feature die stap bevat. Wil je alleen relevante artikellinks tonen, dan heb je geen gegenereerd antwoord nodig.<\/p>\n Je bureau kan dit allemaal bij \u00e9\u00e9n managed zoekprovider afnemen, maar ook losse diensten combineren. Hoe dan ook moet de ontwikkelaar weten op welk onderdeel een voorgestelde wijziging betrekking heeft.<\/p>\n Het model dat de antwoorden schrijft, kun je vaak vervangen zonder de zoekindex aan te passen. Kies je een ander embeddingmodel, dan moet je de document-embeddings meestal opnieuw genereren en de index opnieuw opbouwen. Ook relevantiescores verschillen soms per provider, dus je ontwikkelaar moet controleren of de bestaande drempelwaarde nog bruikbare resultaten oplevert.<\/p>\n Kijk ook naar de recente cijfers uit het onderzoek uit 2025 van Andreessen Horowitz<\/a> onder 100 CIO\u2019s van grote bedrijven. Daarin gebruikt 37% van de CIO\u2019s minstens vijf modellen, tegenover 29% in het vorige onderzoek. Voor deze hypothetische opdrachtgever is \u00e9\u00e9n dienst misschien genoeg, maar je wilt wel weten wat een latere vervanging inhoudt.<\/p>\n Een kleine plugin kan voor die scheiding zorgen, zonder dat het project uitgroeit tot een framework voor elke denkbare leverancier. Zolang de plugin goed is opgezet, kun je het vervangingswerk ook goed inschatten.<\/p>\n Twintig openbare handleidingen over afsprakenbeheer zijn genoeg voor een nuttige eerste test. De supportmedewerkers leveren de vragen die klanten stellen en zoeken er het artikel bij dat het antwoord moet geven.<\/p>\n De ontwikkelaar haalt die zoekopdrachten door de bestaande zoekfunctie en door de proefdienst. Staat de juiste handleiding bij de eerste paar resultaten? Ziet de zoekfunctie het verschil tussen \u00e9\u00e9n afspraak wijzigen en alle toekomstige afspraken in een reeks?<\/p>\n Test ook met vragen waarop de documentatie geen antwoord heeft. Zoekt iemand op een feature die niet wordt ondersteund, dan mag die klant niet bij instructies uitkomen die er niets mee te maken hebben, alleen omdat de woorden op elkaar lijken.<\/p>\n Horen gegenereerde antwoorden bij de proef, beoordeel die dan apart. Een antwoord kan keurig naar de juiste handleiding verwijzen en toch een stap verkeerd weergeven. De supportmedewerkers moeten nagaan of een klant met dat antwoord de taak ook echt kan afronden.<\/p>\n Vier weken proefdraaien geeft de opdrachtgever genoeg tijd om te beslissen of hij met deze tool doorgaat. Spreek ook een budget af. Heeft de provider geen harde uitgavenlimiet, dan moet de tool gebruikslimieten hebben die nieuwe betaalde requests stoppen voordat het budget op is. Een e-mailwaarschuwing alleen houdt de kosten niet tegen, dus denk daar vooraf over na.<\/p>\n Uit het onderzoek \u201c2026 State of AI in the Enterprise\u201d van Deloitte<\/a> blijkt dat slechts 25% van de respondenten ongeveer 40% van hun AI-experimenten in productie neemt. Houd er dus rekening mee dat een tool misschien niet past.<\/p>\n De proef werkt zo goed dat de opdrachtgever de feature in de klantnieuwsbrief wil promoten. Een paar collega\u2019s van support die tijdens een vergadering wat zoekopdrachten testen, vertellen je niet hoe de integratie dat publiek aankan.<\/p>\n Stel dat de WordPress plugin voor elke zoekopdracht een synchrone API request doet. De PHP thread blijft dan bezet zolang hij op het externe antwoord wacht. Lopen er meerdere trage zoekopdrachten tegelijk, dan blijft er mogelijk minder capaciteit over voor andere niet-gecachete requests.<\/p>\n Test gelijktijdige zoekopdrachten dus voordat de nieuwsbrief de deur uitgaat. Je ontwikkelaar kan meten hoe lang de resultaten op zich laten wachten en tegelijk controleren of de rest van de site responsief blijft. Neem ook de rate limits van de externe provider mee in die test.<\/p>\n Datzelfde geldt voor de gebruikskosten. E\u00e9n bezoeker probeert misschien meerdere zoekopdrachten. Genereert de feature antwoorden, dan kan de hoeveelheid tekst die heen en weer gaat naar het model de kosten op basis van tokens be\u00efnvloeden. De requestdata uit de proef geven je een betere schatting dan het aantal bezoekers vermenigvuldigen met de kosten van \u00e9\u00e9n zoekopdracht.<\/p>\n Indexeren kost ook werk als er geen bezoekers zijn. Werk je \u00e9\u00e9n handleiding bij, dan zou normaal gesproken alleen de ge\u00efndexeerde content daarvan moeten veranderen en hoeven de embeddings van het hele helpcentrum niet opnieuw te worden gegenereerd. De ontwikkelaar moet controleren wat de gekozen plugin of dienst echt doet als een redacteur op Update klikt.<\/p>\n Uitbreiden kan ook stap voor stap. Vinden klanten de links nuttig, maar lezen ze de gegenereerde samenvattingen zelden, dan kan de opdrachtgever semantisch zoeken houden en het genereren van antwoorden uitzetten. Omdat die instellingen los van elkaar staan, kan hij concreet kosten besparen zonder de verbetering kwijt te raken die hij waardeert.<\/p>\n Stopt een provider met de API die je plugin gebruikt, dan moet je iets plannen. Een aankondiging van een nieuw model kan wachten tot er een reden is om ernaar te kijken.<\/p>\n Het helpt om de onderdelen uit elkaar te houden. Kiest je bureau zelf een model en roept het dat rechtstreeks aan, dan moet het ook de beschikbaarheid van dat model in de gaten houden. Een managed zoekdienst vangt modelwijzigingen soms intern op, terwijl jouw team de API-meldingen en de kwaliteit van de resultaten bewaakt.<\/p>\n De vragen uit de proef vormen meteen een kleine set regressietests. Een ontwikkelaar kan ze draaien na een grote update van de provider of op een voorgestelde vervanging. Met verwachte resultaten wordt een discussie over \u201cbeter zoeken\u201d een stuk concreter.<\/p>\n Staat de huidige handleiding bij de zoekopdracht over terugkerende afspraken nog bij de bovenste resultaten? En als de feature een antwoord genereert, blijft dan het verschil overeind tussen \u00e9\u00e9n boeking wijzigen en de hele reeks?<\/p>\n Vergelijk providers altijd op dezelfde content. Test je de ene op artikelen van vorige maand en de andere op herschreven handleidingen, dan zegt dat weinig over de providers zelf. Noteer in het testrapport daarom de contentversie en de relevante model- of dienstconfiguratie.<\/p>\n Lopen klanten tegen hiaten aan, dan kunnen supporttickets nieuwe zoekopdrachten opleveren. Zo krijgt een vervanger precies de vragen voor de kiezen die op deze site voor problemen zorgen.<\/p>\n Ook de kosten kunnen een reden zijn om opnieuw te kijken. Een goedkoper model voor gegenereerde antwoorden kan prima passen, zolang de antwoorden kloppen. Een algemene benchmarkscore zegt je minder dan hoe het model presteert op de eigen documentatie van de opdrachtgever.<\/p>\n In een WordPress testomgeving<\/a> kunnen ontwikkelaars een vervangende tool installeren terwijl klanten de live zoekfunctie blijven gebruiken. Kinsta biedt testomgevingen voor dit werk, en voor tests die meer resources nodig hebben zijn er Premium Testomgevingen.<\/p>\n Houd ook de externe zoekopzet gescheiden. Als je WordPress kloont, kunnen plugininstellingen meekomen die naar de productie-index verwijzen. Voordat de ontwikkelaar een indexeringstaak in de testomgeving draait, moet hij dus een testindex en inloggegevens met de juiste toegangsrechten instellen. Anders verandert een test zomaar de live zoekresultaten.<\/p>\n De Application Performance Monitoring<\/a> van Kinsta helpt om de WordPress kant van de integratie te onderzoeken. Met APM ingeschakeld kan je ontwikkelaar databasequery\u2019s en trage externe requests aan de serverzijde onderzoeken<\/a>. Voor calls aan de browserzijde heb je browserdiagnostiek nodig, want APM laat niet elke request zien die de browser van een bezoeker doet.<\/p>\n Aan die traces zie je of WordPress tijdens een trage zoekopdracht vooral op de provider staat te wachten. Extra hostingcapaciteit maakt de responstijd van die provider niet korter.<\/p>\n Blijkt uit tests dat de PHP capaciteit tekortschiet, dan kun je in MyKinsta de PHP resources<\/a> aanpassen binnen de beschikbare pakketopties. Met meer PHP threads kun je meer gelijktijdige requests verwerken, maar verdeel je dezelfde geheugenpool over meer threads, dan houdt elke thread minder geheugen over. Wil je prestaties vergelijken, zorg dan ook dat de resources en cachinginstellingen van de testomgeving redelijk overeenkomen met productie.<\/p>\nWordPress blijft de bron van de content<\/h2>\n
Zo houd je een wisseling van provider beheersbaar<\/h2>\n
Experimenten overzichtelijk houden<\/h2>\n
Voorbereiden op veranderingen in de werklast<\/h2>\n
Redenen om opnieuw te kijken<\/h2>\n
Hosting die je ruimte geeft om bij te sturen<\/h2>\n
![\"Kinsta](\"https:\/\/kinsta.com\/wp-content\/uploads\/2026\/10\/apm-tool.png\")