Este es un procedimiento práctico para planificar, probar, lanzar y vigilar la migración de tu web.
Un CMS nuevo, un alojamiento más rápido o un dominio más limpio pueden abrir años de crecimiento. También pueden romper en un solo lanzamiento años de visibilidad en buscadores, datos de conversión y confianza de los clientes.
Por eso "copiar el contenido, poner redirecciones y lanzar" no es un plan de migración.
Migrar una web es un cambio controlado en producción. Necesita un alcance definido, una línea base, un ensayo, criterios de lanzamiento medibles y responsables con nombre para lo que venga después.
Las redirecciones importan, pero también el proceso de compra, el consentimiento de cookies, las integraciones con el CRM, la accesibilidad, el rendimiento real para los usuarios y la pregunta que nadie quiere responder a las dos de la madrugada:
¿Qué nos haría parar o dar marcha atrás?
Este procedimiento reúne todas esas piezas.
¿Qué cuenta como migración web?
Una migración es cualquier cambio importante que pueda alterar cómo llegan a tu web y cómo la entienden los usuarios, los buscadores o los sistemas conectados.
Ejemplos habituales:
- Pasar a un dominio, subdominio o estructura de URL nuevos
- Cambiar de CMS, de framework o de plataforma de comercio
- Cambiar de alojamiento, servidores, CDN o arquitectura de despliegue
- Unir varias webs tras una adquisición o un cambio de marca
- Rediseñar plantillas y navegación
- Pasar de renderizado en el navegador a renderizado en servidor o estático
- Consolidar, reescribir o retirar grandes cantidades de contenido
- Cambiar el protocolo, la estructura internacional o la gestión de idiomas
No todas las migraciones tienen el mismo riesgo. Un cambio de alojamiento con las mismas URL no se parece a un cambio de marca que combina dominio, CMS, diseño y modelo de contenido nuevos.
Cuantas más variables cambies a la vez, más difícil será averiguar por qué se pierde tráfico.
Siempre que puedas, separa los cambios grandes. Las directrices de Google para mudar un sitio recomiendan cambiar una sola cosa cada vez. Una migración ya es un experimento: no le añadas variables innecesarias.
Empieza con un contrato de migración, no con una lista de tareas
Antes de que nadie prepare un fichero de redirecciones, escribe un contrato de migración de una página.
Debería responder a cinco preguntas:
- ¿Por qué migramos? Explica el problema de negocio, no solo la tecnología elegida.
- ¿Qué cambia? Dominios, URL, plantillas, contenido, medición, infraestructura e integraciones forman parte del alcance.
- ¿Qué no puede empeorar? Nombra los recorridos, páginas, mercados y sistemas críticos para el negocio.
- ¿Cómo mediremos el éxito? Usa métricas con línea base, objetivo, responsable y fecha de revisión.
- ¿Quién puede aprobar, pausar o revertir el lanzamiento? Decídelo antes de la ventana de publicación.
"Mejorar la web" no es un criterio de éxito.
Un buen criterio se parece más a esto:
| Área | Línea base | Requisito de lanzamiento | Objetivo a 30 días | Responsable |
|---|---|---|---|---|
| Compras completadas | 62 % | Ningún fallo en recorridos críticos | Al menos un 62 % | Producto |
| Contactos válidos registrados | 940 al mes | Los contactos de prueba llegan al CRM | Ninguna caída sin explicar | Marketing |
| URL que devuelven 5xx | 0,02 % | Por debajo del 0,1 % | Igual o por debajo de la línea base | Desarrollo |
| Páginas de entrada orgánica | 4.200 | Todas las páginas prioritarias mapeadas | Ninguna exclusión involuntaria | SEO |
| Accesibilidad | 14 problemas críticos conocidos | Ningún problema crítico nuevo | Pendientes existentes reducidos | Diseño y QA |
Las cifras exactas cambian de una organización a otra, pero la estructura obliga a tomar decisiones útiles.
También evita que el equipo dé por buena la migración porque la portada se ve bien mientras la medición de ingresos ha dejado de funcionar.
Fase 1: haz inventario de lo que tienes y decide qué merece la pena migrar
Construye un inventario completo a partir de más de una fuente.
Un rastreador muestra lo que se alcanza mediante enlaces, pero se le escapan las páginas huérfanas. La analítica encuentra las URL visitadas, pero puede omitir ficheros sin medición. Search Console y los datos de enlaces entrantes revelan páginas con demanda de búsqueda o autoridad externa. Las exportaciones del CMS y del servidor muestran lo que las demás herramientas no ven.
Incluye:
- Páginas HTML y sus versiones en otros idiomas
- Imágenes, vídeos, PDF y ficheros descargables
- Títulos, descripciones, encabezados y etiquetas canonical
- Datos estructurados y metadatos para redes sociales
- Enlaces internos y externos
- Formularios, buscador, calculadoras y áreas de cliente
- Eventos de analítica, reglas de consentimiento y configuración del gestor de etiquetas
- Feeds, sitemaps, reglas de robots y endpoints de API
- Responsables de cada página, tráfico, conversiones y enlaces entrantes
Después, clasifica cada elemento: mantener, mejorar, fusionar, archivar o eliminar.
Aquí la migración deja de ser una simple mudanza.
Dos artículos flojos que compiten por la misma búsqueda pueden funcionar mejor como una sola página sólida. Una página de campaña antigua sin tráfico ni enlaces quizá merezca un 410 Gone y no una redirección a la portada. Una página que convierte muy bien puede tener que migrar sin cambios aunque al equipo no le guste su diseño.
La automatización puede reunir las pruebas. No debería tomar la decisión editorial final. La relevancia la juzga una persona.
Fase 2: toma una línea base que puedas comparar después
Si solo empiezas a medir después del lanzamiento, cada anomalía se convierte en una discusión.
Recoge al menos cuatro semanas de datos normales, o un año completo si hay estacionalidad. Segméntalos por tipo de página, directorio, país, dispositivo y canal de captación, para que una pérdida grave en una sección no quede oculta por el crecimiento de otra.
Tu línea base debería cubrir:
- Clics orgánicos, impresiones, posiciones y páginas indexadas
- Sesiones, conversiones, ingresos y conversiones asistidas
- Códigos de estado HTTP, actividad de rastreo y errores del servidor
- Plantillas, número de palabras, títulos, encabezados y enlaces internos
- Rendimiento con usuarios reales, no solo pruebas de laboratorio
- Fallos de accesibilidad por plantilla y gravedad
- Entrega de formularios, pagos completados y otros recorridos críticos
- Capacidad de la infraestructura, latencia y tasa de errores
En rendimiento, compara la web nueva con la antigua y fija un presupuesto explícito.
Los umbrales actuales de "bueno" de las Core Web Vitals son:
- Largest Contentful Paint de 2,5 segundos o menos
- Interaction to Next Paint de 200 milisegundos o menos
- Cumulative Layout Shift de 0,1 o menos
Estos resultados se evalúan en el percentil 75, según web.dev.
Toma estas cifras como referencia útil, no como sustituto de tus propios datos de usuarios y conversiones.
Por último, guarda los rastreos y exportaciones originales. Cuando la web antigua desaparezca, serán tu registro para investigar.
Fase 3: diseña a la vez el destino y el mapa de redirecciones
La nueva arquitectura de información y el mapa de redirecciones son dos caras de la misma decisión:
¿Dónde debe vivir ahora cada intención de búsqueda antigua?
Asigna a cada URL antigua un resultado:
- La URL se mantiene igual
- Redirige de forma permanente a un equivalente cercano
- Su contenido se fusiona en un destino más amplio y relevante
- Se retira a propósito con un 404 Not Found o un 410 Gone
- Sigue disponible temporalmente hasta una fase posterior de la migración
Usa redirecciones 301 o 308 en el servidor para los cambios permanentes. Google interpreta una redirección permanente como señal de que el destino debe pasar a ser la URL canónica. Su documentación sobre redirecciones explica también cuándo conviene una redirección temporal.
Evita cuatro errores habituales.
1. Redirigir todo a la portada
Redirigir todas las páginas eliminadas a la portada frustra a los visitantes y oculta lo que buscaban.
Una página de producto debería llevar al producto sustituto más parecido o a la categoría correspondiente. La página de una oficina antigua debería llevar a la de la nueva ubicación. Un artículo retirado solo debería redirigir a un sucesor real cuando exista.
Si no hay un sustituto relevante, un 404 o un 410 honestos pueden ser mejores que una redirección engañosa.
2. Crear cadenas de redirecciones
Haz que las URL antiguas apunten directamente al destino final, sin pasar por ubicaciones intermedias.
Una cadena como:
Página A → Página B → Página C → Página D
genera peticiones innecesarias, ralentiza el rastreo y añade más puntos de fallo.
Lo normal debería ser:
Página A → Página D
3. Arreglar los enlaces internos con redirecciones
Actualiza los enlaces de la web nueva para que apunten directamente a su URL final.
Las redirecciones sirven para recoger a las personas y sistemas que entran por direcciones antiguas. No deberían sustituir para siempre el mantenimiento de los enlaces internos.
4. Olvidar los ficheros que no son HTML
Imágenes, vídeos y PDF pueden posicionar, conseguir enlaces y atraer tráfico cualificado.
Incluye los ficheros valiosos en el inventario y en el mapa, en lugar de tratarlos como ficheros anónimos que pueden desaparecer en la mudanza.
Trata el mapa completo como datos controlados: con historial de versiones, revisión por otra persona y pruebas automáticas de códigos de estado, destinos, bucles, cadenas y duplicados.
Fase 4: monta un entorno de pruebas igual que producción
El entorno de pruebas (staging) debe comportarse como producción sin ser público.
Protégelo con autenticación o con restricciones de red. Bloquearlo en robots.txt no es control de acceso, y una directiva noindex olvidada puede convertirse en un desastre el día del lanzamiento si se copia a producción.
Prepara los metadatos SEO en staging. No esperes a después del lanzamiento.
Títulos, descripciones, canonicals, anotaciones hreflang, datos estructurados y vistas previas para redes sociales deberían probarse antes de que lleguen usuarios y rastreadores. Lo seguro es mantener el entorno privado y dejar sus páginas listas para producción.
Prueba el sistema completo, no solo páginas sueltas:
- ¿Puede un visitante enviar un formulario?
- ¿Llega bien el registro enviado al CRM?
- ¿Los correos de confirmación salen desde el dominio correcto?
- ¿Funcionan el inicio de sesión, el buscador, la compra, las reservas y la recuperación de cuenta?
- ¿Los eventos de analítica se disparan una sola vez, con el estado de consentimiento y la atribución de campaña correctos?
- ¿Pueden completar los recorridos críticos quienes usan teclado o lector de pantalla?
- ¿El contenido importante sigue presente en el HTML que se entrega?
- ¿Las etiquetas canonical apuntan a las futuras URL de producción y no a staging?
- ¿Las versiones por idioma y región son recíprocas y válidas?
- ¿Pueden los editores crear una página nueva sin volver a introducir encabezados rotos, metadatos incorrectos o saltos de diseño?
En webs que dependen mucho de JavaScript, usa renderizado en servidor, renderizado estático o hidratación para el contenido importante.
Google puede procesar JavaScript, pero sus directrices actuales de SEO para JavaScript siguen indicando que el prerenderizado puede mejorar la velocidad para usuarios y rastreadores, y que no todos los bots ejecutan JavaScript.
Esto importa más allá de los buscadores tradicionales. Los generadores de vistas previas, las herramientas de accesibilidad, los servicios que despliegan enlaces, la monitorización y los rastreadores de IA pueden procesar las páginas de formas distintas.
Una web robusta no debería depender de que todos ejecuten a la perfección el mismo código en el navegador.
Fase 5: ensaya la migración
Una copia de seguridad no es un plan de vuelta atrás hasta que alguien la ha restaurado con éxito.
Haz al menos un ensayo parecido a producción con una copia de datos reales. Cronometra cada paso. Anota las acciones manuales. Compara los recuentos antes y después.
Confirma que el equipo puede restaurar bases de datos, ficheros, configuración y enrutamiento dentro del tiempo de recuperación exigido.
El ensayo debería dar como resultado un procedimiento con:
- Cada acción en orden
- La persona responsable
- Requisitos previos y prueba de que se ha completado
- La duración prevista
- Comprobaciones de validación
- Una condición de parada
- La acción de recuperación si el paso falla
Automatiza las comprobaciones repetibles.
Una buena batería de pruebas de migración puede frenar el lanzamiento si encuentra:
- Un bloqueo de indexación en producción
- Una redirección crítica que no coincide
- Una etiqueta canonical que apunta a staging
- Una etiqueta de analítica que falta
- Una página con el cuerpo vacío
- Una diferencia inesperada en el contenido de páginas prioritarias
- Datos estructurados rotos
- Un sitemap con URL redirigidas o no disponibles
En una web muy grande, plantéate migrar primero una sección de poco riesgo.
Una fase pequeña no revelará todos los problemas posibles, pero puede destapar puntos débiles en el mapa, el despliegue y la monitorización antes del lanzamiento principal.
Fase 6: usa requisitos de lanzamiento, no optimismo
Fija una revisión de "seguimos o no" antes de la ventana de publicación.
Un requisito de lanzamiento debe ser de sí o no y estar respaldado por pruebas.
"El equipo de SEO ha revisado la web" es vago.
"Las 2.400 redirecciones prioritarias devuelven un único salto permanente al destino aprobado" es un requisito de lanzamiento.
Requisitos recomendados:
- Una copia de seguridad hecha y restaurada con éxito
- Ningún fallo de seguridad crítico sin resolver
- Ningún fallo de accesibilidad crítico nuevo
- Los recorridos prioritarios funcionan de principio a fin
- Las pruebas de redirecciones y canonicals pasan
- robots.txt y sitemap XML de producción aprobados
- Analítica, consentimiento y medición de conversiones validados
- Resultados de prueba de carga aceptables y margen para el rastreo
- Certificados TLS, DNS y configuración de la CDN listos
- Atención al cliente, marketing y contactos de incidencias informados
- Paneles, alertas y responsables activos antes del cambio
Programa el lanzamiento en un momento previsible de poco tráfico, pero con las personas adecuadas disponibles.
"El domingo a medianoche" no es de bajo riesgo si nadie de pagos, analítica o contenidos puede responder.
Fase 7: lanza desde una sala de control compartida
Congela los cambios de contenido y configuración que no sean imprescindibles.
Trabaja con un solo procedimiento, un solo registro de decisiones y un solo canal de comunicación. Anota la hora de cada acción importante para poder cruzarla después con los registros y la analítica.
Justo después del cambio:
- Comprueba DNS, certificados, el comportamiento de la CDN y el dominio preferido.
- Confirma que producción se puede rastrear y que staging no es accesible públicamente.
- Prueba la portada, las páginas de entrada prioritarias y los recorridos críticos.
- Prueba una muestra de URL antiguas y lanza la prueba completa de redirecciones.
- Rastrea la web nueva en busca de errores 4xx, 5xx, de canonical, de hreflang y de enlaces internos.
- Verifica la analítica, las conversiones, el consentimiento y los eventos de servidor.
- Valida que el sitemap XML solo contiene URL canónicas que devuelven 200 OK.
- Verifica las propiedades antigua y nueva en Search Console y envía el sitemap.
- Usa la herramienta de cambio de dirección de Search Console cuando cambie el dominio y la mudanza cumpla los requisitos.
- Actualiza campañas de pago, plantillas de correo, perfiles y demás enlaces que controles.
Si la web tiene que estar caída un momento, devuelve un 503 Service Unavailable de verdad, en lugar de una página de error con estado 200 OK.
Una página que parece caída a un visitante pero indica éxito a las máquinas genera datos de monitorización engañosos y los rastreadores pueden interpretarla mal.
Fase 8: acompaña la migración al menos 30 días
La puesta en marcha es el inicio del periodo de observación, no el final del proyecto.
Usa un panel que reúna las señales técnicas, de búsqueda y de negocio:
- Tasa de 5xx, latencia y saturación de la infraestructura
- Volumen de 404 y principales páginas de origen
- Errores de redirección, bucles y destinos inesperados
- Clics, impresiones y cobertura de páginas indexadas
- Actividad de rastreo en URL antiguas y nuevas
- Conversiones, ingresos, calidad de los contactos y compras completadas
- Core Web Vitals reales por plantilla y dispositivo
- Volumen de eventos de analítica y cambios en la atribución
- Problemas de accesibilidad introducidos por contenido nuevo
Al principio, vigila con más frecuencia:
- Alertas continuas y varias revisiones manuales el día del lanzamiento
- Revisiones diarias la primera semana
- Revisiones semanales durante el primer mes
- Seguimiento más largo en migraciones grandes o complejas
Es normal que las búsquedas fluctúen mientras las páginas se vuelven a rastrear y procesar. Eso no significa que cualquier caída deba despacharse con un "Google se está asentando".
Investiga por directorio, tipo de página, dispositivo y mercado.
Una pérdida repentina limitada a una plantilla suele apuntar a una causa técnica concreta. Una caída de conversiones solo en móvil puede indicar un problema de diseño adaptable. Un descenso de contactos registrados con los envíos de formularios estables puede indicar una analítica rota más que una caída de la demanda.
Asigna a cada incidencia un responsable y una fecha límite.
Mantén el equipo de migración hasta que se cumplan los criterios de salida acordados. Después, pasa los paneles, las pruebas y los estándares de contenido a la operación normal.
Si no, la calidad empezará a degradarse en cuanto se disuelva el equipo del proyecto.
Volver atrás no es una máquina del tiempo
Revertir es imprescindible ante fallos catastróficos de la aplicación, de seguridad o de infraestructura.
Es menos sencillo en una migración de dominio o de URL cuando rastreadores y usuarios ya siguen las rutas nuevas.
Alternar varias veces entre URL antiguas y nuevas puede crear todavía más confusión. Decide de antemano qué fallos obligan a revertir y cuáles se corrigen hacia delante.
Por ejemplo:
- Un proceso de compra roto para todos los usuarios puede justificar revertir de inmediato.
- Un pequeño grupo de redirecciones incorrectas suele ser más seguro corregirlo hacia delante.
- Los datos de analítica perdidos no se recuperan revirtiendo la aplicación.
- Un staging expuesto públicamente necesita control de acceso y desindexación, no simplemente otro despliegue.
- Un componente inaccesible reutilizado en todas las páginas de compra puede obligar a frenar el lanzamiento.
- Que falte la descripción en algunos artículos con poco tráfico difícilmente justifica deshacer toda la migración.
Por eso tu plan debería incluir tanto una vuelta atrás técnica como una vía de corrección hacia delante, cada una con quién decide y con plazos.
Checklist resumida de migración web
Antes del lanzamiento
- Define el alcance, los responsables, las métricas de éxito y las condiciones de parada.
- Haz inventario de páginas, ficheros, metadatos, integraciones y medición.
- Clasifica el contenido en mantener, mejorar, fusionar, archivar o eliminar.
- Guarda las líneas base de rastreo, búsqueda, analítica, enlaces y rendimiento.
- Aprueba la nueva arquitectura y el mapa de URL página a página.
- Monta y prueba redirecciones, canonicals, sitemaps y reglas de robots.
- Protege staging mientras completas todos los metadatos de producción.
- Prueba los recorridos críticos, la analítica, el consentimiento y la accesibilidad.
- Ensaya la migración y restaura la copia de seguridad.
- Aprueba requisitos de "seguimos o no" basados en pruebas.
Durante el lanzamiento
- Congela los cambios ajenos y anota la cronología de la migración.
- Valida la infraestructura, la rastreabilidad y las páginas prioritarias.
- Lanza la batería de redirecciones y un rastreo completo de producción.
- Confirma los flujos de datos de formularios, compra, CRM, correo y analítica.
- Envía sitemaps limpios y los avisos pertinentes a los buscadores.
- Mantén disponibles a los responsables técnicos y de negocio.
Después del lanzamiento
- Vigila juntas las señales técnicas, de búsqueda y de conversión.
- Investiga las anomalías por tipo de página, directorio y dispositivo.
- Corrige cadenas de redirecciones, enlaces rotos, metadatos que faltan y fallos de medición.
- Mantén las redirecciones y el dominio antiguo bajo control de la organización.
- Mantén los responsables de cada incidencia hasta cumplir los criterios de salida.
- Convierte las comprobaciones de la migración en controles de calidad permanentes.
Qué es de verdad una migración con éxito
Una migración con éxito no es la que se lanza en la fecha prevista.
Es aquella en la que los clientes siguen pudiendo hacer lo que venían a hacer, los equipos pueden fiarse de sus datos, los buscadores entienden el cambio y la nueva plataforma deja margen para mejorar.
Los equipos más seguros no dependen de una noche de lanzamiento heroica. Reducen el número de cambios simultáneos, convierten las suposiciones en pruebas, ensayan la recuperación y siguen vigilando cuando los demás ya han pasado a otra cosa.
Esa es la diferencia entre mudar una web y migrar un negocio digital.
¿Preparado para planificar la migración de tu web?
Una buena migración debería mejorar tu web sin poner en riesgo innecesario el tráfico, los datos ni los recorridos críticos de tus clientes.
Tanto si cambias de dominio, pasas a un CMS nuevo o rehaces tu web, en DevOpWeb te ayudamos a gestionar la transición desde la planificación hasta el soporte posterior al lanzamiento.