Qué controla realmente el TTL
Mover un sitio a un nuevo hosting parece sencillo en el papel: copiar archivos, apuntar el dominio y listo. En la práctica, los visitantes siguen llegando al servidor anterior durante horas o días porque las cachés de DNS guardan la respuesta vieja. Para un negocio pequeño que recibe prospectos por un formulario de contacto, esa “doble realidad” significa que algunos clientes ven el sitio nuevo y otros el viejo—o una página en blanco cuando usted ya canceló la cuenta anterior.
Esta es una lista de verificación operativa que recomienda TwoQM antes de cambiar registros A, AAAA o CNAME de un sitio de marketing en vivo. No es una comparación de proveedores.
El TTL (time to live) es cuánto tiempo pueden guardar resolvers y navegadores una respuesta de DNS antes de volver a preguntar. Si el registro A de www.ejemplo.com tiene un TTL de 86,400 segundos (24 horas), muchas redes pueden seguir sirviendo la IP anterior hasta un día después de que usted publique la nueva. Baje el TTL antes del traslado, espere a que expire una vez el TTL alto anterior y después haga el cambio.
Errores comunes en negocios pequeños:
Cambiar de hosting y de DNS el mismo día con un TTL de 24 horas todavía activo.
Editar solo el apex (ejemplo.com) y olvidar www, registros de correo o CNAME del CDN.
Apagar el hosting viejo en cuanto el panel muestra “propagación” en una sola laptop y una sola red.
Dos semanas antes: inventarie quién responde por el nombre
Anote en una nota compartida:
Registrador — Dónde renueva el dominio (y quién puede iniciar sesión).
Nameservers — Los del registrador, Cloudflare, el hosting u otro tercero.
Registros en vivo — A/AAAA del apex y www, CNAME de CDN o tienda, MX y TXT de correo, cualquier TXT de verificación (Google, Microsoft, Apple, pagos).
Dónde termina realmente el tráfico — Origen, borde CDN, proxy inverso o una plataforma de marketing que “conecta” el dominio por usted.
Exporte una captura o un archivo de zona del DNS actual. Necesita un objetivo de rollback si el nuevo hosting falla.
De siete a tres días antes: baje el TTL a propósito
Elija los registros que va a cambiar para el traslado (casi siempre A/AAAA del apex y www). Ponga su TTL en un valor corto que permita su proveedor—a menudo 300 segundos (5 minutos) o 600 segundos. Deje MX y TXT de correo quietos a menos que también mueva el correo.
Después espere al menos tanto como duraba el TTL anterior. Si el TTL viejo era de 24 horas, espere un día completo después de publicar el TTL bajo antes de cambiar la IP. Esa espera es el punto: las cachés del mundo refrescan al valor corto para que el corte posterior termine en minutos, no en un día.
Confirme que el TTL bajo está vivo desde más de un resolver (su teléfono en datos celulares, una segunda red o una herramienta pública de consulta). No confíe solo en el mensaje de “éxito” del panel de DNS.
Día del corte: cambie el DNS al final, no al inicio
Un orden que mantiene los prospectos fluyendo:
Construya y pruebe el sitio nuevo en un hostname temporal o con override del archivo hosts—nunca en la URL del cliente hasta estar listo.
Haga smoke test de formularios, HTTPS, redirecciones y checkout/reservas en el origen nuevo.
Publique el A/AAAA o CNAME nuevo hacia el destino correcto (con el TTL corto todavía activo).
Mantenga el hosting viejo en línea y respondiendo hasta que chequeos desde dos redes muestren el sitio nuevo de forma consistente.
Vigile el formulario de contacto y la analítica unas horas. Si algo falla, regrese el DNS con su zona exportada.
Solo cuando el sitio nuevo esté estable cancele la factura del hosting viejo. Cancelar temprano es cómo la “propagación” se convierte en una caída de fin de semana.
Qué verificar en la primera hora después del cambio
Página de inicio y una página interior sobre https:// con certificado válido para el hostname real (no solo el temporal).
Apex y www resuelven al destino correcto, y uno redirige limpio al otro.
El formulario de contacto o la ruta de reservas sigue entregando correo a la bandeja correcta.
Google Business Profile, firmas de correo y anuncios siguen apuntando a la URL que realmente reciben los clientes.
Sin contenido mixto ni URLs viejas del CDN que rompan assets de checkout.
Si usa un CDN delante del origen, purgue caché después del corte y confirme que el borde obtiene el backend nuevo—no un HTML viejo de la semana pasada.
Cuando todo se ve bien: suba el TTL otra vez
Cuando el nuevo hosting haya estado estable uno o dos días, suba el TTL a un valor de producción razonable (a menudo de 1 hora a unas pocas horas) para que cada visita no fuerce una consulta DNS fresca. Deje una nota en el calendario para el próximo traslado: baje el TTL primero, espere y después cambie.
Quién es dueño de cada acceso
Los traslados de DNS fallan más por acceso que por tecnología. Nombre responsables antes del día del corte:
Quién puede editar DNS en el registrador o en el DNS host.
Quién puede abrir un ticket con el hosting viejo y el nuevo.
Quién puede revertir los registros si el certificado o el formulario se rompe.
El consejo fijo de TwoQM para operadores: trate el DNS como un gabinete con llave. Contraseñas compartidas de “admin@” y apps de MFA vencidas son cómo un traslado de sábado se convierte en un caos del lunes.
Resumen para esta semana
Si un cambio de hosting o un re-apunte de dominio está en su calendario, baje el TTL ahora—no la mañana del cambio. Inventarie apex, www y registros de correo. Pruebe el sitio nuevo fuera del nombre público. Mantenga el hosting viejo caliente hasta que dos redes coincidan en que el nuevo está en vivo. Después suba el TTL otra vez y documente quién tiene las llaves.
Un corte de DNS silencioso es aburrido a propósito. Lo aburrido es cómo los negocios pequeños siguen contestando el teléfono a clientes reales en lugar de explicar por qué el sitio “todavía muestra la dirección vieja”.