Migrar WordPress a otro hosting requiere comprobar algo más que la portada. El objetivo es trasladar la web con sus datos y funciones, conservar las direcciones públicas y saber cómo actuar si aparece una incidencia.
Esta guía se centra en una instalación individual que cambia de alojamiento y mantiene dominio, protocolo y rutas. Un cambio de dominio, una tienda con pedidos continuos o una red Multisite necesitan un plan específico. La lista siguiente es una propuesta de trabajo que debes adaptar a tu instalación.
1. Define qué se traslada y quién puede cambiarlo
Antes de copiar archivos, prepara un inventario: alojamiento, base de datos, DNS, certificados, correo, tareas programadas y servicios externos. Anota también quién tiene acceso a cada panel y quién puede autorizar el cambio.
Conviene dejar por escrito tres datos: última copia válida, momento previsto para el cambio y persona responsable de decidir una vuelta atrás. Así la intervención no depende de recordar detalles durante una avería.
Para entender el alcance de una copia editorial, consulta qué incluye el XML de exportación de WordPress. No lo utilices como única garantía de recuperación de toda la instalación.
2. Prepara una copia recuperable
La documentación de WordPress sobre migraciones explica el traslado de archivos y base de datos y la adaptación de la configuración al servidor de destino. Revisa las credenciales de la base de datos en la nueva instalación y conserva la copia de origen.
Como criterio operativo, guarda la copia fuera del servidor que vas a sustituir y registra la fecha. Comprueba que puedes abrirla y restaurarla en un entorno de prueba; el mensaje «copia completada» no demuestra que permita recuperar la web.
La guía de pruebas de restauración en WordPress desarrolla esta comprobación. Si faltan archivos o datos, resuélvelo antes de modificar DNS.
3. Ensaya el destino con una lista de aceptación
Google recomienda preparar y probar la nueva infraestructura antes de dirigirle el tráfico. Incluye páginas, imágenes, formularios y descargas en esa revisión.
Mi recomendación es usar una tabla de control con una fila por función, resultado esperado, resultado observado y responsable. Por ejemplo:
- Contacto: enviar una consulta de prueba y comprobar su registro y entrega.
- Acceso: entrar y salir con un usuario de prueba apropiado.
- Contenido: abrir una página de servicio, una entrada antigua y un PDF.
- Integraciones: revisar webhooks y tareas evitando duplicar envíos reales.
- Presentación: comprobar menú, imágenes y formulario en móvil.
Puedes organizar el ensayo con un entorno de staging. Decide qué acciones externas deben quedar deshabilitadas durante las pruebas y cómo se reactivarán al finalizar.
4. Decide cómo gestionar los cambios de última hora
Plantea este escenario antes del traslado: alguien envía un formulario después de obtener la copia inicial. ¿Dónde quedará ese dato? Como propuesta, fija una ventana de intervención y un procedimiento de sincronización final o de pausa de escrituras, según la actividad de la web.
En una tienda, perder un pedido o reproducirlo dos veces exige un análisis diferente al de una web corporativa. No prometas ausencia de cortes sin haber ensayado ese caso concreto.
5. Cambia DNS con un plan de seguimiento
Para migraciones sin cambios de URL, Google plantea preparar el destino, actualizar DNS, observar ambos servidores y retirar el antiguo cuando deje de recibir tráfico. También recomienda anticipar la reducción del TTL y conservar la verificación de Search Console.
Como medida de control, documenta los registros actuales y modifica solo lo necesario para dirigir la web al destino. Si también vas a mover el correo, trátalo como una intervención diferenciada con sus propias pruebas de envío y recepción.
6. Valida antes de dar por terminado el cambio
Revisa HTTPS, URLs importantes, formularios, descargas y errores. Comprueba también que no permanecen bloqueos temporales de indexación en la versión pública. Conserva el origen mientras se completa el seguimiento del tráfico.
Para cerrar la intervención, recomiendo comparar la lista de aceptación con el ensayo previo y anotar cualquier diferencia. Revisa la directiva noindex y los registros de errores si aparecen síntomas. Publica un acta breve con fecha, comprobaciones y pendientes, sin dar por garantizados resultados SEO.
Cuándo volver atrás
Define por adelantado qué fallos justifican revertir: por ejemplo, imposibilidad de acceder a datos esenciales o fallo sostenido del proceso de contacto. Antes de regresar al origen, identifica los datos nuevos recibidos en destino y cómo conservarlos. Volver a una copia anterior sin esa revisión puede descartar actividad reciente.
¿Necesitas preparar el cambio de alojamiento?
El servicio de mantenimiento WordPress permite abordar el traslado con inventario, pruebas y seguimiento.
Fuentes oficiales
Documentación consultada el 26 de octubre de 2026. El procedimiento propuesto debe adaptarse a las funciones y actividad de cada web.
