Zitten er AI-functies in WordPress core die ik moet uitschakelen?

Zelf gehoste WordPress core levert geen zichtbare AI-schrijfassistent, chatbot of beeldgenerator die standaard meedraait. AI-panelen in de editor komen bijna altijd van een geïnstalleerde plugin, een plugin die je host erin zet, of een integratie in het hostingdashboard. Loop je pluginlijst na voordat je code schrijft om iets te verwijderen dat core misschien helemaal niet bevat.

Hoe zet ik Jetpack AI Assistant uit?

Schakel de module AI Assistant uit in het instellingenscherm van Jetpack in plaats van code aan te passen. Jetpack is opgebouwd uit modules die je los kunt aan- en uitzetten, dus deze ene uitzetten haalt het editorpaneel weg terwijl de rest van Jetpack blijft werken. Gebruik je verder niets van Jetpack, dan is de hele plugin deactiveren eenvoudiger en lichter.

Kan ik met remove_action een AI-functie van een plugin uitzetten?

Soms wel, maar het is broos. Het werkt alleen als je de exacte hook, callback en prioriteit kent waarmee de plugin zich registreert, en één plugin-update kan die namen wijzigen waardoor de functie stilletjes terugkomt. Gebruik de eigen instelling van de plugin als die bestaat, en zie unhooken als laatste redmiddel dat je na elke update opnieuw controleert.

Werkt het blokkeren van AI-crawlers in robots.txt echt?

Alleen bij crawlers die zich er vrijwillig aan houden. Grote partijen zoals OpenAI, Anthropic, Google en Apple publiceren user-agent-tokens waarvan ze zeggen die te respecteren, en die blokkeren is de moeite waard. Robots-regels zijn geen afdwinging, dus kwaadwillenden en door gebruikers gestarte verzoeken kunnen ze negeren. Blokkeren op serverniveau is de laag die je wel kunt afdwingen.

Wat is het verschil tussen een AI-crawler blokkeren en AI-zoekresultaten blokkeren?

Sommige aanbieders gebruiken losse tokens voor training en voor het beantwoorden van actuele vragen. Een trainingstoken blokkeren houdt je content buiten modeltraining maar laat je zichtbaar in AI-antwoorden, terwijl een zoek- of user-agent-token blokkeren je kan weghalen uit AI-antwoorden die je anders zouden citeren en naar je zouden linken. Bepaal welke afweging je wilt voordat je allebei blokkeert.

Is llms.txt een standaard die ik moet invoeren?

Nee, llms.txt is een voorstel uit de community en geen vastgestelde standaard, en geen enkele grote AI-aanbieder heeft toegezegd het als toegangscontrole te respecteren. Het bestand toevoegen is onschadelijk en goedkoop, maar zie het niet als vervanging van robots.txt-regels of blokkades op serverniveau. Het standaardisatiewerk op dit vlak loopt nog.

WordPress AI-functies uitschakelen (core of plugin: het eerlijke verhaal)

Bijna elke AI-functie die mensen uit WordPress willen slopen komt van een plugin, een host of WordPress.com, en niet uit zelf gehoste core. Voordat je een remove_action-snippet in functions.php plakt: open je pluginlijst en zoek uit wat dat AI-paneel daadwerkelijk tekent. Een functie verwijderen die core helemaal niet meelevert is veel verspild werk op een site die toch al hapert.

Dat onderscheid is belangrijk, want de oplossingen verschillen volledig. Een plugin-functie heeft een schakelaar in de instellingen. Een functie die je host injecteert woont in je hostingdashboard, niet in je WordPress-beheer. En de aparte vraag die mensen meestal bedoelen met “AI uitzetten” (voorkomen dat AI-bedrijven op je berichten trainen) is helemaal geen WordPress-instelling. Dat is een kwestie van robots-regels en serverconfiguratie.

Wat wel core is en wat niet

Zelf gehoste WordPress core levert geen zichtbare AI-schrijfassistent, AI-chatbot of AI-beeldgenerator die out of the box meedraait. Zie je een glinsterend AI-icoontje in de blokeditor, dan heeft iets dat geïnstalleerd.

Waar AI-functies wél vandaan komen:

Bron	Typische functie	Waar je het uitzet
Jetpack	AI Assistant-blok en editorpaneel	Jetpack-instellingen, moduleschakelaar
Losse AI-plugins	Contentgenerators, chatbots, alt-tekstschrijvers	Het instellingenscherm van de plugin zelf
SEO-plugins	AI-suggesties voor titel en omschrijving	Plugin-instellingen, meestal per functie
Paginabouwers	AI-teksten en beeldgeneratie in de bouwer	Instellingen van de bouwer of accountpaneel
Managed hosts	AI-assistenten via een mu-plugin of dashboard	Configuratiescherm van de host
WordPress.com	Gehoste AI-schrijftools	Accountinstellingen op WordPress.com, niet op je site

Binnen het WordPress-project loopt wel degelijk AI-gerelateerde ontwikkeling: experimentele feature plugins die uiteindelijk in core kunnen landen. Draai je een recente versie en zie je iets AI-achtigs dat je niet aan een plugin kunt koppelen, kijk dan eerst in je lijst met geïnstalleerde plugins en daarna in de changelog van jouw versie, in plaats van uit te gaan van een core-standaard die je moet wegfilteren. Die slag om de arm is bewust: uitspraken over specifieke versies verouderen hier razendsnel, en een verkeerde stuurt je voor niets bestanden in.

Achterhalen wat het echt toevoegt

Deactiveer plugins in groepjes tot het AI-paneel verdwijnt. Grof, maar het geeft je een hard antwoord in plaats van een vermoeden.

Heb je WP-CLI, som dan eerst alles op wat actief is:

wp plugin list --status=active --field=name

Controleer daarna op code die je host erin zet, want die verschijnt niet in het normale pluginscherm:

ls -la wp-content/mu-plugins/

Must-use plugins laden automatisch en zijn niet vanuit het beheer te deactiveren. Heeft je host daar een AI-assistent neergezet, dan is het configuratiescherm van die host de enige nette manier om ervan af te komen. Het bestand verwijderen betekent meestal dat het bij de volgende platformupdate terugkomt.

Hoe je het netjes uitzet

Gebruik de eigen instelling van de plugin. Dat is het saaie antwoord en het juiste. Jetpack bestaat uit modules die je los kunt schakelen, dus je kunt AI Assistant uitzetten en statistieken, back-ups of wat je verder gebruikt gewoon laten draaien. De meeste losse AI-plugins hebben per functie een vinkje om het aan of uit te zetten.

Gebruik je de plugin verder nergens voor, deactiveer hem dan helemaal. Een AI-plugin die geïnstalleerd blijft maar “uitgeschakeld” is, laadt bij elk verzoek nog steeds zijn code. Deactiveren is sneller, veiliger en meetbaar lichter dan welke filter dan ook.

Unhooken met remove_action is een laatste redmiddel. Het werkt echt, maar alleen als je de exacte hooknaam, callback en prioriteit kent waarmee de plugin zich registreert, en alleen tot de plugin een van die drie hernoemt:

// Only if you have verified the exact hook, callback and priority.
// Runs late so the plugin has already registered its own hooks.
add_action( 'init', function () {
    remove_action( 'enqueue_block_editor_assets', array( 'Some_Plugin_Class', 'enqueue_ai_panel' ), 10 );
}, 99 );

De eerlijke prijs: dit gaat stilletjes stuk. Een plugin-update wijzigt de klassenaam, je verwijdering matcht niet meer, het AI-paneel keert terug, en er komt geen enkele foutmelding die je dat vertelt. Kies je hiervoor, noteer dan wat je hebt weggehaald en controleer het na elke update van die plugin opnieuw.

Dezelfde voorzichtigheid geldt voor het uitschrijven van editorpanelen vanuit JavaScript. Het kan echt, maar je grijpt via een tekstuele identifier in de registratie van een andere plugin, en die identifier is geen publieke afspraak.

Probeer AI-functies niet te blokkeren met wp-config.php-constanten die je in een forumbericht vond. Geen enkele core-constante zet AI van derden uit. Beweert een snippet van wel en kun je die constante niet terugvinden in de documentatie van die plugin, dan doet hij niets.

De andere vraag: AI-training op je content tegenhouden

Dat staat er los van, en daar zit de echte onrust. Een editorpaneel uitzetten verandert niets aan wie je berichten crawlt. Dat regel je in robots.txt en, als je het afgedwongen wilt hebben, op de server.

WordPress serveert een virtuele robots.txt, tenzij er een echt bestand in je webroot staat. Bestaat dat fysieke bestand wel, dan stapt WordPress volledig opzij en krijgen crawlers dat bestand. Wil je de virtuele versie aanpassen, filter hem dan:

add_filter( 'robots_txt', function ( $output ) {
    $output .= "\nUser-agent: GPTBot\nDisallow: /\n";
    return $output;
}, 10 );

De regels met de hand samenstellen is precies waar het misgaat: één verkeerd token blokkeert niets, en een verdwaalde Disallow: / bij de verkeerde agent kan je uit de gewone zoekresultaten trekken. De robots.txt-generator bouwt de AI-crawlerblokken samen met je normale zoekregels, zodat je het hele bestand ziet voordat het live gaat.

Tokens die grote aanbieders publiceren en zeggen te respecteren:

Token	Aanbieder	Waar het over gaat
GPTBot	OpenAI	Crawlen voor modeltraining
ChatGPT-User	OpenAI	Verzoeken die een gebruiker zelf start
ClaudeBot	Anthropic	Crawlen
Google-Extended	Google	Gebruik van je content voor Gemini-training, niet het crawlen zelf
Applebot-Extended	Apple	Gebruik voor Apple’s generatieve modeltraining
PerplexityBot	Perplexity	Crawlen
CCBot	Common Crawl	Bulkarchief waar veel modellen op trainen

Twee eerlijke kanttekeningen. Ten eerste is robots.txt vrijwillig. Nette partijen volgen het; wie het wil negeren, negeert het. Ten tweede is blokkeren niet gratis. Sommige van deze tokens bepalen of je verschijnt in AI-antwoorden die je citeren en naar je linken. Blokkeer je alles, dan verlies je dat verwijsverkeer samen met de trainingsblootstelling. Bepaal waar het je werkelijk om gaat.

Wil je het afdwingen in plaats van beleefd vragen, blokkeer dan op de server. In .htaccess op Apache:

<IfModule mod_setenvif.c>
  SetEnvIfNoCase User-Agent "GPTBot|CCBot|ClaudeBot|PerplexityBot" ai_bot
  <RequireAll>
    Require all granted
    Require not env ai_bot
  </RequireAll>
</IfModule>

User-agent-strings zijn triviaal te vervalsen, dus dit houdt eerlijk-maar-ongewenst verkeer tegen, geen vastbesloten scraper. Blokkeren op geverifieerde IP-reeksen bij je CDN of firewall is sterker, en de meeste CDN’s hebben inmiddels een AI-botregel met één klik die makkelijker te onderhouden is dan een handgeschreven lijst.

Wat niet werkt

llms.txt is een voorstel, geen standaard. Het is een voorgesteld markdownbestand dat je site beschrijft voor taalmodellen. Geen enkele grote aanbieder heeft toegezegd het als toegangscontrole te behandelen. Toevoegen kost niets en helpt misschien bij hoe modellen je lezen, maar het blokkeert niets.

De metatags noai en noimageai worden door vrijwel niemand gerespecteerd. Ze komen voort uit het beleid van één platform, niet uit een brede afspraak in de sector. Ze toevoegen is niet schadelijk; erop rekenen wel.

Een plugin die belooft “AI te blokkeren” schrijft meestal gewoon robots-regels. Dat is prima, en het is precies wat je zelf in tien regels doet. Het is geen juridische of technische barrière, en geen enkele plugin kan er een van maken.

AI-crawlers blokkeren haalt content die al in een getraind model zit er niet uit. Niets wat je vandaag toevoegt trekt je berichten met terugwerkende kracht uit een model dat vorig jaar is uitgebracht. Robots-regels werken alleen vooruit.

Zie je nog steeds een AI-paneel

Staat elke plugin uit en blijft het paneel staan, kijk dan opnieuw in wp-content/mu-plugins/, daarna in het dashboard van je host, en controleer daarna of je op WordPress.com zit in plaats van zelf gehost. Daar staan de schakelaars in de accountinstellingen en niet in het sitebeheer. En komt de functie terug na een plugin-update, dan is dat het handschrift van een unhook-snippet dat niet meer matcht, niet van een core-standaard die zich laat gelden.