WordPress verliest marktaandeel, maar wordt het juist sterker?

Het marktaandeel van WordPress daalt… maar is dat een goed of slecht teken? Jij mag het zeggen!

Het marktaandeel van WordPress daalt. AI-websitebouwers beloven complete websites te maken op basis van een paar prompts. En met behulp van vibe coding kan tegenwoordig bijna iedereen binnen een middag iets bouwen wat op een werkende applicatie lijkt.

Je zou dus kunnen concluderen dat WordPress zijn beste tijd heeft gehad.

Maar is dat ook werkelijk zo?

In het artikel WordPress Lost Market Share and Got Stronger. Here’s Why verdedigt Curt Noble in de blog van MemberPress een heel andere stelling. WordPress verliest weliswaar marktaandeel, maar zou als professioneel platform juist sterker worden. Bovendien ontwikkelt WordPress zich tot een omgeving waarin AI-agents niet alleen teksten en afbeeldingen kunnen genereren, maar ook gecontroleerd handelingen kunnen uitvoeren.

Dat is een interessante gedachte. Het artikel brengt drie ontwikkelingen samen die meestal afzonderlijk worden besproken: het dalende marktaandeel van WordPress, de eerste kater na de hype rond vibe coding en de nieuwe technische infrastructuur voor AI binnen WordPress.

Het is alleen geen neutraal marktonderzoek. Daar kom ik later op terug.

WordPress verliest marktaandeel

Jarenlang werd vrijwel ieder verhaal over WordPress begonnen met dezelfde statistiek: WordPress draaide op ruim 43 procent van alle websites. Dat percentage was zo indrukwekkend dat het bijna als bewijs werd gebruikt dat WordPress vanzelfsprekend de beste keuze was.

Inmiddels is dat aandeel wat gedaald. Voor critici is dat aanleiding om opnieuw de ondergang van WordPress aan te kondigen. Dat gebeurt overigens al zolang ik met WordPress werk. Eerst zou Drupal WordPress overbodig maken, daarna zouden gesloten websitebouwers het overnemen en vervolgens zouden headless systemen, no-codeplatforms en AI-websitebouwers de genadeklap uitdelen.

Toch moeten we een dalend marktaandeel serieus nemen. Geen enkel platform heeft eeuwig recht op zijn positie. Tegelijkertijd vertelt één percentage maar een beperkt verhaal.

Een verlaten hobbyblog, een automatisch gegenereerde affiliatewebsite, een omvangrijke WooCommerce-webshop en de website van een nationale krant tellen in zo’n statistiek namelijk ieder als één website. Het marktaandeel zegt hoeveel websites WordPress gebruiken, maar niet hoe belangrijk die websites zijn, hoeveel bezoekers zij ontvangen of hoeveel economische activiteit ermee is gemoeid.

De vraag is daarom niet alleen hoeveel WordPress-websites verdwijnen. We moeten vooral weten welke websites verdwijnen.

Verdwijnt vooral het laagwaardige deel van het web?

De auteur van het MemberPress-artikel geeft hiervoor een prikkelende verklaring. Een deel van de verdwenen WordPress-websites zou bestaan uit laagwaardige websites die voornamelijk zijn gemaakt om verkeer uit zoekmachines te trekken. Denk aan automatisch geproduceerde affiliatepagina’s, gekopieerde content en grote aantallen oppervlakkige artikelen rond zoekwoorden.

WordPress was daarvoor een logisch platform. Het was goedkoop, eenvoudig te installeren en via plugins bijna onbeperkt uit te breiden. Wie honderd of duizend websites wilde opzetten, kon dat relatief gemakkelijk doen.

Zoekmachines zijn de afgelopen jaren echter veel harder gaan optreden tegen automatisch geproduceerde content zonder duidelijke meerwaarde. Daardoor werd het verdienmodel achter een groot deel van deze websites minder aantrekkelijk. Sites verdwenen, verloren hun verkeer of werden niet langer onderhouden.

Als juist dit type website een relatief groot aandeel had binnen WordPress, kan het verdwijnen ervan het totale marktaandeel zichtbaar laten dalen zonder dat WordPress onder professionele websites even hard terrein verliest.

Dat klinkt aannemelijk. Maar aannemelijk is niet hetzelfde als bewezen.

We beschikken niet over een nette inventarisatie waarin alle verdwenen WordPress-sites naar type en reden van verdwijnen zijn gerangschikt. De auteur baseert dit deel van zijn betoog deels op openbare cijfers en deels op zijn eigen ervaring met de wereld van affiliatewebsites en zoekmachineoptimalisatie.

Het is dus een interessante hypothese, geen vaststaand feit.

De eerste kater na vibe coding

Tegelijkertijd speelt er iets anders. Met AI kan inmiddels in zeer korte tijd code worden gegenereerd. Je beschrijft wat je wilt, de AI schrijft de code en even later staat er iets op je scherm dat verrassend goed lijkt te werken.

Dat is indrukwekkend. Ik gebruik AI zelf ook bij grotere maatwerkprojecten. Maar er zit een groot verschil tussen een overtuigende demonstratie en software die jarenlang veilig, onderhoudbaar en uitbreidbaar moet blijven.

Bij een demonstratie is de belangrijkste vraag: werkt het nu?

Bij een professionele website of applicatie komen daar andere vragen bij. Wie begrijpt de gegenereerde code? Zijn de juiste permissies toegepast? Wat gebeurt er bij onverwachte invoer? Kan iemand anders het project later overnemen? Zijn wijzigingen getest? En wat gebeurt er als een plugin, API of PHP-versie verandert?

Daar ontstaat de kater na vibe coding. AI kan razendsnel iets produceren, maar snelheid aan het begin zegt weinig over de kosten en risico’s tijdens de rest van de levensduur.

Een website genereren is iets anders dan een website professioneel ontwikkelen en beheren.

Voor mij betekent AI-ondersteunde ontwikkeling daarom niet dat de mens uit het proces verdwijnt. Integendeel. De ontwikkelaar verschuift deels van uitvoerder naar architect, beoordelaar en eindverantwoordelijke. Requirements, beveiliging, versiebeheer en tests worden niet minder belangrijk omdat code sneller kan worden geschreven. Ze worden juist belangrijker.

WordPress bouwt infrastructuur voor AI

Het technisch interessantste deel van het artikel gaat over de manier waarop WordPress op AI reageert.

WordPress probeert niet één allesomvattende AI-assistent te bouwen die iedere denkbare taak uitvoert. In plaats daarvan ontstaat een infrastructuur waarmee WordPress, plugins en externe systemen op een gestandaardiseerde manier kunnen samenwerken.

Daarbij spelen onder meer de AI Client, de Abilities API en de WordPress MCP Adapter een rol.

De AI Client moet het voor plugins eenvoudiger maken om verschillende AI-providers te gebruiken zonder allemaal afzonderlijk hetzelfde technische wiel uit te vinden. De Abilities API biedt een standaard om vast te leggen welke handelingen WordPress of een plugin kan uitvoeren. Via een MCP Adapter kunnen zulke mogelijkheden vervolgens beschikbaar worden gemaakt aan AI-agents.

Een ability is daarbij meer dan een losse PHP-functie. De ontwikkelaar beschrijft onder andere:

• welke handeling beschikbaar is;
• welke invoer daarvoor nodig is;
• welke uitvoer wordt teruggegeven;
• wie de handeling mag uitvoeren;
• hoe invoer en uitvoer worden gevalideerd.

Een plugin zou bijvoorbeeld een ability kunnen aanbieden om een bestelling op te zoeken, een cursusinschrijving aan te maken of de metadata van een bericht te controleren. Een agent kan zo’n mogelijkheid ontdekken en gebruiken, maar alleen binnen de grenzen die door de ontwikkelaar zijn vastgelegd.

Dat laatste is belangrijk. Een professionele AI-integratie bestaat niet uit een agent onbeperkt toegang geven tot WordPress en vervolgens hopen dat het goed gaat. De agent hoort alleen de gereedschappen en bevoegdheden te krijgen die voor de taak nodig zijn.

Waarom dit groter is dan AI

De naam Abilities API doet misschien vermoeden dat het uitsluitend om AI gaat. De mogelijke betekenis is echter breder.

WordPress-functionaliteit wordt traditioneel op allerlei manieren beschikbaar gemaakt. De ene plugin gebruikt hooks, een andere levert globale functies, een derde gebruikt PHP-klassen en een vierde biedt eigen REST-endpoints aan. Voor ontwikkelaars is daar prima mee te werken, maar externe systemen kunnen niet vanzelf ontdekken wat een plugin kan en hoe die functionaliteit gebruikt moet worden.

Een gestandaardiseerde ability is vindbaar en beschrijft zichzelf. Dat kan niet alleen nuttig zijn voor AI-agents, maar ook voor automatisering, koppelingen tussen plugins, beheertools en externe applicaties.

De werkelijke vernieuwing is daarom niet dat WordPress ineens teksten met AI kan schrijven. Daar bestaan al jaren plugins voor. De vernieuwing is dat WordPress een gemeenschappelijke technische taal probeert te creëren voor handelingen die door mensen, plugins, applicaties en agents kunnen worden uitgevoerd.

Of dat werkelijk breed wordt geadopteerd, moeten we nog zien. WordPress kent genoeg veelbelovende API’s die slechts gedeeltelijk door het ecosysteem zijn omarmd. Maar als pluginontwikkelaars deze standaard wel gaan gebruiken, kan dit een belangrijker verandering worden dan de zichtbare AI-knoppen in de editor.

Wat betekent dit voor WordPress-klantwerk?

Voor bestaande websites betekent dit niet dat we nu haastig overal AI aan moeten toevoegen. Eerst moet de onderliggende website op orde zijn.

Een agent maakt een rommelige pluginstructuur niet automatisch beter. Onduidelijke rollen en permissies worden niet veiliger doordat er AI bij komt. En een slecht ontworpen gegevensmodel blijft een slecht ontworpen gegevensmodel, ook wanneer je er in gewone taal opdrachten aan kunt geven.

Bij maatwerkplugins wordt het wel verstandig om na te denken over de handelingen die later als ability beschikbaar kunnen worden gemaakt. Niet iedere interne methode of kleine functie hoeft naar buiten toe toegankelijk te worden. Het gaat vooral om duidelijke bedrijfsacties die ook vanuit een automatisering of een agent zinvol zijn.

Denk bijvoorbeeld aan:

• het opvragen van de status van een bestelling;
• het aanmaken van een supportticket;
• het controleren van ontbrekende productgegevens;
• het inschrijven van een cursist;
• het genereren van een rapportage binnen vooraf bepaalde grenzen.

Dat vraagt om een andere manier van ontwerpen. De functionaliteit moet niet alleen werken vanuit één beheerscherm, maar als een duidelijk afgebakende handeling met voorspelbare invoer, uitvoer en toegangscontrole.

Ook in offertes en klantgesprekken wordt het onderscheid belangrijker. Een klant kan terecht vragen waarom een website nog door een specialist moet worden gebouwd als AI binnen enkele minuten code kan genereren. Het antwoord is niet dat AI niets kan. Dat zou aantoonbaar onzin zijn.

Het antwoord is dat professionele ontwikkeling meer omvat dan de eerste productie van code. Het gaat ook om architectuur, beveiliging, onderhoudbaarheid, integraties, testen en verantwoordelijkheid. Juist nu bijna iedereen iets kan laten genereren, wordt het verschil tussen iets werkends en een betrouwbare oplossing zichtbaarder.

En wat betekent dit voor trainingen?

Voor trainingen rond WordPress, Elementor en AI betekent deze ontwikkeling dat alleen leren prompten niet voldoende is.

Een goede prompt kan een uitstekend resultaat opleveren, maar cursisten moeten ook begrijpen wat een agent doet, welke context beschikbaar is en welke gereedschappen de agent gebruikt. Ze moeten leren dat een agent fouten kan maken, aannames kan doen en opdrachten soms te letterlijk of juist te ruim interpreteert.

Dat bleek bijvoorbeeld ook tijdens mijn eigen tests met Elementor MCP. Een opdracht die voor een mens duidelijk lijkt, wordt niet noodzakelijk correct vertaald naar de onderliggende Elementor-widgets en velden. Het zichtbare resultaat kan aardig in de buurt komen, terwijl veldtypen, ID’s of andere technische details ongewijzigd blijven.

Daarom hoort een professionele workflow niet te eindigen bij: schrijf een prompt en bekijk de pagina.

Er horen ook requirements, tussencontroles, functionele tests en een eindcontrole bij. De mens blijft degene die bepaalt wat het doel is, of het resultaat klopt en of het verantwoord kan worden opgeleverd.

De opkomst van agents maakt vakkennis dus niet overbodig. Zonder kennis kun je moeilijk beoordelen of een agent goed werk heeft geleverd.

Een overtuigend verhaal is nog geen bewijs

Het MemberPress-artikel vertelt een aantrekkelijk verhaal. WordPress verliest aan de onderkant een hoeveelheid laagwaardige websites, blijft sterk bij serieuze organisaties en bouwt ondertussen de infrastructuur voor het tijdperk van AI-agents.

Ik zie zeker argumenten voor die visie. Vooral de technische ontwikkeling rond abilities en MCP is relevant. Toch moeten we opletten dat we een overtuigend verhaal niet verwarren met bewijs.

MemberPress is een commerciële pluginleverancier. Het bedrijf heeft belang bij een gezond en toekomstbestendig WordPress-ecosysteem. Dat betekent niet dat de analyse onjuist is, maar wel dat de gekozen invalshoek niet neutraal is.

Bovendien worden verschillende soorten uitspraken met elkaar verbonden. Het dalende marktaandeel is meetbaar. De strengere aanpak van laagwaardige content door zoekmachines is eveneens aantoonbaar. Maar de conclusie dat vooral zulke websites verantwoordelijk zijn voor de daling van WordPress is een interpretatie. En de verwachting dat de nieuwe AI-infrastructuur WordPress sterker zal maken, blijft voorlopig een voorspelling.

Het artikel bewijst dus niet dat WordPress sterker wordt. Het laat wel overtuigend zien waarom een dalend marktaandeel niet automatisch betekent dat het platform technisch of economisch achteruitgaat.

Drie vragen om over na te denken

1. Wanneer zegt marktaandeel werkelijk iets over de gezondheid van een platform?

Moeten we vooral kijken naar het totale aantal installaties? Of zijn het type websites, de hoeveelheid actief onderhoud, de economische waarde en het gebruik door professionele organisaties minstens zo belangrijk?

2. Maakt AI WordPress belangrijker of juist minder noodzakelijk?

AI kan steeds meer code en websites genereren. Tegelijkertijd hebben agents betrouwbare gegevensstructuren, duidelijke permissies en voorspelbare interfaces nodig. Is een volwassen CMS daarvoor een voordeel, of kunnen agents uiteindelijk voldoende infrastructuur zelf bouwen?

3. Waar ligt straks de waarde van de WordPress-professional?

Blijft het vak voornamelijk bestaan uit websites en plugins bouwen? Of verschuift de waarde steeds verder naar architectuur, kwaliteitscontrole, beveiliging, automatisering en het begeleiden van AI-agents?

WordPress hoeft niet de snelste te zijn

WordPress staat onder druk. Gesloten websitebouwers worden gebruiksvriendelijker, SaaS-platforms nemen technische zorgen uit handen en AI kan in korte tijd verrassend veel produceren. Het zou naïef zijn om te denken dat WordPress zijn positie vanzelf behoudt.

Tegelijkertijd ontwikkelt WordPress zich. Het wordt niet alleen een CMS waarin mensen pagina’s en berichten beheren, maar mogelijk ook een platform waarvan de functies op een gestandaardiseerde en gecontroleerde manier door andere systemen kunnen worden gebruikt.

Of dat voldoende is om WordPress sterker te maken, weten we nog niet. Dat hangt niet alleen af van wat er in WordPress Core wordt gebouwd, maar vooral van de vraag of pluginmakers, bureaus en ontwikkelaars die nieuwe mogelijkheden werkelijk gaan toepassen.

Bovendien moeten we niet vergeten, dat WordPress op technologisch vlak een mastodont is. In een artikel met de prikkelende titel ‘De Toekomst van WordPress- Heeft ons favoriete CMS de beste tijd gehad?‘ stel ik -terechte- vragen met betrekking tot de geschiktheid van WordPress voor een aantal specifieke doelen. WordPress is in eerste instantie een content-platform, geen applicatieplatform.

In mijn eerdere artikel ‘Gaan Webapps voor WordPress plugins vervangen?‘, stel ik dan -opnieuw naar mijn eigen mening de terechte- vraag, of ‘mega plugins’ binnen WordPress eigenlijk wel zo’n goed idee zijn, en of het niet beter is de werklast hiervan te offloaden naar andere, zelfstandig draaiende, applicaties.

De lichte daling van het marktaandeel bewijst daarom noch de ondergang, noch de heropleving van WordPress. De belangrijkere vraag is of het platform relevant blijft voor websites die veilig, onderhoudbaar en uitbreidbaar moeten zijn.

WordPress hoeft daarbij niet de snelste manier te zijn om iets te genereren. Het moet de betrouwbaarste omgeving worden om wat gegenereerd is professioneel te beheren.

Verder lezen

• WordPress Lost Market Share and Got Stronger. Here’s Why.
• Officiële documentatie van de WordPress Abilities API