La guía de migraciones web de esta sección cubre cambios de dominio, de HTTP a HTTPS o de estructura de URLs. Este es un caso distinto y más frecuente de lo que parece: el dominio no cambia en absoluto, las URLs son exactamente las mismas, pero el servidor que las responde sí cambia, porque el sitio se muda a otro proveedor de hosting o a otra IP dentro del mismo proveedor. Al no cambiar ninguna URL no hace falta mapeo ni redirecciones, pero el riesgo técnico es real y distinto: durante la ventana de transición existen, momentáneamente, dos servidores distintos respondiendo al mismo dominio según a quién le pregunte cada visitante o cada rastreador.
Preparación previa: bajar el TTL del DNS con antelación
El registro DNS que apunta el dominio a una IP concreta (normalmente un registro A, o CNAME si se usa un alias) incluye un valor TTL (Time To Live) que indica cuánto tiempo pueden los resolutores DNS de todo el mundo cachear esa respuesta antes de volver a consultarla. Un TTL habitual en un dominio ya estable puede ser de varias horas o incluso 24 horas, un valor razonable cuando no se espera ningún cambio, pero un obstáculo serio el día de una migración: si se cambia la IP con un TTL alto todavía activo, una parte del tráfico (y de los rastreadores) seguirá llegando al servidor antiguo durante ese tiempo completo, sin ningún margen de control.
; Antes de migrar (varios días antes, nunca el mismo día):
; bajar el TTL a un valor corto para poder reaccionar rápido
www.tudominio.com. 300 IN A 203.0.113.10 ; TTL = 300s = 5 minutos
; Tras confirmar que la migración es estable,
; volver a subir el TTL a un valor normal (p. ej. 3600s o más)El TTL bajo debe activarse con varios días de antelación al cambio real, no el mismo día: el TTL alto anterior sigue vigente en los resolutores que ya cachearon la respuesta hasta que expire por su cuenta, así que reducirlo en el último momento no acelera nada para quien ya tiene la respuesta antigua en caché. Solo después de que haya pasado tiempo suficiente para que el TTL corto esté ya propagado en la inmensa mayoría de resolutores del mundo tiene sentido proceder con el cambio de IP.
Mantener ambos servidores sincronizados durante la ventana de transición
Mientras el DNS todavía no ha terminado de propagarse a todos los resolutores, un mismo dominio puede resolver a IPs distintas según la ubicación geográfica del visitante o del rastreador, y según cuándo cada resolutor concreto refrescó su caché por última vez. Esto significa que, durante esa ventana (que puede ir de minutos a un par de días según el TTL previo y el comportamiento real de determinados resolutores que ignoran el TTL declarado), ambos servidores, el antiguo y el nuevo, deben servir exactamente el mismo contenido. Esto implica sincronizar no solo los archivos y el código, sino cualquier dato que cambie durante la ventana: si el sitio tiene un mini-CMS, un carrito de compra o cualquier contenido editado en producción, una edición hecha en el servidor nuevo mientras una parte del tráfico todavía llega al antiguo (o viceversa) puede perderse o generar una inconsistencia visible según a qué servidor responda cada visita.
El día del corte: verificar la propagación, no darla por hecha
Antes de considerar la migración completa, hay que verificar la propagación real del DNS, no asumir que "ya ha pasado tiempo suficiente". Herramientas de consulta DNS distribuida (que consultan resolutores en distintas regiones del mundo simultáneamente) muestran de un vistazo si algún resolutor concreto todavía devuelve la IP antigua, algo que una consulta local desde el propio equipo no puede detectar porque el resolutor local probablemente ya tiene la respuesta nueva:
# Consultar directamente al servidor DNS autoritativo,
# sin pasar por ningún resolutor intermedio con posible caché
dig www.tudominio.com @ns1.tuproveedordns.com +short
# Consultar el TTL restante de la respuesta que ve
# un resolutor público concreto en este momento
dig www.tudominio.com @8.8.8.8Monitorización activa durante la ventana de transición
Durante todo el corte conviene tener monitorización activa de dos cosas a la vez: la disponibilidad y el código de respuesta de ambos servidores (para detectar de inmediato si uno de los dos empieza a fallar mientras todavía recibe una parte del tráfico), y, si se tiene acceso a los logs de servidor de ambos, el volumen de peticiones de Googlebot y de otros rastreadores en cada uno, que permite confirmar en tiempo real cómo se está repartiendo el rastreo entre ambas IPs a medida que el DNS se propaga, en vez de descubrirlo días después revisando Search Console.
Qué comprobar inmediatamente después del corte
Una vez que la propagación se ha confirmado prácticamente completa, hay una lista concreta de comprobaciones que hay que hacer contra el servidor nuevo, no dar por buenas de antemano: que los códigos de respuesta HTTP de las páginas principales siguen siendo 200 (un error de configuración del servidor nuevo, como una regla de reescritura que no se migró, puede convertir páginas enteras en 404 o 500 sin que cambie ninguna URL); que el TTFB del servidor nuevo es igual o mejor que el del antiguo, no peor (una migración de hosting mal dimensionada puede empeorar el rendimiento, con el consiguiente impacto en Core Web Vitals); y, con particular atención, que no ha aparecido contenido mixto por URLs del servidor antiguo escritas a fuego en el código o en la base de datos (una URL absoluta hacia la IP o el hostname interno del servidor anterior, por ejemplo en una configuración de CDN o de subida de imágenes, que sigue apuntando al servidor que ya no debería usarse).
Plan de rollback: decidir el criterio antes de necesitarlo
El plan de vuelta atrás solo funciona si se decide antes de la migración, no en mitad de una incidencia con presión de tiempo. Esto significa fijar de antemano: durante cuánto tiempo se mantiene el servidor antiguo completamente operativo y sincronizado tras el corte (nunca apagarlo ni reutilizar su IP inmediatamente); qué umbral concreto de errores o de degradación de rendimiento dispara la decisión de revertir (un porcentaje de errores 5xx, un TTFB por encima de cierto valor); y que revertir es tan simple técnicamente como volver a cambiar el registro DNS a la IP antigua, lo cual solo es rápido si el TTL sigue siendo bajo en ese momento, otra razón para no subirlo de nuevo a un valor alto hasta tener la certeza de que la migración fue estable.
Preguntas frecuentes
¿Cuánto tiempo antes debo bajar el TTL del DNS?
Como mínimo, el tiempo equivalente al TTL actualmente activo (para que ese valor alto termine de expirar de forma natural en todos los resolutores) más un margen de seguridad de uno o dos días antes de proceder con el cambio real de IP.
¿Necesito mantener el servidor antiguo funcionando después del corte?
Sí, durante toda la ventana de propagación del DNS y un margen adicional de seguridad después: parte del tráfico y del rastreo puede seguir llegando ahí durante ese tiempo, y debe recibir exactamente el mismo contenido que el servidor nuevo, no un error ni una versión desactualizada.
¿Afecta esta migración al posicionamiento aunque las URLs no cambien?
Si se ejecuta bien, el impacto debería ser prácticamente nulo porque Google identifica el contenido por URL, no por IP de servidor. El riesgo real está en errores de configuración durante la transición (downtime, contenido inconsistente entre servidores, mixed content por URLs internas mal migradas), no en el cambio de servidor en sí.
¿Cómo sé si Googlebot ya está rastreando desde el servidor nuevo?
Revisando los logs de acceso del servidor nuevo filtrados por user-agent de Googlebot (verificado también por IP inversa), o de forma indirecta observando en Search Console si el informe de rastreo sigue mostrando actividad normal sin picos de error durante la ventana de transición.