Staging PrestaShop: actualiza tu tienda sin riesgo

📅 Publicado el 6 de noviembre, 2026 · Por Equipo RedServicio

Actualizar PrestaShop, instalar un módulo nuevo o tocar el tema de tu tienda sin haber probado nada antes es, francamente, jugarse los negocios a una sola carta. Puede salir bien. También puede dejar tu tienda offline durante horas o días, con las ventas cayendo y los clientes molestándose. Ahí es donde entra el Staging PrestaShop: una réplica exacta de tu tienda donde puedes probar actualizaciones, módulos y cambios de diseño sin arriesgar la web en producción. Te contamos, paso a paso, cómo montar el tuyo. Y si en algún momento te atascas, en RedServicio tenemos soporte 24/7 para acompañarte en el proceso.

¿Qué es un entorno de staging y por qué tu tienda PrestaShop lo necesita?

Un entorno de staging (o de preproducción) es una copia clonada de tu tienda que corre en un espacio aislado, normalmente en un subdominio tipo staging.tutienda.com o preview.tutienda.com. Mismos archivos, misma base de datos, misma configuración que la tienda real. Pero protegida del público: tus clientes no pueden entrar ni hacer pedidos por accidente.

¿Por qué tanto énfasis en PrestaShop? Porque es un ecosistema complejo: el núcleo, el tema, decenas de módulos (muchos de terceros) y personalizaciones propias. Cuando saltas de una versión mayor a otra (de PrestaShop 1.7.8 a 8.x, por ejemplo), es bastante habitual que algún módulo deje de ser compatible o que el tema se rompa. Si eso pasa en producción, la tienda deja de vender. Si pasa en staging, corriges y vuelves a probar. Sin drama.

Los beneficios son claros:

• Cero riesgo para tus ventas: cualquier error queda confinado en el entorno de pruebas.
• Pruebas reales: puedes simular pedidos completos, pasarelas de pago en modo sandbox y correos de confirmación con datos reales de tu catálogo.
• Ahorro de tiempo: detectar una incompatibilidad en staging toma minutos; recuperar una tienda caída en producción puede llevar horas.
• Máxima seguridad: al aislar el entorno, evitas que Google indexe contenido duplicado si configuras bien el bloqueo.

El staging no es un lujo reservado a grandes tiendas. Es mantenimiento básico, y punto.

Requisitos previos para crear tu staging PrestaShop

Antes de ponerte manos a la obra, revisa que cumples con esto:

1. Espacio y recursos en tu hosting

Necesitas espacio suficiente para duplicar todos los archivos de la tienda (ojo con la carpeta de imágenes /img, que suele ser la más pesada) y para crear una segunda base de datos MySQL. Si tu plan actual se queda corto, quizá toque escalar. En RedServicio puedes subir de plan fácilmente a medida que crece tu catálogo.

2. Un subdominio

Crea un subdominio desde el panel de control de tu hosting (por ejemplo, staging.tutienda.com). Después puedes protegerlo con una contraseña HTTP Basic o deshabilitar el indexado en robots.txt.

3. Accesos y credenciales

Acceso por FTP o al gestor de archivos, acceso a phpMyAdmin para la base de datos y los datos de administrador del back office de PrestaShop. Nada más exótico.

4. Una copia de seguridad reciente

Sí, ya sabemos: el staging existe precisamente para reducir riesgos. Aun así, trabaja siempre con un backup completo y verificable. Nunca dupliques una tienda sin tener antes un respaldo íntegro de archivos y base de datos. Nunca.

Con todo esto listo, toca la clonación.

Cómo duplicar tu tienda: copia de archivos y base de datos

El proceso se divide en tres fases: copiar archivos, duplicar la base de datos y ajustar la configuración.

Fase 1: copiar los archivos

1. Conéctate por FTP o al gestor de archivos y descarga (o copia directamente en el servidor) todo el contenido del directorio raíz de tu tienda: carpetas /app, /classes, /modules, /themes, /img y el resto.
2. Pega esa copia en el directorio asignado a tu subdominio de staging.
3. Verifica que la copia está completa. Sobre todo la carpeta /img/p, donde viven las imágenes de los productos; es la que más se queda a medias.

Fase 2: duplicar la base de datos

1. Accede a phpMyAdmin y selecciona la base de datos de tu tienda.
2. Usa la opción Exportar con método rápido y formato SQL.
3. Crea una base de datos nueva (por ejemplo, presta_staging) y su usuario correspondiente con todos los privilegios.
4. Importa el archivo SQL exportado en la nueva base de datos y comprueba que las tablas se han creado correctamente.

Fase 3: conectar la copia con la nueva base de datos

Edita el archivo app/config/parameters.php de tu staging (en PrestaShop 1.7 y 8.x) y actualiza los datos de conexión:

Por último, desde phpMyAdmin actualiza las URLs en las tablas ps_shop_url y ps_configuration (campos PS_SHOP_DOMAIN y PS_SHOP_DOMAIN_SSL) para que apunten al subdominio de staging, y borra la caché eliminando el contenido de /var/cache. Con eso, tu réplica ya funciona de forma independiente. Siguiente paso: configurar y proteger el entorno de pruebas.

Configuración del entorno de pruebas y bloqueo de motores de búsqueda

La tienda está replicada. Bien. Pero falta lo más importante: que Google no indexe tu staging de PrestaShop. Si lo hace, tendrás contenido duplicado que penaliza tu SEO, y puede que un cliente acabe encontrando la versión de pruebas en los resultados de búsqueda. No es un escenario raro. Pasa más de lo que la gente cree.

Bloqueo mediante robots.txt y cabeceras

Crea o edita el archivo robots.txt en la raíz del subdominio de staging con este contenido:

1. User-agent: *
2. Disallow: /

Sencillo, ¿verdad? Pues ojo: robots.txt es solo la barrera básica, y no todos los bots la respetan. Por eso conviene añadir también la cabecera X-Robots-Tag desde un archivo .htaccess:

Header set X-Robots-Tag «noindex, nofollow»

Protección con contraseña a nivel de servidor

La opción más robusta, la que yo recomendaría sin dudarlo, es proteger todo el subdominio con autenticación básica HTTP. En Apache, añade esto al .htaccess del subdominio:

• AuthType Basic
• AuthName «Staging»
• AuthUserFile /ruta/.htpasswd
• Require valid-user

El archivo de contraseñas se genera desde la consola con htpasswd -c /ruta/.htpasswd usuario. Esta capa hace dos cosas a la vez: corta el rastreo y bloquea accesos no autorizados a datos reales de clientes. Doble beneficio.

Ajustes adicionales dentro de PrestaShop

Dentro del back office de staging hay algo de limpieza que hacer: desactiva los módulos de envío de emails (o redirígelos a una cuenta de prueba con el módulo Mail alerts modificado), deshabilita las pasarelas de pago en modo real y activa el modo depuración en config/defines.inc.php, cambiando _PS_MODE_DEV_ a true.

Cómo probar y actualizar la tienda PrestaShop en staging

Entorno protegido. Ya puedes trabajar con cierta tranquilidad. Lo que buscas ahora es reproducir en staging, paso a paso, la misma actualización que aplicarás después en producción.

Lista de verificación antes de actualizar

• Copia de seguridad previa: genera un snapshot del staging antes de tocar nada. Si algo sale mal, revertir te llevará minutos.
• Versión PHP compatible: verifica que la versión de PHP del staging coincide con la de producción; si no, los resultados de tus pruebas no servirán de mucho.
• Documenta tu punto de partida: anota la versión actual de PrestaShop, los módulos instalados y sus versiones. Suena burocrático, pero te lo agradecerás.

Proceso de prueba de la actualización

Aplica la actualización en staging (mediante el módulo 1-Click Upgrade o a mano, según tu caso) y después ejecuta una batería de pruebas sistemática:

1. Recorre el flujo completo de compra: añadir al carrito, checkout y registro de pedido.
2. Verifica que los correos transaccionales se generan correctamente.
3. Comprueba los módulos críticos, especialmente los de pago y envío.
4. Revisa los errores en el modo depuración y en los logs del servidor.
5. Mide los tiempos de carga. Si suben de forma notable, investiga antes de migrar nada.

La actualización no es válida hasta que todo el flujo de ventas funcione sin errores. Y si algo falla, recuerda que en RedServicio puedes crear subdominios de staging con un solo clic, y nuestro soporte 24/7 te acompaña durante las pruebas.

Cómo migrar los cambios de staging a producción de forma segura

Pruebas superadas. Toca trasladar los resultados a producción. ¿Qué estrategia seguir? Depende del tipo de cambio.

Para cambios de código y plantillas

Si la actualización solo afecta a archivos (temas, overrides, módulos), copia los archivos modificados por FTP o Git a producción, borra la caché y verifica que todo funciona. Guarda siempre una copia de los archivos originales. Por si hay que revertir al instante.

Para actualizaciones completas de PrestaShop

Aquí el proceso es más delicado:

1. Realiza una copia de seguridad completa de producción (archivos y base de datos).
2. Activa el modo mantenimiento en la tienda real.
3. Aplica la misma actualización validada en staging, en horario de bajo tráfico.
4. Ejecuta una verificación rápida del flujo de compra.
5. Desactiva el modo mantenimiento y vacía la caché.

Una regla que no deberías romper jamás: nada de innovar en producción. Aplica exactamente la misma secuencia de pasos que ya validaste, sin improvisaciones de última hora.

El flujo staging → pruebas → producción acaba convirtiéndose en un hábito, y ese hábito quita el miedo a actualizar tu tienda PrestaShop. Una hora invertida en montar el entorno de pruebas te ahorra muchas horas de estrés, ventas perdidas y clientes enfadados. Cálculo que, visto desde la tranquilidad de después, casi nadie lamenta haber hecho.