Un tema de WordPress creado con IA puede considerarse una base de diseño; para aceptar una web terminada hay que comprobar contenido real, edición cotidiana y operación posterior. La rapidez con la que aparece una primera versión no demuestra que el equipo podrá mantenerla cuando cambien servicios, responsables o requisitos.

WordPress.com anunció el 15 de septiembre de 2026 que su constructor con IA genera temas personalizados en los planes Premium y Business, y describió mejoras para solicitar cambios. El anuncio se refiere a ese servicio y esas condiciones. No significa que todas las instalaciones de WordPress.org dispongan del mismo flujo ni que un tema generado resuelva el alcance completo de una web empresarial. Consultar la fuente.

La pregunta para contratar es más duradera: ¿qué pruebas separan una propuesta visual de una entrega que la empresa puede utilizar?

La primera pantalla tiene un sesgo a su favor

Una demostración suele mostrar el contenido que mejor encaja: títulos breves, imágenes de proporción adecuada y pocas excepciones. El proyecto real incorpora nombres largos, servicios que no comparten estructura, fotografías distintas y documentos que necesitan contextualización.

Si solo evalúas la portada, aceptarás decisiones que todavía no han pasado por esas variaciones. Un diseño atractivo puede funcionar con sus ejemplos y romperse cuando el equipo edita una ficha. El problema no depende exclusivamente de que se haya usado IA; también ocurre con plantillas y diseños manuales.

La automatización cambia el coste de producir versiones. Por eso conviene reforzar el criterio de aceptación: generar más alternativas no debe sustituir comprobar la que se entrega.

Un contrato de aceptación en tres momentos

Proponemos organizar la aceptación por momentos de uso, en vez de por una lista de pantallas. Cada momento necesita una persona responsable y una evidencia. El formato puede incorporarse al alcance del proyecto, con las condiciones acordadas entre las partes.

  • Publicar: el contenido real se entiende, las rutas funcionan y los elementos importantes se conservan en distintos anchos.
  • Editar: la persona autorizada puede modificar tareas habituales sin desorganizar el diseño ni depender de instrucciones ambiguas.
  • Evolucionar: existe una forma prevista de añadir información, cambiar componentes y trasladar lo necesario si cambia la operación.

Estos momentos no sustituyen seguridad, SEO o accesibilidad. Ayudan a comprobarlos en situaciones concretas. «La web es editable» no explica qué puede editar el equipo, con qué permisos y qué ocurre si necesita un bloque diferente.

El contenido de prueba debe ser incómodo

Incluye un título largo, una imagen con otra proporción, una lista extensa y un servicio con condiciones particulares. No son datos ficticios para publicar, sino material de ensayo controlado. Después sustituye el ensayo por información confirmada y comprueba la versión final.

La prueba permite ver si el sistema admite variedad o solo reproduce una composición. Si cada excepción exige una nueva instrucción al generador, documenta ese coste. Puede ser una opción válida, pero no debe ocultarse detrás de una promesa de autonomía editorial.

Un caso hipotético: una empresa que cambia su oferta

Una consultora recibe una web generada con cinco servicios. Meses después decide retirar uno y añadir otro con requisitos de entrada diferentes. La persona de marketing sabe editar párrafos, pero no puede reorganizar la comparación ni actualizar los enlaces relacionados.

La entrega inicial parecía completa porque todas las páginas estaban publicadas. La prueba de evolución habría revelado que la autonomía terminaba al cambiar la estructura. El siguiente paso habría sido acordar componentes reutilizables, un procedimiento asistido o un alcance de soporte explícito.

No existe una solución universal. Una empresa que cambia contenido a diario necesita más control que otra con una oferta estable y revisión trimestral. La arquitectura debe responder a esa frecuencia real, sin vender una complejidad que el equipo no necesita.

El resultado del ejemplo no es una reducción de costes calculada. Es una incógnita que puede resolverse antes de contratar: quién ejecutará los cambios previsibles y cómo se comprobarán.

La edición cotidiana necesita una prueba con el usuario real

Pide a la persona que administrará la web que cambie una información habitual en un entorno de prueba. Puede ser una descripción, una fotografía o un enlace a documentación. Entrega solo las instrucciones previstas para el uso diario.

Observa si identifica el elemento correcto, puede previsualizar y entiende qué está publicando. Comprueba permisos con una cuenta representativa. Una prueba realizada siempre como administrador no demuestra que el rol editorial tenga las mismas capacidades.

Después revisa el resultado público: enlaces, encabezados, texto alternativo y comportamiento móvil. El objetivo es descubrir qué errores puede provocar una operación normal y qué límites del sistema ayudan a evitarlos.

La formación tampoco debe quedar reducida a una llamada informal. Un procedimiento breve con ejemplos pertinentes permite mantener la operación cuando cambia la persona responsable.

Qué debe quedar claro en la entrega

Identifica cuentas, propiedad de activos, alcance de licencias, accesos y tareas de mantenimiento. Revisa las condiciones concretas del proveedor sobre exportación y traslado antes de prometer portabilidad. Que el contenido pueda exportarse no demuestra que diseño, funciones y configuración se reproduzcan igual en otro entorno.

Incluye las dependencias de servicios externos y qué ocurre si se cancela una suscripción. El coste de operación no se conoce sumando solo alojamiento y dominio si hay funciones que dependen de otros planes.

También conviene entregar las decisiones importantes: por qué se eligió una estructura, qué información es común y qué excepciones existen. Una conversación extensa con el generador no es necesariamente una documentación utilizable por el siguiente equipo.

La reflexión de futuro: la entrega se desplazará hacia la aceptación

Nuestra hipótesis es que, a medida que crear una primera versión resulte más sencillo, aumentará el valor del trabajo que define cuándo esa versión sirve. La diferencia profesional podría estar en los criterios, la integración y la capacidad de evolución, además de la apariencia.

Puedes contrastarlo registrando qué partes de los proyectos necesitan más correcciones después de publicar. Si los problemas aparecen en edición y cambios de estructura, el contrato de aceptación debe cubrir esos momentos. Si la oferta casi no cambia y el equipo trabaja bien, no hace falta añadir controles por costumbre.

Pide que te enseñen el segundo cambio

Antes de aceptar una web, no te limites a verla. Pide modificar una información, comprobarla y realizar un cambio de estructura previsto. Esa pequeña secuencia muestra qué autonomía compra la empresa y qué trabajo seguirá necesitando.

Es una base más sólida para contratar que elegir únicamente la versión que mejor impresiona en una demostración.

Para completar esta decisión, consulta Constructor visual o componentes a medida.