WordPress 7.1 propone incorporar al núcleo tres nuevas «Core Abilities» de solo lectura: core/read-settings, core/read-content y core/read-users. En términos sencillos, son puertas de acceso estandarizadas para que un agente de IA pueda consultar la configuración, el contenido y los usuarios de tu sitio de forma controlada, en vez de tener que adivinarlo o depender de que cada plugin haga las cosas a su manera. En este artículo explicamos qué es exactamente cada una, qué permisos las protegen, qué puede y qué no puede hacer todavía un agente con acceso a ellas, y qué precauciones conviene tomar antes de que algo con acceso a tu WordPress empiece a leer de verdad lo que hay dentro.
En este artículo
- De dónde viene esto: un poco de contexto
- Qué puede leer exactamente cada Core Ability
- Cómo está protegido el acceso: no hay una capa de permisos nueva
- Lo que estas abilities no hacen (todavía)
- Cómo saber si tu web ya está exponiendo esta información
- La pieza que conecta esto con agentes externos: el adaptador MCP
- Precauciones y buenas prácticas antes de que un agente empiece a leer tu web
- Qué esperar a partir de aquí
Si has leído nuestro artículo sobre cómo conectar WordPress a proveedores de IA como ChatGPT, Gemini o Claude a través de la pantalla Connectors, esa conexión resuelve una parte del problema: cómo autenticarse. Pero conectar la clave API no es lo mismo que darle a un agente algo útil que hacer. Un modelo de IA conectado a tu web, si no tiene forma de consultar qué contenido existe realmente, apenas puede ir más allá de generar texto genérico. Las Core Abilities son la pieza que faltaba: el mecanismo por el que un agente puede preguntar «¿qué entradas hay?» o «¿cuál es la página de inicio?» y recibir una respuesta real, estructurada y con permisos verificados.
De dónde viene esto: un poco de contexto
La API de Abilities no es una novedad de última hora, aunque ahora esté cobrando protagonismo. Llegó al núcleo en la versión 6.9 como un registro de «capacidades» discretas: funciones concretas que WordPress puede exponer con un esquema claro de qué recibe y qué devuelve, y con comprobación de permisos incorporada desde el diseño, no añadida después.
En la versión 7.0 esa API se extendió también al navegador, lo que permitió que el propio editor y otras herramientas del panel de administración empezaran a apoyarse en ella. Con la 7.1, prevista para el 19 de agosto de 2026, llega la parte que de verdad interesa a quien no es desarrollador: un primer conjunto de abilities que cubren los tres tipos de datos más básicos de cualquier WordPress, ajustes, contenido y usuarios, ya en modo de solo lectura.
La lógica detrás de esta expansión, según ha explicado el propio equipo de contribución al proponerla, es simple: sin estas piezas, cualquier integración de IA puede llamar a un modelo, pero no puede responder con fiabilidad preguntas tan básicas como qué entradas existen o cuál es la página de inicio configurada.
Qué puede leer exactamente cada Core Ability
core/read-settings
Permite consultar los ajustes generales del sitio: título, descripción, estructura de permalinks y otros valores de configuración similares. No cualquier ajuste queda expuesto automáticamente: cada grupo de ajustes tiene que marcarse explícitamente como visible para esta funcionalidad mediante un indicador (`show_in_abilities`), del mismo modo que ya ocurre con `show_in_rest` para la API REST. Si un desarrollador no lo activa, esa configuración simplemente no aparece disponible para los agentes.
core/read-content
Permite consultar contenido de los tipos de contenido que estén marcados como visibles, tanto elementos individuales como colecciones (por ejemplo, «dame todas las entradas publicadas en junio»). Igual que con los ajustes, un tipo de contenido personalizado no queda expuesto por defecto: alguien tiene que decidir explícitamente que lo esté.
core/read-users
Permite consultar datos de usuarios, ya sea de forma individual o filtrados por rol o estado. Aquí el control de acceso es especialmente relevante, porque estamos hablando de datos de personas, no solo de contenido publicado.
Un ejemplo que se ha usado para justificar esta funcionalidad y que ilustra bien para qué sirve en la práctica: poder pedirle a un asistente de IA conectado a tu web algo como «prepárame un borrador titulado ‘Resumen de junio’ que enlace y resuma todas las entradas que publiqué ese mes». Para que un agente pueda hacer eso de forma fiable, necesita antes poder consultar qué entradas existen realmente, en vez de inventárselas.
Cómo está protegido el acceso: no hay una capa de permisos nueva
Este es, probablemente, el punto que más tranquiliza y a la vez más conviene entender bien: estas abilities no inventan un sistema de permisos nuevo. Reutilizan las capacidades (capabilities) que WordPress ya usa desde siempre.
– **core/read-settings** requiere el permiso `manage_options`, el mismo que ya controla quién puede tocar los ajustes generales del sitio desde el panel de administración.
– **core/read-users** requiere `list_users`, el mismo permiso que decide quién puede ver el listado de usuarios en el escritorio.
– **core/read-content** respeta el mapa de capacidades habitual de cada tipo de contenido: si un rol no puede ver un borrador ajeno desde el panel, tampoco podrá verlo a través de esta funcionalidad.
En otras palabras: un agente de IA no obtiene ningún superpoder que un usuario humano con el mismo rol no tuviera ya. Si el agente actúa autenticado como administrador, verá lo que un administrador vería. Si actúa con un rol más limitado, verá menos. Esto es, en el fondo, una decisión de diseño consciente para no complicar el modelo de permisos de WordPress con una capa paralela.
Lo que estas abilities no hacen (todavía)
Conviene ser preciso aquí porque es fácil imaginar más de lo que hay: las tres abilities propuestas para la 7.1 son de **solo lectura**. Ningún agente puede, a través de ellas, modificar ajustes, crear o editar contenido, ni cambiar datos de usuarios. Las capacidades equivalentes de escritura (`core/manage-settings`, `core/manage-content`, `core/manage-users`) están ya sobre la mesa como siguiente paso, pero no forman parte de esta propuesta.
Tampoco incluyen, de momento, consultas avanzadas del tipo meta_query o tax_query, ni combinaciones cruzadas con taxonomías complejas; eso queda explícitamente pospuesto para una versión posterior. Si ves a algún plugin o servicio anunciando funciones muy sofisticadas de consulta apoyadas en estas abilities, merece la pena comprobar sobre qué versión de WordPress están construidas realmente.
Cómo saber si tu web ya está exponiendo esta información
Aquí hay un matiz importante para quien no es desarrollador: **activar qué se expone no es, de momento, un interruptor visible en el panel de ajustes para el propietario del sitio**. La decisión de marcar un ajuste o un tipo de contenido como visible para estas abilities (`show_in_abilities`) la toma quien desarrolla el tema o el plugin, en el código. No es algo que tú vayas a encontrar como una casilla que marcar o desmarcar desde Ajustes, al menos con lo propuesto hasta ahora.
Esto significa que, en la práctica, la forma de saber qué está expuesto en tu web es preguntarle directamente a quien mantiene tus plugins y tu tema, o revisar su documentación si la actualizan explicando esta compatibilidad. Si gestionas la web tú mismo con un tema y plugins conocidos, otra opción razonable es esperar a que la propia comunidad y las guías de cada plugin vayan aclarando qué exponen por defecto una vez la 7.1 esté publicada de forma estable.
La pieza que conecta esto con agentes externos: el adaptador MCP
Estas abilities no solo sirven para el asistente de IA integrado en el propio WordPress. A través de un adaptador de MCP (Model Context Protocol), las mismas capacidades pueden exponerse como herramientas utilizables por agentes externos, incluyendo asistentes como Claude o ChatGPT cuando se conectan a tu sitio mediante la pantalla Connectors que ya vimos en un artículo anterior. Dicho de forma sencilla: primero conectas el proveedor de IA a tu WordPress, y estas abilities son parte de lo que ese proveedor puede llegar a consultar una vez conectado, siempre dentro de los permisos del usuario o la integración con la que se haya autenticado.
Precauciones y buenas prácticas antes de que un agente empiece a leer tu web
Que el sistema reutilice los permisos existentes es una buena noticia, pero no elimina la necesidad de pensar con cuidado cómo se configura todo esto en un sitio real. Algunas recomendaciones concretas:
– **No conectes agentes externos con credenciales de administrador por comodidad.** Si tu plugin o integración lo permite, crea un usuario o una contraseña de aplicación específica con el rol más bajo que sea funcionalmente suficiente. Si el agente solo necesita leer entradas publicadas, no necesita permisos para ver usuarios ni ajustes generales.
– **Revisa periódicamente qué está marcado como visible.** Aunque tú no controles directamente el indicador `show_in_abilities`, sí puedes (y conviene) preguntar a los desarrolladores de tus plugins y tema qué exponen, especialmente si tu web maneja datos de clientes, formularios o áreas privadas.
– **Ten especial cuidado con core/read-users.** De las tres, es la que más directamente toca datos personales. Si gestionas una web con usuarios registrados (una tienda, una comunidad, un área de clientes), revisa qué rol tiene la integración de IA antes de darla por buena, y valora si de verdad necesita acceso a esa información.
– **Vigila los registros de acceso si tu hosting los ofrece.** Al ser un mecanismo nuevo y todavía en rodaje, tiene sentido revisar de vez en cuando qué está consultando cada integración conectada, sobre todo en los primeros meses tras actualizar a la 7.1.
– **No asumas que «de solo lectura» significa «sin riesgo».** Leer datos también puede ser un problema si esos datos son sensibles y terminan procesados por un servicio externo. Esto conecta directamente con lo que ya comentamos sobre privacidad al hablar de las conexiones a proveedores de IA: antes de que un agente lea contenido o usuarios de tu web, vale la pena tener claro hacia dónde viaja esa información y qué hace el proveedor con ella.
– **Actualiza con algo de margen, no el primer día.** Como suele pasar con funcionalidades nuevas del núcleo, es razonable esperar a que pasen las primeras semanas tras el lanzamiento de la 7.1 antes de actualizar un sitio en producción con estas dependencias activas, y probarlo primero en un entorno de pruebas.
Vale la pena mencionar, además, que esta propuesta concreta no ha llegado sin debate interno dentro del propio equipo de WordPress: algún mantenedor de la API ha expresado dudas sobre si las abilities están suficientemente probadas para entrar directamente en el núcleo en la 7.1, en vez de rodarse antes como parte del plugin experimental de IA. Es una señal razonable de que, aunque el diseño de permisos es sólido sobre el papel, la implementación todavía se está terminando de asentar, y conviene seguir de cerca cómo evoluciona antes de apoyar procesos críticos en ella.
Qué esperar a partir de aquí
Lo que llega en la 7.1 es, sobre todo, la base: tres piezas de solo lectura que dan a los agentes de IA algo real que consultar en vez de tener que adivinarlo. Las capacidades de escritura, las consultas más avanzadas y la cobertura de otros tipos de datos (comentarios, taxonomías, medios, temas, plugins) están planteadas como pasos siguientes, no como parte de esta versión.
Para quien gestiona una web, el mensaje práctico es sencillo: no hace falta activar nada de forma urgente ni tampoco hay motivo para alarmarse. Sí conviene entender qué es esto cuando empiece a aparecer mencionado en la documentación de tus plugins, y aplicar el mismo sentido común que ya usarías con cualquier otro tipo de acceso a tu web: dar el mínimo permiso necesario, y no más.