Cómo pasar WordPress de un hosting a otro paso a paso

Introducción

Cambiar un sitio web de un hosting a otro es una de esas tareas que, en teoría, parecen sencillas, pero que en la práctica pueden convertirse en una pesadilla si no se ejecutan con método. Todos los que gestionamos proyectos digitales hemos sentido esa punzada de ansiedad al imaginar la pantalla de "Error de conexión" o, peor aún, el momento en que descubrimos que la base de datos no importó correctamente y hemos perdido los comentarios de los últimos meses.

La necesidad de migrar surge por múltiples motivos reales: el plan contratado se queda corto ante el crecimiento del tráfico, el soporte técnico no responde con la rapidez que exige un negocio, los tiempos de carga se vuelven lentos o, simplemente, encontramos una opción con mejor relación calidad-precio. Sea cual sea tu situación, el proceso implica mover tres elementos fundamentales: los archivos del sitio (el núcleo de WordPress, los temas y los plugins), la base de datos (donde se almacenan tus entradas, páginas y ajustes) y la configuración del dominio.

La razón por la que este tema merece una guía detallada es que un error aparentemente menor —como olvidar actualizar una URL en la tabla de opciones de la base de datos— puede provocar que el panel de administración devuelva un error 500 o que la web muestre únicamente una pantalla en blanco.

Afortunadamente, migrar no requiere ser un desarrollador avanzado. Con una metodología clara y las herramientas adecuadas —que pueden ser tanto un plugin de migración como una copia manual—, puedes realizar el traslado sin perder datos ni posicionamiento SEO, siempre que mantengas una copia de seguridad íntegra y sigas un orden lógico. En este artículo vamos a desgranar el proceso completo: desde la preparación del entorno de destino hasta la verificación final del sitio, pasando por la transferencia de archivos, la exportación e importación de la base de datos y los ajustes de configuración necesarios para que todo funcione a la perfección.

Qué es

Qué es migrar WordPress de un hosting a otro

Migrar WordPress de un hosting a otro es el proceso de trasladar todos los archivos, la base de datos y la configuración de tu sitio web desde un servidor de alojamiento actual a uno nuevo. En términos prácticos, significa mover todo lo que hace funcionar tu página: los temas, los plugins, las imágenes, los textos publicados, los usuarios registrados, los comentarios y cualquier ajuste personalizado.

A diferencia de lo que muchos piensan, una migración no consiste solo en copiar y pegar archivos. WordPress funciona con dos componentes fundamentales que deben viajar juntos: el sistema de archivos (todo lo que ves en el directorio `wp-content`, más los archivos núcleo de WordPress) y la base de datos MySQL (donde se almacenan las entradas, páginas, opciones del sistema y configuraciones).

La confusión más común es creer que transferir únicamente los archivos del tema o hacer una exportación de contenido mediante la herramienta nativa de WordPress es suficiente. La opción de Herramientas > Exportar del panel de administración solo genera un archivo XML con el contenido editorial, pero no incluye plugins, configuraciones de personalización, usuarios con sus roles, ni ajustes del sistema. Para una migración completa necesitas mover la base de datos entera.

Otra alternativa que se confunde con la migración es la duplicación. Cuando creas un sitio de pruebas (staging) o un entorno de desarrollo, estás duplicando tu WordPress, pero en el mismo servidor o en un servidor que no será el definitivo. La migración, en cambio, tiene un destino claro y permanente: el nuevo hosting donde operará tu sitio en producción.

Un matiz importante: migrar no es lo mismo que rediseñar ni reconstruir. El objetivo es que tu sitio funcione exactamente igual en el nuevo servidor, con todos sus datos históricos y su configuración intacta. Si usas un constructor de páginas como Elementor o Divi, la migración también debe preservar las condiciones bajo las cuales esos constructores pueden regenerar sus estilos y maquetaciones, lo que depende de que la URL del sitio y las rutas de archivos se mantengan coherentes.

¿Por qué se realiza una migración?

Las razones más habituales para trasladar un WordPress de hosting son:

Mejor rendimiento: el hosting actual se queda corto en recursos, tiempos de carga o capacidad de respuesta.
Problemas recurrentes de disponibilidad: caídas frecuentes del servidor que afectan el posicionamiento y la confianza de los visitantes.
Necesidad de más seguridad: pasar a un proveedor con mejor infraestructura, certificados SSL automatizados, copias de seguridad más robustas o protección contra ataques DDoS.
Costos: buscar un precio más competitivo con prestaciones equivalentes o superiores.
Soporte técnico: cambiar a una empresa con atención más ágil o especializada en WordPress.
Escalabilidad: si tu proyecto crece, quizá necesites un servidor dedicado o un plan cloud con recursos elásticos.

Comprender esta distinción te ayuda a tomar decisiones correctas antes de empezar. Por ejemplo, si tu objetivo es mejorar la velocidad, migrar a un hosting optimizado para WordPress será útil solo si además revisas el resto de factores que influyen en el rendimiento, como el tamaño de las imágenes o el uso de caché. Si buscas seguridad, la migración debe acompañarse de una limpieza previa del sitio en caso de que estuviera comprometido.

Componentes que viajan en una migración

Para que el concepto quede claro, esto es lo que se transfiere durante una migración completa:

Archivos principales de WordPress: el núcleo, el archivo `wp-config.php`, el directorio `wp-content` completo (temas, plugins y subidas).
Base de datos: todas las tablas que empiezan por `wp_` (aunque el prefijo puede ser personalizado) y que contienen el contenido, los usuarios, las opciones, los enlaces permanentes, los widgets, los menús, etc.
Permisos de archivos: los ajustes de lectura/escritura necesarios para que WordPress y sus plugins funcionen correctamente.
URLs y referencias internas: si cambias el dominio o el subdominio, será necesario actualizar las referencias en la base de datos para que el site funcione sin errores de enlaces rotos.

Entender esto último es crucial: si migras a un hosting donde el sitio tendrá una URL distinta (por ejemplo, de `miproyecto.com` a una dirección temporal o a un subdominio de pruebas), no basta con mover archivos y base de datos. Hay que actualizar las URLs almacenadas en las tablas de opciones y en el contenido publicado, o el sitio devolverá errores o redirigirá al lugar equivocado.

Conocer qué significa exactamente migrar WordPress te permite abordar el proceso con los pasos adecuados y evitar pérdidas de datos o períodos largos de inactividad. En las secciones siguientes verás cómo preparar tu sitio, qué herramientas usar y cómo verificar que la migración se haya completado correctamente.

Aspectos importantes a evaluar

Aspectos importantes a evaluar antes de migrar tu WordPress

Migrar una web es como mudar una oficina llena de archivos: no basta con llevar las cajas; hay que asegurarse de que cada documento llegue en orden y que nada quede en el camino. Antes de tocar un solo archivo o exportar una base de datos, un análisis inicial evita dolores de cabeza futuros y, sobre todo, la pérdida de datos o un tiempo de inactividad mayor al necesario. Aquí es donde se decide si la operación será un trámite sencillo o una auténtica pesadilla.

Dimensiona tu sitio: no es lo mismo un blog que una tienda

El primer paso es entender qué estás moviendo. No es lo mismo una web de 50 MB con 5 páginas que una tienda de WooCommerce con 10,000 productos y una base de datos de 2 GB. Esa diferencia no es solo de tamaño, sino de complejidad operativa.

Peso del sitio: Revisa el tamaño de la carpeta `wp-content` (temas, plugins y, sobre todo, la subcarpeta `uploads`). Las imágenes sin optimizar son la causa más común de webs pesadas. Si tu carpeta `uploads` supera los 500 MB, ya estás en territorio de migración delicada, no por dificultad técnica, sino por tiempo de transferencia y límites de ejecución en servidores (más sobre este punto en el apartado de tiempos).
Número de archivos: Un sitio con decenas de miles de archivos pequeños (imágenes minúsculas, avatares, archivos generados por plugins de caché) se transfiere más lento que uno con pocos archivos pero de gran tamaño. El sistema de archivos del servidor sufre al procesar miles de inodos, y los plugins de migración a veces colapsan al intentar comprimirlos.
Tamaño de la base de datos: Aquí no solo importa el peso en MB. Una base de datos con muchas tablas transitorias (como las de WooCommerce, que guardan carritos y sesiones) requerirá una limpieza previa. Exportar una base de datos gigante con datos basura (revisiones de entradas antiguas, transients caducados) es un error de novato. Si tu web tiene más de 100 posts, es probable que tengas cientos de revisiones guardadas que inflan el archivo SQL innecesariamente.

Ejemplo práctico: Imagina que tienes una tienda online con 1,500 productos y 8,000 imágenes en miniatura. Si intentas migrar sin depurar, el archivo comprimido puede pesar 4 GB. Al importarlo en el nuevo hosting, el tiempo de ejecución del servidor (el llamado `max_execution_time`) se agotará, y el proceso se cortará a mitad. El resultado: una base de datos corrupta y una web rota. La solución técnica existe (dividir la importación en partes), pero la estrategia inteligente es limpiar antes de migrar: elimina plugins innecesarios, borra revisiones antiguas (puedes usar plugins como WP-Optimize pero configurados con criterio) y comprime las imágenes.

La configuración del origen: atar cabos sueltos

Un sitio de WordPress no se limita a los archivos y la base de datos. Hay configuraciones que viajan "ocultas" y que, si no se replican, rompen la lógica de tu web.

Cron jobs (tareas programadas): Si usas plugins de programación (como backups automáticos o envío de newsletters), es probable que dependas del cron de WordPress (servidor) o del cron del sistema (cPanel). Al migrar, esta configuración no viaja en la copia de seguridad. Si pasas por alto este detalle, tus backups no se ejecutarán y tu newsletter quedará congelada. Debes anotar las tareas cron existentes en el hosting antiguo (desde cPanel o Plesk) y recrearlas en el nuevo.
Rutas y dominios: WordPress guarda en la base de datos las URLs absolutas de tu web. Si te mudas a un hosting nuevo pero mantienes el mismo dominio, el proceso es más simple, pero necesitarás ajustar las URLs en las opciones de `wp_options` o usar el método `wp-cli` para hacer un reemplazo seguro. Si cambias de dominio (por ejemplo, de `misitioweb.es` a `misitioweb.com`), hay que hacer un reemplazo de URL en la base de datos, y no solo en las dos filas principales, sino en todas las tablas que contengan URLs serializadas (como las del plugin de página de opciones o los menús de navegación). Un fallo aquí provoca la pérdida de imágenes visibles o la imposibilidad de acceder al panel de administración.

Consejo: Antes de mover nada, descarga un archivo de prueba en el hosting actual (por ejemplo, una imagen desde `wp-admin`) y comprueba si el servidor actual tiene límites de subida inusualmente bajos o restricciones de seguridad que puedan interferir con la migración. No es raro que un hosting bien configurado tenga bloqueado el acceso a ciertos puertos o directorios, y eso afecta la importación.

El destino: capacidad y compatibilidad no es negociable

Si elegiste el hosting nuevo solo por el precio o la capacidad de almacenamiento, estás obviando el factor más importante: la pila de software. WordPress es exigente con la versión de PHP y el tipo de servidor.

Versión de PHP: La mayoría de las webs antiguas funcionan con PHP 7.4 o 8.0. El nuevo hosting debe soportar, como mínimo, la misma versión o una superior. No migres de un server con PHP 8.0 a uno con PHP 8.2 sin verificar que tus plugins son compatibles. En la práctica, esto se traduce en errores de tipo "White Screen of Death" (pantalla blanca) o páginas que devuelven código 500. No es una cuestión de "instalar y listo", sino de que el nuevo servidor tenga configurado el PHP que tu web necesita. Puedes comprobarlo con un archivo de prueba `info.php`, pero lo más rápido es preguntar directamente al soporte técnico antes de contratar o activar el servicio.
MySQL vs. MariaDB: Son casi idénticos, pero en proyectos grandes (webs con más de 1 GB de base de datos), las diferencias de rendimiento entre MySQL 5.7 y MySQL 8.0 son notables. Si tu web usa consultas complejas (por ejemplo, un plugin de reservas), un cambio radical de versión de MariaDB a MySQL puede alterar los tiempos de respuesta. No es que no funcione, es que el rendimiento puede degradarse y no sabrás por qué.

Tiempo de inactividad: lo que nadie te dice

La migración ideal es invisible para el usuario. En la práctica, siempre habrá una ventana temporal donde tu web estará caída o en modo mantenimiento. La clave es planificar cuándo ocurrirá esa ventana.

Migración en vivo vs. migración con apagado: La forma profesional es hacer una copia de seguridad completa, importarla al nuevo hosting y luego apuntar el dominio hacia la nueva IP (cambiando los DNS). Esto significa que tu web operará desde el nuevo hosting antes de que el dominio "apunte" allí. El inconveniente: los cambios que hagas en tu web (un post, un comentario, una compra) durante ese período no estarán en el hosting nuevo. Es decir, perderás los últimos datos. La solución es hacer el cambio de DNS en un horario de bajo tráfico o simplemente aceptar esa pérdida mínima.
Contenido dinámico: Una tienda online con carritos activos o un foro con usuarios registrados sufre más el cambio. Aquí, la estrategia cambia: necesitarás un plugin de migración que sincronice la base de datos del sitio nuevo con la del antiguo (por ejemplo, UpdraftPlus con su opción de transferir solo los cambios recientes) o hacer la migración en dos fases. No es un trabajo apto para principiantes, pero sí importante que lo tengas presente.

No existe una fórmula universal para migrar sin dolor. La evaluación previa te permite decidir el método: si tu sitio es pequeño (menos de 500 MB en total), un plugin gratuito clásico es suficiente. Si hablamos de un sitio corporativo grande, necesitarás acceso a SSH y herramientas como `wp-cli` o `rsync` para garantizar que no se pierda ningún dato. La decisión no es solo técnica, es estratégica; y se toma después de responder a la pregunta: "¿Qué pasa si falla la migración a mitad de camino?". La respuesta define si necesitas un plan B rápido o si puedes darte el lujo de experimentar.

Cómo funciona o cómo tomar una decisión

Cómo funciona el proceso: mucho más que copiar archivos

Para entender cómo se hace una migración de WordPress correctamente, primero hay que desmontar una idea muy extendida: no se trata simplemente de descargar los archivos del hosting actual y subirlos al nuevo con un gestor FTP. Si haces eso, lo más probable es que acabes con un sitio roto, con la base de datos desconectada o, peor aún, con un mensaje de "Error al establecer la conexión con la base de datos".

WordPress está compuesto por dos partes inseparables: por un lado, los archivos del núcleo (el core), los temas y los plugins; por otro lado, la base de datos, que es donde se almacenan tus entradas, páginas, comentarios, ajustes de configuración y, muy importante, las URLs permanentes del sitio. La migración implica mover ambas partes y, además, actualizar las referencias que apuntan a la antigua dirección del dominio si esta cambia.

El proceso, visto desde dentro, tiene una lógica de tres fases:

Empaquetar el estado actual: obtener una copia íntegra de los archivos y una copia de seguridad (dump) de la base de datos.
Preparar el destino: asegurarse de que el nuevo servidor tiene el software necesario (PHP y MySQL/MariaDB) y crear una base de datos vacía con un usuario asociado.
Desempaquetar en el destino: subir los archivos, importar la base de datos y ajustar las configuraciones para que ambos elementos "se encuentren" y funcionen como una unidad.

Si esta lógica te parece abrumadora, no te preocupes. La buena noticia es que existen dos rutas principales para ejecutarla, y tu elección dependerá de tu nivel de comodidad técnica y del tiempo que quieras invertir.

Ruta 1: La vía manual con plugins (la más recomendable para la mayoría)

Esta es la opción que equilibra mejor el control y la seguridad. Consiste en usar un plugin de migración, pero prestando atención a sus ajustes. La clave aquí es entender que el plugin se encarga de la parte tediosa (manejar la base de datos y las URLs), pero tú sigues teniendo el control del proceso.

Un plugin como UpdraftPlus o Duplicator funciona de la siguiente manera:

Respaldo del sitio: creas un archivo comprimido (un zip) que contiene los archivos y la base de datos. Este archivo se descarga a tu ordenador.
Preparación del destino: instalas un WordPress nuevo y limpio en el nuevo hosting. Esto asegura que el servidor tiene las rutas y permisos correctos.
Restauración inteligente: el plugin detecta que estás restaurando un respaldo sobre una instalación nueva y te pide el archivo zip. Él mismo descarga tu copia, la descomprime en el servidor y luego reemplaza los datos de la base de datos recién creada por los tuyos.

La ventaja práctica de este método es la capacidad de "rollback" o reversión. Si algo falla durante el proceso, tu sitio original en el hosting antiguo permanece intacto. Puedes seguir operando con normalidad mientras resuelves el problema. Además, estos plugins suelen manejar de forma automática los cambios de URLs, evitando el dolor de cabeza de los enlaces rotos.

Ruta 2: La vía manual con phpMyAdmin (para los que quieren control absoluto)

Esta es la opción clásica del administrador de sistemas. No requiere instalar nada extra en WordPress, pero exige más atención a los detalles. Se realiza directamente desde los paneles de control de los hosts (como cPanel o Plesk).

Aquí, el proceso sería:

En el hosting antiguo, comprimes todos los archivos de la carpeta `public_html` (o la carpeta raíz de WordPress) y los descargas.
Entras en phpMyAdmin, seleccionas tu base de datos de WordPress y la exportas como un archivo `.sql`.
En el hosting nuevo, creas una base de datos nueva y un usuario con todos los privilegios.
Subes tus archivos comprimidos al nuevo `public_html` y los descomprimes.
En phpMyAdmin del nuevo hosting, importas el archivo `.sql` en la base de datos vacía.
Editas el archivo `wp-config.php` en el nuevo servidor para poner el nombre de la nueva base de datos, el nuevo usuario y la nueva contraseña.
El paso más crítico: modificar las URLs. La base de datos contiene la URL antigua en todas tus publicaciones y enlaces internos. Si no las actualizas, al abrir tu sitio te redirigirá al dominio antiguo. Para solucionarlo, puedes usar un plugin de búsqueda y reemplazo, o ejecutar consultas SQL directas en phpMyAdmin para actualizar las opciones `siteurl` y `home`.

Esta ruta te da un conocimiento profundo de la arquitectura de WordPress, pero es fácil cometer errores en el paso de las URLs. Por eso, muchos optan por la ruta 1 incluso siendo desarrolladores, porque ahorra tiempo y automatiza el proceso.

---

La decisión en la práctica: ¿qué herramienta elegir?

No hay una respuesta única, pero sí un criterio claro. Piensa en esto: ¿qué es más valioso para ti, tener una opción con soporte y gestionada por la comunidad, o tener la máxima flexibilidad de hacerlo todo manualmente?

Si quieres una solución que te permita clonar el sitio a un entorno de pruebas (staging) para verificar que funciona antes de cambiar los DNS, plugins como Duplicator son excelentes. Su función "Package" (paquete) crea un instalador que te guía paso a paso en el nuevo servidor, incluso detectando automáticamente las nuevas rutas de archivos.

Por otro lado, si tu nuevo hosting ofrece una herramienta de migración automática (como los "Auto Installers" de algunos proveedores), estos pueden ser muy útiles. Pero ten cuidado: estas herramientas a veces tienen límites de tamaño o no transfieren ciertos archivos de configuración del servidor. Siempre es recomendable hacer una verificación manual después de usarlas.

En resumen, la decisión no es entre "hacerlo con plugin" o "hacerlo sin plugin"; es entender que el plugin es una herramienta que facilita la ejecución, pero la lógica de los tres pasos (empaquetar, preparar, desempaquetar) siempre está presente. Dominar esa lógica te hará capaz de migrar a cualquier hosting, incluso si el que elijas no tiene los plugins que usabas antes.

Planificar el momento: cuándo ejecutar la migración

Sea cual sea la ruta técnica, un factor determinante es el factor humano. Migrar un sitio web no es solo copiar datos; es gestionar la expectativa de tus usuarios. ¿Qué pasa si alguien deja un comentario o hace una compra justo mientras exportas la base de datos? Ese dato se perdería.

Por eso, el proceso real de migración siempre debe ir seguido de una ventana de mantenimiento. Esto no significa que tu sitio deba estar caído durante horas; con un plugin, la ventana puede ser de 15 a 30 minutos. El consejo práctico es:

Ejecuta la copia de seguridad en horario de bajo tráfico.
Una vez que la copia esté segura en tu ordenador, puedes tomar la decisión de poner el sitio viejo en modo mantenimiento. Así te aseguras de que no se generen datos nuevos entre la copia y la puesta en producción en el nuevo servidor.
Antes de apuntar el dominio al nuevo hosting, verifica el sitio nuevo con una URL temporal o modificando el archivo `hosts` de tu ordenador. De esta manera, compruebas que todo funciona sin afectar a los visitantes reales.

La migración perfecta no existe; existe la migración bien planificada. Y esa planificación comienza por comprender que estás manejando una base de datos con relaciones entre tablas, no solo archivos sueltos. Con esa mentalidad, el proceso deja de ser un misterio y se convierte en una tarea repetible.

Ventajas y limitaciones

Migrar WordPress entre servidores suele percibirse como una tarea tediosa, pero cuando se ejecuta correctamente, el balance final es profundamente positivo. La principal fortaleza de un cambio de hosting bien planificado no es únicamente técnica, sino estratégica: se obtiene un control total sobre el entorno donde vive tu proyecto digital. Realizar esta operación con criterio elimina la dependencia de factores externos que no puedes gestionar, como la saturación de un servidor compartido o las políticas restrictivas de un proveedor económico.

Uno de los beneficios más inmediatos que notarás es la optimización del rendimiento. Al mover tu sitio a un servidor con mejores recursos (como NVMe, más RAM o una configuración de caché servidor-side), la velocidad de carga mejora de forma notable. Esta mejora no es un simple capricho estético: un tiempo de carga inferior a 2,5 segundos impacta directamente en la tasa de rebote y en el posicionamiento en buscadores. Por ejemplo, si actualmente tu web tarda más de 4 segundos en cargar en un hosting básico y migras a un plan administrado con LiteSpeed, es probable que el PageSpeed Insights pase de una puntuación de 60 a superar los 90 sin tocar una sola línea de código, simplemente por la infraestructura subyacente.

Otra fortaleza clave es la seguridad y el aislamiento. En muchos hostings económicos, convives con cientos de sitios en el mismo servidor. Si uno de esos sitios es comprometido o recibe un pico de tráfico malicioso, el rendimiento del tuyo puede degradarse o, en el peor de los casos, ser víctima de un ataque. Al migrar a un entorno donde tienes más control (como un VPS o un hosting dedicado), reduces drásticamente la superficie de ataque. Además, durante el proceso de migración, al hacer una copia de archivos y base de datos, tienes la oportunidad de limpiar el código y los datos obsoletos. Es el momento perfecto para eliminar plugins que ya no usas, revisar si hay archivos sospechosos en el servidor o purgar la base de datos de revisiones antiguas y transients caducados, algo que normalmente se descuida en la operativa diaria.

Sin embargo, esta operación también arrastra limitaciones que deben considerarse con honestidad. La más evidente es la posible interrupción del servicio. Aunque se puede hacer una migración casi en caliente (donde los usuarios apenas notan el cambio), la mayoría de las migraciones manuales requieren un pequeño mantenimiento. Si no gestionas bien el cambio de los DNS (los servidores de nombres que apuntan tu dominio al nuevo servidor), puedes sufrir períodos de inactividad de varias horas o incluso hasta 48 horas mientras los registros se propagan por internet. Aquí no hay opciones intermedias: o aceptas la ventana de corte o contratas servicios de DNS gestionado (como Cloudflare), que permiten reducir ese tiempo a minutos, pero añaden una capa de configuración extra que no todo el mundo domina.

La segunda limitación práctica es el riesgo de errores en la transferencia de datos. Un fallo en la exportación de la base de datos puede provocar que los enlaces permanentes (permalinks) se rompan o que las imágenes desaparezcan. Un error común es olvidar actualizar la URL del sitio en la tabla `wp_options` de la base de datos; si esto no se corrige, la web redirigirá al servidor antiguo durante el proceso de copia. Esta fricción técnica no implica que el proceso sea defectuoso, sino que exige un procedimiento metódico: descargar los archivos por SSH, exportar la base de datos con `mysqldump` (para evitar que se corten las conexiones en la exportación) y ajustar las rutas absolutas en el `wp-config.php` y en la base de datos.

Por último, es relevante señalar que una migración no resolverá problemas estructurales de tu web. Si tu tema está mal optimizado o tienes demasiadas peticiones HTTP, pasar a un hosting mejor solo disimulará el problema durante un tiempo. La migración, por tanto, actúa como una mejora de entorno y no como una cura para el código pobre. Esta distinción es importante para no frustrarse después: si tu web es lenta porque tu servidor está lejos geográficamente de tu audiencia, un hosting más potente ayudará, pero la solución real sería usar una CDN o elegir un nuevo servidor cerca de tu público objetivo.

En definitiva, las ventajas superan con creces las incomodidades cuando el objetivo es escalar. Un sitio que migra correctamente gana en autonomía, velocidad y tranquilidad. La limitación radica únicamente en la curva de aprendizaje y en la paciencia necesaria para ejecutar una copia íntegra. No es una tarea imposible, pero requiere de una checklist clara para no dejar cabos sueltos. La clave está en entender que migrar no es mover cajas de una casa a otra, sino reconstruir el sistema eléctrico y de plomería del nuevo edificio para que todo fluya con normalidad.

Errores comunes

Errores comunes al cambiar de hosting (y cómo esquivarlos)

Migrar una web es un proceso delicado. Incluso siguiendo un tutorial al pie de la letra, es fácil caer en errores que convierten una operación de 30 minutos en un dolor de cabeza de días. La mayoría de estos fallos no se deben a la complejidad técnica, sino a la falta de previsión.

Estos son los errores más frecuentes y la forma concreta de evitarlos.

1. Migrar archivos, pero olvidar la base de datos

Es el error más clásico. Algunos usuarios, especialmente si migran manualmente por FTP, copian todo el contenido de `wp-content` y los archivos raíz de WordPress, pero olvidan que toda la lógica del sitio (entradas, páginas, configuraciones, usuarios) vive en la base de datos MySQL.

Si solo subes los archivos, tu nuevo WordPress se verá en blanco o te pedirá instalar el blog desde cero. Cómo evitarlo: Antes de empezar, exporta siempre la base de datos desde phpMyAdmin o desde el panel de tu hosting actual (normalmente como archivo `.sql`). Sin ese archivo, tienes solo la mitad del trabajo hecho.

2. No reemplazar las URLs en la base de datos

WordPress almacena las URLs absolutas del sitio en la base de datos. Si tu web estaba en `midominio.com` y la mueves a `midominio.com/prueba` (para hacer la migración en un directorio temporal) o cambias el dominio por completo, las URLs internas quedarán obsoletas.

El síntoma típico: Accedes a la web nueva, pero los enlaces internos te redirigen al hosting antiguo o devuelven errores 404. Cómo evitarlo: Usa un plugin de migración (como All-in-One WP Migration o Duplicator) que haga este reemplazo automáticamente. Si lo haces manualmente, tendrás que ejecutar una consulta SQL de reemplazo masivo o usar un plugin como Better Search Replace. Olvidar este paso es la causa número uno de "la web se ve rota" tras una mudanza.

3. Dejar el hosting antiguo activo durante días (y que el SEO se resienta)

Es común mantener ambos hostings activos para "verificar" que todo funciona. El problema surge cuando no configuras la redirección adecuada. Si durante 48 horas Google ve tu web en dos servidores distintos con el mismo contenido, puede interpretarlo como contenido duplicado, lo que diluye la autoridad del dominio y degrada tu posicionamiento.

Cómo evitarlo: El cambio de DNS es el momento crítico. En lugar de esperar días, planifica un corte limpio: sube todo al hosting nuevo, verifica que funciona en local o con un archivo `hosts` temporal, y solo entonces apunta los DNS. Una vez propagados, cancela el hosting antiguo para evitar duplicidades.

4. Olvidar los correos electrónicos

Muchos planes de hosting incluyen cuentas de correo asociadas al dominio. Si solo migras la web y te olvidas de los buzones de email, tus clientes seguirán escribiéndote, pero tú no recibirás nada en el nuevo servidor.

Cómo evitarlo: Haz una lista de todas las cuentas de correo que tienes en el hosting actual (generalmente en cPanel o Plesk). Deberás recrearlas en el nuevo proveedor. Si te importa conservar los emails antiguos, necesitarás un método de copia (como un cliente de escritorio tipo Outlook o Thunderbird para descargarlos antes de cancelar el servicio). Es un paso tedioso, pero vital para no perder comunicaciones importantes.

5. No actualizar los DNS de los servicios de terceros

Si usas una CDN (como Cloudflare), un servicio de email transaccional (como SendGrid) o un sistema de caché externo, deberás actualizar la IP del servidor en estos paneles.

El error: Cambiar el hosting y olvidar actualizar Cloudflare. El resultado es que tu web sigue cargando desde la IP antigua (caída) o, peor aún, el certificado SSL no se emite correctamente. Cómo evitarlo: Una vez que tengas la IP pública del nuevo hosting, actualiza los registros A y CNAME en tu sistema DNS externo antes de propagar, no después.

6. Migrar sin copia de seguridad local

Mover un sitio web implica manipular miles de archivos. Un fallo de conexión FTP a mitad de camino, un servidor que se reinicia o un error humano pueden dejar una instalación incompleta. Si no tienes una copia local, estarás en un limbo técnico.

Cómo evitarlo: Antes de tocar nada, descarga una copia completa de la web en tu ordenador (archivos + base de datos). Esta copia es tu seguro de vida. Si algo sale mal, siempre puedes restaurar el estado original en el hosting antiguo y empezar de nuevo sin daños colaterales.

En resumen: La migración no falla por complejidad técnica, sino por no verificar el orden de las operaciones. Archivos primero, base de datos después, URLs ajustadas y DNS al final. Si controlas esos cuatro frentes, habrás evitado el 90% de los problemas habituales.

Preguntas frecuentes

Cambiar la URL de WordPress es uno de los errores más comunes al realizar una migración, y también uno de los que más dolores de cabeza genera. Si accedes a tu panel de administración después del cambio y ves errores de estilo (todo sin formato), imágenes rotas o enlaces que apuntan al dominio anterior, la causa suele ser que las rutas absolutas quedaron grabadas en la base de datos.

WordPress guarda la URL completa del sitio (como `https://miviejo-dominio.com/wp-content/uploads/2024/foto.jpg`) en las tablas `wp_options` (en los campos `siteurl` y `home`) y también dentro del contenido de las entradas y páginas. Si mueves el sitio a un nuevo dominio temporal o a una URL de pruebas, esos enlaces se rompen.

Para solucionarlo, tienes varias opciones. La más segura es usar el plugin Better Search Replace. Este plugin no solo reemplaza la URL en las opciones principales, sino que también recorre todas las tablas de la base de datos (como `wp_posts` y `wp_postmeta`) para actualizar cada referencia. El proceso es sencillo: introduces la URL antigua en el campo "Search for", la nueva en "Replace with", seleccionas todas las tablas y pulsas "Dry Run" primero para ver cuántas coincidencias hay. Si el resultado es correcto, ejecutas el cambio real.

Otra alternativa, si prefieres usar phpMyAdmin, es ejecutar una consulta SQL directa. Sin embargo, debes tener cuidado porque un reemplazo masivo en toda la base de datos puede alterar URLs dentro de código serializado de plugins (como widgets o menús), lo que podría corromper los datos. Por eso, siempre es recomendable usar un plugin especializado que maneje correctamente los datos serializados.

Si migras el sitio a un subdirectorio temporal (por ejemplo, `https://mihosting.com/miweb`) mientras apuntas el dominio, necesitarás además editar el archivo `.htaccess` (en Apache) o `wp-config.php` para forzar las constantes `WP_HOME` y `WP_SITEURL`. Esto evita que WordPress redirija automáticamente al dominio anterior.

Tras el reemplazo, verifica los enlaces internos, las imágenes de la galería y las rutas de los assets. Un buen truco es usar la consola de desarrollador del navegador (F12) para buscar errores 404 en la pestaña "Network" y confirmar que todas las solicitudes apuntan al nuevo dominio.

---

¿Cuánto tarda en propagarse el cambio de DNS si cambio los servidores de mi hosting?

La propagación de DNS no es un proceso instantáneo ni uniforme. Cuando cambias los nameservers de tu dominio hacia el nuevo hosting, la información viaja a través de una red jerárquica de servidores DNS alrededor del mundo. El tiempo de propagación suele oscilar entre 24 y 72 horas, aunque en muchos casos el cambio se completa en menos de 12 horas.

Lo que debes entender es que durante ese periodo, algunos visitantes (o tú mismo desde tu ISP) verán el sitio alojado en el servidor antiguo, mientras que otros verán la versión del nuevo servidor. Esto se debe a que tu proveedor de internet guarda en caché los registros DNS por un tiempo determinado (conocido como TTL, Time To Live). Si tu registro anterior tenía un TTL alto (por ejemplo, 24 horas), la propagación será más lenta.

Para acelerar el proceso, puedes reducir el TTL al mínimo (300 segundos) unas 24 horas antes de realizar la migración. Esto hará que los servidores intermedios actualicen la información más rápido. También puedes comprobar la propagación desde diferentes ubicaciones utilizando herramientas como Whatsmydns.net.

Mientras tanto, hay dos estrategias prácticas que puedes implementar para evitar la pérdida de tráfico:

Habilitar el modo de mantenimiento en el servidor antiguo después de que hayas lanzado el sitio en el nuevo. Coloca un archivo `.maintenance` en la raíz de la instalación antigua para que muestre un aviso breve a los usuarios que aún caigan en esa versión, indicando que el sitio se está moviendo.
Editar tu archivo hosts local (en tu ordenador) para forzar la resolución del dominio hacia la IP del nuevo servidor. Esto te permite trabajar y verificar el sitio en el nuevo hosting sin esperar la propagación. En Windows, el archivo `hosts` se encuentra en `C:\Windows\System32\drivers\etc`, y en macOS/Linux en `/etc/hosts`. Añade una línea como `123.456.789.10 midominio.com` (reemplaza la IP por la de tu nuevo servidor).

Finalmente, no realices cambios importantes en el sitio durante las 72 horas posteriores al cambio de DNS, ya que cualquier modificación en el servidor antiguo (como comentarios o pedidos) podría no transferirse al nuevo. Si la espera es inevitable, considera mantener la base de datos sincronizada (duplicándola diariamente) hasta que el DNS se asiente por completo.

---

¿Puedo mantener el correo en el hosting antiguo mientras muevo la web al nuevo?

Sí, y de hecho es una de las prácticas más recomendadas para reducir el riesgo de pérdida de correos durante una migración. El correo electrónico y el alojamiento web son servicios independientes aunque gestiones ambos desde el mismo proveedor. Cuando cambias los nombres de servidor (nameservers) de tu dominio, estás redirigiendo también los registros MX (Mail Exchange), que determinan a qué servidor debe entregarse el correo.

Si no estás preparado para migrar las cuentas de correo al mismo tiempo, tienes dos opciones:

Mover únicamente los registros A (web): En lugar de cambiar los nameservers completos, puedes editar solo el registro A que apunta a `www.midominio.com` y `midominio.com` para que señale a la IP del nuevo servidor. Mientras tanto, los registros MX seguirán apuntando al servidor de correo antiguo. Esta configuración se realiza desde el panel de DNS de tu registrador de dominios (donde compraste el dominio, como GoDaddy, Namecheap, etc.). Es una solución más quirúrgica que te permite mantener el correo funcionando sin interrupciones mientras lanzas la web nueva.

Configurar el reenvío de correos: Si tu nuevo hosting ya tiene gestionado el correo y necesitas hacer el cambio completo, puedes configurar una regla de reenvío en el servidor antiguo para que copie todos los mensajes entrantes a una cuenta temporal de Gmail o al nuevo servidor durante la transición. Esto te da un colchón de seguridad.

Antes de tomar cualquier decisión, revisa el panel de control de tu nuevo hosting (cPanel, Plesk o similar) y crea todas las cuentas de correo que tenías en el servidor antiguo. Exporta las libretas de direcciones y, si es posible, realiza una copia de seguridad de los buzones (IMAP) utilizando un cliente como Thunderbird o Outlook. Una vez que hayas verificado que el correo entrante y saliente funciona correctamente en el nuevo hosting (enviando mensajes de prueba), puedes cambiar los registros MX.

Un truco profesional: si tu dominio utiliza servicios externos de correo (como Google Workspace o Microsoft 365), los registros MX apuntan a esos servicios y no debes tocarlos durante la migración. Solo tienes que asegurarte de que el nuevo servidor tenga deshabilitado el servicio de correo local (o configurado con dominios distintos) para que no haya conflictos en el puerto 25.

Conclusión

Mudar un sitio WordPress entre hostings siempre parece una operación de alto riesgo, pero la realidad es que se reduce a un proceso mecánico de copiar y pegar archivos y bases de datos. Si has seguido los pasos de esta guía—exportar la base de datos, comprimir el directorio `public_html` y ajustar las URLs en el `wp-config.php` o la tabla `wp_options`—el mayor desafío no será la técnica, sino la verificación.

Antes de cancelar tu plan anterior, convive con el nuevo hosting durante al menos 48 horas. Navega por todas las categorías, envía un formulario de prueba y revisa los enlaces internos. La mayoría de los errores post-migración no aparecen en la portada, sino en páginas secundarias o en la carga de medios. Si algo falla, la causa más común no es la copia de archivos, sino una discrepancia en las rutas absolutas serializadas en la base de datos.

Como criterio práctico final: si no eres desarrollador, no edites las URLs a mano. Usa un plugin como *Better Search Replace* o una consulta SQL directa en phpMyAdmin para actualizar el dominio de forma segura. Esto evitará que el sitio se rompa o que pierdas la configuración de los widgets y menús. Con una copia de seguridad fresca y la paciencia para validar cada detalle, la migración se convierte en una tarea de mantenimiento rutinario.