Cómo hacer un staging de WordPress

• Miguel Taboada
• 15 Jul 2026

Cómo hacer un staging de WordPress

Actualizar un plugin importante, cambiar de tema, migrar a un constructor de páginas diferente o modificar el código de tu web sin haberlo probado antes en un entorno seguro es uno de los errores más costosos que puede cometer un propietario de web. Un staging de WordPress es exactamente eso: una copia exacta de tu web en producción donde puedes probar cualquier cambio sin riesgo de romper nada que afecte a tus visitantes reales.

En esta guía te explico qué es un staging, cómo crearlo con tres métodos diferentes y cómo sincronizar los cambios de vuelta a producción cuando estés listo.

Qué es un entorno de staging y por qué necesitas uno

Un entorno de staging (también llamado entorno de pruebas o preproducción) es una copia funcional de tu web que vive en una URL separada, normalmente un subdominio como staging.tudominio.com o dev.tudominio.com. Es idéntica a la producción: mismos archivos, misma base de datos, mismos plugins y el mismo tema.

La diferencia es que los cambios que hagas en staging no afectan a la web que ven tus usuarios. Puedes actualizar WordPress, instalar un plugin nuevo, cambiar el tema, modificar código PHP o reorganizar el contenido sin ningún riesgo.

Cuándo es imprescindible usar staging

Antes de actualizar WordPress: las actualizaciones de WordPress, especialmente las de versión mayor (de 6.4 a 6.5, por ejemplo), pueden romper plugins o temas incompatibles. Pruébalas en staging primero.

Antes de actualizar plugins críticos: WooCommerce, Elementor, Yoast, WPML y otros plugins que afectan a toda la web deben probarse en staging antes de actualizarlos en producción.

Al cambiar de tema: un cambio de tema puede afectar a la presentación de todo el contenido, las tipografías, los estilos personalizados y el rendimiento. Staging te permite ver el resultado final antes de que lo vean tus visitantes.

Al desarrollar funcionalidades nuevas: si añades código personalizado al functions.php o instalas un plugin a medida, staging es el lugar correcto para probarlo.

Antes de migrar a un constructor de páginas diferente: pasar de Gutenberg a Elementor o viceversa puede alterar significativamente la presentación del contenido existente.

Al hacer cambios en el .htaccess o en la configuración del servidor: los errores aquí pueden tumbar toda la web. Mejor probarlos primero.

Método 1: Staging con plugin (el más sencillo)

La forma más rápida de crear un staging es con un plugin dedicado. Las opciones más usadas son:

WP Staging

WP Staging es el plugin más popular para staging en WordPress. La versión gratuita cubre la mayoría de necesidades de webs pequeñas y medianas.

Instalación:

1. Panel de WordPress → Plugins → Añadir nuevo → busca «WP Staging»
2. Instala y activa el plugin de WP Staging
3. Ve a WP Staging → Start en el menú lateral

Crear el sitio de staging:

1. Haz clic en Create new staging site
2. Dale un nombre al staging (se usará como subdirectorio, ej: staging)
3. Selecciona qué tablas de la base de datos incluir (por defecto todas)
4. Haz clic en Start Cloning

El proceso tarda entre 1 y 10 minutos dependiendo del tamaño de la web. Cuando termina, el staging está accesible en tudominio.com/staging/.

Limitaciones de la versión gratuita:

• El staging se crea como subdirectorio, no como subdominio
• No incluye la función de push (enviar cambios de staging a producción)
• No incluye staging externo ni sincronización automática

La versión Pro añade push a producción, staging en subdominio propio y soporte para WooCommerce.

Duplicator

Duplicator es otro plugin muy popular que sirve tanto para staging como para migraciones y backups.

1. Instala Duplicator desde el repositorio de WordPress
2. Ve a Duplicator → Paquetes → Crear nuevo
3. Completa el asistente de creación del paquete
4. Descarga el instalador y el archivo zip generados
5. Súbelos a la carpeta del subdominio de staging que hayas creado previamente en cPanel
6. Accede al subdominio en el navegador y sigue el instalador

Este método requiere más pasos pero da más control sobre el proceso.

Método 2: Staging manual con cPanel (el más flexible)

El método manual te da control total sobre el proceso y no depende de plugins. Funciona en cualquier instalación de WordPress independientemente del tamaño.

Paso 1: Crear el subdominio de staging

Como se explica en el artículo sobre cómo crear un subdominio en cPanel:

1. cPanel → Dominios → Subdominios
2. Subdominio: staging
3. Dominio: tudominio.com
4. Raíz del documento: /public_html/staging (cPanel la rellena automáticamente)
5. Haz clic en Crear

El subdominio staging.tudominio.com está listo y apunta a /public_html/staging/.

Paso 2: Copiar los archivos de producción a staging

Desde cPanel → Gestor de archivos:

1. Navega a /public_html/
2. Selecciona todos los archivos y carpetas (excepto la carpeta staging que acabas de crear)
3. Haz clic en Copiar
4. Destino: /public_html/staging/
5. Confirma la copia

Alternativa desde SSH (más rápido para webs grandes):

bash

cp -r /home/tuusuario/public_html/. /home/tuusuario/public_html/staging/

O usando rsync para mayor eficiencia:

bash

rsync -av --exclude='staging' /home/tuusuario/public_html/ /home/tuusuario/public_html/staging/

Paso 3: Crear una nueva base de datos para staging

1. cPanel → Bases de datos MySQL
2. Crea una nueva base de datos: tuusuario_staging
3. Crea un nuevo usuario: tuusuario_stguser con contraseña segura
4. Asigna todos los privilegios del usuario a la base de datos

El artículo sobre crear una base de datos MySQL en cPanel cubre este proceso en detalle.

Paso 4: Exportar la base de datos de producción e importarla en staging

Exportar desde phpMyAdmin:

1. cPanel → Bases de datos → phpMyAdmin
2. Selecciona la base de datos de producción
3. Pestaña Exportar
4. Método: Rápido, formato: SQL
5. Haz clic en Continuar y guarda el archivo .sql

Importar en la base de datos de staging:

1. En phpMyAdmin, selecciona la base de datos tuusuario_staging
2. Pestaña Importar
3. Selecciona el archivo .sql que exportaste
4. Haz clic en Continuar

El artículo sobre administrar phpMyAdmin desde cPanel cubre el proceso completo.

Paso 5: Actualizar el wp-config.php de staging

Edita el archivo /public_html/staging/wp-config.php y actualiza las credenciales de la base de datos con las del staging:

php

define('DB_NAME', 'tuusuario_staging');
define('DB_USER', 'tuusuario_stguser');
define('DB_PASSWORD', 'contraseña_del_usuario_staging');
define('DB_HOST', 'localhost');

Paso 6: Actualizar las URLs en la base de datos de staging

La base de datos importada contiene las URLs de producción (https://tudominio.com). Hay que reemplazarlas por las del staging (https://staging.tudominio.com).

Opción A — WP-CLI desde SSH:

bash

cd /home/tuusuario/public_html/staging
wp search-replace 'https://tudominio.com' 'https://staging.tudominio.com' --all-tables

Opción B — Plugin Better Search Replace:
Instálalo temporalmente en el staging, ejecuta el reemplazo y desinstálalo.

Opción C — SQL directo en phpMyAdmin:

sql

UPDATE wp_options 
SET option_value = 'https://staging.tudominio.com' 
WHERE option_name IN ('siteurl', 'home');

Esto es suficiente para que el staging funcione. Las URLs dentro del contenido seguirán apuntando al dominio de producción, lo que es aceptable para un entorno de pruebas.

Paso 7: Regenerar los permalinks en staging

Accede al panel de administración del staging en staging.tudominio.com/wp-admin/ y ve a Ajustes → Enlaces permanentes → Guardar cambios. Esto regenera el .htaccess del staging con las rutas correctas.

Si el .htaccess del staging tiene conflictos por ser un subdirectorio, puede que necesites editarlo manualmente para ajustar el RewriteBase:

apache

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /staging/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /staging/index.php [L]
</IfModule>
# END WordPress

Si usas subdominio en lugar de subdirectorio el RewriteBase es simplemente /.

Método 3: Staging con herramientas de desarrollo locales

Si prefieres trabajar en local antes de subir al staging en el servidor:

LocalWP (antes Local by Flywheel) es la herramienta más popular para desarrollo WordPress local. Permite crear instalaciones de WordPress en tu ordenador con un clic, importar webs existentes y exportarlas de vuelta al servidor.

XAMPP o WAMP son alternativas más manuales pero igualmente válidas si ya estás familiarizado con ellas.

El flujo de trabajo en este caso es:

1. Importar producción a Local
2. Hacer los cambios en local
3. Exportar y subir al staging en el servidor
4. Verificar en staging
5. Empujar a producción

Cómo proteger el staging de accesos no deseados

Un entorno de staging no debe ser accesible públicamente por varias razones:

• Google podría indexarlo y crear contenido duplicado
• Los formularios de contacto o WooCommerce podrían procesar pedidos reales por error
• Expone información sobre la estructura interna de tu web

Proteger con contraseña mediante .htaccess

Añade estas líneas al .htaccess del staging (en /public_html/staging/.htaccess o en la raíz del subdominio):

apache

AuthType Basic
AuthName "Área restringida - Staging"
AuthUserFile /home/tuusuario/public_html/staging/.htpasswd
Require valid-user

Crea el archivo .htpasswd con las credenciales. Desde cPanel → Privacidad de directorios, puedes hacerlo de forma visual sin tocar archivos.

Evitar la indexación por Google

Desde el panel de WordPress del staging: Ajustes → Lectura → marca Solicitar a los motores de búsqueda que no indexen este sitio. Además, añade en el robots.txt del staging:

User-agent: *
Disallow: /

Desactivar los emails de WooCommerce en staging

Si tienes WooCommerce, evita que el staging envíe emails reales de confirmación de pedido. Añade al wp-config.php del staging:

php

// Redirigir todos los emails a una dirección de prueba
add_filter('wp_mail', function($args) {
    $args['to'] = 'test@tudominio.com';
    return $args;
});

O usa el plugin WP Mail SMTP con una cuenta de prueba.

Cómo sincronizar cambios de staging a producción

Esta es la parte más delicada del proceso. Hay varias estrategias según qué hayas cambiado:

Solo cambios de código (plugins, temas, archivos)

Si solo has instalado plugins, actualizado temas o modificado archivos PHP:

1. Exporta la lista de plugins actualizados (anótalos manualmente o usa WP-CLI: wp plugin list)
2. En producción, aplica los mismos cambios: actualiza los mismos plugins y archivos
3. Prueba en producción que todo funciona

No copies directamente la base de datos de staging a producción si en producción ha habido actividad (nuevos pedidos, comentarios, entradas) — perderías ese contenido.

Solo cambios de base de datos (nuevo contenido, configuración)

Si has añadido entradas, cambiado opciones o modificado configuración en staging:

Con WP Staging Pro: el botón Push to Live sincroniza automáticamente los cambios seleccionados de staging a producción.

Manualmente: exporta solo las tablas modificadas desde phpMyAdmin e impórtalas en producción. Requiere cuidado para no sobrescribir contenido nuevo en producción.

Cambios combinados (código + contenido)

Lo más seguro es:

1. Hacer un backup completo de producción con JetBackup antes de tocar nada
2. Subir los archivos modificados a producción (plugins, temas, código)
3. Aplicar manualmente los cambios de base de datos que sean necesarios
4. Probar en producción inmediatamente después de cada cambio
5. Si algo falla, restaurar desde el backup

Mantener el staging actualizado

El staging se queda desactualizado rápidamente si la producción recibe contenido nuevo. Decide con qué frecuencia vas a sincronizarlo:

• Para proyectos activos con actualizaciones frecuentes: sincroniza antes de cada ciclo de desarrollo
• Para webs estáticas o con poco contenido nuevo: el staging puede durar semanas sin necesidad de sincronizar
• Para WooCommerce: nunca sincronices el staging con los pedidos y datos de clientes reales sin anonimizarlos antes

Staging en VPS

Si usas un VPS con acceso root, tienes más opciones para el staging:

Git para control de versiones del código: mantén el código de tu tema y plugins personalizados en Git. La rama develop es el staging; main es producción.

Docker para entornos aislados: como se explica en el artículo sobre instalar Docker en VPS Ubuntu, puedes crear contenedores completamente aislados para el staging sin que compartan ningún recurso con producción.

Scripts de deploy automatizado: usa scripts bash o herramientas como Deployer para automatizar la sincronización de cambios de staging a producción con un solo comando.

👉 Planes Hosting WordPress con Staging

---

Preguntas frecuentes

¿El staging consume recursos adicionales de mi hosting?
Sí. El staging ocupa espacio en disco (una copia completa de los archivos y la base de datos) y cuando accedes a él consume RAM y CPU. En hosting compartido, ten en cuenta que el staging comparte los recursos de tu cuenta con la web de producción.

¿Puedo tener staging en un hosting compartido o necesito VPS?
Puedes tener staging en hosting compartido con cPanel usando cualquiera de los métodos descritos. La limitación es el espacio en disco y los recursos compartidos. Para webs grandes o con mucho tráfico en staging, un VPS es más adecuado.

¿Cada cuánto debo actualizar el staging con los datos de producción?
Depende de con qué frecuencia cambia tu web. Para webs con contenido que se actualiza diariamente, sincroniza el staging antes de cada ciclo de cambios. Para webs más estáticas, puede no ser necesario actualizarlo con cada cambio menor.

¿El staging afecta al SEO?
No si está correctamente protegido. Asegúrate de que el staging no es indexable (robots.txt con Disallow: / y la opción de WordPress de no indexar activada) y de que está protegido con contraseña para evitar que Google lo rastree.

¿Puedo usar el mismo dominio para staging con una contraseña diferente?
No es lo recomendable. Un subdominio separado (staging.tudominio.com) es la forma correcta — mantiene la separación clara entre producción y staging, facilita la gestión de SSL por separado y evita confusiones.

¿Qué hago si staging y producción se desincronizaron demasiado?
Borra el staging y créalo de nuevo desde producción. Es más seguro que intentar sincronizar un staging muy desactualizado con producción, especialmente si ha habido muchos cambios en ambos entornos.