Hosting web en España: migración y copias de seguridad
Cómo probar cambios de WordPress en staging
Un staging permite ensayar cambios antes de llevarlos al sitio activo, pero una copia de producción también puede contener pedidos, correos, tareas programadas y claves de integraciones. Esta guía ordena la prueba para reducir efectos laterales y evitar que una publicación sobrescriba datos nuevos de la web en producción.
Equipo de El Rankeador · Guía editorial con asistencia de IA · Revisada: 2026-10-12
Un caso ficticio para preparar tu prueba
La tienda inventada tienda.example va a actualizar un tema y un complemento de pago. El CSV contiene seis comprobaciones pendientes para practicar la separación entre copia y producción. No son pruebas ejecutadas ni resultados de ningún proveedor; utiliza datos sintéticos y una pasarela en modo de prueba, nunca pedidos o credenciales reales.
Descargar plantilla CSV del ejemplo
La plantilla reúne datos ficticios. Adapta campos, formato y referencias al producto y al entorno separado que vas a evaluar.
| caso_id | area | comprobacion | resultado_esperado | estado | observacion_de_prueba |
|---|---|---|---|---|---|
| ST-01 | Acceso e indexación | Abrir el subdominio de pruebas e intentar entrar sin autenticación | El entorno sólo es accesible a quienes lo prueban y no se indexa | Pendiente | Usar URL y cuenta ficticias |
| ST-02 | Portada y producto | Abrir portada, producto, imágenes y enlaces internos | Las páginas cargan y los enlaces no apuntan por error a la copia o a rutas rotas | Pendiente | Sin medición; registrar URL de prueba |
| ST-03 | Formulario y correo | Enviar una solicitud con datos sintéticos | El formulario responde y ningún mensaje se entrega a clientes reales | Pendiente | Desactivar envíos o usar buzón de pruebas |
| ST-04 | Carrito y pago | Completar un pedido ficticio con la pasarela en modo de pruebas | El pedido usa el entorno sandbox y no genera cargos reales | Pendiente | No usar una tarjeta de cliente |
| ST-05 | Tareas e integraciones | Revisar cron, webhooks y automatizaciones activas | No se duplican correos, avisos, cargos ni sincronizaciones de producción | Pendiente | Anotar cada integración que se desactivó |
| ST-06 | Publicación y vuelta atrás | Comparar los cambios y ensayar el procedimiento de reversión | Se publica sólo el cambio aprobado y se conservan pedidos nuevos de producción | Pendiente | Hacer copia y registrar responsable |
Comprobaciones paso a paso
Delimita el cambio y comprueba el entorno
Anota qué vas a actualizar, en qué web y qué debe seguir funcionando. Decide si necesitas clonar la instalación o levantar una web limpia, y confirma plan, recursos, versión de WordPress y compatibilidad del método. Una copia de staging no sustituye una copia de seguridad ni confirma que el cambio sea publicable.
Qué conservar: Versión origen, cambio que se ensaya, responsable, plan y recursos disponibles.
Aísla la copia y reduce los datos expuestos
Usa autenticación o acceso privado y reemplaza datos personales o de clientes por valores sintéticos siempre que sea posible. Si el entorno es accesible sin iniciar sesión, configura una regla noindex y comprueba que Google pueda rastrearla para leerla; robots.txt por sí solo no garantiza que la URL quede fuera de los resultados. No compartas claves de producción en capturas ni en el CSV.
Qué conservar: Quién puede entrar, regla de acceso/indexación y qué datos de la copia se anonimizaron.
Desactiva acciones que puedan salir a producción
Antes de probar formularios o pedidos, revisa correos, cron, webhooks, sincronización de inventario, CRM y pasarelas. Usa endpoints y modo de pago de pruebas; si no puedes aislar una integración, apágala temporalmente. En WooCommerce, un pedido de prueba aún puede generar correos y aparecer en analítica, así que comprueba las opciones de notificación y el cleanup.
Qué conservar: Integraciones aisladas, modo sandbox, destino de correos y acciones programadas revisadas.
Ejecuta casos de aceptación con resultados esperados
Prueba portada, fichas, imágenes, roles, formularios y la ruta de compra con pedidos ficticios. Escribe el resultado esperado antes de ejecutar cada caso y marca aprobado, fallido o pendiente; una captura aislada no sustituye repetir el flujo desde el inicio.
Qué conservar: Caso, pasos, resultado observado, estado y evidencia sin datos sensibles.
Decide qué se publica y protege los datos nuevos
Separa archivos de código, ajustes y datos de base de datos. Una base clonada puede ser anterior a pedidos, comentarios o formularios recibidos mientras probabas; evita sobrescribirla íntegramente sin revisar cómo reconciliar esos registros. Haz una copia recuperable, prepara responsables y define una condición concreta para revertir.
Qué conservar: Lista exacta de cambios, datos que no se deben reemplazar, copia verificada y plan de reversión.
Verifica el sitio activo después del cambio
Tras publicar, comprueba la portada, inicio de sesión, HTTPS, formulario y checkout con el método apropiado. Revisa correos, cron y conexión de integraciones en producción antes de dar el cambio por terminado. Si falla un criterio crítico, activa la vuelta atrás definida y registra qué ocurrió.
Qué conservar: Hora, versión publicada, pruebas de humo, incidencias y decisión final.
Resultado esperado del ejercicio
Estos puntos describen la referencia del caso ficticio y lo que debes comprobar. No son resultados medidos en un proveedor.
- El ejemplo tiene seis casos, todos en estado Pendiente: no representa pruebas realizadas ni resultados medidos.
- El acceso a la copia se limita y no se reutilizan credenciales ni datos personales innecesarios.
- Los formularios, notificaciones, pasarela, cron y webhooks se prueban sin efectos reales sobre clientes.
- El plan de publicación distingue archivos y configuración de los pedidos y otros datos que se generan en producción.
- Cada caso tiene un resultado esperado y un criterio claro de aprobación o reversión.
Documentación que puedes contrastar
Las siguientes afirmaciones proceden de las fichas revisadas. Sirven para identificar capacidades y condiciones del producto; el ejemplo y su protocolo son una propuesta editorial de El Rankeador.
SiteGround
SiteGround documenta una herramienta de staging para copiar los archivos y la base de datos de una instalación WordPress, con límites de capacidad y sin compatibilidad actual con WordPress Multisite.
La base de datos debe ser menor de 5 GB y tener menos de 500 tablas. · La guía exige más del 51% de espacio libre y más del 20% de inodos libres. · No es compatible con WordPress Multisite según la página revisada. · La herramienta utiliza subdominios; puede requerir preparar DNS manualmente. ✓ Verificado
Webempresa
La tabla de hosting WooCommerce de Webempresa muestra entorno de pruebas en varios planes, pero no en el plan inicial.
La disponibilidad depende del plan; la tabla consultada muestra el entorno de pruebas desactivado en el inicial. · Disponibilidad y publicación del entorno de pruebas según plan. · Entorno de pruebas aislado para validar cambios sin afectar a pedidos reales. ✓ Verificado
Referencias para la metodología
- Google Search Central: bloquear la indexación con noindex
Explica cuándo Google puede leer una regla noindex y por qué robots.txt no sustituye esa regla; usa acceso privado para que la copia no quede expuesta.
- WooCommerce: probar pedidos
Advierte que los pedidos de prueba pueden generar correos y aparecer en analítica; describe el modo de pruebas de las pasarelas y el uso de staging.
Continúa según lo que tengas pendiente
- Cómo probar la restauración de una copia de seguridad
Ensaya una restauración aparte y comprueba que existe una vuelta atrás antes de publicar.
- Cómo comprobar HTTPS y el certificado SSL antes de abrir una web
Valida HTTPS y el certificado de la web activa después del despliegue.
- Cómo documentar una incidencia de hosting para poder reproducirla
Si un caso falla, registra URL, hora, pasos y cambios para que otra persona pueda reproducirlo.
Preguntas frecuentes
¿Staging evita que Google indexe la copia?
No por sí solo. Para un entorno de prueba, prefiere autenticación. Si dejas una URL accesible públicamente, aplica noindex y permite que Google la rastree para leer la regla; bloquearla sólo con robots.txt no garantiza que no aparezca en resultados.
¿Puedo copiar toda la base de datos de staging al sitio activo?
No lo des por seguro: la copia puede haber quedado desactualizada mientras producción recibía pedidos, registros o comentarios. Identifica qué tablas y campos cambiaron, protege los datos nuevos y publica selectivamente después de una copia recuperable.
¿Los pedidos de prueba son inocuos automáticamente?
No. En WooCommerce los pedidos de prueba pueden activar correos y aparecer en analítica. Usa el modo sandbox de la pasarela, revisa integraciones y notificaciones, evita cargos reales y limpia los datos de prueba según el procedimiento del sitio.
Volver a comparar alternativas · Cómo se revisan las fuentes