WordPress cumplió su misión. «Democratizar la publicación» ya no es una utopía pendiente, es el check que marcamos hace años. Tienes un móvil, cinco minutos, una cuenta en cualquier hosting de tres euros (o un Raspberry Pi en tu salón) y tienes un sitio web funcional, con un editor de bloques moderno, retrocompatible con versiones que ni siquiera recuerdas, capaz de servirse desde cualquier servidor HTTP estándar. El sueño se realizó.

Pero hay un problema. Los que estábamos en la trinchera cuando había que explicar qué era un permalink o por qué no podías tener cien plugins activados en un hosting compartido de 2006, nos estamos haciendo mayores. Y los que llegan ahora, los que tienen veintitantos y quieren construir cosas para la web, no miran a WordPress. Miran a la IA generativa de código. Le piden a ChatGPT, Claude o a herramientas como v0 o Bolt una landing page, un SaaS, una tienda. La IA escupe React, Tailwind, una base de datos serverless y un despliegue en Vercel en cuestión de minutos.

Es alucinante. Y es una trampa.

El lock-in del desarrollo a medida generado por IA

Cuando un cliente te pide una web y tú se la generas con una IA sobre una arquitectura propietaria (esa pila de JavaScript que solo tú entiendes, desplegada en una plataforma cerrada), el cliente no tiene un sitio. Tiene un alquiler camuflado. No puede moverlo, no puede auditarlo, no puede contratar a otra persona para que lo mantenga sin reconstruirlo desde cero. La IA ha democratizado la creación momentánea, pero ha aristocratizado la propiedad. El código generado es especialista, opaco, efímero. No es un bien que el cliente controla; es un servicio que le prestas disfrazado de producto.

Esto es exactamente lo contrario a lo que WordPress representa. En WordPress, el cliente posee su base de datos. Puede exportar sus entradas. Puede cambiar de hosting sin rediseñar nada. Puede contratar a otro desarrollador y que entienda la estructura en diez minutos. Ese principio de soberanía digital está en peligro de extinción justo cuando la tecnología prometía liberarnos.

La ironía es que WordPress tiene todo lo que la IA necesita para ser útil: una estructura de datos semántica (tipos de contenido, taxonomías, metadatos), una API REST completa, un sistema de hooks y filtros que permite intervenir en cualquier capa sin romper el núcleo, y una licencia GPL que garantiza que el software sigue siendo del usuario. Lo único que falta es que la IA sepa cómo trabajar con WordPress en lugar de al margen de él.

El vacío visual: donde la IA aún no gana

Si hay un terreno donde los agentes de IA siguen dando patadas en la oscuridad, es el frontend visual. La IA genera código backend impecable. Escribe funciones PHP, consultas SQL, lógica de negocio, con una precisión que asusta. Pero cuando le pides que diseñe una página web bonita, funcional, coherente con una marca, que se vea bien en móvil y no pese veinte megabytes, el resultado es, con demasiada frecuencia, un desastre estético. Bloques mal anidados, CSS contradictorio, decisiones de diseño que no tienen sentido de la escala ni del ritmo visual.

Esto no es culpa de los modelos de lenguaje. Es culpa de la falta de estructura. Cuando la IA genera React puro, está escribiendo en un lienzo en blanco sin reglas. No hay un sistema de diseño impuesto, no hay un theme que respete, no hay una parrilla de bloques que obligue a la coherencia. Es el caos creativo de un niño con cien rotuladores.

Aquí es donde WordPress puede hacer algo que ninguna otra plataforma puede ofrecer: un lienzo estructurado para la creatividad artificial.

Gutenberg no es perfecto, pero es algo extraordinariamente valioso: un editor que impone una gramática visual. Los bloques son entidades semánticas. Un párrafo es un párrafo. Una columna es una columna. Un grupo es un grupo. La IA no tiene que adivinar cómo maquetar; tiene que elegir qué bloques encajan y en qué orden. Es como darle a un arquitecto no un montón de ladrillos sueltos, sino un sistema constructivo prefabricado donde cada pieza encaja con la siguiente. La calidad del diseño generado por IA sobre WordPress no dependerá de lo «listo» que sea el modelo, sino de lo bien definido que esté el sistema de bloques y los patrones del tema.

Imagina un flujo: le dices a tu agente de IA que necesitas una landing para un festival de jazz en San Sebastián (Donostia Jazz lleva 50 años con nosotros…). El agente no genera HTML desde cero. Se conecta a tu WordPress, elige un tema base con patrones de bloques adecuados, genera el contenido (textos, estructura de headings, alt texts accesibles), lo inserta en bloques nativos, ajusta los estilos globales del tema para que la paleta coincida con la identidad del festival, y publica. Tú luego puedes entrar en el editor y mover un bloque. El cliente puede cambiar la fecha del concierto sin llamarte. Y si el año que viene el festival cambia de diseño, se cambia el tema, no se reescribe el sitio.

Eso es democratización. Lo otro es artesanía digital irreproducible.

La capa de habilidades: plugins que hablan el idioma de los agentes

Para que esto funcione, WordPress necesita algo más que una API REST y un editor bonito. Necesita que todo el ecosistema de plugins se convierta en legible para máquinas. Hoy, instalar un plugin de formularios, de cacheo, de SEO o de comercio electrónico requiere una odisea de clicks, pantallas de configuración, y decisiones humanas que un agente no puede tomar porque no hay estándar para expresarlas.

Esto es inaceptable en la era de los agentes.

Lo que necesitamos es que cada plugin declare, de forma declarativa y estandarizada, qué puede hacer y cómo configurarse. Algo así como un abilities.json o un schema embebido que el core o un servicio de orquestación pueda leer:

• Este plugin de cacheo expone estas tres opciones: tipo de caché (objeto/página), tiempo de expiración, y exclusiones por URL.
• Este plugin de formularios tiene estos tipos de campo, estas reglas de validación, y estas acciones de envío.
• Este plugin de SEO necesita saber el nombre del sitio, la estructura de títulos, y si debe generar sitemaps.

Con esa información, un agente podría instalar, configurar y optimizar plugins sin intervención humana. No estoy hablando de magia; estoy hablando de que los desarrolladores de plugins incluyan archivos de esquema, comandos WP-CLI completos, y puntos de extensión bien documentados. Es trabajo de ingeniería aburrida, pero es lo que separa a una plataforma juguete de una plataforma infraestructura.

Automattic ya está moviendo fichas en esta dirección con el soporte de MCP (Model Context Protocol), permitiendo que agentes como Claude lean y escriban contenido en WordPress. Pero eso solo cubre el contenido. Falta la capa de administración. Falta que un agente pueda decir: «Voy a instalar este plugin, y sé exactamente qué filtros tiene disponibles para configurarlo sin tocar el panel de administración».

La comunidad debería empezar a exigirlo. Los repositorios de plugins deberían validar si un plugin tiene interfaz WP-CLI completa. Los marketplaces deberían puntuar mejor a los plugins que expongan schemas de configuración. El propio core debería ofrecer una API de «capabilities discovery» para que los agentes sepan qué pueden tocar y qué no. Sé que está en ello, pero no acaba de salir.

La infraestructura como ventaja competitiva injusta

Hay algo más, y esto me toca de cerca como administrador de sistemas. WordPress corre en cualquier parte. En un VPS de cinco euros. En un Proxmox en tu rack del garaje. En un Raspberry Pi. En una instancia EC2 o en un alojamiento compartido que aún usa Apache con mod_php. Esa ubiquidad no es un defecto; es un superpoder que ninguna plataforma cerrada puede replicar.

Cuando la IA genera software a medida sobre arquitecturas propietarias, está atando al cliente a un ecosistema: las funciones serverless de AWS, la base de datos de Firebase, el edge computing de Cloudflare. El cliente no tiene soberanía. Si la empresa cierra, si suben los precios, si cambian las políticas, el sitio muere o se reescribe. WordPress ofrece lo contrario: portabilidad total. Y en una era de incertidumbre geopolítica y regulatoria (piensa en GDPR, en la AI Act, en la dependencia de proveedores estadounidenses), la capacidad de tener tu sitio en tu propio hardware, en tu propia jurisdicción, no es nostalgia. Es estrategia de riesgo.

La web agentic no debería significar que cedemos el control a los agentes de las grandes corporaciones. Debería significar que cada persona, cada pyme, cada asociación, puede tener su propio agente operando sobre su propia infraestructura. WordPress es el único candidato serio para ser ese substrato.

Implicaciones: si no lo hacemos nosotros, lo harán otros (peor)

Si la comunidad WordPress no articula esta nueva misión, otros sí lo harán. Ya vemos plataformas como Framer, Webflow o incluso los generadores de código de IA intentando convertirse en el «sistema operativo de la web». Pero todos ellos fallan en el mismo punto: el cliente no posee nada. Estás alquilando un lienzo cerrado.

La oportunidad histórica de WordPress es convertirse en la única plataforma donde la IA trabaja para el usuario final, no en lugar de él. Donde el agente es un mayordomo que opera dentro de una casa que el cliente posee, no un operario de una fábrica a la que no puede entrar.

Esto requiere cambios concretos:

1. El core debe abrazar la agenticidad: mejorar la API REST, estabilizar las APIs internas para que los agentes puedan confiar en ellas durante años, y ofrecer endpoints de descubrimiento de capacidades.
2. Los themes deben ser sistemas de diseño para IA: no just pretty faces, sino bibliotecas de patrones de bloques bien documentados, con tokens de diseño que un agente pueda manipular programáticamente.
3. Los plugins deben exponer habilidades: schemas de configuración, comandos WP-CLI exhaustivos, y filtros que permitan la orquestación automatizada.
4. La comunidad debe evangelizar la soberanía: no solo la libertad del software, sino la libertad del sitio. Que el cliente pueda levantar su WordPress en otro servidor esta tarde si quiere.

El futuro

WordPress ganó la batalla de la publicación. Ahora tiene que ganar la batalla de la propiedad en la era de los agentes. No se trata de añadir más bloques al editor ni de hacer el panel de administración más bonito. Se trata de redefinir el contrato: cuando una IA construye algo para ti… ¿Dónde vive? ¿Quién lo controla? ¿Puedes moverlo?

Si la respuesta sigue siendo «en mi servidor, bajo mi dominio, con mi base de datos, y puedo cambiar de hosting mañana», entonces WordPress no solo tiene futuro. Tiene el futuro más importante de todos: el de la web que sigue siendo de las personas.

Y eso es algo por lo que merece la pena que sigamos levantando la mano en la sala.

Últimas entradas