Cómo migrar una web sin perder posicionamiento: el procedimiento completo

Qué cuenta como migración y por qué es arriesgada

En SEO se llama migración a cualquier cambio que altere de forma significativa cómo Google descubre, rastrea o interpreta tu web. No hace falta cambiar de dominio:

Tipo	Ejemplo	Riesgo principal
Cambio de dominio	de empresa.es a empresa.com	Todas las URLs cambian; las señales deben transferirse con redirecciones.
Cambio de protocolo o subdominio	HTTP a HTTPS, www a sin www	Redirecciones incompletas, contenido mixto, canonicals antiguos.
Cambio de estructura de URLs	/blog/2023/post a /recursos/post	Mapa de redirecciones incompleto, enlaces internos rotos.
Cambio de CMS o plataforma	De un CMS a otro, o a una tienda online alojada	Cambios no previstos en URLs, plantillas, metadatos y datos estructurados.
Rediseño o cambio de contenido	Nueva web con menos páginas o textos reducidos	Pérdida de contenido que posicionaba, cambios en enlazado interno.
Cambio de idiomas o países	Pasar de subdominios a carpetas por idioma	Errores de hreflang y de canonicalización.

Lo más frecuente es que se combinen varios tipos a la vez: nuevo CMS, nuevo diseño y nueva estructura. Cada capa añade riesgo, y cuando algo va mal es difícil saber qué lo ha causado. Si puedes separar los cambios en fases (por ejemplo, primero la plataforma manteniendo URLs, después la reestructuración), el diagnóstico es mucho más sencillo.

Conviene ajustar expectativas: incluso una migración bien ejecutada puede provocar fluctuaciones temporales mientras Google rastrea y reprocesa las nuevas URLs. El objetivo es que sean cortas y moderadas, no que no existan.

Paso 1: inventario completo de URLs

No puedes redirigir lo que no sabes que existe. El inventario debe reunir todas las URLs con valor, no solo las que aparecen en el menú. Fuentes que combinamos:

• Rastreo completo de la web actual con una herramienta de crawling (Screaming Frog, Sitebulb o similar), incluyendo imágenes y PDFs.
• Sitemaps XML actuales.
• Google Search Console: páginas con impresiones o clics en los últimos 16 meses (el máximo que guarda la herramienta) y el informe de indexación.
• Google Analytics: páginas de destino con sesiones orgánicas y conversiones.
• Herramientas de enlaces: URLs que reciben enlaces externos, incluidas páginas antiguas que ya devuelven 404 pero siguen enlazadas.
• Logs del servidor, si están disponibles: URLs que Googlebot visita realmente.

El resultado es una hoja con una fila por URL y columnas para tráfico orgánico, conversiones, enlaces externos, estado de indexación y tipo de página. Esa hoja se convierte en la base de todo lo demás y en tu "foto de antes" para comparar.

Antes del mapa: conservar, consolidar o eliminar

Una migración es una buena ocasión para ordenar el contenido, pero también la forma más rápida de perder lo que funcionaba. Con el inventario delante, clasifica cada URL en una de cuatro decisiones:

Decisión	Cuándo aplica	Qué hacer
Conservar	La página tiene tráfico, enlaces o conversiones, y su contenido sigue siendo válido.	Migrarla con el mismo contenido principal; mejorar después, no a la vez.
Consolidar	Varias páginas compiten por la misma intención o son variaciones casi iguales.	Fusionar en una página más completa y redirigir todas las antiguas a ella.
Actualizar	El tema es valioso pero el contenido está desfasado.	Reescribir manteniendo la URL o redirigiendo a la nueva versión.
Eliminar	Sin tráfico, sin enlaces, sin valor para el usuario (promociones caducadas, páginas de prueba).	404 o 410, y retirarla del enlazado interno y del sitemap.

No olvides los recursos que no son páginas. Las imágenes pueden recibir tráfico desde Google Imágenes y enlaces directos; si cambian de ruta, también conviene redirigirlas, sobre todo las que aparecen en el inventario con visitas o enlaces. Los PDFs (catálogos, fichas técnicas, guías) suelen acumular enlaces externos durante años y son los grandes olvidados. Y si cambias de nombre de marca a la vez que de dominio, recuerda que la entidad también cambia: actualiza los datos estructurados de Organization, los perfiles enlazados con sameAs y la información en directorios, para que buscadores y asistentes de IA conecten la marca nueva con la reputación de la antigua.

Paso 2: el mapa de redirecciones

El mapa asigna a cada URL antigua su destino en la web nueva. Las reglas básicas:

1. Redirección 301 (o 308) uno a uno hacia la página nueva más equivalente. Google trata las redirecciones permanentes como una señal fuerte de que la nueva URL es la canónica.
2. Nada de redirigir todo a la home. Google suele tratar las redirecciones masivas a una página no relacionada como errores soft 404, y se pierde el valor de esas URLs.
3. Sin cadenas. Si una URL ya redirigía a otra, actualiza la regla antigua para que apunte directamente al destino final.
4. Para contenido eliminado sin equivalente, un 404 o 410 es más honesto que una redirección forzada. Antes, comprueba que esa página no tenga tráfico ni enlaces relevantes; si los tiene, quizá merece conservar el contenido.
5. Reglas por patrón cuando sea posible (expresiones regulares en el servidor), pero valida cada patrón contra el inventario: los patrones generan errores en los casos límite.
6. Incluye parámetros, mayúsculas, barras finales y versiones antiguas (HTTP, www) que sigan recibiendo visitas.

URL antigua                          → URL nueva                         Tipo
/servicios/seo-local.html            → /servicios/seo-local/             301
/blog/2023/05/guia-hreflang/         → /recursos/blog/hreflang/          301
/promo-verano-2021/                  → (sin equivalente, sin enlaces)    410

Google recomienda mantener las redirecciones durante el mayor tiempo posible y, como mínimo, un año. En la práctica, si puedes, no las retires nunca: los enlaces externos y los marcadores de los usuarios seguirán apuntando a las URLs antiguas durante años.

Paso 3: entorno de pruebas protegido y QA

La web nueva debe construirse y probarse en un entorno de pruebas (staging) que Google no pueda indexar. Lo más fiable es protegerlo con autenticación HTTP o restricción por IP; además, puedes añadir noindex como segunda barrera. Bloquear solo con robots.txt no basta: impide rastrear, pero una URL bloqueada puede indexarse si recibe enlaces.

Aquí nace el error más clásico de las migraciones: el noindex o el Disallow: / del staging viaja con el código a producción. Anota en el checklist de lanzamiento, en negrita, quién lo retira y quién lo comprueba.

En staging se valida, comparando con el inventario:

• Contenido: que las páginas con tráfico conservan su texto principal, títulos, encabezados y datos estructurados, o los mejoran conscientemente.
• Metadatos: title, meta description, canonical (apuntando al dominio de producción, no al de staging), hreflang, directivas robots.
• Enlazado interno: que los enlaces apuntan a las URLs nuevas definitivas, sin pasar por redirecciones.
• Renderizado: que el contenido principal está en el HTML o se renderiza correctamente; prueba con la herramienta de inspección de URLs en cuanto sea posible.
• Rendimiento: que la web nueva no es más lenta que la antigua; revisa las Core Web Vitals en laboratorio.
• Analítica: que las etiquetas de GA4 y las conversiones están instaladas y funcionan con el banner de consentimiento.
• Redirecciones: que el mapa está cargado y probado (puedes rastrear la lista de URLs antiguas contra staging si el entorno lo permite).

Paso 4: checklist del día del lanzamiento

Elige un momento de baja actividad comercial, nunca justo antes de un fin de semana largo o de tu temporada alta, y con el equipo técnico disponible los días siguientes.

1. Copia de seguridad completa de la web antigua y exportación de su rastreo final.
2. Despliegue y retirada de la protección de staging, noindex y bloqueos de robots.txt.
3. Activación de las redirecciones; prueba inmediata de una muestra de URLs prioritarias y, después, de la lista completa con un rastreador en modo lista.
4. Verificación de robots.txt, sitemap XML con las URLs nuevas (solo 200 y canónicas) y envío en Search Console.
5. En cambios de dominio: verificar ambas propiedades en Search Console y usar la herramienta de cambio de dirección. Mantén también la propiedad antigua para seguir sus datos.
6. Comprobación de HTTPS, certificados y versiones canónicas (con y sin www).
7. Inspección de URLs clave en Search Console y solicitud de indexación de las más importantes.
8. Revisión de analítica en tiempo real: que se registran visitas y conversiones.
9. Actualización de enlaces que controlas: Perfil de Empresa de Google, redes sociales, campañas de Google Ads, firmas de correo, directorios.

Paso 5: monitorización después del lanzamiento

Las primeras semanas son críticas. Un calendario razonable:

Cuándo	Qué revisar
Primeras 24–72 horas	Errores 404 y 5xx en logs y rastreos, redirecciones que fallan, páginas con noindex, conversiones en analítica.
Primera semana	Estadísticas de rastreo e informe de indexación en Search Console, cobertura del sitemap nuevo, URLs antiguas que siguen apareciendo en resultados.
Semanas 2–8	Clics e impresiones comparados con el mismo periodo anterior (y el del año pasado si hay estacionalidad), por grupo de páginas; consultas que han caído; enlaces externos importantes que apuntan a 404.
Meses 3–6	Estabilización, oportunidades de mejora, limpieza de redirecciones en cadena que hayan aparecido.

Compara siempre por grupos de páginas (servicios, categorías, fichas, blog) y no solo el total. Una caída del total puede ocultar que una sección concreta ha perdido casi todo su tráfico por un patrón de redirección mal escrito.

Si el tráfico cae más allá de la fluctuación esperable, revisa en orden: primero, si Google puede rastrear e indexar las páginas nuevas (robots, noindex, canonicals); segundo, si las URLs antiguas redirigen bien y en un solo salto; tercero, si ha cambiado el contenido o el enlazado interno del grupo de páginas afectado. Solo cuando esas tres causas están descartadas tiene sentido buscar causas externas, como una actualización del algoritmo que coincidiera con el lanzamiento.

Fallos típicos y cómo detectarlos

• noindex o robots.txt de staging en producción. Se detecta en horas con un rastreo; tarda semanas en notarse en tráfico, cuando ya hay daño.
• Redirecciones a la home o a categorías genéricas. Aparecen como soft 404 en Search Console.
• Contenido recortado. El rediseño elimina los textos "largos" que eran justamente los que posicionaban. Compara longitud y encabezados de las páginas con más tráfico.
• Canonicals apuntando a staging o a la web antigua. Visibles en el rastreo y en la inspección de URLs.
• Enlaces internos a URLs antiguas que pasan por redirecciones o, peor, a 404.
• Pérdida de datos estructurados (productos, preguntas frecuentes, breadcrumbs) al cambiar de plantillas.
• Cambios en navegación facetada que generan miles de URLs nuevas rastreables y diluyen el presupuesto de rastreo; un riesgo típico en tiendas online.
• Analítica rota justo cuando más falta hace medir.
• Versiones de idioma descolgadas: hreflang apuntando a URLs antiguas o versiones que se lanzan semanas después. Lo tratamos en SEO multidioma y hreflang.

Plazos, roles y cuándo pedir ayuda

La fase SEO de una migración debería empezar cuando se define la nueva arquitectura, no la semana antes del lanzamiento. Como orientación, para una web corporativa de tamaño medio, el inventario y el mapa de redirecciones requieren varias semanas de trabajo coordinado con el equipo de desarrollo; en webs grandes o tiendas con miles de productos, más. Define desde el principio:

• Responsable SEO: inventario, mapa, criterios de QA y monitorización.
• Responsable técnico: implementación de redirecciones, entornos, despliegue.
• Responsable de contenido: que no se pierde texto valioso y que lo nuevo cumple los mínimos.
• Quién decide si se retrasa el lanzamiento cuando el QA no pasa.

Si tu equipo no ha hecho nunca una migración, o la web genera una parte importante de tus ventas por canal orgánico, merece la pena contar con apoyo externo especializado al menos para el inventario, el mapa y la revisión previa al lanzamiento. Muchos de los controles técnicos de este artículo están también en nuestra lista de verificación SEO.

Conclusión

Migrar sin perder SEO es, sobre todo, una cuestión de método: saber qué tienes, decidir a dónde va cada cosa, probarlo antes de que lo vea Google y vigilarlo después. Los fallos graves casi siempre son evitables y casi siempre se detectan con un rastreo a tiempo. Si estás planificando un cambio de web, cuéntanoslo antes de fijar la fecha de lanzamiento: revisar el plan al principio cuesta mucho menos que recuperar tráfico después. Empieza por una auditoría o escríbenos.