How to Disable WordPress AI Features (Core vs Plugin, Honestly)

Almost every AI feature people want gone in WordPress comes from a plugin, a host, or WordPress.com — not from self-hosted core. Before you paste a remove_action snippet into functions.php, open your plugin list and find the thing that is actually rendering that AI panel, because removing a feature core does not ship is a lot of wasted effort on a site that is already misbehaving.

That distinction matters because the fixes are completely different. A plugin feature has a settings toggle. A host-injected feature lives in your hosting dashboard, not your WordPress admin. And the separate question people usually mean when they say “disable AI” — stopping AI companies from training on your posts — is not a WordPress setting at all. It is a robots and server-config problem.

What is core and what is not

Self-hosted WordPress core does not ship a user-facing AI writing assistant, AI chatbot, or AI image generator that runs out of the box. If you see an AI sparkle icon in the block editor, something installed it.

Where AI features genuinely do come from:

Source	Typical feature	Where you turn it off
Jetpack	AI Assistant block and editor panel	Jetpack settings, module toggle
Standalone AI plugins	Content generators, chatbots, alt-text writers	The plugin’s own settings screen
SEO plugins	AI title/description suggestions	Plugin settings, usually per-feature
Page builders	AI copy and image generation in the builder UI	Builder settings or account panel
Managed hosts	AI assistants injected via an mu-plugin or dashboard	Host control panel
WordPress.com	Hosted AI writing tools	WordPress.com account settings, not your site

The WordPress project does have ongoing AI-related development — experimental feature plugins that may eventually land in core. If you are on a recent release and see something AI-flavored you cannot attribute to a plugin, check your installed plugin list first and your release’s own changelog second, rather than assuming a core default you need to filter away. That hedge is deliberate: version-specific claims in this area go stale fast, and a wrong one sends you editing files for no reason.

Find what is actually adding it

Deactivate plugins in batches until the AI panel disappears. Crude, but it gives you a definite answer instead of a guess.

If you have WP-CLI, list everything active first:

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

Then check for host-injected code, which does not show up in the normal plugin screen:

ls -la wp-content/mu-plugins/

Must-use plugins load automatically and cannot be deactivated from the admin. If your host dropped an AI assistant in there, the only clean removal is through their control panel — deleting the file often means it reappears on the next platform update.

Turning it off properly

Use the plugin’s own setting. This is the boring answer and it is the right one. Jetpack in particular is built around independently toggleable modules, so you can switch off AI Assistant while keeping stats, backups, or whatever else you rely on. Most standalone AI plugins expose an enable/disable checkbox per feature.

If you do not use the plugin for anything else, deactivate the whole plugin. An AI plugin left installed but “disabled” still loads its code on every request. Deactivating is faster, safer, and measurably lighter than any filter.

Unhooking with remove_action is a last resort. It genuinely works, but only when you know the exact hook name, callback, and priority the plugin registered, and only until the plugin renames any of those:

// 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 );

The honest cost: this breaks silently. A plugin update changes the class name, your removal stops matching, the AI panel comes back, and nothing errors to tell you. If you use this approach, write down what you removed and re-check it after every update of that plugin.

The same caution applies to unregistering editor panels from JavaScript. It is a real capability, but you are reaching into another plugin’s registration by string identifier, and that identifier is not a public contract.

Do not try to block AI features by editing wp-config.php constants you found in a forum post. No core constant switches off third-party plugin AI. If a snippet claims otherwise and you cannot trace the constant to that plugin’s documentation, it does nothing.

The other question: stopping AI training on your content

This is separate, and it is where most of the real anxiety sits. Turning off an editor panel changes nothing about who crawls your posts. Controlling that happens in robots.txt and, if you want it enforced, at the server.

WordPress serves a virtual robots.txt unless a real file exists at your web root. If a physical file is present, WordPress steps aside entirely and that file is what crawlers get. To edit the virtual one, filter it:

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

Building the rules by hand is where people make mistakes — one wrong token blocks nothing, and a stray Disallow: / on the wrong agent can pull you out of normal search. The robots.txt generator assembles the AI-crawler blocks alongside your regular search directives so you can see the whole file before it goes live.

Tokens that major operators publish and say they honor:

Token	Operator	What it covers
GPTBot	OpenAI	Crawling for model training
ChatGPT-User	OpenAI	Fetches triggered by a user’s request
ClaudeBot	Anthropic	Crawling
Google-Extended	Google	Use of your content for Gemini training, not crawling itself
Applebot-Extended	Apple	Use for Apple’s generative model training
PerplexityBot	Perplexity	Crawling
CCBot	Common Crawl	Bulk archive many models train on

Two honest caveats. First, robots.txt is voluntary. Well-behaved operators follow it; anything that wants to ignore it will. Second, blocking is not free. Some of these tokens govern whether you appear in AI-generated answers that cite and link you. Block them all and you lose that referral surface along with the training exposure. Decide which one you actually care about.

For enforcement rather than a polite request, block at the server. In .htaccess on 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 are trivially spoofed, so this stops honest-but-unwanted traffic, not a determined scraper. Blocking by verified IP range at your CDN or firewall is stronger, and most CDNs now ship a one-click AI-bot rule that is easier to maintain than a hand-written list.

What does not work

llms.txt is a proposal, not a standard. It is a suggested markdown file describing your site for language models. No major operator has committed to treating it as access control. Adding it costs nothing and may help how models read you, but it blocks nothing.

noai and noimageai meta tags are honored by almost nobody. They came out of one platform’s policy, not a cross-industry agreement. Adding them is not harmful; expecting them to work is.

A plugin promising to “block AI” usually just writes robots rules. That is fine, and it is exactly what you can do yourself in ten lines. It is not a legal or technical barrier, and no plugin can make it one.

Blocking AI crawlers does not remove content already in a trained model. Nothing you add today retroactively pulls your posts out of a model shipped last year. Robots rules are forward-looking only.

Still seeing an AI panel

If every plugin is off and the panel persists, check wp-content/mu-plugins/ again, then your host’s dashboard, then whether you are on WordPress.com rather than self-hosted — the toggles live in the account settings there, not in the site admin. And if the feature reappears after a plugin update, that is the signature of an unhooking snippet that stopped matching, not of a core default asserting itself.