Que cargue la portada de staging es una prueba débil. La copia debe compartir el entorno de producción y ejecutar las funciones del componente actualizado, incluidos guardados, cron, correo e integraciones.
Define los criterios de aceptación antes de pulsar Actualizar. Así, la ausencia de un error evidente no se confunde con éxito.
Crea un staging seguro
Copia archivos y base actuales con control de acceso. Desactiva indexación, correo real, pagos, webhooks y APIs externas destructivas.
Anonimiza datos cuando sea posible y restringe usuarios. No expongas una base de clientes clonada en un subdominio público.
Anota la hora de la copia porque los cambios posteriores no estarán allí.
Iguala el entorno
Utiliza las mismas versiones y extensiones PHP, MySQL o MariaDB, servidor web, configuración de WordPress, caché y ruta de proxy DNS o SSL.
Lista de paridad:
WordPress y núcleo
tema y plugins activos
controlador y límites PHP
almacenamiento y esquema de base
cron
caché de objetos y páginaDocumenta diferencias inevitables como la pasarela sandbox.
Considera los cambios posteriores de producción
Staging envejece al clonarse. Anota cambios de configuración o contenido durante las pruebas y decide si afectan a la compatibilidad.
Antes de desplegar, vuelve a comparar versiones, PHP, tema, plugins obligatorios, drop-ins y opciones relevantes. No copies la base de staging a producción para llevar una actualización: borrarías datos comerciales nuevos. Despliega código y deja ejecutar solo las migraciones documentadas.
Incluye seguridad y privacidad
Comprueba que la versión no amplía endpoints REST, acceso a archivos, roles o capacidades. Prueba el acceso anónimo a páginas privadas y que los logs no contengan nuevos secretos.
Revisa consentimiento y peticiones externas si se añaden scripts. Una actualización funcional que rompe permisos o privacidad no está lista.
Conserva material de reversión
Haz copia de staging y conserva los paquetes exactos anterior y nuevo. Anota recuentos de tablas y versiones de esquema.
Prueba allí la restauración de archivos y datos. Un estado verde de la copia no demuestra que recupere la web.
Mantén estrecho el límite de rollback de producción: paquete de código frente a base.
Lee la información de la versión
Revisa changelog, versiones mínimas, seguridad, funciones retiradas y migraciones. Comprueba dependencias y plantillas sobrescritas por el tema.
Para saltos grandes, prueba versiones intermedias si el fabricante las exige.
No confíes únicamente en escáneres automáticos.
Aplica un cambio cada vez
Actualiza el componente objetivo y deja terminar sus migraciones. Conserva errores de PHP, navegador, base y tareas.
No mezcles en una misma prueba PHP, WordPress, tema y varios plugins; no sabrás atribuir el fallo.
Limpia OPcache y recursos en el momento correcto y vuelve a probar con caché caliente.
Ejecuta pruebas de la función real
Prueba acceso, roles, editor, medios, búsqueda, navegación, REST o AJAX, cron y correo. Ejecuta el recorrido comercial exacto del componente.
Para cada prueba:
entrada o estado
resultado esperado
resultado observado
referencia de log o petición
aprobado o fallidoIncluye móvil y usuarios anónimos o conectados.
Prueba el fallo y la reversión
Simula un fallo seguro: entrada inválida, API no disponible o cancelación. Confirma que el error es claro y el trabajo parcial recuperable.
Revierte el componente en staging y demuestra que los datos actuales siguen. Si el downgrade de base falla, producción necesita un plan más sólido de mantenimiento, restauración y unión.
No descubras la incompatibilidad durante la caída real.
Define una puerta de despliegue
Enumera fallos bloqueantes, problemas conocidos aceptables, aprobador y umbral de rollback. Una prueba crítica fallida no se compensa porque la portada funcione.
Registra checksums y ventana. Si producción supera el umbral —nuevo fatal, fallo al guardar o función caída— ejecuta el rollback ensayado en vez de depurar indefinidamente en público.
Despliega observando
Programa según el riesgo, haz una copia nueva y aplica el mismo paquete y procedimiento. Ejecuta pruebas rápidas.
Vigila errores PHP y HTTP, cron y métricas de la función durante un periodo representativo. El mantenimiento recurrente debe conservar esta batería y ejecutarla tras cada versión; las pruebas convierten la actualización en un cambio controlado.