Mantenimiento

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

Google no penaliza cambiar de servidor: lo que hunde el tráfico son cinco errores concretos durante la mudanza. Checklist completo, paso a paso.

JU Por Junior Calderón
· · 7 min de lectura
Cubos de datos migrando entre dos servidores bajo un escudo protector, cambio de hosting seguro.

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.

Cómo migrar una web sin perder SEO: lo esencial en cinco pasos

Migrar una web sin perder SEO se reduce a cinco pasos que esta guía desarrolla uno a uno: hacer inventario de lo que tienes (URL, redirecciones, correos, DNS), montar y probar el destino sin tocar todavía el DNS, bajar el TTL unos días antes del cambio, hacer el cambio y vigilar las primeras cuarenta y ocho horas, y comprobar en Search Console que no aparecen errores nuevos. Si saltas alguno, es cuando se pierden posiciones.

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:

TipoQué cambiaRiesgo SEO
Cambio de hostingSolo el servidor. Dominio y URLs igualesBajo si se hace bien
Cambio de protocolo (HTTP a HTTPS)El esquema de todas las URLsMedio
Cambio de dominio o rediseñoDominio, estructura de URLs o ambosAlto
Cambio de plataformaCMS completo y estructura de URLsMuy 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.

Herramienta gratuita: Una comprobación de dos minutos evita sustos: analiza la home y dos páginas internas con el analizador SEO gratuito antes y después de mover el DNS, y compara los dos informes.

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

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

Compartir X LinkedIn WhatsApp
JU
Escrito por

Junior Calderón

Fundador de JC Páginas Web. Diseña y programa webs desde 2014 para autónomos y pymes, con foco en velocidad, seguridad y SEO local en Sevilla.

Quiénes somos
Sigue leyendo

Artículos relacionados

Mazo judicial y balanza junto a una pantalla con el símbolo de accesibilidad universal, ley de accesibilidad web.
· 8 min

Ley de accesibilidad web en España: ¿obliga a tu negocio?

Dos normas obligan a las webs españolas a ser accesibles: la Ley 11/2023 y el RD 193/2023. A quién aplica cada una, desde cuándo y qué multas hay.

Cumplir el RGPD en tu web: checklist paso a paso para pymes — cumplir RGPD web pymes · JC Páginas Web
· 7 min

Cumplir el RGPD en tu web: checklist paso a paso para pymes

Descubre cómo cumplir RGPD web pymes con nuestra guía paso a paso. Checklist legal para evitar sanciones de la AEPD y mejorar la confianza de tus clientes.

Migración de HTTP a HTTPS sin perder posicionamiento SEO — migración HTTPS SEO · JC Páginas Web
· 7 min

Migración de HTTP a HTTPS sin perder posicionamiento SEO

Descubre cómo realizar una migración HTTPS SEO segura. Evita caídas de tráfico, soluciona el contenido mixto y protege la reputación de tu pyme en Google.

¿Por qué tu web necesita HTTPS/SSL hoy mismo? — HTTPS SSL web · JC Páginas Web
· 8 min

¿Por qué tu web necesita HTTPS/SSL hoy mismo?

Implementar HTTPS SSL web ya no es opcional. Descubre cómo este certificado protege los datos, mejora tu SEO y evita que Chrome marque tu web como peligrosa.

Empieza tu proyecto

Hablemos de tu próximo proyecto.

Presupuesto cerrado en menos de 24 horas laborables. Sin compromiso, sin letra pequeña.