WordPress Playground es la forma más rápida de abrir una copia completa de un WordPress dentro del propio navegador, sin contratar hosting ni tocar la base de datos real. La construye el propio equipo de WordPress.org con WebAssembly: PHP y SQLite corren en el cliente, así que cualquier cambio queda aislado de tu web en producción. Sirve para probar un plugin nuevo, comprobar si un tema rompe algo con PHP 8.4 o reproducir un fallo que reporta un cliente, todo en segundos y sin pedir permiso a nadie del equipo técnico.
WordPress Playground es una herramienta oficial de WordPress.org que ejecuta un WordPress completo dentro del navegador mediante WebAssembly, sin servidor ni base de datos real. Permite probar plugins, temas y actualizaciones de PHP en una copia desechable antes de tocar la web en producción, y cualquier cambio desaparece al cerrar la pestaña salvo que se exporte.
Qué resuelve WordPress Playground en el día a día
La mayoría de los sustos en un WordPress de producción no vienen de un ataque: vienen de una actualización que nadie probó antes. Un plugin que cambia de versión mayor, un tema que deja de pintar bien con PHP 8.4 o una regla de caché que entra en conflicto con otra extensión. Playground resuelve ese paso que casi nadie se para a dar porque exige levantar un entorno aparte: con un enlace basta para tener un WordPress limpio, con la versión de PHP y de core que se quiera elegir, listo en el navegador en unos segundos.
El caso típico: probar una actualización antes de aplicarla
El uso más habitual es el más aburrido: antes de actualizar un plugin de pago en la web de un cliente, se sube el mismo archivo a una instancia de Playground y se repite el flujo crítico —el formulario de contacto, el checkout, el filtro del catálogo— para comprobar que nada se rompe. Si la actualización falla, falla ahí, sin que el cliente lo note. El propio WordPress Playground se documenta como entorno de pruebas desechable: cada instancia vive aislada en el navegador y no deja rastro en ningún servidor real.
También sirve al revés: cuando un cliente reporta un fallo y no se puede reproducir en local, cargar su misma versión de WordPress y PHP en Playground acerca mucho más el escenario que adivinar con una instalación genérica.
Blueprints, la receta que clona tu configuración
Repetir a mano la misma instalación —mismo tema, mismos plugins, mismo contenido de prueba— cada vez que se abre una instancia nueva es la parte que cansa. Los blueprints son el archivo que evita eso: un JSON que describe paso a paso cómo debe quedar la instalación, y que Playground ejecuta solo al arrancar.
Un blueprint es un archivo JSON que define qué tema, qué plugins, qué contenido y qué versión de WordPress y PHP debe tener una instancia, para que no haga falta repetir esos pasos a mano cada vez.
La documentación oficial de blueprints detalla qué puede automatizar uno:
- Instalar un tema y una lista concreta de plugins, incluso en versiones determinadas.
- Importar contenido de prueba para no partir de una web vacía.
- Fijar la versión de WordPress y de PHP que se quiere comprobar.
- Crear un usuario administrador ya configurado, sin pasar por el asistente de instalación.
Qué define un blueprint en JSON
Un blueprint no ejecuta código arbitrario: solo describe pasos dentro de un vocabulario cerrado que el propio Playground interpreta, así que compartir uno con otra persona del equipo no exige la confianza que exigiría compartir un script. Para una agencia que mantiene varias webs con la misma pila de plugins, esto significa escribir un blueprint una vez y reutilizarlo en cada cliente que comparta esa configuración, en vez de montar el entorno de pruebas desde cero cada vez que toca revisar una actualización.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Por qué conviene antes de instalar un plugin
El motivo no es solo evitar un error visual. Según el informe State of WordPress Security de Patchstack, en 2025 se registraron 11.334 vulnerabilidades nuevas en el ecosistema de WordPress, un 42% más que el año anterior, y el 91% de ellas estaban en plugins, no en el núcleo. Probar un plugin antes de activarlo en producción no detecta una vulnerabilidad por sí solo, pero sí detecta el síntoma más frecuente de uno mal mantenido: errores con versiones recientes de PHP, conflictos con otros plugins activos o un panel de administración que deja de responder.
Esto encaja con lo ya visto al hablar de las vulnerabilidades en plugins de WordPress que se quedan sin parche: cuanto menos se sabe de un plugin antes de activarlo en la web real, más expuesta queda. Playground no sustituye una auditoría de seguridad, pero añade un filtro gratuito antes de esa decisión: si algo falla en una copia desechable, mejor ahí que en la web que factura.
Dónde se queda corto frente a un staging real
Playground no es un sustituto de un entorno de staging con su propio dominio y su propia base de datos persistente. Es una herramienta para una comprobación puntual, no para dejar un proyecto montado durante semanas.
Qué no reproduce Playground de tu servidor
Al correr entero en el navegador, sin conexión a internet desde dentro de la instancia, no puede probarse nada que dependa de una llamada externa real: una pasarela de pago, una integración con el CRM del cliente o un envío de correo con SMTP. Tampoco hay cron real ni persistencia garantizada —cerrar la pestaña sin exportar el estado borra lo que se haya hecho, que es justo el comportamiento que interesa para una prueba rápida pero no para un proyecto que se trabaja varios días—. Y la configuración de servidor (Nginx, Apache, reglas de reescritura, certificados) no existe: todo lo que dependa de esa capa hay que seguir probándolo en un staging de verdad, con mantenimiento WordPress gestionado como el que ya cubre la mayoría de agencias.
Así lo usan ya las agencias de WordPress
En una agencia de WordPress en Barcelona con varios clientes activos, el entorno de pruebas suele ser el cuello de botella: montar un staging por cliente cuesta tiempo de servidor y mantenimiento, así que en la práctica se salta ese paso y se actualiza directamente sobre la web real. Playground quita esa excusa para el primer filtro: no sustituye el staging del proyecto grande, pero cubre buena parte de las comprobaciones rápidas que hoy se hacen a ciegas.
El propio equipo de WordPress.org lo plantea también como entorno pensado para trabajar con agentes de IA, en la misma línea que la Abilities API de WordPress, que permite a esos agentes actuar directamente sobre una instalación: un agente puede levantar una instancia, aplicar un cambio y comprobar el resultado sin que nadie tenga que dejarle las llaves de la web real mientras lo hace.
Preguntas frecuentes sobre WordPress Playground
¿Es gratis WordPress Playground?
Sí. Es un proyecto de código abierto del propio WordPress.org, sin coste ni cuenta que crear. Se usa desde el navegador en playground.wordpress.net o se instala como plugin para clonar un sitio ya existente y probarlo aparte.
¿Se pierde el trabajo al cerrar la pestaña?
Por defecto sí: cada instancia vive solo en la memoria del navegador y desaparece al recargar. Para conservar los cambios hay que exportar el sitio como archivo ZIP o guardar el blueprint que lo reconstruye, en vez de depender de la sesión abierta en todo momento.
¿Sirve para probar una tienda online completa?
Sirve para probar la parte que no depende de servicios externos: el catálogo, las reglas de precio o el panel de administración. En cuanto entra una pasarela de pago real o un envío de correo, esa prueba hay que hacerla en un staging con conexión a internet, no en Playground.
¿Hace falta saber programar para usarlo?
No para el uso básico: elegir tema, versión de WordPress y de PHP, y subir un plugin se hace desde la interfaz sin escribir nada. Escribir un blueprint propio sí pide conocer JSON, pero ya existen varios de ejemplo en la documentación oficial para partir de uno y adaptarlo.
