Cómo desactivar las funciones de IA en WordPress (núcleo o plugin, sin rodeos)
Descubre qué plugin, hosting o mu-plugin añade ese panel de IA, desactívalo sin romper nada y bloquea los rastreadores de IA en robots.txt sin perder tráfico de búsqueda.
Publicada
Casi toda función de IA que la gente quiere quitar de WordPress viene de un plugin, del hosting o de WordPress.com, no del núcleo autoalojado. Antes de pegar un fragmento con remove_action en functions.php, abre tu lista de plugins y localiza qué está pintando realmente ese panel de IA, porque eliminar una función que el núcleo no incluye es mucho esfuerzo tirado en un sitio que ya se está portando mal.
Esa distinción importa porque las soluciones son completamente distintas. Una función de un plugin tiene un interruptor en sus ajustes. Una función inyectada por el hosting vive en el panel de tu proveedor, no en el escritorio de WordPress. Y la otra pregunta, la que la gente suele tener en mente cuando dice “desactivar la IA” —impedir que las empresas de IA entrenen con tus entradas—, no es una opción de WordPress. Es un asunto de robots y de configuración del servidor.
Qué es del núcleo y qué no
WordPress autoalojado no incluye de serie ningún asistente de escritura con IA, chatbot ni generador de imágenes visible para el usuario. Si ves un icono de destellos de IA en el editor de bloques, algo lo ha instalado.
De dónde salen realmente las funciones de IA:
| Origen | Función típica | Dónde se desactiva |
|---|---|---|
| Jetpack | Bloque y panel del Asistente de IA | Ajustes de Jetpack, interruptor del módulo |
| Plugins de IA independientes | Generadores de contenido, chatbots, redactores de texto alternativo | La pantalla de ajustes del propio plugin |
| Plugins de SEO | Sugerencias de título y descripción con IA | Ajustes del plugin, normalmente por función |
| Maquetadores visuales | Generación de textos e imágenes con IA en la interfaz | Ajustes del maquetador o panel de la cuenta |
| Hostings gestionados | Asistentes de IA inyectados vía mu-plugin o panel | Panel de control del hosting |
| WordPress.com | Herramientas de escritura con IA alojadas | Ajustes de la cuenta de WordPress.com, no de tu sitio |
El proyecto WordPress sí tiene desarrollo activo relacionado con IA: plugins de funcionalidad experimentales que quizá acaben en el núcleo. Si estás en una versión reciente y ves algo con aire de IA que no puedes atribuir a un plugin, revisa primero tu lista de plugins instalados y después el registro de cambios de tu versión, en lugar de dar por hecho que hay un comportamiento del núcleo que debes filtrar. Esa cautela es deliberada: las afirmaciones ligadas a versiones concretas caducan rápido en este terreno, y una equivocada te manda a editar archivos sin motivo.
Localiza qué lo está añadiendo de verdad
Desactiva plugins por tandas hasta que el panel de IA desaparezca. Es tosco, pero te da una respuesta firme en vez de una suposición.
Si tienes WP-CLI, empieza listando todo lo activo:
wp plugin list --status=active --field=name
Después comprueba si hay código inyectado por el hosting, que no aparece en la pantalla normal de plugins:
ls -la wp-content/mu-plugins/
Los plugins de uso obligatorio se cargan automáticamente y no se pueden desactivar desde el escritorio. Si tu proveedor ha dejado ahí un asistente de IA, la única forma limpia de quitarlo es desde su panel de control: borrar el archivo suele acabar con el archivo de vuelta en la siguiente actualización de la plataforma.
Cómo desactivarlo bien
Usa el ajuste del propio plugin. Es la respuesta aburrida y es la correcta. Jetpack en concreto está construido con módulos independientes, así que puedes apagar el Asistente de IA y conservar estadísticas, copias de seguridad o lo que uses. La mayoría de plugins de IA independientes ofrecen una casilla de activación por función.
Si no usas el plugin para nada más, desactívalo entero. Un plugin de IA instalado pero “apagado” sigue cargando su código en cada petición. Desactivarlo es más rápido, más seguro y bastante más ligero que cualquier filtro.
Desenganchar con remove_action es el último recurso. Funciona de verdad, pero solo si conoces el nombre exacto del hook, el callback y la prioridad que registró el plugin, y solo hasta que el plugin renombre cualquiera de esas cosas:
// 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 );
El coste real: esto se rompe en silencio. Una actualización del plugin cambia el nombre de la clase, tu eliminación deja de coincidir, el panel de IA vuelve y nada da error para avisarte. Si usas este método, apunta qué has quitado y vuelve a comprobarlo después de cada actualización de ese plugin.
La misma cautela vale para desregistrar paneles del editor desde JavaScript. Es una capacidad real, pero estás metiendo mano en el registro de otro plugin mediante un identificador de texto, y ese identificador no es un contrato público.
No intentes bloquear funciones de IA editando constantes de wp-config.php que hayas encontrado en un foro. Ninguna constante del núcleo apaga la IA de un plugin de terceros. Si un fragmento afirma lo contrario y no puedes rastrear la constante hasta la documentación de ese plugin, no hace nada.
La otra pregunta: frenar el entrenamiento de IA con tu contenido
Esto es un tema aparte, y es donde está casi toda la inquietud real. Apagar un panel del editor no cambia nada sobre quién rastrea tus entradas. Eso se controla en robots.txt y, si quieres que se cumpla de verdad, en el servidor.
WordPress sirve un robots.txt virtual salvo que exista un archivo real en la raíz web. Si hay un archivo físico, WordPress se aparta por completo y ese archivo es lo que reciben los rastreadores. Para editar el virtual, fíltralo:
add_filter( 'robots_txt', function ( $output ) {
$output .= "\nUser-agent: GPTBot\nDisallow: /\n";
return $output;
}, 10 );
Montar las reglas a mano es donde la gente se equivoca: un token mal escrito no bloquea nada, y un Disallow: / despistado en el agente equivocado puede sacarte de la búsqueda normal. El generador de robots.txt monta los bloqueos de rastreadores de IA junto a tus directivas de búsqueda habituales para que veas el archivo completo antes de publicarlo.
Tokens que los grandes operadores publican y dicen respetar:
| Token | Operador | Qué cubre |
|---|---|---|
| GPTBot | OpenAI | Rastreo para entrenar modelos |
| ChatGPT-User | OpenAI | Peticiones lanzadas por la solicitud de un usuario |
| ClaudeBot | Anthropic | Rastreo |
| Google-Extended | Uso de tu contenido para entrenar Gemini, no el rastreo en sí | |
| Applebot-Extended | Apple | Uso para entrenar los modelos generativos de Apple |
| PerplexityBot | Perplexity | Rastreo |
| CCBot | Common Crawl | Archivo masivo con el que entrenan muchos modelos |
Dos advertencias honestas. La primera: robots.txt es voluntario. Los operadores serios lo cumplen; cualquiera que quiera ignorarlo lo hará. La segunda: bloquear no sale gratis. Algunos de estos tokens deciden si apareces en respuestas generadas por IA que te citan y te enlazan. Bloquéalos todos y pierdes esa vía de tráfico junto con la exposición al entrenamiento. Decide cuál de las dos cosas te importa de verdad.
Para imponerlo en vez de pedirlo por favor, bloquea en el servidor. En .htaccess con 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>
Las cadenas de user-agent se falsifican con una facilidad ridícula, así que esto frena el tráfico honesto pero no deseado, no a un scraper decidido. Bloquear por rango de IP verificado en tu CDN o cortafuegos es más fuerte, y la mayoría de CDN ya ofrecen una regla anti-bots de IA de un clic más fácil de mantener que una lista escrita a mano.
Lo que no funciona
llms.txt es una propuesta, no un estándar. Es un archivo markdown sugerido que describe tu sitio para los modelos de lenguaje. Ningún operador grande se ha comprometido a tratarlo como control de acceso. Añadirlo no cuesta nada y puede ayudar a cómo te leen los modelos, pero no bloquea nada.
Las metaetiquetas noai y noimageai no las respeta casi nadie. Salieron de la política de una plataforma concreta, no de un acuerdo del sector. Añadirlas no hace daño; esperar que funcionen sí.
Un plugin que promete “bloquear la IA” normalmente solo escribe reglas de robots. Está bien, y es exactamente lo que puedes hacer tú en diez líneas. No es una barrera legal ni técnica, y ningún plugin puede convertirla en una.
Bloquear rastreadores de IA no borra el contenido que ya está en un modelo entrenado. Nada de lo que añadas hoy saca retroactivamente tus entradas de un modelo publicado el año pasado. Las reglas de robots solo miran hacia delante.
Si sigues viendo un panel de IA
Si has apagado todos los plugins y el panel sigue ahí, revisa otra vez wp-content/mu-plugins/, después el panel de tu hosting y después si estás en WordPress.com en lugar de en una instalación autoalojada: allí los interruptores están en los ajustes de la cuenta, no en el escritorio del sitio. Y si la función reaparece tras actualizar un plugin, esa es la firma de un fragmento de desenganche que dejó de coincidir, no de un comportamiento del núcleo imponiéndose.
FAQ
Preguntas
¿El núcleo de WordPress trae funciones de IA que haya que desactivar?
WordPress autoalojado no incluye por defecto ningún asistente de escritura con IA, chatbot ni generador de imágenes visible para el usuario. Los paneles de IA en el editor vienen casi siempre de un plugin instalado, de un plugin inyectado por el hosting o de una integración del panel de tu proveedor. Revisa la lista de plugins antes de escribir código para eliminar algo que quizá el núcleo ni siquiera incluye.
¿Cómo desactivo el Asistente de IA de Jetpack?
Desactiva el módulo del Asistente de IA desde la pantalla de ajustes de Jetpack en lugar de tocar código. Jetpack está construido con módulos que se activan y desactivan de forma independiente, así que apagar ese quita su panel del editor y deja el resto funcionando. Si no usas ninguna otra función de Jetpack, desactivar el plugin entero es más sencillo y más ligero.
¿Puede remove_action desactivar la IA de un plugin?
A veces, pero es frágil. Solo funciona si conoces el hook, el callback y la prioridad exactos que registró el plugin, y una actualización puede renombrar cualquiera de los tres y restaurar la función sin avisar. Usa el ajuste propio del plugin cuando exista y deja el desenganche como último recurso que vuelves a comprobar tras cada actualización.
¿Bloquear rastreadores de IA en robots.txt sirve de algo?
Solo con los rastreadores que deciden obedecerlo. Operadores grandes como OpenAI, Anthropic, Google y Apple publican tokens de user-agent que dicen respetar, y bloquear esos merece la pena. Las reglas de robots no son un mecanismo de obligación, así que los actores malintencionados y las peticiones lanzadas por un usuario pueden ignorarlas. El bloqueo a nivel de servidor es la capa que sí se aplica.
¿Qué diferencia hay entre bloquear un rastreador de IA y bloquear la búsqueda con IA?
Algunos operadores usan tokens distintos para el entrenamiento y para responder preguntas en directo. Bloquear un token de entrenamiento mantiene tu contenido fuera del entrenamiento de modelos pero te deja visible en las respuestas de IA, mientras que bloquear un token de búsqueda o de user-agent puede sacarte de resultados generados por IA que de otro modo te citarían y enlazarían. Decide qué compensación quieres antes de bloquear los dos.
¿Es llms.txt un estándar que deba implementar?
No, llms.txt es una propuesta de la comunidad, no un estándar aprobado, y ningún operador grande de IA se ha comprometido a respetarlo como mecanismo de control de acceso. Añadir el archivo es inofensivo y barato, pero no lo trates como sustituto de las directivas de robots.txt ni del bloqueo a nivel de servidor. El trabajo de estandarización en esta área sigue en marcha.