Puedes cambiar de hosting y conservar el dominio. El alojamiento guarda y sirve la web; el dominio es la dirección que utiliza el visitante. Para hacer el traslado, prepara una copia funcional en el destino, pruébala y modifica los registros DNS necesarios cuando estés listo.
La portada carga en el nuevo servidor, pero falta comprobar el formulario que recibe las solicitudes, el correo y los datos creados durante el traslado. Una migración de hosting se acepta revisando esas funciones, no solo mirando el diseño.
El riesgo SEO no está en el hecho de cambiar de proveedor, sino en que el traslado provoque errores, bloqueos, contenido incompleto o cambios involuntarios de URLs. Si las direcciones se mantienen, no necesitas convertir el proyecto en una migración de dominio.
Qué debes identificar antes de contratar el destino
Anota dónde se administra el dominio, quién gestiona DNS, dónde viven los buzones y qué sistemas envían correos. Es frecuente que estos servicios estén en proveedores diferentes. No asumas que mover la web también mueve el correo o que una copia de archivos incluye la base de datos.
Revisa requisitos del sitio: versión del lenguaje, extensiones, base de datos, almacenamiento, tareas programadas y conexiones externas. Solicita al proveedor de destino confirmación de compatibilidad. Un plan con más recursos no corrige por sí mismo una aplicación mal configurada.
Haz un respaldo y documenta cómo recuperarlo
Guarda archivos y base de datos cuando corresponda, además de la configuración necesaria para reconstruir el sitio. Conserva el respaldo fuera del servidor que vas a sustituir. Comprueba que el archivo se abre y que la base de datos contiene las tablas esperadas.
Define un punto de retorno: quién puede restaurar, qué copia usaría y qué datos nuevos habría que conciliar. En una web informativa el riesgo de cambios simultáneos puede ser pequeño; en una tienda, cada pedido creado durante el traslado importa.
Prueba la copia sin dirigir todavía todo el tráfico
Utiliza el mecanismo de vista previa que ofrezca el alojamiento o una resolución local controlada para probar el dominio contra el nuevo servidor. Evita hacer pública una copia indexable del sitio. Si empleas una dirección temporal, recuerda que algunas funciones dependen del dominio definitivo.
| Prueba | Qué validar |
|---|---|
| Portada y plantillas | Contenido, estilos, imágenes y navegación. |
| Formularios | Recepción y registro de una prueba identificable. |
| Compra o reservas | Flujo completo según el modo de prueba disponible. |
| URLs antiguas | Mismas rutas y respuestas esperadas. |
| Servicios externos | Conexiones con CRM, logística o sistemas de pago. |
| SEO técnico | Directivas, canonical, sitemap y enlaces internos. |
Prueba tanto con sesión como sin ella. Si la copia carga pero no envía formularios, todavía hay trabajo pendiente. Revisa registros de errores antes de atribuir un fallo al DNS.
Planifica el cambio de DNS sin romper el correo
Determina qué registros necesitan cambiar. Modificar el destino de la web no requiere necesariamente sustituir todos los servidores de nombres. Si vas a cambiar la zona DNS completa, reproduce primero los registros que siguen siendo necesarios, incluidos los de correo y verificaciones.
El TTL influye en cuánto pueden conservar una respuesta los resolutores. Ajustarlo con antelación puede ayudar a organizar la transición, pero no garantiza que todos los usuarios cambien de servidor al mismo segundo. Mantén ambos entornos preparados durante el periodo de coexistencia.
La documentación de Google para traslados de alojamiento recomienda preparar y probar la nueva infraestructura antes del cambio y vigilar el tráfico que sigue llegando al origen. Usa esa secuencia como marco, adaptada a tu proveedor.
Controla los datos que cambian durante el traslado
Una copia tomada el lunes puede estar desactualizada al lanzar el martes. Define una pausa de edición o una sincronización final para publicaciones, formularios y pedidos. En una tienda, evita dejar dos sistemas aceptando operaciones que después no puedas reconciliar.
Antes del corte, registra el último pedido y la hora de la exportación final. Después revisa las operaciones de la ventana de transición. Esto permite detectar faltantes o duplicados con un criterio concreto, en lugar de confiar solo en que «la web funciona».
Qué revisar después de cambiar el alojamiento
Comprueba la resolución del dominio, HTTPS, las páginas críticas y una transacción de prueba permitida. Confirma que no quedó una protección del entorno de desarrollo bloqueando usuarios o buscadores. Verifica que se mantuvieron las URLs, las reglas de redirección previas y las etiquetas de medición.
Si una página deja de verse en resultados tras el traslado, separa el estado de rastreo e indexación con nuestra guía de diagnóstico de visibilidad.
Observa errores del servidor y rendimiento con una muestra comparable. Si la nueva infraestructura responde peor en una plantilla, investiga caché, consultas y recursos. Para trabajar el rendimiento de forma específica, consulta la guía de WPO y Core Web Vitals.
Un escenario frecuente: la web se mueve, pero el correo vive en otro lugar
Imagina que tu dominio está registrado con un proveedor, la web funciona en otro y el correo corporativo utiliza un tercero. El nuevo hosting te entrega servidores de nombres y alguien propone reemplazarlos inmediatamente. Antes de hacerlo, necesitas saber qué contiene la zona actual y qué servicios dependen de ella.
Prepara un inventario legible de registros y su función. Identifica los que sirven la web, los que intervienen en correo y los que verifican servicios. Guarda una copia con fecha. No hace falta mostrar secretos al equipo editorial; sí hace falta que el responsable técnico sepa qué debe conservar y por qué.
Si solo cambia el destino web, puede bastar con modificar los registros correspondientes. Si cambias quién administra toda la zona, prepara la nueva configuración antes del corte. En ambos casos, prueba envío y recepción de correo con el equipo cuando la transición termine.
Este ejemplo explica por qué «migración incluida» necesita un alcance escrito. Algunos servicios trasladan archivos y base de datos; otros también revisan DNS y correo. Pregunta qué se verifica, qué necesita intervención de terceros y qué evidencia recibirás al finalizar.
Qué contiene una copia útil de WordPress
Una web WordPress combina archivos y base de datos, además de dependencias externas. Conservar solo la carpeta de imágenes no preserva publicaciones, configuraciones o relaciones. Conservar solo la base de datos tampoco garantiza que dispongas de los temas y recursos necesarios para reconstruirla.
Documenta qué se respaldó y cómo se recuperaría. Registra versiones relevantes, ubicación de recursos y configuración que no deba circular en texto abierto. Guarda credenciales mediante el mecanismo seguro acordado, sin copiarlas a informes ni chats de coordinación.
Prueba la restauración en el entorno de destino o en un entorno controlado. El objetivo es comprobar que el respaldo permite reconstruir una aplicación funcional, no únicamente que el archivo comprimido existe. Si falta una dependencia, es mejor descubrirla antes de cambiar el tráfico.
Incluye una comprobación de permisos de archivos y tareas necesarias para la operación. Una web puede cargar la portada y fallar al subir medios, generar documentos o ejecutar procesos de fondo. Selecciona las pruebas según lo que realmente hace tu sitio.
Cómo ensayar sin alterar lo que ven los clientes
Solicita al equipo técnico una vista previa controlada del servidor de destino. Debe permitir comprobar la aplicación con el contexto adecuado del dominio y mantener la copia fuera del acceso público no previsto. Documenta las limitaciones del método de prueba que utilices.
Durante el ensayo, recorre una lista de URLs por plantilla. Abre la portada, una página larga, un formulario y una ruta que históricamente redirigía. Si tienes idiomas o subdominios, incorpóralos. Revisa también archivos descargables y recursos que el usuario necesita para completar una acción.
Comprueba las funciones de escritura por separado: crear un registro de prueba, recibirlo en el sistema esperado y verificar que no genera comunicaciones equivocadas. Identifica los datos de prueba para limpiarlos después mediante el procedimiento autorizado. Una prueba sin trazabilidad puede confundirse con una solicitud real.
Guarda los resultados del ensayo y resuelve primero los bloqueos. No aceptes como validación una captura de la portada. El sitio debe realizar sus funciones críticas en el destino y el equipo debe conocer las excepciones todavía pendientes.
El problema de los pedidos creados mientras cambia el tráfico
En una tienda, el tiempo entre la primera copia y el corte puede producir nuevos pedidos, cambios de stock y cuentas de clientes. Si importas únicamente la copia inicial, esos cambios no aparecerán en el destino. El plan necesita una regla explícita para conciliarlos.
Una opción operativa puede ser una ventana acordada de pausa y sincronización final; otra puede requerir un mecanismo de sincronización más complejo. La elección depende de la plataforma y del negocio. Lo importante es evitar que dos bases de datos acepten cambios independientes sin saber después cuál es la fuente válida.
Anota la hora del último respaldo y los registros que delimitan el corte. Después compara las operaciones de la ventana de transición. Incluye modificaciones de pedidos existentes, no solo pedidos nuevos, si el negocio puede editarlos durante ese periodo.
Si aparece un incidente y necesitas volver al origen, conserva primero los cambios hechos en el destino. Una reversión de infraestructura no revierte automáticamente el tiempo. El procedimiento de retorno debe explicar qué ocurre con los datos creados durante la prueba pública.
Qué incidencias vigilar durante la primera jornada
Organiza una revisión por funciones: acceso, formularios, correo, compra, integraciones y medición. Asigna a una persona la coordinación para evitar que varias cambien la misma configuración a la vez. Cada incidencia debe incluir URL, hora, pasos y resultado esperado.
Si algunos usuarios llegan al origen y otros al destino, considera la coexistencia de respuestas DNS dentro del diagnóstico. Si todos llegan al destino pero una sección falla, investiga la aplicación, rutas o recursos. Esta distinción evita cambiar DNS repetidamente para intentar resolver un problema de código.
Revisa registros del servidor y compara con la experiencia real. Un error aislado de un robot no tiene la misma urgencia que un fallo repetido de compra. Prioriza por impacto y repetición, dejando constancia de qué se corrigió y cómo se comprobó.
Cierra el traslado con una entrega breve: proveedor actual, responsables, sistema de copias, dependencias conservadas y decisiones pendientes. Ese documento será útil cuando haya una renovación, una incidencia o un nuevo cambio de equipo.
Cuándo cerrar el hosting anterior
No lo canceles solo porque tu equipo ve la nueva portada. Confirma que el tráfico ya llega al destino, que no quedan datos exclusivos en el origen y que correo, tareas e integraciones no dependen de él. Conserva las copias acordadas con acceso restringido.
Si también cambia el dominio o la estructura de las rutas, añade un plan específico de redirecciones y seguimiento. El proyecto deja de ser un simple traslado de infraestructura. Documentar esta diferencia desde el inicio evita presupuestos incompletos y sorpresas durante el lanzamiento.
Si el sitio recibe pedidos, formularios o correo en el mismo dominio, planifica el traslado con nuestro equipo a partir de una copia probada y un plan de conciliación.
Fuentes y documentación consultada
Documentación consultada el 27 de septiembre de 2026.
Preguntas frecuentes sobre el cambio de hosting
¿Cambiar hosting cambia mi dominio?
No necesariamente. Puedes conservar el dominio y apuntar la web a otro servidor mediante su configuración DNS.
¿Tengo que transferir el dominio al nuevo proveedor?
No es obligatorio para trasladar el alojamiento. La transferencia del registro del dominio es una decisión separada.
¿Se pierde el correo al mover la web?
Puede afectarse si modificas registros o cancelas servicios de los que depende. Identifica dónde funciona el correo y conserva su configuración.
¿Debo usar Cambio de dirección en Search Console?
Un traslado de hosting que mantiene las mismas URLs no es un cambio de dominio. No utilices esa herramienta como sustituto del control de infraestructura.
