Cómo cambiar de hosting sin perder SEO ni tráfico

Cambiar de hosting no daña el SEO por sí mismo: lo daña hacerlo mal. Google no penaliza un cambio de servidor. Lo que hunde el tráfico son cinco cosas concretas que ocurren durante la mudanza: URLs que cambian sin redirección, un noindex heredado del entorno de pruebas, horas de caída durante el rastreo, el archivo robots.txt del servidor nuevo bloqueando todo, y un certificado SSL mal configurado. Las cinco son evitables con una lista de comprobación.

Antes de nada: qué tipo de migración vas a hacer

Se llama "migración" a cosas muy distintas y el riesgo no es el mismo. Ubica la tuya:

Tipo	Qué cambia	Riesgo SEO
Cambio de hosting	Solo el servidor. Dominio y URLs iguales	Bajo si se hace bien
Cambio de protocolo (HTTP a HTTPS)	El esquema de todas las URLs	Medio
Cambio de dominio o rediseño	Dominio, estructura de URLs o ambos	Alto
Cambio de plataforma	CMS completo y estructura de URLs	Muy alto

Este artículo cubre el primer caso, que es el más habitual y el que menos debería doler. Si vas a cambiar de dominio o a rediseñar, el trabajo es otro y lo explico en rebranding sin perder SEO. Si el paso es de HTTP a HTTPS, el detalle está en migración de HTTP a HTTPS.

Paso 1: inventario antes de tocar nada

Lo que no está inventariado no se echa de menos hasta que un cliente se queja. Antes de mover un solo archivo:

• Listado completo de URLs indexadas. Descarga el sitemap y, en Search Console, exporta las páginas con impresiones de los últimos noventa días. Ese segundo listado es el que importa: son las que traen tráfico.
• Foto del rendimiento actual. Clics e impresiones de los últimos veintiocho días. Sin esa referencia no podrás saber si la caída posterior es normal o un problema.
• Inventario técnico: versión de PHP, base de datos, extensiones, tareas programadas (cron), cuentas de correo, certificados, redirecciones existentes en el .htaccess.
• Correo. Es lo que más se olvida y lo que más ruido genera: si el correo va en el mismo servidor, planifica también los registros MX.

Paso 2: montar y probar el destino sin tocar el DNS

La regla de oro es no cambiar el DNS hasta que el sitio nuevo funcione. Se copia todo al servidor nuevo y se prueba apuntando el equipo local a la IP destino mediante el archivo hosts, sin que ningún visitante ni ningún buscador se entere.

Con esa configuración, verifica seis cosas en el servidor nuevo:

1. La portada y una página de cada tipo cargan sin errores.
2. El formulario de contacto envía y el correo llega.
3. El certificado SSL es válido y no hay contenido mixto.
4. El archivo robots.txt es el correcto, no el del entorno de pruebas.
5. Los ajustes del CMS no tienen activada la casilla de disuadir a los buscadores.
6. Las redirecciones antiguas siguen funcionando.

Los puntos 4 y 5 son la causa número uno de desapariciones tras una migración: se copia el sitio desde un entorno de pruebas que estaba bloqueado a propósito y nadie deshace ese bloqueo. La página se ve perfecta y, tres días después, empieza a caerse del índice.

Paso 3: bajar el TTL antes del cambio

El TTL indica cuánto tiempo guardan los servidores DNS la dirección antigua. Si está en 24 horas, habrá visitantes llegando al servidor viejo durante un día entero después del cambio.

Baja el TTL a 300 segundos al menos 24 horas antes de la migración. Así la propagación es cuestión de minutos y ambos servidores conviven poco tiempo. Mantén el servidor antiguo encendido y sincronizado durante 48 horas más, por si hay que volver atrás.

Paso 4: el cambio y las primeras cuarenta y ocho horas

Elige el momento de menor tráfico, que en un negocio local suele ser la madrugada del martes o del miércoles, nunca un viernes: si algo se tuerce, quieres tener días laborables por delante.

Después del cambio, comprueba en este orden:

1. Códigos de respuesta. Las URLs de tu listado deben devolver 200, no 301 en cadena ni 404.
2. Redirecciones. Con y sin "www", con y sin barra final, HTTP a HTTPS: todo debe acabar en la versión canónica en un solo salto.
3. Inspección de URL en Search Console sobre tres páginas clave, y solicitud de indexación de la portada.
4. Reenvío del sitemap desde Search Console.
5. Velocidad. Compara el tiempo de respuesta del servidor con el que tenías. Si es peor, has cambiado un problema por otro.
6. Cobertura en Search Console durante dos semanas, atento a subidas de errores de servidor o de páginas excluidas.

Qué es normal y qué no después de migrar

Cierta fluctuación durante los primeros días es esperable mientras Google vuelve a rastrear. Lo que no es normal:

• Caída sostenida de impresiones más de dos semanas.
• Aumento de errores 5xx en el informe de cobertura.
• Páginas que pasan a "Descubierta, actualmente sin indexar" en bloque.
• Tiempo de respuesta del servidor peor que antes de la migración.

Si aparece alguno, el orden de revisión es siempre el mismo: robots.txt, metaetiqueta de índice, códigos de respuesta y velocidad. En ese orden, porque es el de mayor a menor daño.

El caso urgente: migrar porque la web está caída o comprometida

No siempre se migra por gusto. A veces se migra porque el hosting está muerto, porque la web se ha infectado o porque el proveedor anterior no da acceso. Ahí el orden cambia:

1. Contener. Poner el sitio en mantenimiento antes de que Google rastree contenido comprometido o páginas de spam inyectadas.
2. Rescatar lo que se pueda del servidor antiguo y de la copia de seguridad más reciente que esté limpia.
3. Reconstruir en limpio. Instalación nueva, contenido revisado, contraseñas rotadas, usuarios administradores auditados.
4. Solicitar la revisión en Search Console si Google marcó el sitio como pirateado.
5. Volver a levantar con copias automáticas configuradas desde el primer día.

La diferencia con una migración planificada es que aquí se prioriza cortar el daño sobre conservar todo. Es el escenario que cubre el servicio de migración y rescate de WordPress, y también donde se nota si había una estrategia de copias 3-2-1 o no la había.

Preguntas frecuentes

¿Cuánto tarda Google en asimilar un cambio de hosting?

Si el dominio y las URLs no cambian, normalmente no hay nada que asimilar: Google sigue rastreando las mismas direcciones. Puede haber fluctuación durante unos días mientras se recalcula la velocidad del servidor, pero no hay reindexación masiva como sí ocurre al cambiar de dominio.

¿Tengo que avisar a Google de que cambio de servidor?

No existe una herramienta para eso. La herramienta de cambio de dirección de Search Console es solo para cambios de dominio. En un cambio de hosting basta con reenviar el sitemap y vigilar la cobertura.

¿Puedo migrar yo con un plugin?

Los plugins de migración funcionan bien en sitios sencillos. Donde suelen fallar es en webs grandes, con la base de datos muy cargada o con configuraciones a medida en el servidor. Lo crítico no es la copia de archivos: es la verificación posterior, y eso no lo hace ningún plugin por ti.

¿Merece la pena cambiar de hosting solo por velocidad?

Depende de dónde esté el cuello de botella. Si el tiempo de respuesta del servidor es alto y ya has optimizado imágenes, caché y base de datos, sí. Si el problema son cuatro megas de imágenes sin comprimir, el servidor nuevo te dará una mejora pequeña y cara.

Conclusión

1. Prueba en el destino antes de tocar el DNS. Con el archivo hosts pruebas el sitio completo sin exponer a nadie a una versión rota.
2. Revisa robots.txt y la etiqueta de índice el mismo día. Es la causa más común de desaparecer del índice tras migrar, y la más silenciosa.
3. Guarda la foto de rendimiento previa. Sin la referencia de las cuatro semanas anteriores no podrás distinguir una fluctuación normal de un problema real.

Sigue leyendo

• Ley de accesibilidad web en España: ¿obliga a tu negocio?
• Migración de HTTP a HTTPS sin perder posicionamiento SEO
• Mantenimiento web: 5 cosas que pasan si no actualizas tu sitio

¿Necesitas ayuda con esto? Te ayudamos con plan de mantenimiento web o cuéntanos tu caso.