Cómo migrar WordPress a otro hosting sin perder SEO ni downtime

Un cambio de hosting puede ser invisible para Google y para tus usuarios… o convertirse en una semana de llamadas de “no carga la web”, formularios rotos y posiciones que se desploman justo cuando más las necesitas. La diferencia rara vez está en “el plugin de migración”, sino en el plan. Migrar WordPress a otro hosting es un proceso técnico, sí, pero sobre todo es gestión del riesgo: SEO, correo, cachés, DNS y tiempo de inactividad.

En VisualTec HOST llevamos desde 2003 moviendo webs en producción y, si algo se repite, es este patrón: cuando una migración sale mal, casi siempre se podía haber evitado con tres cosas sencillas. Un inventario mínimo, un entorno de destino bien preparado y un cambio de DNS hecho con cabeza. Nada de magia. Pura metodología.

En esta primera parte vamos a sentar las bases: qué se migra exactamente, dónde se rompen los rankings, cómo reducir a minutos el downtime (o dejarlo en cero percibido) y qué preparar antes de copiar un solo archivo. En la segunda parte entraremos con el “paso a paso” y la validación final.

Qué significa realmente migrar WordPress a otro hosting (y qué NO)

Migrar WordPress a otro hosting no es “subir una carpeta por FTP” ni “exportar una base de datos” por separado. WordPress funciona como un sistema: archivos, base de datos, configuración, capa de servidor (PHP, extensiones, límites), y un tercer actor que suele olvidarse: el DNS, que decide a qué servidor llega cada visita.

Piensa en tu web como un restaurante. Los archivos (themes, plugins, uploads) son la cocina y el almacén; la base de datos es el recetario; la configuración es el plan de sala; y el DNS es el cartel de la puerta con la dirección. Puedes tener la cocina perfecta, pero si el cartel apunta al local antiguo, los clientes seguirán llamando a la puerta equivocada.

Las piezas que se mueven en una migración bien hecha

• Archivos: núcleo de WordPress, wp-content (temas, plugins, uploads), mu-plugins si existen.
• Base de datos: contenidos, usuarios, ajustes, tablas de plugins. Suele ser lo más delicado por tamaño y tiempos.
• Configuración: wp-config.php (claves, prefijo de tablas, debug), reglas de .htaccess si aplica, tareas programadas.
• Entorno de servidor: versión de PHP compatible, límites de memoria, PHP-FPM/OPcache si están disponibles, módulos necesarios.
• Capa de red: DNS (A/AAAA/CNAME), TTL, y si hay CDN o proxy (tipo Cloudflare), su configuración.
• HTTPS: certificado SSL y redirecciones a https. Aquí se pierde SEO con facilidad si se deja a medias.

El objetivo profesional no es “que cargue”. Es más exigente: que la web cargue igual o mejor, que Google vea las mismas URLs devolviendo el mismo contenido, y que los usuarios no noten el cambio.

Por qué una migración puede hacerte perder SEO (aunque no cambies nada “visible”)

El SEO se rompe por detalles pequeños que, en conjunto, generan señales negativas: rastreo interrumpido, contenido duplicado temporal, cambios de canonical, tiempos de respuesta peores o errores intermitentes. En una migración, esos fallos aparecen justo cuando más bots están revisando tu sitio por el cambio de IP.

Google no penaliza una migración; penaliza la inconsistencia. Si durante horas (o días) una URL responde 200 en un servidor, 500 en otro, y a ratos redirige a http, la confianza cae. Lo mismo si de repente el servidor devuelve cabeceras raras o bloquea recursos por límites demasiado agresivos.

Los 7 “clásicos” que vemos cuando el SEO sufre tras cambiar de hosting

• Downtime real: el servidor antiguo ya no sirve la web y el nuevo aún no recibe el tráfico por DNS.
• Contenido mixto (mixed content): pasas a https, pero imágenes, CSS o JS siguen en http.
• Redirecciones mal planteadas: bucles, 302 temporales donde debería haber 301, o pérdida de la versión canónica.
• Robots no coherente: un robots.txt restrictivo por un “modo mantenimiento” que se queda activado.
• Bloqueo por firewall: reglas que frenan bots legítimos al cambiar el patrón de tráfico.
• Rendimiento peor: TTFB más alto, saturación de CPU o I/O; a la larga afecta a rastreo y experiencia.
• Errores de base de datos: tablas corruptas, collation distinta o importaciones truncadas por límites.

La buena noticia: todo lo anterior se puede anticipar. El orden de operaciones manda más que la herramienta que uses.

¿Qué necesitas antes de tocar nada? Un checklist que te ahorra horas

Una migración rápida no es la que se hace corriendo. Es la que se hace con la información correcta desde el minuto uno. Antes de copiar archivos, crea un “mapa” de tu WordPress actual. Te servirá para replicar el entorno en el destino, detectar dependencias y, si algo falla, volver atrás sin improvisar.

1) Inventario técnico mínimo (10 minutos que valen oro)

• Versión de WordPress y versión de PHP recomendada por tus plugins críticos.
• Plugins que tocan caché/seguridad: cachés, WAF, minificación, plugins de login, antispam.
• Reglas personalizadas en .htaccess o redirecciones en el panel del hosting.
• Tamaños: carpeta /uploads y tamaño de base de datos (orientativo). Esto te dice cuánto tardará la copia.
• Correo asociado al dominio: cuentas, forwarders, registros MX actuales. Muchas migraciones “rompen” el mail por olvido.
• Subdominios y micrositios: staging, landing, API, etc.

Si tu web genera ventas o leads, añade una lista de rutas de verificación rápida: home, categoría, ficha de producto, checkout, formulario de contacto y área privada. Es tu prueba de humo cuando el tráfico aterrice en el nuevo servidor.

2) Copia de seguridad “de verdad” (no solo la del plugin)

La copia de seguridad que necesitas para migrar tiene que permitirte reconstruir la web completa: archivos + base de datos, y preferiblemente sin depender de que WordPress funcione para restaurar. Si tu hosting incluye backups diarios automáticos, suma tranquilidad, pero para una migración conviene generar una copia manual justo antes del corte.

En VisualTec HOST, por ejemplo, los planes incorporan backups diarios y soporte 24/7/365 en español, pero aun así seguimos una regla interna: “dos copias y en dos sitios”. Una para ejecutar la migración y otra como red de seguridad por si el origen cambia mientras trabajas.

3) Baja el TTL del DNS antes del cambio (y evita la lotería de la propagación)

El TTL es el “tiempo de caché” que los resolvers guardan una respuesta DNS. Si lo tienes alto (por ejemplo, horas), el cambio de IP se vuelve impredecible: parte de tus usuarios irá al servidor antiguo mientras otros ya aterrizan en el nuevo. Eso complica el control del downtime y puede crear inconsistencia.

El enfoque profesional es simple: 24–48 horas antes, baja el TTL de los registros relevantes (A/AAAA y, si aplica, www) a un valor bajo. Luego, cuando hagas el cambio, la transición será más rápida y homogénea. Si no puedes tocar DNS en el proveedor actual, planifica una ventana con más margen.

Elegir destino: no todos los hostings se comportan igual con WordPress

Si el motivo de la migración es rendimiento, estabilidad o soporte, el destino no puede ser una caja negra. WordPress “perdona” muchas cosas en desarrollo, pero en producción castiga el servidor mal dimensionado: picos de CPU, discos lentos, límites agresivos o falta de aislamiento entre cuentas en entornos compartidos.

Un hosting orientado a WordPress debe darte un mínimo técnico: PHP optimizado, base de datos fiable, HTTPS sencillo, y una capa de seguridad que no convierta cada actualización en un susto. En VisualTec HOST lo enfocamos con infraestructura propia (servidores, red y sistema autónomo) alojada en el datacenter NLighten de Madrid (Tier III+), servidores Dell PowerEdge con Intel Xeon de última generación y almacenamiento full NVMe en RAID 10, porque el cuello de botella clásico en WordPress es I/O y latencia, no “falta de megas”.

Señales técnicas de que el nuevo hosting te va a simplificar la vida

• Aislamiento real entre cuentas: en entornos compartidos, tecnologías como CloudLinux ayudan a que el vecino no te arrastre en un pico.
• Panel de control claro: cPanel/WHM facilita restauraciones, bases de datos, SSL y tareas habituales sin fricción.
• Apache bien afinado: con una configuración optimizada y PHP bien integrado, WordPress funciona de forma muy consistente.
• Soporte con criterio: cuando algo falla durante la ventana de cambio, el “te respondo mañana” no vale.

Si estás buscando un entorno diseñado específicamente para este CMS, tiene sentido partir de un servicio especializado como Hosting WordPress optimizado, donde el stack y los límites se plantean pensando en WordPress, no en “cualquier cosa que subas”.

Downtime cero (o casi): la estrategia que usamos en migraciones profesionales

“Sin tiempo de inactividad” suele significar “sin caída perceptible”. En Internet siempre hay cachés, resolvers y sesiones activas. El objetivo realista es que, durante el cambio, como mucho haya un corto periodo donde algunos usuarios sigan en el servidor antiguo y otros entren al nuevo… pero sin que nadie vea una web rota.

La clave es separar dos planos: la preparación (todo lo que puedes hacer sin tocar DNS) y el corte (el momento en el que cambias la resolución del dominio). Si haces demasiadas cosas durante el corte, el riesgo se dispara. Si dejas el trabajo pesado hecho antes, el cambio se vuelve una formalidad.

Previsualiza el nuevo servidor sin cambiar el dominio (método “hosts”)

Una táctica de manual consiste en montar el WordPress en el servidor nuevo y probarlo apuntando tu ordenador a esa IP, sin tocar el DNS público. Se hace editando el archivo hosts del sistema. Así navegas por la web “como si” el dominio ya estuviera migrado, pero solo tú lo ves.

Esta prueba descubre fallos típicos antes del día D: enlaces absolutos a http, recursos bloqueados por permisos, errores de PHP por incompatibilidades o plugins que dependen de rutas específicas. Cuando todo está validado, el cambio DNS llega con la tensión mucho más baja.

Preparar el nuevo hosting: entorno limpio, SSL y base lista para recibir la web

Un destino bien preparado acelera el resto. Lo que buscas es un WordPress “aterrizable”: dominio añadido, certificado listo, base de datos creada y parámetros claros para importar. En hostings con cPanel, esta fase suele ser ágil: creas el dominio, preparas una base y decides si harás la copia por plugin, por asistente o de forma manual.

Si vas a usar SSL (y deberías), deja el HTTPS resuelto desde el inicio. En VisualTec HOST incluimos certificados SSL gratuitos (Let’s Encrypt) con renovación automática, lo que permite montar el entorno de pruebas en https desde el primer momento y detectar mixed content antes del corte definitivo.

En este punto todavía no hemos migrado datos: hemos construido la “pista de aterrizaje”. En la siguiente parte entraremos en la transferencia (archivos + base), los ajustes finos de wp-config, la verificación SEO (Search Console, sitemaps, canonicals) y el cambio de DNS con plan de vuelta atrás.

Métodos para migrar WordPress a otro hosting: plugin, manual o migración asistida

Hay tres formas habituales de mover un WordPress y, aunque todas “funcionan”, no todas sirven para el mismo escenario. La elección correcta no va de gustos: va de riesgo, de complejidad y de cuánto margen de maniobra necesitas si algo se tuerce. En más de dos décadas viendo migraciones, el patrón se repite: los proyectos sencillos se rompen por prisas, y los proyectos complejos se rompen por exceso de confianza. La buena noticia es que, si eliges el método con criterio, migrar WordPress a otro hosting puede ser un cambio prácticamente transparente para usuarios y para Google.

1) Migración con plugin: rápida, cómoda… y no siempre inocua

Los plugins de migración (copian archivos y base de datos, empaquetan y restauran) son ideales cuando tienes una web pequeña o media, sin dependencias raras y con un hosting origen que no te pone trabas. En la práctica, suelen ir bien en sitios con pocos plugins, sin multisitio, con una base de datos que cabe en un export “normal” y con recursos suficientes para descomprimir y reconstruir. ¿El punto débil? Precisamente lo que los hace cómodos: ejecutan tareas pesadas desde PHP, y eso implica límites de tiempo, memoria y tamaño de subida. Si tu WordPress pesa más de lo habitual (miles de imágenes, backups dentro de /wp-content, o un WooCommerce con tablas grandes), el plugin puede fallar a medias y dejarte un estado intermedio difícil de auditar.

2) Migración manual: control total, ideal para proyectos con exigencias SEO

La migración manual consiste en mover la base de datos y los archivos “de verdad” (sobre todo /wp-content), y después ajustar configuración y URLs. Es el método más robusto cuando te preocupa el SEO, porque te permite validar paso a paso: comprobar que el dominio apunta donde toca, que el HTTPS está limpio, que las redirecciones 301 son coherentes y que no estás arrastrando basura (cachés antiguas, copias duplicadas, directorios olvidados). A cambio, exige método: un export bien hecho, un import sin errores de collation, permisos correctos y un Search & Replace seguro (sin romper datos serializados). Si tu objetivo es cero sorpresas, este enfoque suele ser el más sensato.

3) Migración asistida: cuando el coste de un fallo es mayor que el coste de externalizar

Hay proyectos donde el “hazlo tú mismo” no compensa: ecommerce con campañas en marcha, webs con formularios críticos, membresías, academias, integraciones con ERPs o pasarelas de pago… Aquí una migración asistida marca la diferencia, porque se planifica el corte, se prueban rutas de rollback y se valida correo, SSL y cachés con checklist. Si además el proveedor destino incluye migración, reduces trabajo y, sobre todo, reduces incertidumbre. En VisualTec HOST, por ejemplo, la migración gratuita desde otros proveedores permite centrarte en el negocio mientras el equipo técnico ejecuta la parte delicada con procedimientos y comprobaciones. Si estás buscando un entorno pensado para WordPress, puedes ver los planes en /hosting-wordpress.

Criterios de elección (rápidos, pero realistas)

• Web pequeña, sin tienda, sin multilenguaje: plugin suele bastar (siempre con pruebas previas).
• Web con SEO sensible (muchas URLs indexadas, blog activo, enlaces entrantes): mejor manual o asistida para controlar canonicals, 301 y rastreo.
• Web pesada (muchos medios, base de datos grande): manual con export/import robusto; ideal si tienes acceso a herramientas o soporte técnico.
• Necesitas pruebas en “entorno espejo”: manual/asistida te permite validar con hosts file o URL temporal sin tocar DNS todavía.

Paso a paso (manual) para migrar WordPress a otro hosting sin improvisar

Este es el flujo que menos sustos da porque separa tareas y te permite verificar cada capa: datos, archivos, configuración y servidor. La clave es trabajar con una copia consistente: si tu web cambia cada minuto (pedidos, reservas, comentarios), programa una ventana de mantenimiento o pon el sitio en modo mantenimiento justo antes del volcado final para evitar desajustes entre base de datos y archivos.

1) Exporta la base de datos (y comprueba que el volcado termina bien)

La base de datos contiene el contenido, usuarios, ajustes, enlaces internos, slugs y, en general, el “cerebro” del WordPress. Puedes exportar desde phpMyAdmin (export rápido + formato SQL) o con herramientas de línea de comandos si el hosting lo permite. Si el export pesa mucho, conviene dividirlo o usar métodos que no dependan del navegador para evitar timeouts. Un detalle que suele olvidarse: revisa que el volcado no termina con un corte abrupto y que incluye todas las tablas (especialmente si tienes plugins que crean sus propias tablas, como eCommerce o cachés).

2) Copia los archivos: prioriza /wp-content y no arrastres basura

En una migración manual no necesitas copiar todo WordPress si vas a desplegar una instalación limpia en el destino; lo crítico es /wp-content (themes, plugins, uploads) y, si procede, archivos como .htaccess o robots.txt si los tienes personalizados. Aun así, antes de copiar conviene “sanear”: muchos sitios acumulan backups dentro de wp-content, directorios de caché gigantes o restos de plugins eliminados a medias. Eso alarga la migración y, peor, te llevas problemas que ya tenías sin saberlo. Copia por SFTP/FTP o, si tu plan lo permite, con herramientas más rápidas. En VisualTec HOST, el acceso SSH está disponible en planes Premium, lo que facilita operaciones más eficientes en proyectos grandes; puedes verlos en /hosting-premium.

3) Crea la base de datos en destino e importa

En el hosting nuevo crea una base de datos y un usuario con permisos, y después importa el SQL. Aquí aparecen los errores típicos: límites de tamaño, charset/collation incompatibles o importaciones que se quedan a medias. Si el import falla, no “parchees” encima: borra tablas incompletas y repite con un método más fiable. En entornos profesionales, un import limpio vale más que tres intentos con errores silenciosos.

4) Ajusta wp-config.php: credenciales, prefijo y claves

wp-config.php debe apuntar a la base de datos correcta. Cambia DB_NAME, DB_USER, DB_PASSWORD y DB_HOST según el destino. Si tu WordPress usa un prefijo distinto al estándar (por ejemplo, por seguridad o por legado), asegúrate de que $table_prefix coincide con el que has importado. Aprovecha para revisar claves y salts (AUTH_KEY, SECURE_AUTH_KEY, etc.) si quieres forzar cierre de sesión general tras el cambio, algo útil si sospechas de sesiones antiguas o si vienes de un hosting con incidentes.

5) Permisos y propietario: cuando “carga en blanco” no es un misterio

Los errores 403, el “white screen” o problemas al subir medios muchas veces vienen de permisos mal ajustados. Como norma general, directorios con permisos coherentes y archivos sin permisos excesivos. No se trata de memorizar un número mágico, sino de mantener el principio mínimo: escritura solo donde toca (uploads, cachés si existen) y lectura donde debe. Si tras la migración la librería de medios no permite subir, revisa el directorio uploads y la configuración de PHP para tamaños máximos, pero empieza por lo básico: permisos y rutas.

URLs, HTTPS y SEO: el punto donde se ganan (o se pierden) posiciones

El SEO no se rompe porque cambies de servidor; se rompe porque cambias señales sin querer: versión canónica, protocolo, slash final, www/no-www, reglas de redirección, o contenido mixto que “ensucia” la experiencia. Por eso, antes de tocar DNS conviene decidir cuál es la URL final exacta (por ejemplo, https://tudominio.com) y asegurar que todo el sitio converge a ella con redirecciones consistentes. Google tolera cambios, pero penaliza incoherencias persistentes: cadenas de redirecciones, canonicals contradictorios o páginas que alternan HTTP y HTTPS.

Search & Replace seguro: cambia el dominio sin romper datos serializados

Si cambias de dominio, de subdominio o de http a https, tendrás que actualizar URLs dentro de la base de datos. Aquí no vale un “buscar y reemplazar” a lo bruto, porque WordPress y muchos plugins guardan estructuras serializadas; si rompes el conteo interno, aparecen fallos extraños: widgets que desaparecen, constructores visuales que pierden configuración o páginas que muestran módulos en blanco. Usa herramientas que entiendan serialización (desde plugins específicos hasta utilidades con control de serializados). Y antes de ejecutar el reemplazo final, haz una copia del SQL original: volver atrás debe ser posible en minutos, no en horas.

Mixed content: el enemigo silencioso del candado verde

El contenido mixto ocurre cuando tu web carga por HTTPS, pero incluye recursos por HTTP (imágenes, scripts, fuentes). El navegador lo bloquea o lo marca como inseguro, y eso impacta en confianza, conversiones y, a veces, en rendimiento. Tras migrar, revisa plantillas y constructores que incrustan URLs absolutas, y pasa un rastreo rápido: páginas clave, home, categorías, producto/servicio y formularios. Si necesitas emitir o gestionar certificados, recuerda que un SSL bien configurado es parte del SEO técnico: puedes ampliar información en /ssl.

Canonicals y ajustes de WordPress: revisa “Ajustes > Generales”

WordPress define la “Dirección de WordPress (URL)” y la “Dirección del sitio (URL)”. Después de la migración, asegúrate de que ambas reflejan la URL final (con https y con la variante www o sin www que hayas decidido). A partir de ahí, valida canonicals en páginas relevantes: si tu SEO depende de una estructura muy concreta (por ejemplo, sin /category/ o con slugs específicos), comprueba que el plugin SEO y tu .htaccess no han heredado reglas del servidor antiguo que ahora se comportan distinto.

Redirecciones 301 en Apache: menos reglas, pero bien pensadas

En Apache, la gestión típica de redirecciones vive en .htaccess. Si estás unificando http→https o www→no-www, evita hacer dos redirecciones separadas que creen una cadena. Lo ideal es una única regla que lleve cualquier variante a la URL canónica final. Y si además hay cambio de dominio, mapea patrones de URL con 301 manteniendo el path (por ejemplo, /blog/entrada → /blog/entrada) siempre que la estructura sea la misma. Tras aplicar redirecciones, prueba con páginas profundas (no solo la home) y verifica que no aparecen 302 accidentales.

Cambio de DNS y ventana de corte: cómo hacerlo con red de seguridad

El momento del DNS es donde se suele improvisar… y donde más se nota la experiencia. La estrategia profesional se parece más a un despliegue controlado que a “cambio los registros y a ver qué pasa”. Hay tres conceptos que conviene interiorizar: propagación (no es instantánea), caché (en tu equipo y en redes intermedias) y rollback (volver al origen si aparece un problema crítico).

Pruebas antes de apuntar el dominio: ver el sitio en el servidor nuevo

Antes de modificar el DNS, prueba el WordPress en destino. Puedes hacerlo de varias formas (según tu entorno): acceso por URL temporal, ajustes en el archivo hosts para forzar la resolución del dominio hacia la IP nueva solo en tu equipo, o un subdominio de pruebas si lo tienes. El objetivo es claro: navegar, loguearte, probar formularios, revisar imágenes y comprobar que el panel funciona. Si algo falla aquí, estás a tiempo de corregir sin que el usuario final lo vea.

Plan de corte y rollback: decide el “punto de no retorno”

Para minimizar pérdidas de datos, justo antes del cambio definitivo conviene congelar cambios (modo mantenimiento) y ejecutar un último volcado “final” de base de datos si tu sitio ha seguido recibiendo actividad desde el primer export. En ese punto defines tu plan de vuelta atrás: si tras el cambio ves errores graves (checkout roto, login imposible, 500 persistentes), ¿puedes volver a apuntar al hosting antiguo y dejarlo operativo? La respuesta debe ser “sí” durante una ventana razonable. Ese margen es tu seguro: te permite arreglar con calma sin incendiar soporte ni redes sociales.

Cachés, CDN y DNS: el triángulo de las confusiones

Tras el cambio, aparecen los síntomas típicos: “yo lo veo bien” y “a mí me sale la web antigua”. Esto casi siempre es caché (navegador, plugin de caché, CDN o DNS local). Purga la caché del plugin, limpia cachés a nivel CDN si lo usas y prueba desde una red distinta (datos móviles, por ejemplo). Si hay una CDN delante, revisa que el origen (origin) apunte al servidor correcto y que el SSL del proxy no esté en modo incompatible con tu configuración. Y, por supuesto, vigila el correo: si tu dominio también gestiona email, el DNS no es solo A/AAAA; los registros MX y SPF/DKIM/DMARC deben mantenerse coherentes con tu proveedor de correo.

Checklist post-migración: lo que revisamos cuando no queremos sorpresas a los 3 días

Cuando la web “carga”, la migración no ha terminado. Ha empezado la fase de verificación, que es la que protege tu SEO y tu operativa. Aquí tienes un checklist práctico, basado en incidencias reales: las que no se ven a simple vista, pero aparecen cuando el tráfico vuelve a la normalidad o cuando Google rastrea de nuevo.

Rendimiento y estabilidad

• Comprueba TTFB y carga de páginas clave (home, categorías, producto/servicio, contacto).
• Revisa que OPcache y PHP-FPM (si aplica) están funcionando de forma estable y que no hay errores recurrentes.
• Valida que las imágenes se sirven correctamente y que no hay 404 en recursos estáticos.

Logs y errores: donde se esconde el SEO técnico

• Revisa el error log: warnings de PHP repetidos, “headers already sent”, timeouts y errores 500.
• Escanea 404: enlaces internos rotos, recursos de tema, endpoints de APIs de plugins.
• Comprueba robots.txt y sitemap: accesibles, actualizados y sin bloquear secciones críticas.

Formularios, ecommerce y correos transaccionales

• Prueba formulario de contacto (envío y recepción).
• Si hay tienda: flujo completo (carrito, checkout, emails de pedido, webhooks de pago).
• Verifica que el remitente y el dominio están alineados para evitar bandejas de spam (SPF/DKIM/DMARC si gestionas correo propio).

Search Console y monitorización

• En Search Console, revisa cobertura e indexación en los días siguientes: picos de 404 o soft-404, problemas de HTTPS, páginas duplicadas.
• Monitoriza uptime y tiempos de respuesta: detectar microcortes tempranos evita pérdidas de rastreo.
• Si cambias de dominio, gestiona correctamente el cambio de dirección y las propiedades (según el caso).

Hardening básico tras el cambio (sin obsesionarse, pero con criterio)

Una migración es un buen momento para cerrar puertas: elimina usuarios que ya no se usan, actualiza plugins y tema, revisa permisos y desactiva lo que no necesitas. Si no utilizas XML-RPC, valora deshabilitarlo; reduce superficie de ataque y ruido en logs. Y confirma que tienes backups automáticos verificables. En VisualTec HOST, por ejemplo, hay backups diarios automáticos incluidos, lo que te da una red de seguridad real si tras la migración aparece un fallo lógico (no un fallo “de servidor”, sino un ajuste mal aplicado).

Conclusiones: una migración limpia no es magia, es método (y el hosting influye)

El mejor consejo para migrar WordPress a otro hosting sin perder SEO ni tiempo de inactividad es tratar el proceso como un cambio controlado: preparar, clonar, probar, cortar y verificar. Los plugins ayudan, pero no sustituyen la planificación; la migración manual da control, pero exige disciplina; y la migración asistida reduce carga mental cuando el proyecto no puede permitirse ni un día de incertidumbre.

También hay una realidad que muchos descubren tarde: el servidor destino condiciona el resultado. Un WordPress bien migrado necesita una base sólida: rendimiento de disco para consultas y cachés, aislamiento de recursos para que un vecino no te afecte, soporte que responda cuando el problema aparece fuera de horario, y un entorno coherente para SSL, DNS y Apache. En VisualTec HOST llevamos desde 2003 operando infraestructura propia (servidores, red y sistema autónomo) en el datacenter NLighten de Madrid (Tier III+), con servidores Dell PowerEdge, almacenamiento full NVMe en RAID 10, CloudLinux para aislamiento y soporte 24/7/365 en español.

Si estás planificando el cambio y quieres un WordPress optimizado, con SSL gratuito (Let’s Encrypt), backups diarios y migración incluida, tienes los planes específicos en /hosting-wordpress. Y si prefieres delegar el mantenimiento y las tareas recurrentes (actualizaciones, revisiones, seguridad y rendimiento) para que una migración no sea “otro frente”, puedes apoyarte en /mantenimiento-web.

Preguntas Frecuentes

¿Cómo migrar WordPress a otro hosting sin perder SEO paso a paso?

Migrar WordPress a otro hosting sin perder SEO es copiar archivos y base de datos manteniendo las mismas URLs, activando HTTPS correctamente y cambiando el DNS con un TTL bajo y pruebas previas. La clave es evitar respuestas inconsistentes (errores, redirecciones raras) durante la transición.

El proceso fiable incluye: preparar el destino, probar por archivo hosts, migrar datos, validar canonicals/sitemap/robots y solo entonces cambiar DNS. Tras el cambio, revisa Search Console, rastreo y errores 404 para corregir rápido cualquier desviación.

¿Cuánto tiempo se tarda en migrar WordPress a otro hosting sin downtime?

Migrar WordPress a otro hosting sin downtime perceptible puede hacerse en una ventana corta si el destino está preparado y el TTL del DNS se ha bajado con antelación. La copia de archivos y base de datos es lo que más tiempo consume; el cambio DNS debería ser el paso final.

En webs pequeñas, la transferencia suele ser rápida; en proyectos con muchos uploads o bases grandes, conviene planificar por fases y congelar cambios antes del corte. Probar el sitio en el nuevo servidor antes de tocar DNS reduce el tiempo crítico.

¿Qué es el TTL del DNS y por qué afecta al migrar WordPress a otro hosting?

El TTL del DNS es el tiempo que servidores intermedios guardan en caché la IP asociada a tu dominio, y afecta a la migración porque determina cuánto tardan los usuarios en “ver” el nuevo hosting. Un TTL alto hace que parte del tráfico siga yendo al servidor antiguo durante más tiempo.

Bajar el TTL 24–48 horas antes del cambio acelera la propagación efectiva y reduce escenarios de “mitad de usuarios en un sitio, mitad en otro”. Eso ayuda a evitar inconsistencias que pueden afectar al rastreo y a la experiencia de usuario.

¿Qué plugin es mejor para migrar WordPress a otro hosting con cPanel?

El mejor plugin para migrar WordPress a otro hosting con cPanel es el que maneja bien tu tamaño de web, tus límites de servidor y la restauración completa, porque no hay un único ganador para todos los casos. Si tu web es grande, la migración manual o asistida suele ser más estable que una exportación empaquetada.

Los plugins funcionan bien en sitios medianos, pero pueden fallar por timeouts, límites de subida o bases de datos pesadas. Con cPanel puedes preparar base de datos y archivos para una restauración más controlada si el plugin se queda corto.

¿Qué hay que revisar después de migrar WordPress a otro hosting para no perder tráfico?

Después de migrar WordPress a otro hosting, revisa que todas las URLs clave devuelvan 200, que HTTPS esté bien redirigido, que no haya mixed content, que el robots.txt no bloquee y que el sitemap sea accesible. También conviene comprobar 404, rendimiento y logs durante los primeros días.

En proyectos con SEO trabajado, valida canonicals, datos estructurados y la configuración de caché. En Search Console, vigila cobertura e incidencias de rastreo; en analítica, compara tráfico orgánico y landing pages para detectar caídas puntuales y corregirlas rápido.