En WordPress sin staging, restaurar borra pedidos

El fallo más caro de una migración no siempre es una web caída: puede ser restaurar una copia tras cambiar las DNS y borrar pedidos, contactos o contenidos creados mientras tus visitantes seguían usando la web antigua. Si tu negocio vende, capta leads o depende del posicionamiento, una validación tardía puede convertir unas horas de cambio en pérdidas difíciles de detectar.

Migrar WordPress sin staging no siempre rompe la web, pero convierte a tus visitantes en testers: pueden ver errores, comprar sobre datos desactualizados o enviar formularios que no llegan. El mayor riesgo no es copiar archivos, sino validar tarde. Reduce el impacto con un backup verificable, pruebas mediante hosts, una ventana de baja actividad y un rollback preparado antes de tocar las DNS.

Migrar sin staging expone fallos al público

Migrar en producción significa cambiar una web que usan personas reales sin haber probado antes la copia en el nuevo servidor. Un fallo puede durar entre unos minutos y varias horas, según el DNS, la caché y la rapidez con que se detecte el problema.

El error más frecuente en este punto es cambiar los DNS porque la portada del clon parece correcta. La portada es solo la puerta del local: no confirma que funcionen la caja, el correo, los accesos privados ni las conexiones con otros servicios.

Qué ve un visitante cuando falla

Una caída visible puede mostrar un error 500, una página en blanco o enlaces que llevan a errores 404. El error 500 indica que el servidor no puede completar una petición, como una centralita que recibe la llamada pero no sabe a qué extensión enviarla.

También pueden fallar acciones menos visibles. Un formulario puede mostrar el mensaje “enviado” y no entregar el correo, o un usuario puede perder su sesión porque las cookies del nuevo servidor no coinciden con las anteriores.

En WooCommerce, el problema puede afectar al carrito, al cálculo de envío o a la pasarela de pago. Un cliente que llega al checkout y no puede pagar rara vez espera a que el técnico termine las comprobaciones.

Cuándo el riesgo deja de ser asumible

Una tienda con pedidos activos, una web de reservas o una membresía no debería migrarse directamente sin un plan de datos. Cada alta, pago o reserva que entra durante la ventana de cambio puede quedar en una de las dos versiones de la base de datos MySQL.

Un caso habitual es una tienda que cambia DNS a mediodía y restaura la copia de la mañana al detectar un error de PHP. La web vuelve a cargar, pero desaparecen los pedidos y cambios de stock hechos entre ambas horas si no se exportaron antes.

El riesgo aumenta cuando hay campañas activas, anuncios, lanzamientos o tráfico desde móvil. En negocios de Madrid que reciben contactos durante el horario comercial, una caída de 30 a 90 minutos puede dejar formularios repartidos entre el hosting antiguo y el nuevo.

Saber qué puede fallar ayuda, pero todavía falta distinguir las herramientas que previenen el fallo de las que solo reparan sus consecuencias.

Backup y staging resuelven problemas distintos

Un backup es una copia guardada de archivos y base de datos, mientras que un staging es una copia aislada donde se prueba la web antes de publicarla. Un clon local es otra opción: funciona en un ordenador, no en el servidor público.

La experiencia demuestra que una copia automática no basta hasta que se verifica su restauración. Es como tener un extintor precintado: tranquiliza verlo, pero no demuestra que funcione cuando hace falta.

Qué debe contener una copia restaurable

Una copia completa incluye archivos de WordPress, imágenes, plugins, tema, wp-config.php y la base de datos. El archivo wp-config.php guarda datos de conexión que permiten a WordPress hablar con MySQL, como una llave que abre el almacén de datos.

Comprueba que el proveedor permite descargar o restaurar esa copia en un entorno separado. Si solo existe una copia dentro del mismo servidor que vas a abandonar, no es una protección suficiente ante un error de migración.

Guarda una exportación adicional de los datos vivos. En WooCommerce incluye pedidos, clientes, productos y stock; en formularios, exporta los contactos; en reservas, descarga la agenda y los pagos pendientes.

Por qué restaurar puede borrar ventas

Restaurar toda la base de datos devuelve la web a la hora exacta de la copia. Todo lo creado después deja de existir en esa versión, aunque sí haya ocurrido para el cliente.

Por eso, antes de una reversión, hay que separar dos decisiones: devolver el DNS a la web antigua y restaurar datos. A veces basta con volver a la IP anterior; no siempre es necesario sobrescribir archivos y tablas.

La restauración completa es el último recurso, no el primer botón que pulsar cuando una migración falla.

Un hosting con staging suele costar en España entre 8 y 30 € al mes en planes gestionados básicos, mientras que una intervención urgente de migración puede situarse entre 80 y 250 € según tienda, correo e integraciones. La comparación no es exacta para todos los proveedores, pero ilustra por qué probar antes suele salir mejor que reparar deprisa.

Una vez clara esta diferencia, toca decidir qué nivel de control necesita cada tipo de sitio.

El tipo de web decide si puedes asumir riesgo

Una web estática de bajo tráfico puede migrarse con controles básicos, pero WooCommerce, reservas, membresías y multisite requieren proteger datos que cambian cada minuto. La diferencia no está en el diseño: está en si el visitante puede crear información nueva.

Al comparar fuentes especializadas de WordPress y documentación de alojamientos gestionados, la recomendación que se repite es probar el clon antes del DNS, especialmente cuando existen pagos, sesiones o servicios externos.

Blogs y corporativas con riesgo controlado

Un blog o una web corporativa puede admitir una ventana corta si no recibe cambios frecuentes. Aun así, hay que probar enlaces permanentes, imágenes, buscador, formularios y correos SMTP, que es el sistema encargado de entregar emails.

Pausa publicaciones y cambios de contenido durante la migración. Si la web capta presupuestos, avisa al equipo comercial para que revise tanto el buzón como el panel del formulario durante el cambio.

Tiendas y reservas con riesgo alto

En tiendas, los datos no son solo tablas de WordPress. Una pasarela puede enviar un webhook, una notificación automática entre servicios, mientras el pedido entra por otra ruta.

También debes revisar impuestos, métodos de envío, cupones y stock. Un checkout de prueba con tarjeta en modo sandbox, cuando la pasarela lo permite, vale más que comprobar diez veces la página de inicio.

El problema es que esto solo funciona si el nuevo servidor se prueba sin que el público llegue a él. Hay una forma práctica de hacerlo incluso sin staging formal.

Prueba el nuevo servidor sin tocar el DNS

Puedes validar un clon de WordPress con el archivo hosts o con una URL temporal del proveedor antes de cambiar el dominio público. Así, tu ordenador abre el nuevo servidor mientras el resto de visitantes sigue usando la web antigua.

El archivo hosts actúa como una pequeña agenda privada de direcciones. Le dice a tu equipo que tudominio.es debe ir a una IP concreta, aunque el DNS general todavía apunte al hosting anterior.

Cómo usar hosts sin exponer el clon

Pide al nuevo hosting la IP del servidor y añade una línea temporal en el archivo hosts de un ordenador de prueba. Después abre el dominio habitual en una ventana privada, borra caché si es necesario y revisa que el contenido procede del clon.

No hagas estas pruebas solo con una sesión ya iniciada. Comprueba navegación normal, login, logout y formularios como visitante, porque las cookies antiguas pueden ocultar errores de sesión.

Cuando termines, elimina la línea de hosts. Dejarla activa puede hacer que tu equipo vea una versión diferente de la que ve el resto de la empresa.

URL temporal y protección del clon

Una URL temporal sirve si el hosting la ofrece, aunque algunas funciones dependen del dominio final y no se comportan igual. Por eso hosts suele ser más fiable para pagos, HTTPS, redirecciones y cookies.

Protege el clon con contraseña y marca la copia como no indexable mientras se prueba. Un noindex pide a Google que no incluya esa versión en resultados, pero debe retirarse antes de publicar si se copió al entorno final.

Revisa el certificado SSL antes del cambio. Let’s Encrypt necesita validar el dominio para emitir HTTPS, por lo que algunos certificados solo estarán activos tras apuntar el DNS al nuevo servidor.

Checklist antes del cambio de DNS y SEO

No cambies DNS hasta completar pruebas funcionales, de correo y de SEO en el servidor nuevo. Un DNS es el sistema que traduce un dominio a una dirección de servidor, como el listado que indica dónde está cada negocio.

WordPress.org recomienda mantener WordPress y sus componentes actualizados y protegidos, pero durante una migración conviene congelar actualizaciones. Cambiar PHP, plugins y hosting el mismo día mezcla causas y dificulta saber qué rompió la web.

Funciones que deben probarse de verdad

No basta con marcar tareas como revisadas. Haz una acción completa y comprueba el resultado final, incluido el correo recibido y el dato guardado en el panel.

• Envía un formulario con archivo adjunto y confirma su llegada por SMTP.
• Prueba login, recuperación de contraseña y cierre de sesión.
• En WooCommerce, prueba carrito, cupón, envío, checkout y email de pedido.
• Comprueba búsqueda, enlaces permanentes, páginas privadas y redirecciones 301.
• Revisa caché, CDN de Cloudflare, tareas programadas y APIs externas.

SEO que puede perderse en minutos

Una migración sin validar puede publicar un noindex, un robots.txt de pruebas o etiquetas canonical que apuntan al dominio equivocado. La canonical indica a Google cuál es la URL principal de un contenido; si señala al clon, el buscador recibe una señal errónea.

Comprueba sitemap XML, Google Search Console, analítica y etiquetas de conversión. También revisa las Core Web Vitals, que miden experiencia de carga e interacción, porque una caché o una versión de PHP distinta puede empeorarlas.

La recomendación extendida de “cambiar DNS de noche” es incompleta. Una madrugada con menos visitas reduce el impacto visible, pero no evita perder pedidos diferidos, webhooks o formularios que entren mientras las resoluciones DNS se reparten.

Migrar sin staging es aceptable solo si has probado el clon de forma privada, has guardado los datos vivos y puedes volver al servidor anterior sin restaurar a ciegas. Una web estática puede asumir una ventana corta; una tienda, reserva o membresía debe proteger pedidos y registros nuevos antes de tocar DNS. La decisión segura no depende de que la portada cargue, sino de que las funciones que generan negocio hayan superado pruebas reales.

Además de las pruebas visibles, valida los errores técnicos que suelen aparecer al cambiar de hosting. Las URLs antiguas pueden seguir guardadas en opciones, widgets o datos serializados de la base de datos MySQL; sustituirlas con una consulta SQL genérica puede corromper esos datos, por lo que conviene usar una herramienta compatible con WordPress o la función de búsqueda y reemplazo del proveedor. Si los enlaces permanentes devuelven errores 404, guarda de nuevo la estructura de enlaces para regenerar .htaccess y confirma que el servidor permite sus reglas.

Revisa también los permisos de archivos y carpetas, la versión de PHP, extensiones como mysqli, curl e imagick, y los límites de memoria: una web puede cargar la portada y fallar al subir imágenes, enviar correos o ejecutar tareas programadas.

DNS y rollback sin borrar datos recientes

La ejecución segura combina una ventana de baja actividad con un plan de reversión que protege los datos nuevos. El rollback no significa automáticamente restaurar todo: primero se identifica si el fallo es de DNS, archivos, configuración o base de datos.

Reduce TTL y congela cambios

Baja el TTL entre 24 y 48 horas antes si tu proveedor DNS lo permite. El TTL es el tiempo que otros sistemas guardan una dirección en caché; reducirlo ayuda a que el cambio se propague antes, aunque no elimina todas las cachés.

Documenta los registros A, AAAA, CNAME, MX y TXT antes de tocar nada. Los registros MX y TXT suelen afectar al correo y a validaciones SPF, DKIM o DMARC, por lo que una migración web puede romper emails si se modifica la zona DNS completa sin cuidado.

Durante la ventana, congela cambios de plugins, tema, PHP, campañas e importaciones. Mantén el hosting antiguo activo hasta confirmar que no recibe pedidos, formularios ni tráfico relevante.

Cuándo volver atrás y qué guardar

Revierte DNS de inmediato ante pagos fallidos, errores 500 generalizados, SSL bloqueado o accesos privados rotos. Si el fallo es un plugin o permiso de archivos, quizá baste corregirlo sin tocar la base de datos.

Antes de restaurar MySQL, exporta pedidos, clientes, reservas, formularios y contenido creado desde el inicio de la ventana. Haz también capturas o exportaciones de registros de pago, webhooks y CRM para poder reconciliar datos después.

Si vas a cambiar de hosting y tu web tiene formularios, ventas o reservas, un servicio profesional de mantenimiento WordPress puede preparar el clon, las pruebas y la reversión sin dejar esos puntos al azar.

Preguntas frecuentes

¿Qué pasa si migro WordPress sin staging?

Migrar WordPress sin staging puede mostrar errores, romper formularios o afectar compras mientras el público usa la web. El riesgo crece si hay pedidos, reservas o usuarios activos durante el cambio.

¿Se puede migrar una web sin caída?

Sí, una migración puede tener cero minutos visibles de caída si el clon y el DNS están bien preparados. Aun así, conviene vigilar entre 24 y 48 horas las resoluciones, correos y transacciones.

¿Cómo pruebo el nuevo hosting antes del DNS?

Puedes usar el archivo hosts para abrir el dominio en el nuevo servidor solo desde tu ordenador. También sirve una URL temporal, aunque puede no reproducir bien cookies, HTTPS o redirecciones.

¿Debo restaurar todo si la migración falla?

No, primero debes decidir si basta con revertir DNS o corregir archivos y configuración. Restaurar toda la base de datos sin exportar datos recientes puede borrar pedidos y formularios.

¿Qué datos debo guardar antes de un rollback?

Guarda pedidos, clientes, reservas, leads, usuarios y contenido creado desde el inicio de la migración. En tiendas, incluye pagos, stock, cupones y notas de pedido.

¿Puede una migración afectar al SEO?

Sí, un noindex, canonical errónea, robots.txt restrictivo o redirección rota puede afectar la indexación de Google. Revisa sitemap, Search Console, HTTPS y errores 404 antes y después del cambio.

Qué hacer antes de aceptar la migración

No aceptes una migración directa solo porque incluye una copia de seguridad. Pide que el proveedor detalle cómo probará el clon, qué funciones revisará y cómo protegerá los datos generados durante la ventana.

Para una web simple, exige como mínimo backup verificable, prueba con hosts, SSL preparado y revisión de enlaces. Para una tienda, reserva o membresía, añade exportación de datos vivos, pruebas de pago y una persona responsable de decidir el rollback.

• Reintentar una importación XML puede duplicar contenido
• El hosting para EDD que entrega descargas sin cortes

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.