Qué comprobar después de cambiar de hosting: correo, SSL, redirecciones y formularios

Comprueba con el verificador de propagación de DNS que el dominio y www resuelven a la nueva IP desde resolvedores públicos de todo el mundo, y con ¿Mi dominio ya apunta al nuevo servidor? que el sitio responde realmente allí. Un registro AAAA (IPv6) antiguo es el resto clásico: los visitantes con IPv6 siguen llegando al hosting anterior y ven contenido desactualizado.

Si moviste los DNS a otro proveedor, compara la zona anterior y la nueva con el comparador de DNS. Un registro TXT o CNAME que falta rompe cosas sin avisar: la verificación del dominio para Google o Microsoft, la firma del correo o un subdominio que usa un servicio de terceros.

Muchos hostings emiten el certificado solo cuando el dominio ya apunta a ellos, así que revísalo cuando se hayan movido los DNS. El verificador de SSL muestra el emisor, la fecha de expiración, los nombres que cubre el certificado y si los navegadores confían en la cadena. Asegúrate de que cubre tanto example.com como www.example.com, y cualquier otro nombre de host que sirvas.

Si probaste con un enlace de vista previa de DNSPeek en modo Omitir verificación, cámbialo a Verificar después de la mudanza: la vista previa fallará entonces ante cualquier error de certificado, lo que sirve de confirmación rápida. Consulta modos SSL.

La configuración del servidor no siempre viaja con los archivos. Las reglas de .htaccess no funcionan en nginx, y un hosting nuevo puede gestionar www de otra forma. Pasa el verificador de redirecciones por tu dominio: http:// debería llegar a la página https:// final en uno o dos saltos, con redirecciones permanentes (301 o 308) y sin bucles.

Después ejecuta la comprobación de cabeceras de seguridad. HSTS, Content-Security-Policy y cabeceras similares las define el servidor o la CDN y es fácil perderlas en una mudanza. Compara la nota con la que tenías antes.

El correo es donde las mudanzas fallan con más discreción: el sitio web se ve bien y nadie nota durante días que el correo rebota o acaba en spam.

Después haz una prueba real: escribe a un buzón del dominio desde una dirección externa y responde. Si el correo estaba alojado en el servidor anterior, comprueba que se copiaron los mensajes recibidos durante el cambio.

Los formularios de contacto, los restablecimientos de contraseña y las confirmaciones de pedido suelen enviar correo desde el propio servidor web. En un servidor nuevo, mail() de PHP puede estar desactivado, el puerto 25 puede estar bloqueado (habitual en VPS en la nube) o la nueva IP puede no figurar en el SPF. Envía todos los formularios y provoca un restablecimiento de contraseña. Si los mensajes no llegan, envía a través de un servicio SMTP autenticado en lugar del correo local del servidor.

• Tareas cron y tareas programadas: copias de seguridad, feeds, precarga de caché y colas de boletines. Recréalas en el servidor nuevo y comprueba que el anterior ya no las ejecuta, o se ejecutarán dos veces.
• Listas de IP permitidas: pasarelas de pago, API, firewalls y bases de datos remotas que solo aceptan la IP del servidor anterior.
• Webhooks: los servicios que llaman a tu sitio, como los proveedores de pago, siguen funcionando a través de los DNS, pero revisa sus registros de entrega por si hubo errores en torno al cambio.
• Permisos de archivos y subidas: sube una imagen o un archivo a través del CMS.
• Caché: vacía las cachés de página y de la CDN para que los visitantes no reciban páginas generadas en el servidor anterior.

Un ajuste de staging que se haya arrastrado puede ocultar todo el sitio a los buscadores. Busca una metaetiqueta robots noindex o una cabecera X-Robots-Tag, un robots.txt que lo bloquee todo y URL canónicas que apunten a un host temporal. Comprueba que la etiqueta de analítica sigue registrando datos y que el sitemap es accesible. Un informe de QA de DNSPeek señala estos restos que afectan a los buscadores, junto con páginas rotas, archivos que faltan y contenido mixto.

Si probaste el servidor nuevo con un enlace de vista previa de DNSPeek antes del cambio, activa sus alertas de propagación de DNS (planes de pago). Cuando el dominio se haya propagado, DNSPeek vuelve a ejecutar el informe de QA en el dominio en producción y lo compara con el último informe anterior al cambio: páginas que se rompieron, que redirigen a otro sitio o que perdieron su título. Consulta Después del cambio de DNS.

1. 1

   Paso 1: Confirma que los DNS se han movido

   Comprueba el dominio y www desde resolvedores públicos y confirma que el sitio responde desde la nueva IP.

2. 2

   Paso 2: Verifica el certificado

   Revisa el emisor, la expiración y los nombres de host cubiertos con el verificador de SSL.

3. 3

   Paso 3: Prueba las redirecciones y las cabeceras

   Sigue http:// hasta la página final con el verificador de redirecciones y compara las cabeceras de seguridad con la configuración anterior.

4. 4

   Paso 4: Revisa los registros de correo y envía una prueba

   Consulta MX, SPF y DMARC, confirma DKIM en tu proveedor de correo y luego envía y recibe un mensaje de prueba.

5. 5

   Paso 5: Envía todos los formularios

   Envía cada formulario de contacto y un restablecimiento de contraseña, y confirma que los correos llegan y no se marcan como spam.

6. 6

   Paso 6: Revisa las tareas programadas y las integraciones

   Recrea las tareas cron, actualiza las listas de IP permitidas, revisa los registros de los webhooks y vacía las cachés.

7. 7

   Paso 7: Revisa los ajustes de búsqueda y conserva un tiempo el hosting anterior

   Quita las reglas noindex de staging, confirma el robots.txt y el sitemap, y conserva el hosting anterior hasta que sus registros no muestren más visitantes.