Cambiar de proveedor web: qué revisar para conservar dominio y correo

Puedes cambiar de profesional sin cambiar de dominio

Cambiar de proveedor web sin perder el dominio es posible: renovar la página o contratar a otro diseñador no implica necesariamente cambiar su dirección ni trasladarla a otro registrador. Primero hay que identificar quién controla el dominio, dónde se gestiona el DNS y qué servicios dependen del contrato actual, especialmente el correo.

Si tu web se ha quedado antigua pero el negocio sigue usando su dominio y sus cuentas de correo, el encargo no debería empezar por «darlo todo de baja». Conviene separar lo que quieres renovar de lo que debe seguir funcionando. Esta guía propone una secuencia de preparación, revisión y comprobación; no garantiza cero interrupciones ni sustituye un plan técnico para tu caso.

Dominio, DNS, web y correo: cinco piezas distintas

Que un proveedor te facture todo junto no significa que todo sea el mismo servicio.

Puedes mantener el dominio y su registrador mientras cambias de alojamiento web. También puedes mantener el alojamiento y contratar a otra persona para trabajar sobre una web compatible. El correo puede estar en un proveedor independiente o incluido en el hosting: hay que comprobarlo, no deducirlo por el logotipo que aparece al abrir el buzón.

La FAQ de ICANN sobre transferencias distingue cambiar de alojamiento de cambiar de registrador. Transferir el registro solo debe plantearse si hay un motivo concreto; no es un requisito automático para rediseñar una web.

1. Confirma titularidad, accesos y fechas antes de contratar

Pide al proveedor actual que identifique al titular registrado del dominio y al registrador que lo gestiona, aunque haya un intermediario. Contrasta la información con el panel y la documentación contractual. Una factura ayuda a reconstruir la relación, pero no demuestra por sí sola quién figura como titular; tampoco debes inferirlo únicamente de un WHOIS o consulta pública con datos ocultos.

Comprueba quién puede administrar la cuenta, recibir avisos y recuperar el acceso. El negocio debería tener un control adecuado y documentado, con una vía de recuperación que no dependa exclusivamente de la persona que deja el proyecto. Si el titular no es quien esperabas, aclara la situación con el registrador antes de ordenar cambios: modificar titularidad y transferir registrador son trámites distintos.

Anota vencimiento, renovación automática, importe y responsable de pago del dominio, hosting, correo y licencias. Evita que una renovación pendiente quede sin atender durante el relevo. Revisa también el preaviso de baja, posibles costes de salida y qué se elimina al cancelar.

Para trabajar, prioriza invitaciones y permisos limitados cuando la herramienta los permita. No envíes contraseñas, códigos de transferencia ni códigos de doble factor por el chat de una consulta comercial; acuerda un canal seguro si llegan a ser necesarios.

¿Y si realmente quieres transferir el dominio?

Solicita al registrador el procedimiento de tu extensión y el estado concreto del dominio. La política de transferencias de ICANN regula transferencias entre registradores en su ámbito de dominios genéricos: puede haber bloqueos y requisitos de autorización. No conviertas las referencias a 60 días o a códigos AuthInfo/EPP en una regla universal para cualquier dominio.

Los .es tienen su procedimiento oficial de transferencia de Dominios.es: contempla un AuthCode y la intervención de la persona de contacto administrativo. No se debe aplicar por analogía todo el procedimiento de un .com a un .es. Para un .cat u otra extensión, verifica sus condiciones con el registro y el registrador correspondientes, sin asumir los mismos plazos. No hace falta iniciar esta transferencia si basta con mantener el registro actual.

2. Haz inventario y acuerda qué se puede llevar

Antes de sustituir nada, prepara una lista de servicios: web, subdominios, correo, formularios, reservas, tienda, herramientas externas, analítica y Search Console, si se utilizan. Señala quién los paga, quién los administra y si dependen del alojamiento que quieres cancelar. Incluye los envíos de correo de formularios o aplicaciones: no todo el correo del negocio sale del programa que usas a diario.

Pide una copia o exportación adecuada a la tecnología, con archivos y base de datos cuando corresponda. Aclara quién comprobará que es utilizable y qué queda fuera. Una copia dentro de la cuenta que vas a cancelar no es un respaldo independiente para el relevo.

Revisa por escrito la entrega y los derechos de uso de textos, fotografías, logotipo, diseño, código y materiales editables. No des por hecho que pagar una web transfiere cualquier licencia de tema, tipografía, fotografía o complemento. Pregunta qué puede seguir usándose y qué habrá que sustituir o contratar de nuevo. Son puntos para revisar en el contrato, no una conclusión jurídica sobre la propiedad de tu web.

En una plataforma cerrada, una exportación de contenido no equivale necesariamente a una web completa que pueda funcionar fuera. Por ejemplo, Wix explica que su sitio depende de su infraestructura y no admite alojamiento externo. Esto no determina las opciones de todas las plataformas: comprueba las de la tuya. Puede ser necesario reconstruir parte del sitio conservando el dominio y los materiales reutilizables.

3. Decide por separado qué ocurrirá con el correo

Pregunta primero: «¿Podemos mantener los buzones actuales aunque cambiemos la web?». Si el correo es independiente y se mantienen su contrato y la configuración necesaria, puede no hacer falta moverlo. Si viene incluido en el hosting anterior, confirma si se puede contratar por separado o si habrá que preparar otro destino antes de la baja.

Conservar una dirección de correo con tu dominio no significa conservar automáticamente todo lo demás. Si cambia el proveedor, deja definidos:

• Buzones, usuarios, capacidad y licencias que necesita cada persona.
• Mensajes antiguos, carpetas y enviados; también archivos guardados solo en un ordenador, si existen.
• Alias, reenvíos, buzones compartidos y reglas que se deban recrear.
• Contactos y calendarios, con su método de exportación e importación.
• Nuevos accesos, doble factor y configuración en móviles y programas de correo.
• Quién comprobará los datos trasladados y cómo se recogerán los mensajes que lleguen durante la transición.

Como ejemplo de límite, la documentación de Microsoft sobre migración de correo indica que su migración por IMAP no traslada contactos, calendarios ni tareas. No presupongas que una herramienta copiará todo ni que las credenciales antiguas seguirán siendo válidas en otro servicio.

El DNS puede afectar al correo aunque solo quieras cambiar la web

Cambiar servidores de nombres —nameservers— puede cambiar qué zona DNS se utiliza. Antes de hacerlo, hay que inventariar y preparar los registros necesarios para los servicios que continúan. Google Workspace documenta la necesidad de trasladar los registros al cambiar de alojamiento DNS.

No basta con decir «cambiamos un registro A» ni «dejamos los MX». Según la configuración, habrá que revisar A/AAAA o CNAME de la web, MX de recepción, registros de verificación y los relacionados con SPF, DKIM y DMARC, además de otras dependencias. Las directrices de remitentes de Gmail distinguen la autenticación del correo de otros requisitos de entrega. Tener MX no acredita que el envío esté autenticado ni garantiza que llegue a la bandeja de entrada.

El profesional responsable debe validar los valores concretos con cada proveedor, así como HTTPS y el certificado de la nueva web. No copies una configuración genérica: esta guía no proporciona valores DNS ni instrucciones para modificar infraestructura.

4. Revisa las URLs aunque conserves el dominio

Mantener el mismo dominio no garantiza conservar las posiciones en Google si cambian rutas, contenido o acceso a las páginas. Antes de renovar, pide un inventario de las URLs existentes, incluidos idiomas, páginas de servicios y descargas relevantes. Decide cuáles se conservan y qué destino equivalente tendrá cada una que cambie.

Google Search Central recomienda mapear las URLs y planificar redirecciones permanentes cuando cambian, preferiblemente del lado del servidor, como 301 o 308 cuando sea técnicamente posible. No conviene mandar todas las páginas antiguas a la portada: cada destino debe responder a la necesidad anterior. Si se retira contenido sin equivalente, hay que acordar la respuesta adecuada, no forzar una redirección irrelevante.

Pide revisar también enlaces internos, canonical, versiones por idioma, sitemap y posibles bloqueos de rastreo o indexación de la fase de preparación. Si el rediseño implica reorganizar servicios, la guía web de una página o varias ayuda a decidir la estructura; aquí lo importante es no borrar las direcciones anteriores sin un plan. Puede haber fluctuaciones en buscadores, y no existe un plazo universal para estabilizarlas.

5. Qué pedir a cada proveedor y cuándo retirar el servicio anterior

Al proveedor actual, solicita una entrega documentada:

• Identificación de registrador y titular, accesos disponibles y renovaciones pendientes.
• Inventario de DNS, web, correo y servicios asociados, sin publicar datos sensibles.
• Copias o exportaciones disponibles, sus límites y materiales con derechos de uso aclarados.
• Condiciones de salida: preaviso, coste y efecto de cada baja sobre los demás servicios.

Al nuevo profesional, pide respuestas antes de aceptar el presupuesto:

• ¿Qué mantendremos y qué cambiaremos? ¿Es necesario mover el correo o el registro del dominio?
• ¿Qué es compatible, qué hay que reconstruir y qué no se puede trasladar?
• ¿Quién coordina cada cambio, con qué calendario y con qué plan de recuperación si algo falla?
• ¿Qué comprobaciones y seguimiento incluye el encargo, y qué costes iniciales y recurrentes quedan fuera?

Acordad una transición en la que el servicio anterior siga disponible durante el periodo necesario para las comprobaciones y la posible recuperación. La duración depende de las dependencias y condiciones reales, no de una cifra fija de «propagación».

Antes de autorizar una baja, el responsable técnico y el negocio deberían confirmar:

1. La web correcta carga por HTTPS, con sus variantes de dominio previstas, idiomas, páginas y descargas.
2. Los enlaces, redirecciones y vías de contacto funcionan según el alcance acordado; las pruebas de formularios se hacen de forma controlada y autorizada.
3. El correo recibe y envía en las cuentas previstas, con revisión de autenticación y dispositivos; si se migró, se ha comprobado el histórico y los elementos acordados.
4. El negocio conserva accesos, recuperación de cuentas, documentación y copias utilizables.
5. Dominio, DNS, correo u otros servicios que deben continuar no se cancelarán junto con el hosting viejo.
6. Se ha validado el cierre del proceso y quién atiende incidencias; queda por escrito qué contrato se retira y cuál se mantiene.

Si una comprobación falla, no des por terminado el relevo ni elimines la vía de recuperación. Conserva lo necesario y resuelve la incidencia con los responsables antes de retirar el servicio del que todavía dependes.

Valora la renovación de tu web con GVGKODE

Nuestro servicio de diseño web para autónomos y pequeños negocios contempla renovar una web existente y revisar contenido y URLs antes de definir la estructura. La compatibilidad, las tareas de traslado y sus costes necesitan una valoración particular: no damos por incluida una migración de dominio, hosting o correo en el pack Web de 250 €.

Para consultar la renovación de tu web con GVGKODE, envíanos su dirección pública, qué quieres mejorar, la plataforma si la conoces y si utilizas correo con ese dominio. Indica qué proveedores tienes y qué accesos sabes que están disponibles, sin adjuntar contraseñas, tokens ni datos de clientes. Con esa información podremos valorar el alcance antes de confirmar una solución. El formulario abre WhatsApp: revisa el mensaje y envíalo allí para completar la consulta.