Un sitio de staging es una copia privada de su sitio web en la que puede probar cambios antes de que lleguen a los visitantes reales.
La idea es sencilla: si una actualización va a romper algo, es mucho mejor que se rompa en una copia que en el sitio web que utilizan sus clientes.
Para muchos sitios web, probar las actualizaciones en staging es una de las formas más eficaces de evitar sorpresas desagradables. Pero exige cierto esfuerzo y no siempre es necesario. Un pequeño sitio corporativo con unos pocos plugins puede no necesitarlo para cada actualización. Una tienda online o una plataforma de membresía, normalmente sí.
El staging también tiene sus propios riesgos. Una copia indexada por Google por error, o una base de datos de staging subida encima de la de producción, pueden crear sus propios problemas.
Esta guía explica qué es el staging, cuándo merece la pena utilizarlo, cómo mantenerlo privado, qué diferencias cabe esperar entre staging y producción y cómo trasladar los cambios sin sobrescribir pedidos o registros reales.
¿Qué es un sitio de staging?
Un sitio de staging es una copia independiente de su sitio web, normalmente en un subdominio o en una dirección temporal, que los visitantes no pueden ver.
Normalmente contiene:
- la misma versión de WordPress, los mismos plugins y el mismo tema
- una copia de la base de datos en el momento en que se creó
- los mismos archivos y medios subidos, o la mayoría de ellos
Se utiliza para probar actualizaciones, nuevos plugins, cambios de diseño o cambios de código. Si todo funciona, los mismos cambios se aplican al sitio en producción. Si algo falla, el sitio en producción no se ve afectado.
El staging es distinto de un backup. Un backup es una copia guardada que puede restaurar. Un sitio de staging es una copia en funcionamiento que puede usar y probar.
¿Por qué es importante probar en staging?
La mayoría de las actualizaciones de WordPress se aplican sin problemas. El problema son las pocas que no, y el hecho de que no es fácil saber de antemano cuáles serán.
Probar en staging le ayuda a:
- ver conflictos entre plugins, el tema y el código personalizado antes que sus clientes
- comprobar funciones importantes, como el checkout, sin arriesgar pedidos reales
- probar una actualización importante o un cambio de versión de PHP sin presión
- planificar la actualización en producción para un momento tranquilo, sabiendo qué esperar
También hace menos frecuentes las vueltas atrás. Menos sorpresas en el sitio en producción significa menos restauraciones de urgencia.
¿Cuándo merece la pena el staging?
Normalmente merece la pena
- tiendas online, sobre todo sitios WooCommerce con pasarelas de pago, reglas de envío o suscripciones
- sitios de membresía, donde el inicio de sesión, las reglas de acceso y los pagos recurrentes deben seguir funcionando
- plataformas de e-learning, donde importan el progreso de los alumnos y el acceso a los cursos
- sitios con código personalizado o con un tema a medida
- actualizaciones importantes: una nueva versión principal de WordPress, WooCommerce, un maquetador visual o PHP
- sitios con muchos plugins, donde los conflictos son más probables
A menudo es opcional
- pequeños sitios corporativos con pocos plugins
- versiones menores de corrección de errores de plugins sencillos y bien mantenidos
- cambios de contenido, como editar un texto o añadir una entrada al blog
Incluso en los sitios más sencillos, el staging es útil antes de un cambio mayor, como cambiar de tema o actualizar PHP.
La guía sobre con qué frecuencia actualizar los plugins de WordPress explica qué plugins suelen necesitar pruebas previas.
¿Cómo se crea un sitio de staging?
Hay varias vías habituales.
Herramientas de staging del hosting
Muchos proveedores de hosting gestionado para WordPress incluyen una función de staging en su panel de control. Normalmente permite crear una copia con un clic y, a veces, enviar los cambios de vuelta a producción. Las opciones exactas varían de un proveedor a otro, así que consulte la documentación de su hosting para saber qué copia y qué sobrescribe.
Plugins de staging
Algunos plugins de WordPress pueden crear una copia de staging dentro de su cuenta de hosting. Pueden ser cómodos, pero compruebe con atención dónde se crea la copia y cómo se protege.
Copia manual
Un desarrollador puede crear un sitio de staging copiando los archivos y la base de datos en otra ubicación y ajustando la dirección del sitio web. Ofrece más control, pero requiere experiencia técnica.
Sea cual sea la vía elegida, asegúrese de que existe un backup reciente del sitio en producción antes de empezar.
¿Cómo se mantiene privado el staging?
Un sitio de staging que cualquiera puede visitar, o que Google indexa, puede causar problemas reales:
- los visitantes podrían encontrarlo y creer que es el sitio web real
- puede aparecer contenido duplicado en los resultados de búsqueda
- datos antiguos o de prueba pueden hacerse públicos
- personas reales podrían usar los formularios del staging
Dos protecciones funcionan bien juntas.
Disuadir a los motores de búsqueda
En el escritorio de WordPress del staging, vaya a Settings > Reading (Ajustes > Lectura) y marque Discourage search engines from indexing this site (Disuadir a los motores de búsqueda de indexar este sitio). Esto pide a los motores de búsqueda que no indexen el sitio web. Es una petición, no un cerrojo, así que no debería ser su única protección.
Protección con contraseña
Proteja todo el sitio de staging con una contraseña a nivel de servidor, lo que en los paneles de hosting suele llamarse autenticación HTTP o directorios protegidos con contraseña. Muchas herramientas de staging del hosting lo ofrecen como opción. Así ni los visitantes ni los motores de búsqueda pueden ver el contenido.
Recuerde también:
- no copiar nunca el ajuste "disuadir a los motores de búsqueda" de vuelta al sitio en producción
- eliminar los sitios de staging que ya no utilice
- no compartir las contraseñas del staging por correo electrónico
¿Qué diferencias cabe esperar entre staging y producción?
Un sitio de staging es una copia, pero nunca es perfectamente idéntico.
Datos
La base de datos del staging es una instantánea. Los nuevos pedidos, registros y mensajes que lleguen al sitio en producción después de hacer la copia no estarán en el staging.
Correos electrónicos
Un sitio de staging puede enviar correos reales: confirmaciones de pedido, restablecimientos de contraseña, newsletters. Si la base de datos contiene direcciones reales de clientes, las acciones de prueba podrían llegar a personas reales. Muchos equipos desactivan el correo saliente en el staging o lo redirigen a un buzón de prueba.
Pagos
Las pasarelas de pago deben estar en modo de prueba o sandbox en el staging. No procese nunca pagos reales desde un sitio de staging.
Algunas herramientas de suscripción detectan cuando un sitio web se ha copiado a una nueva dirección y pausan las renovaciones automáticas, pero no confíe en ello. Revise la configuración de sus plugins de pago y suscripción.
Tareas programadas e integraciones
El staging puede ejecutar las mismas tareas programadas que el sitio en producción: sincronizar el stock, enviar datos a un CRM, registrar en un sistema contable. Desactive las integraciones que podrían enviar datos de prueba a servicios externos reales.
Entorno del servidor
El staging puede funcionar con una versión o configuración de PHP ligeramente distinta. Compruebe que se parece lo más posible al sitio en producción; de lo contrario, la prueba puede no ser fiable.
¿Cómo se trasladan los cambios sin perder datos de producción?
Aquí es donde el staging puede salir mal.
No suba la base de datos del staging encima de la base de datos de producción en un sitio que recibe pedidos, registros o mensajes. Todo lo que haya llegado al sitio en producción después de crear la copia de staging se perdería.
Para la mayoría de las actualizaciones, el enfoque más seguro es:
- Pruebe las actualizaciones en el staging.
- Anote exactamente qué ha actualizado y en qué orden.
- Haga un backup reciente del sitio en producción.
- Aplique las mismas actualizaciones directamente en el sitio en producción, en el mismo orden.
- Compruebe las funciones importantes en producción.
Así, el staging sirve para aprender qué funciona y el sitio en producción conserva todos sus datos reales.
Si utiliza una herramienta del hosting que envía los cambios del staging a producción, compruebe si puede enviar solo los archivos sin tocar la base de datos. Algunas herramientas ofrecen esta opción. Si no está seguro de lo que sobrescribirá la herramienta, pregunte a su proveedor de hosting antes de usarla.
Para cambios más complejos que afectan tanto a los archivos como a la configuración de la base de datos, como un rediseño, el traslado debe planificarse con cuidado. Es un buen momento para contar con un desarrollador.
Errores habituales
- dejar el staging visible públicamente o indexado
- enviar correos reales a clientes desde el staging
- ejecutar pagos o renovaciones reales en una copia
- subir una base de datos de staging antigua encima de una tienda en producción
- hacer pruebas en un staging que lleva meses desactualizado
- probar solo la página de inicio y no el checkout, el inicio de sesión o los formularios
- olvidarse de aplicar en producción exactamente lo que se ha probado
¿Cómo es una buena práctica de staging?
El staging se actualiza desde producción poco antes de las pruebas. Es privado y no está indexado. Los correos, los pagos y las integraciones se neutralizan. Las actualizaciones se prueban siguiendo una lista de comprobación escrita. Después, las mismas actualizaciones se aplican en producción, con un backup previo, y se vuelven a comprobar las funciones clave.
Cómo puede ayudarle D4Hub
D4Hub puede configurar y utilizar el staging como parte de un proceso de actualización seguro.
Según sus necesidades, D4Hub puede:
- crear una copia de staging privada de su sitio web
- protegerla de los motores de búsqueda y de los visitantes
- neutralizar los correos, los pagos y las integraciones en el staging
- probar actualizaciones de WordPress, plugins, temas y PHP
- aplicar las actualizaciones probadas al sitio en producción sin sobrescribir pedidos ni registros
- ayudarle a entender qué copia y qué sobrescribe la herramienta de staging de su hosting
- incluir las actualizaciones probadas en el mantenimiento continuo a través de MAP
Puede pedir ayuda en cualquier momento, desde la configuración de un primer staging hasta la revisión de un traslado del que no está seguro.
Abrir un ticket de soportePara usuarios con perfil técnico: probar actualizaciones en staging
Estos pasos son para usuarios que se manejan con el escritorio de WordPress y, opcionalmente, con WP-CLI. Antes de crear o actualizar un sitio de staging, haga un backup completo del sitio en producción.
Proteja el staging antes que nada
En el escritorio del staging, vaya a Settings > Reading (Ajustes > Lectura), marque Discourage search engines from indexing this site (Disuadir a los motores de búsqueda de indexar este sitio) y guarde.
Con WP-CLI en el sitio de staging, puede comprobar y establecer la misma opción:
wp option get blog_public
wp option update blog_public 0Un valor de 0 significa que se disuade a los motores de búsqueda. Después, añada la protección con contraseña al staging desde el panel de su hosting.
Ejecute estos comandos solo en el staging. Establecer blog_public en 0 en el sitio en producción pediría a los motores de búsqueda que dejaran de indexarlo.
Actualice la dirección del sitio después de clonarlo
Si copia un sitio web manualmente, la base de datos sigue conteniendo la dirección de producción. WP-CLI puede sustituirla, también dentro de los datos serializados que un simple buscar y reemplazar en la base de datos dañaría.
Haga siempre primero una prueba en seco:
wp search-replace 'https://www.example.com' 'https://staging.example.com' --skip-columns=guid --dry-runSi los resultados parecen correctos, vuelva a ejecutarlo sin --dry-run.
Atención: asegúrese por completo de que está conectado al sitio de staging antes de ejecutar este comando. Ejecutarlo en el sitio en producción cambiaría todas las direcciones de producción por la del staging. Haga antes un backup de la base de datos:
wp db export before-search-replace.sqlGuarde ese archivo fuera de la carpeta web pública y elimínelo cuando ya no lo necesite.
Compruebe que las versiones coinciden
Tanto en el staging como en producción, compare:
wp core version
wp plugin list --fields=name,status,version
wp --infoLa versión de PHP debe ser la misma; de lo contrario, la prueba puede no reflejar lo que ocurrirá en producción.
Aplique las actualizaciones de una en una
wp plugin update <slug>Anote cada actualización y su versión. Repetirá la misma lista en producción.
Lista de comprobación después de las actualizaciones
- La página de inicio y las páginas principales se cargan sin errores
- Los menús, la cabecera y el pie de página se muestran correctamente
- El formulario de contacto y los demás formularios se envían y muestran una confirmación
- El inicio de sesión, el cierre de sesión y el restablecimiento de contraseña funcionan
- En tiendas: página de producto, añadir al carrito, carrito, checkout en modo de prueba, confirmación del pedido
- En membresías y cursos: contenido restringido, página de cuenta del miembro, acceso a los cursos
- La búsqueda funciona
- La versión móvil se ve correctamente
- El escritorio y el editor de WordPress se abren con normalidad
- No hay errores nuevos en Tools > Site Health (Herramientas > Salud del sitio) ni en el log de errores de PHP
Si todo es correcto, haga un backup reciente de producción y aplique allí las mismas actualizaciones, en el mismo orden.
Preguntas frecuentes
¿El staging es lo mismo que un backup?
No. Un backup es una copia guardada que restaura si algo va mal. El staging es una copia en funcionamiento en la que prueba los cambios antes. Necesita backups tanto si usa staging como si no.
¿Con qué frecuencia debo actualizar el sitio de staging?
Lo ideal es justo antes de cada ronda de pruebas, para que refleje el sitio en producción actual. Una copia de staging de hace meses puede no mostrar los mismos problemas.
¿Puedo usar el staging para probar un cambio de versión de PHP?
Sí, y es uno de sus mejores usos. Cambie el staging a la nueva versión de PHP, pruebe el sitio web a fondo y revise el log de errores antes de cambiar el servidor de producción.
Mi proveedor de hosting ofrece publicar en producción con un clic. ¿Es seguro?
Puede serlo, pero compruebe qué sobrescribe. Si sustituye la base de datos de producción, podrían perderse los pedidos y registros recientes. Si no está seguro, aplique las actualizaciones manualmente en producción.
¿Necesito staging para cada pequeña actualización?
No siempre. En sitios sencillos y actualizaciones menores de plugins de bajo riesgo, puede bastar con un backup y una comprobación rápida después de actualizar. En tiendas, membresías y plugins críticos, el staging suele merecer la pena.
¿Se puede encontrar el staging en Google?
Sí, si no está protegido. Utilice tanto el ajuste Discourage search engines (Disuadir a los motores de búsqueda) como la protección con contraseña, y elimine los sitios de staging que ya no utilice.