Cambiar de hosting sin perder posicionamiento en Google

Transparencia: algunos enlaces de esta página pueden ser de afiliado. Si contratas a través de ellos, puedo recibir una comisión sin que pagues más. Solo recomiendo lo que uso o implanto.

La pregunta de verdad: ¿cambias solo de servidor o también de URLs?

Cuando un cliente me dice «quiero irme de mi hosting, pero me da miedo perder Google», lo primero que le pregunto es qué va a cambiar exactamente. Porque bajo la palabra «migrar» se esconden dos operaciones muy distintas, con riesgos muy distintos.

Cambio de servidor sin cambiar URLs

Mismo dominio, mismas direcciones de página, mismo contenido. Solo cambia la máquina que sirve la web y, por tanto, la IP a la que apunta el DNS. Para Google es casi invisible. Riesgo bajo si no rompes nada por el camino.

Cambio de URLs o rediseño (con o sin cambio de servidor)

Cambias la estructura de direcciones (/servicios/seo/ pasa a /seo/), el dominio, o rehaces la web y desaparecen páginas. Google tiene que descubrir dónde ha ido cada cosa. Riesgo alto: si una URL con tráfico se queda sin redirección, pierdes lo que posicionaba.

Google lo trata igual: tiene una guía oficial para mover un sitio sin cambios de URL (cambio de hosting o de CDN) y otra distinta para mover un sitio con cambios de URL. La segunda es bastante más larga, y por algo es.

Mi consejo: no hagas las dos cosas a la vez si puedes evitarlo. Primero cambia de hosting con la web tal cual. Cuando lleve un par de semanas estable, rediseña. Si algo baja, sabrás qué lo ha causado. Si lo haces todo junto y caes, no sabrás si ha sido el servidor, las URLs o el contenido nuevo.

Lo que me pasó a mí en octubre de 2026 (y no fue culpa del hosting)

Te lo cuento porque es la lección más útil de toda esta guía. En octubre de 2026 rediseñé esta web. Mismo hosting, mismo dominio. Cambié la estructura de algunas secciones y reorganicé páginas.

El 20 de octubre, revisando Search Console, vi que la página antigua /agencia-seo-albacete/ devolvía un error 404. No era una página cualquiera: era la URL con más impresiones de todo el sitio, 16.738 impresiones en 16 meses. Se había quedado fuera del mapa de redirecciones porque hice la lista de URLs a mano, mirando el menú de la web nueva, en vez de partir de los datos de Search Console.

Lo arreglé con redirecciones 301 a la página equivalente nueva. Pero la lección es clara: el servidor no tuvo nada que ver. El fallo fue no exportar antes las URL con tráfico. Si alguien hubiera cambiado de hosting ese mismo día, habría culpado al hosting nuevo. Y se habría equivocado.

Regla que saco de aquello: antes de tocar nada, exporta de Search Console las páginas con impresiones de los últimos 16 meses. Esa lista, no tu menú ni tu memoria, es la que manda.

Lista de comprobación: antes de migrar

Esta es la fase que más se salta la gente y la que más problemas evita. Calcula una semana de margen antes del día del cambio.

1. 1

   1. Copia completa y descargada

   Archivos de la web y base de datos, guardados en tu ordenador o en tu nube, no solo en el hosting viejo. En cPanel: «Copia de seguridad» → copia completa, o un plugin de copias en WordPress. Comprueba que el archivo abre y que pesa lo que esperas.

2. 2

   2. Exporta las páginas con impresiones

   Search Console → Rendimiento → Páginas → intervalo «Últimos 16 meses» → Exportar. Es el máximo histórico que guarda la herramienta. Guarda también las consultas principales y las posiciones medias: serán tu punto de comparación.

3. 3

   3. Rastrea la web actual

   Con Screaming Frog (gratis hasta 500 URLs) u otra herramienta de rastreo. Te da la lista de URLs que responden 200, los títulos, las redirecciones que ya existen y los enlaces rotos de antes. Así no confundes un problema antiguo con uno nuevo.

4. 4

   4. Baja el TTL del DNS

   Al menos una semana antes, baja el TTL de los registros A y de www (por ejemplo, a 300 segundos o una hora). Google lo recomienda en su guía de cambios de hosting: los cachés de DNS se actualizan antes y la transición dura horas en vez de días.

5. 5

   5. Inventario del correo

   Si el correo está en el mismo hosting, apunta todas las cuentas, reenvíos y alias, y haz copia de los buzones. Revisa los registros MX, SPF, DKIM y DMARC actuales. Es lo que más se rompe sin que nadie lo vea hasta que un cliente dice «te mandé un correo y me rebotó».

6. 6

   6. Anota versiones y servicios

   Versión de PHP, tareas cron, reglas del .htaccess, accesos FTP, plugins de caché. Si el hosting nuevo usa una versión de PHP distinta, conviene saberlo antes.

Si tu web lleva redirecciones antiguas en el .htaccess, cópialas tal cual. Son SEO acumulado de años.

Durante la migración: la web nueva no se publica hasta que funcione

La clave de esta fase es simple: la web vieja sigue sirviendo a tus visitas mientras tú montas y pruebas la nueva en paralelo. Nadie de fuera debe notar nada.

Mover los archivos y la base de datos

Si vienes de un hosting con cPanel y vas a otro con cPanel, muchos proveedores lo hacen por ti. Banahosting, donde tengo esta web, incluye la migración gratis de cPanel a cPanel. Si no es tu caso, en WordPress puedes usar un plugin de migración o hacerlo a mano: subir archivos, importar la base de datos y ajustar wp-config.php con los datos nuevos.

Probar antes de cambiar el DNS

Aquí es donde se separa una migración tranquila de un susto. Tienes dos formas de ver la web nueva sin que el público la vea:

• Archivo hosts de tu ordenador. Añades una línea con la IP del servidor nuevo y tu dominio. Tu navegador irá al hosting nuevo; el resto del mundo, al viejo. Es la prueba más fiel, porque ves la web con su dominio real.
• URL temporal del hosting. Muchos paneles dan una dirección provisional. Sirve para un vistazo rápido, pero en WordPress puede dar fallos de rutas que luego no existen con el dominio real.

Con la web nueva delante, comprueba: portada y páginas principales, formularios (envía uno de prueba y mira si llega), buscador interno, imágenes, versión móvil, área de clientes o tienda si la tienes, y que el rastreador con el archivo hosts activo devuelve las mismas URLs con 200 que en la web vieja.

Certificado SSL

El SSL gratuito (Let’s Encrypt) suele emitirse cuando el dominio ya apunta al servidor nuevo, así que durante unos minutos tras el cambio de DNS puede aparecer el aviso de «conexión no segura». Para reducir ese hueco, pregunta al hosting nuevo si pueden emitir el certificado antes, o haz el cambio en hora de poco tráfico y revisa el SSL en cuanto propague. Comprueba también que http:// redirige a https:// y que la versión con y sin www va a la misma.

El cambio de DNS: propagación y paciencia

Cuando todo funciona en el servidor nuevo, cambias los registros A (o los servidores de nombres) para que el dominio apunte a la IP nueva. Con el TTL bajado una semana antes, la mayoría de usuarios verán la web nueva en minutos o pocas horas. Algunos proveedores de internet tardan más.

• No toques contenido en la web vieja desde que empiezas la migración. Si alguien publica una entrada o un cliente hace un pedido en el servidor viejo, se perderá.
• No canceles el hosting viejo todavía. Google lo dice en su guía: revisa los registros del servidor anterior y apágalo cuando deje de recibir tráfico. Yo dejo un margen de al menos una o dos semanas y cancelo al terminar el periodo que ya tengo pagado.
• Comprueba la propagación con una herramienta pública de consulta de DNS desde varios países.
• Vuelve a subir el TTL a su valor normal cuando todo esté estable.

Google también avisa de que, justo después de un cambio de infraestructura, es normal que el robot de Google rastree con menos frecuencia durante unos días y luego vuelva a subir. No es una penalización: está comprobando que tu servidor nuevo aguanta.

Después de migrar: comprobaciones de la primera semana

1. Todas las URL dan 200 o 301. Vuelve a rastrear la web y cruza el resultado con la lista exportada de Search Console. Cada URL con impresiones debe responder 200 (si sigue existiendo) o 301 hacia su equivalente. Un solo 404 en una página con tráfico es lo que me pasó a mí.
2. Search Console. Comprueba que la propiedad sigue verificada (si la verificaste con un archivo HTML en el servidor, puede haberse perdido). Usa la inspección de URLs en la portada y en dos o tres páginas importantes y pide indexación si hace falta.
3. Sitemap. Que /sitemap.xml (o el que genere tu plugin SEO) carga, lista las URLs correctas y está enviado en Search Console.
4. robots.txt. Que no se ha colado un «Disallow: /» de la web de pruebas. Pasa más de lo que parece, sobre todo si alguien marcó en WordPress «Disuadir a los motores de búsqueda».
5. Velocidad. Pasa PageSpeed Insights a la portada y a una página interior y compáralo con los datos de antes. Si has cambiado a un servidor más cerca de tu público, debería mejorar.
6. Formularios y llamadas. Envía un formulario de cada tipo y comprueba que llega. Revisa que el botón de WhatsApp y el teléfono siguen bien.
7. Correo. Envía y recibe desde cada cuenta, también hacia Gmail y Outlook, y mira si los mensajes llegan a la bandeja de entrada o a spam.
8. Analítica y etiquetas. Que Google Analytics, Tag Manager y las conversiones de anuncios siguen disparando. Si no, durante días no sabrás qué te trae clientes.
9. Ficha de Google. Que el enlace a la web de tu Perfil de Empresa apunta a una URL que funciona. Si apuntaba a una página que has movido, cámbialo.

Mi rutina: comprobación completa el día del cambio, otra a los 3 días y otra a las 2 semanas comparando clics e impresiones con el mismo periodo anterior en Search Console.

Qué puede salir mal y cómo detectarlo

Cuánto tarda cada fase

Con cambio de URLs, Google dice en su guía que un sitio mediano puede tardar varias semanas o más en procesar el traslado y que el posicionamiento puede fluctuar temporalmente. También recomienda redirecciones permanentes (301 o 308) y mantenerlas durante al menos 1 año; para los usuarios, aconseja dejarlas indefinidamente (Google Search Central, actualizada en septiembre de 2026). Yo no las quito nunca: no cuestan nada y siguen recibiendo enlaces antiguos.

Si quieres entender por qué tus posiciones tardan en recuperarse o en subir, tienes más detalle en cuánto tarda en notarse el SEO local.

¿Y Google Maps? La ficha no depende del hosting

Tu Perfil de Empresa en Google vive en los servidores de Google, no en tu hosting. Cambiar de servidor no lo toca. Lo que sí influye es la web enlazada: si la URL de la ficha da error o tarda mucho, la ficha pierde parte de su apoyo. Tras migrar, abre el enlace de tu ficha y comprueba que funciona. Si después notas que no apareces, repasa por qué un negocio no aparece en Google Maps: casi nunca es el hosting.

Adónde migrar si te vas por caro o por lento

Si el motivo del cambio es que pagas mucho por un hosting lento, el destino importa tanto como la migración. Para la web de un negocio local o una pyme, lo que miro es: servidor cerca de tu público, caché a nivel de servidor, copias diarias, SSL gratis y que la renovación no se dispare. Lo explico con más calma en qué hosting necesita la web de un negocio local.

Yo tengo esta web y la de una app en Banahosting desde hace más de dos años, en el plan Starter, sin incidencias que me obligaran a abrir un ticket. Medí la portada en octubre de 2026: 97 en PageSpeed móvil. Pero el Starter solo tiene servidor en EE. UU., y desde España el primer byte tarda unos 0,85 s sin caché. Por eso, si tu público está en España, te recomiendo el plan Professional con el servidor en Europa: menos latencia y los datos en la UE. Cuesta unos 6,20 €/mes (6,95 $) al cambio de octubre de 2026, renueva al mismo precio y la migración desde otro cPanel es gratis. El importe en euros varía con el dólar. Tienes mi análisis completo en la opinión de Banahosting.

Cuándo no te lo recomiendo: si tienes una tienda online grande o con mucho tráfico (mejor un VPS o un hosting gestionado de WooCommerce), si usas Odoo (no funciona en hosting compartido; lo explico en hosting para Odoo), si necesitas factura española con IVA o soporte por teléfono, o si no quieres tocar nada técnico. La factura la emite una empresa de EE. UU. en dólares: si eres autónomo o empresa, consúltalo con tu gestoría.

Si el correo también está en el hosting viejo, aprovecha para ordenarlo: tienes opciones en correo profesional con tu dominio. Y para ver el coste total del año, no solo el hosting, mira cuánto cuesta mantener una web al año.

Si además vas a rediseñar: el mapa de redirecciones

Si el cambio de hosting viene con web nueva, añade un paso que no es negociable: una hoja de cálculo con dos columnas, URL antigua y URL nueva. La columna de URLs antiguas sale de la exportación de Search Console (16 meses) más el rastreo. Ninguna URL con impresiones puede quedarse sin destino. Cuando una página desaparece sin equivalente, redirígela a la más parecida en tema, no a la portada por defecto.

Antes de decidir si toca rediseño, piensa si realmente lo necesitas. A veces con arreglar velocidad, textos y llamadas a la acción basta, y te ahorras el riesgo. Lo cuento en si tu web necesita un rediseño o solo arreglos.

Resumen para llevar

• Cambiar solo de servidor, con mismas URLs, es de riesgo bajo. Cambiar URLs o rediseñar es lo arriesgado.
• Exporta de Search Console las páginas con impresiones de 16 meses antes de tocar nada.
• Baja el TTL una semana antes, prueba con el archivo hosts y no canceles el hosting viejo hasta que deje de recibir tráfico.
• Después, cada URL con tráfico debe dar 200 o 301. Mantén las 301 al menos un año (yo, siempre).
• Revisa correo, formularios, analítica y el enlace de tu ficha de Google, no solo la portada.

Si prefieres que lo revise yo antes y después del cambio, es parte de mi trabajo de SEO para negocios locales.

ConsejoNo canceles el hosting viejo el mismo día del cambio. Déjalo activo al menos una o dos semanas: es tu plan B si algo falla y Google sigue visitándolo mientras propaga el DNS.