Migrar de hosting sin perder posiciones en Google

Por qué se pierden posiciones (y por qué casi nunca es culpa de Google)

Google indexa URLs, no servidores. Si https://tudominio.com/servicios/diseno-web/ sigue existiendo, con el mismo contenido y respondiendo en menos de un segundo, no hay motivo para que baje. El problema aparece cuando en la migración cambia algo de esa ecuación sin que nadie lo note:

• Rutas distintas. El hosting nuevo fuerza /index.php/ en las URLs, o se cambia de www a sin www, o se pasa el blog a un subdominio. Cada variante sin redirección es una URL que Google olvida.
• Caída superior a unas horas. Si el sitio devuelve error 500 durante dos días, el rastreo se detiene y la recuperación tarda semanas.
• Rendimiento peor. Un plan más barato con menos recursos puede subir el TTFB de 300 ms a 1,4 s y arrastrar el LCP. Migrar para ahorrar 10 € al mes y perder velocidad es un mal negocio.
• Correo roto. Es el fallo más caro y el menos vigilado: si al mover el DNS se olvidan los registros MX, dejas de recibir presupuestos y no te enteras hasta que un cliente te llama por otro canal.
• Robots, noindex o certificados mal trasladados. Un Disallow: / heredado de la fase de pruebas, o un SSL que no se renueva, hunden el tráfico en días.

Fase 0: inventario y medición antes de tocar nada

La migración empieza dos semanas antes del corte, con una lista escrita. Sin inventario no hay migración: hay traslado a ciegas.

• Dominios y subdominios implicados, con la cuenta donde están registrados y la fecha de renovación.
• Correo corporativo: proveedor, número de buzones, alias, listas de distribución, firmas y registros SPF, DKIM y DMARC actuales.
• Integraciones: pasarelas de pago con URL de retorno, webhooks, API de ERP o CRM, apps externas con IP autorizada del servidor.
• Tareas programadas (cron): copias, informes, sincronizaciones. Es lo primero que se olvida y lo que rompe procesos en silencio.
• Baseline medible: TTFB, tiempo de carga, Core Web Vitals de campo, posiciones y clics de las 50 URLs principales, número de formularios recibidos al día.

Ese baseline es lo que permite demostrar después si la migración ha ido bien. Sin él, cualquier discusión sobre el tráfico se convierte en una opinión.

Fase 1 y 2: copia verificada y entorno de pruebas

Una copia que no se ha restaurado nunca no es una copia: es una carpeta. El procedimiento que aplicamos es siempre el mismo.

• Copia completa de ficheros y base de datos, con recuento de tablas, número de usuarios y tamaño total anotados. Así se comprueba que la restauración es idéntica y no falta una tabla.
• Restauración real en el hosting nuevo, no solo copia de seguridad. Se levanta el sitio en un dominio temporal o en un subdominio de pruebas.
• Bloqueo de la versión de pruebas. Contraseña de acceso o noindex con cabecera X-Robots-Tag, y comprobación de que robots.txt no queda publicado después. Una web de pruebas indexada compite con la real y genera contenido duplicado.
• Prueba funcional completa: iniciar sesión en el panel, enviar un formulario, cerrar un pedido de prueba con pasarela en modo test, comprobar buscador interno, filtros, mapa, idiomas y generación de PDF si existe.
• Comparación de rendimiento entre servidor antiguo y nuevo con la misma herramienta y el mismo punto de red. Si el nuevo no mejora o iguala, no se corta.

Fase 3: DNS, TTL y correo, en ese orden

Aquí se decide si la migración sale limpia o si hay dos días de incidencias. La clave es reducir el TTL antes y no tocar más registros de los necesarios.

Registro	Qué hace	Acción en la migración
A / AAAA	Apuntan el dominio a la IP del servidor	Se cambian a la IP del hosting nuevo
CNAME	Alias de subdominios (www, blog, tienda)	Se actualiza solo si cambia el destino
MX	Recibe el correo del dominio	No se toca salvo que el correo se migre también
TXT (SPF, DKIM, DMARC)	Autenticación del correo saliente	Se copian tal cual al nuevo proveedor de DNS
CAA	Qué autoridades pueden emitir el certificado	Se revisa si el hosting nuevo emite SSL por otra vía

El TTL (tiempo de vida) es el dato que casi nadie ajusta. Se baja a 300 segundos entre 24 y 48 horas antes del corte: así los resolutores de todo el mundo releen la IP nueva en minutos en lugar de en horas. Cuando la migración está estable, se sube de nuevo a un valor alto (3.600 o 14.400 segundos) para reducir consultas.

Y una regla que evita sustos: si el correo corporativo vive en un proveedor distinto, el DNS del correo no se toca el día del corte. Se cambia solo el registro del sitio y se comprueba el envío y la recepción desde una cuenta externa.

Fase 4: el corte, con ventana y con lista de comprobación

El corte se hace en horario de bajo tráfico, de lunes a jueves, y nunca en viernes, en campaña ni en el pico de temporada de tu sector. Desde el cambio de IP hasta la verificación completa suelen ser entre 30 y 90 minutos de trabajo:

• Comprobar el certificado SSL en el dominio final, incluido www y cualquier subdominio activo.
• Verificar redirecciones: http → https, sin www → con www (o al contrario, con un único criterio), y toda URL antigua con 301 a su equivalente.
• Revisar códigos de respuesta de las 50 URLs principales. Cualquier 404 que antes no existía se redirige el mismo día.
• Enviar un formulario y un pedido de prueba en producción, con pago real de importe mínimo y devolución posterior.
• Confirmar el correo: enviar y recibir desde el dominio, y comprobar que los correos automáticos de la web salen sin acabar en spam.

Fase 5: verificación en Search Console y seguimiento a 30 y 90 días

Si el dominio no cambia, no hay que declarar ninguna “dirección nueva”. El trabajo aquí es de comprobación:

• Inspección de URL de la portada, tres páginas de servicio, tres fichas de producto y tres artículos del blog. Se comprueba que Google ve el contenido actualizado y con el código 200.
• Cobertura y errores 404 día a día durante la primera semana. Los errores nuevos se redirigen en menos de 24 horas.
• Informe de sitemap: confirmar que se lee sin errores desde el nuevo servidor y que las fechas de última modificación son coherentes.
• Comparación de posiciones y clics a los 7, 30 y 90 días, contra el baseline. Una variación del 5 % es ruido; una caída sostenida del 20 % en un grupo de URLs indica un problema real que hay que localizar.
• Rendimiento y disponibilidad: monitorización de uptime y comparación de TTFB antes y después.

El hosting viejo no se cancela el día de la migración: se mantiene pagado entre 30 y 60 días. Es la red de seguridad más barata que existe, y la única forma de volver atrás en veinte minutos si algo falla.

Los errores que provocan caídas de tráfico

Error	Consecuencia habitual	Cómo evitarlo
No redirigir URLs antiguas	404 en páginas con enlaces y tráfico, pérdida de autoridad	Comparar el listado de URLs antiguas con las nuevas y crear 301 una a una
Cambiar dominio y www a la vez	Dos cambios que se atribuyen a la vez, difícil diagnosticar	Un solo cambio por migración y con redirecciones completas
Olvidar los MX	Pérdida de correos de clientes durante días	Auditar la zona DNS completa antes del corte y no tocar el correo
Dejar el noindex de pruebas	La web desaparece de Google en semanas	Comprobarlo como última tarea del corte y también a los siete días
Migrar a un plan inferior	Más lentitud y peor experiencia móvil	Medir TTFB y recursos antes y después, con los mismos datos
Cancelar el hosting antiguo el primer día	Sin posibilidad de revertir	Mantenerlo pagado uno o dos meses

Conclusión: la migración se gana antes del corte

Una migración limpia se parece poco a un traslado y bastante a un protocolo: inventario, baseline medido, copia restaurada y probada, TTL bajo, corte con lista de comprobación, verificación en Search Console y seguimiento a 90 días. Cuando alguien te dice que una migración se hace en una hora, está describiendo el cambio de IP, no la migración.

Si tu hosting actual es el techo de tu rendimiento, esto conecta directamente con los umbrales de Core Web Vitals: un TTFB alto no se arregla desde el front-end. Puedes ver el procedimiento completo en el servicio de migración WordPress y hosting, y qué se revisa después en mantenimiento y backups.