Migración web: cómo mover un sitio sin perder tráfico ni posiciones

Una migración web es cualquier proyecto que traslada un sitio a una dirección nueva, a una plataforma nueva o a una estructura nueva: un cambio de CMS, un cambio de dominio, el paso de HTTP a HTTPS o un rediseño que renombra todas las URL. Aquí hablamos de mover un sitio, no de inmigración ni de trámites de extranjería, que es lo que devuelve Google cuando la consulta se queda en la palabra suelta.

Los contenidos sobreviven al traslado. Las direcciones a las que apuntan Google, otros sitios y tus propias campañas de correo, muchas veces no. Ese hueco es donde aparece el daño. Según Google Search Central, un traslado con cambio de URL necesita mantener las redirecciones al menos un año, y las posiciones se mueven mientras el cambio se procesa. Todo lo que se pase por alto en esa ventana cuesta tráfico ya pagado: una URL sin destino, un robots.txt de pruebas que llegó a producción, una etiqueta de medición que nunca entró en las plantillas nuevas.

Esta guía está escrita para quien aprueba el proyecto, no para quien ejecuta el despliegue. Cubre los cuatro tipos de migración y el riesgo de cada uno, el inventario previo, el mapa de redirecciones, las pruebas antes del lanzamiento, el orden del día de salida, los primeros 30 días y lo que debe figurar en el contrato.

Migración es una palabra para cuatro proyectos distintos, y no cargan el mismo riesgo. La primera pregunta es qué cambia de verdad: dónde se sirven los archivos, el sistema que genera las páginas, el nombre de dominio o las rutas de las URL. Un cambio de plataforma que conserva todas las URL es un fin de semana tranquilo. Un cambio de dominio que además renombra cada página termina en un informe de incidencias.

En la práctica casi todos los proyectos son una mezcla. Una empresa sustituye un CMS antiguo, marketing aprovecha para pedir otra navegación y el área legal pide abandonar el dominio de país. Tres migraciones se agrupan en un solo lanzamiento y, cuando el tráfico cae, nadie sabe cuál de las tres lo provocó.

Si te llevas una sola decisión de esta guía, que sea esta: cambia una variable cada vez siempre que el calendario lo permita. Primero mueve la plataforma sin tocar las URL, comprueba que los números aguantaron y después renombra la estructura en una segunda entrega. Cuesta un despliegue más y te da una respuesta cuando algo sale mal.

El tráfico no desaparece porque un sitio se haya movido. Desaparece porque unas pocas conexiones se rompieron y nadie las revisó. En la práctica se repiten cinco fallos en proyectos de cualquier tamaño, y cuatro de ellos los detecta un rastreo de una tarde.

URL sin destino. Cada dirección antigua que devuelve 404 pierde el posicionamiento, los enlaces y el tráfico de campaña que tenía. La solución es poco vistosa: una línea por URL antigua en un archivo de correspondencias, revisada por una persona.

Redirecciones que confluyen en una sola página. Una regla masiva que manda 400 fichas retiradas a la portada evita los 404 sobre el papel y destruye la relevancia al mismo tiempo. Google trata una redirección hacia una página no equivalente de forma parecida a un soft 404.

Cadenas y bucles. URL antigua a URL intermedia a URL final consume presupuesto de rastreo y frena a cada visitante que llega desde un enlace viejo. El objetivo es un solo salto, y las cadenas se auditan antes del lanzamiento, no después.

Bloqueos que salen del entorno de pruebas. Los entornos de preproducción están cerrados a los rastreadores a propósito. La línea Disallow: / y la etiqueta noindex son las dos piezas que jamás deben llegar a producción, y son la causa de las caídas más graves.

Enlaces internos que siguen apuntando al árbol antiguo. Menús, pies de página, enlaces dentro del texto y sitemaps XML con rutas viejas obligan a cada rastreador a pasar por la capa de redirecciones y diluyen el enlazado interno que has construido durante años.

Una migración merece su riesgo cuando la solución actual bloquea algo que el negocio necesita, no cuando el sitio parece anticuado. Tres detonantes justifican el proyecto por sí solos: la plataforma no soporta lo que vendes hoy, mantenerla cuesta más que sustituirla, o un cambio legal o de marca obliga a mover la dirección.

El argumento de la plataforma llega casi siempre tarde. En la práctica se reconoce así: añadir un tipo de página exige un desarrollador en vez de una editora, cada integración depende de un plugin que se rompe en la siguiente actualización, la velocidad se hunde con el tráfico de campaña y un segundo idioma se convierte en un segundo sitio. Son los síntomas de un sitio que se ha quedado pequeño para su base, y ningún presupuesto de diseño los arregla.

El argumento del coste sí se calcula. Suma licencias, suscripciones de plugins, alojamiento y las horas que tu equipo dedica a rodear el sistema. Compáralo con una reconstrucción repartida en tres años. Cuando la suma de los rodeos es la mayor, la decisión ya está tomada.

También hay malas razones, y salen caras: una dirección de marketing recién llegada que prefiere otra tecnología, una agencia que solo construye sobre un sistema, o un deseo de diseño que se resolvería con una actualización de plantillas. Si lo único que cambia es el aspecto, lo que necesitas es un rediseño, y la preparación de un rediseño es el camino más corto y más barato.

Planificar aquí es hacer inventario, y ocurre antes del diseño, antes del desarrollo y antes de elegir plataforma. Respondes a una pregunta: qué existe hoy y cuánto vale cada elemento. Quien se salta el inventario deja que el equipo decida por accidente, casi siempre migrando lo que era fácil de exportar.

Empieza por cuatro exportaciones. Un rastreo completo del sitio en producción da todas las URL con su código de estado, título y canónica. Search Console da todas las páginas con impresiones en doce meses. La analítica da páginas de entrada y conversiones por página. Una exportación de enlaces entrantes da las páginas a las que apuntan otros sitios, que son las que nunca pueden devolver 404.

Cruza las cuatro listas en una hoja y marca cada URL con una decisión: conservar, fusionar, renombrar o retirar. Una página sin tráfico, sin posiciones y sin enlaces puede retirarse. Una página con dos enlaces entrantes y sin tráfico necesita destino igualmente. Esa hoja es a la vez mapa de redirecciones, plan de contenidos y lista de aceptación.

El mismo repaso responde a lo que suele aparecer tarde: cuántos formularios existen y a dónde llegan los envíos, qué sistemas escriben en el sitio, cuántos idiomas hay, qué páginas llevan textos legales y quién gestiona los registros DNS.

El mapa de redirecciones es una tabla con una fila por URL antigua y un único destino en cada fila. Es el entregable que hay que pedir por su nombre, revisar antes del lanzamiento y conservar cuando el proyecto se cierra. Si una agencia no puede enseñarlo, la migración se está haciendo a ojo.

Tres reglas lo mantienen honesto. Cada destino tiene que ser la página equivalente más cercana, no una categoría ni la portada. Cada redirección es permanente, un 301, para que los buscadores trasladen las señales antiguas. Y cada URL antigua sin equivalente devuelve 410, que indica a los rastreadores que la página se retiró a propósito en lugar de fingir un traslado.

Revísalo tú, en una hoja de cálculo, en las filas que importan: tus 50 páginas con más tráfico, tus 50 con más enlaces y cualquier página que aparezca en una campaña activa o en un pie de correo. Es una hora de tu tiempo frente al coste de encontrar el error en la analítica tres meses después.

La visibilidad en buscadores se lleva la atención porque se mide en público. Los fallos que cuestan más dinero suelen ser invisibles durante semanas: un formulario de contacto que envía al vacío, un banner de consentimiento que bloquea toda la medición, o el correo transaccional que deja de llegar porque los registros DNS se movieron con el alojamiento.

El consentimiento merece línea propia. Rehacer un sitio implica rehacer el banner de cookies y, según el RGPD junto con la LSSI, las cookies no necesarias no pueden instalarse antes de que la persona acepte. Los equipos que reconstruyen la medición contrarreloj publican banners que o bien bloquean todo, y entonces el informe parece una caída de tráfico, o bien no bloquean nada, y entonces ya no es un problema de informes.

La tabla siguiente es la versión corta de la conversación de traspaso. Cada fila necesita responsable y una prueba en preproducción, no la promesa de revisarlo después del lanzamiento.

Probar antes de lanzar es comparar, no opinar. Rastreas el entorno de preproducción con la misma herramienta que usaste en producción y pones los dos inventarios uno al lado del otro. Todo lo que aparece en el rastreo antiguo y falta en el nuevo es o una retirada intencionada con 410 o un defecto, y no hay una tercera opción.

Cinco comprobaciones atrapan casi todo. Comparar número de páginas y títulos entre viejo y nuevo. Confirmar que cada canónica apunta al dominio de producción y no al de pruebas. Comprobar que hreflang es recíproco, porque Google exige que cada versión de idioma liste a todas las demás y a sí misma. Confirmar que no queda ninguna etiqueta noindex en páginas que deben indexarse. Y pasar el mapa de redirecciones por lotes: entregar las URL antiguas al rastreador y confirmar que cada una responde con un único 301 hacia una página viva.

El rendimiento entra en el mismo repaso. Las Core Web Vitals se evalúan en el percentil 75 de las cargas reales, así que una plantilla puede ir bien en tu portátil y suspender en campo. Mide las plantillas nuevas contra los umbrales publicados en web.dev y trata cualquier empeoramiento como bloqueante, no como una optimización para más adelante. Nuestras notas sobre velocidad de carga explican qué arreglar primero cuando la web nueva sale más lenta que la que sustituye.

La accesibilidad forma parte de la misma conversación desde 2025. La Directiva (UE) 2019/882 se aplica desde el 28 de junio de 2025, transpuesta en España por la Ley 11/2023, y un servicio reconstruido o modificado de forma sustancial cuenta como nuevo, no como heredado. Si vendes a consumidores, la migración es el momento de incorporar accesibilidad, no de aplazarla.

El día del lanzamiento falla por el orden más a menudo que por el código. La lista siguiente da por hecho que el sitio nuevo está aprobado en preproducción y que el mapa de redirecciones se ha verificado por lotes, de modo que el día en sí es mecánico.

1. Congelar la edición de contenidos en el sitio antiguo, avisando al equipo de cuándo empieza.
2. Rastrear por última vez el sitio en producción. Es la última foto con la que podrás comparar.
3. Bajar el TTL del DNS 48 horas antes para que el cambio se propague en minutos y no en un día.
4. Desplegar el sitio nuevo, todavía cerrado a rastreadores, y revisar los caminos críticos.
5. Retirar los bloqueos: primero robots.txt, después cualquier noindex que quede en plantillas.
6. Activar las redirecciones y probar 20 URL a mano, elegidas por tráfico y por enlaces.
7. Publicar el sitemap XML nuevo y enviarlo en Search Console.
8. Confirmar que analítica, consentimiento y formularios registran en producción, no solo en pruebas.
9. Vigilar los registros del servidor el resto del día y corregir los 404 que aparezcan.

Mantén el entorno antiguo accesible un tiempo después del cambio. No publicado, pero recuperable. Un plan de vuelta atrás que solo existe como frase en una propuesta no es un plan de vuelta atrás.

El primer mes decide si la migración fue un proyecto o un incidente. Los buscadores necesitan tiempo para volver a rastrear y procesar las direcciones nuevas, así que una bajada en las dos primeras semanas es normal y una bajada que se profundiza en la cuarta no lo es. Vigila grupos de páginas en vez del total del sitio, porque la media esconde justo la sección que se rompió.

Fija el ritmo de revisión antes de lanzar: a diario la primera semana, dos veces la segunda y después semanal. Dale a una persona la tarea de reportarlo. Las migraciones rara vez fallan a gritos, fallan como un descenso lento que todo el mundo supone que otro está mirando.

El coste sigue al tipo de traslado, no al número de páginas. Mover el alojamiento es un día de trabajo. Cambiar de plataforma conservando las URL es rehacer las plantillas más una exportación de datos. Cambiar de dominio y renombrar todas las URL añade la correspondencia, las pruebas y la ventana de vigilancia sobre lo anterior.

Los precios publicados sirven de referencia. Nuestros precios parten de €1.500 para una landing entregada en dos o tres días, €4.500 para un sitio corporativo de 10 a 30 páginas entregado en una a tres semanas y €9.000 para un portal de 50 páginas o más entregado en uno a tres meses. Migrar un sitio existente de tamaño equivalente cae en el mismo rango, con la correspondencia y la verificación encima, porque la reconstrucción es la misma y el inventario se suma. Cifras vigentes en agosto de 2026.

Lo que sorprende no es la construcción, son los dos extremos. El inventario y la correspondencia consumen de una a tres semanas de calendario en un sitio mediano porque necesitan aportaciones de marketing, comercial y legal, no más horas de desarrollo. La ventana de vigilancia posterior dura de cuatro a ocho semanas y tiene que estar en el contrato como trabajo pagado, no como cortesía.

Presupuesta aparte lo que siempre se olvida: rehacer la configuración de consentimiento, volver a probar cada formulario e integración, actualizar las URL de campaña en las plataformas de anuncios y de correo, y corregir los enlaces internos de artículos antiguos que apuntan a páginas renombradas.

Un contrato de migración que solo promete que el sitio nuevo se parecerá a los diseños deja fuera todo lo que puede salir mal. Los criterios de aceptación deberían poder comprobarse por alguien que no programa, lo que significa escribirlos como pruebas con resultado apto o no apto.

Pide estos siete por escrito. Un mapa de redirecciones que cubra todas las URL con tráfico o con un enlace entrante en los últimos doce meses, entregado para revisión antes del lanzamiento. La confirmación de que las URL antiguas responden con un único 301 hacia una página pertinente y de que las retiradas devuelven 410. La conservación de títulos, descripciones, canónicas y hreflang, o una justificación documentada donde cambien. Un plan de pruebas de medición con cada evento, objetivo y formulario que debe funcionar el día del lanzamiento. Una declaración sobre las obligaciones de accesibilidad cuando el sitio entre en el ámbito de la Ley 11/2023. Objetivos de rendimiento medidos en campo para las plantillas principales. Y una ventana de vigilancia nombrada, de cuatro a ocho semanas, con tiempos de respuesta para los defectos que aparezcan en ella.

Añade una cláusula que no cuesta nada y evita discusiones: el mapa de redirecciones, las exportaciones de rastreo y el plan de medición se entregan como archivos al cerrar el proyecto. Son documentos tuyos. La siguiente agencia los pedirá, y tú también.

Esta es la versión corta de todo lo anterior, en el orden en que ocurre el trabajo. Cópiala en tu gestor de proyectos y dale a cada línea un responsable y una fecha.

Antes de construir

• Rastrear el sitio en producción y exportar cada URL con estado, título y canónica.
• Exportar doce meses de Search Console, páginas de entrada de la analítica y dominios de referencia.
• Marcar cada URL: conservar, fusionar, renombrar o retirar.
• Listar formularios, integraciones, etiquetas de medición, feeds y páginas legales con sus responsables.
• Decidir si plataforma, estructura y dominio cambian en una entrega o en varias.

Antes del lanzamiento

• Mapa de redirecciones revisado a mano en las 50 páginas con más tráfico y las 50 con más enlaces.
• Preproducción rastreada y comparada con el inventario de producción.
• Canónicas apuntando a producción, hreflang recíproco, sin noindex perdidos.
• Formularios, rutas de consentimiento y eventos de analítica probados en preproducción.
• Core Web Vitals medidas en las plantillas nuevas, los empeoramientos son bloqueantes.
• Plan de vuelta atrás por escrito y TTL del DNS bajado.

Día del lanzamiento y después

• Bloqueo retirado, redirecciones activas, sitemap enviado.
• Veinte redirecciones probadas a mano, registros del servidor vigilados por 404.
• URL de destino de anuncios y correos apuntando a las direcciones nuevas.
• Ritmo de vigilancia acordado: a diario una semana, después semanal durante un mes.
• Redirecciones activas al menos un año y mapa archivado con la documentación del proyecto.

Este caso podemos contarlo desde dentro, porque es nuestro sitio. Vezert funciona en inglés, alemán, español, francés y neerlandés, y cada idioma tiene su propio slug en la URL en lugar de una página traducida colgando de una dirección inglesa. Cada vez que un slug cambia, la dirección antigua recibe una redirección permanente, y el archivo que las guarda contiene ahora mismo 329.

Dos decisiones hicieron el trabajo. Cada artículo lleva un identificador estable que nunca cambia, de modo que hreflang se genera a partir de ese identificador y no de un nombre de archivo, y renombrar una página en un idioma no puede romper la conexión con los otros cuatro. Y el cambio de slug emite su redirección de forma automática dentro del mismo guion que renombra el archivo, lo que elimina el paso que la gente olvida.

La lección sirve para cualquier migración: la redirección es parte del renombrado, no una tarea posterior. Cuando van separadas, alguien acaba renombrando una página un viernes y la redirección llega el lunes, si llega. Si tu traslado además suma idiomas, nuestra guía de sitios web multiidioma cubre las decisiones de estructura de URL que después cuesta revertir, y la estructura del sitio cubre el árbol de páginas al que el mapa de redirecciones tiene que ajustarse.