Cómo migrar una web vieja a una nueva sin perder posicionamiento

Las migraciones web mal hechas son responsables de algunos de los casos más dolorosos que veo. Una pyme con SEO razonable lleva años acumulando autoridad en Google, decide rediseñar la web (motivos legítimos: visual obsoleto, tecnología antigua, cambios de servicio) y, dos semanas después del lanzamiento, su tráfico orgánico ha caído un 60%. Recuperarlo cuesta meses.

La buena noticia: estos desastres son casi siempre evitables con un checklist disciplinado. La mala: la mayoría de proveedores que ejecutan la migración no lo siguen porque "es la primera vez que hago una migración con redirecciones 301 sistemáticas".

Vamos a la guía paso a paso. Es larga porque la migración es importante; no hay versión corta sin riesgo.

Antes de empezar: lo que vas a perder si te equivocas

Una migración mal hecha puede causar:

• Caída del 40-80% del tráfico orgánico durante 1-3 meses.
• Pérdida permanente de posicionamiento en keywords competitivas.
• Errores 404 masivos en enlaces externos que apuntan a tu web vieja.
• Pérdida de autoridad acumulada (backlinks que dejan de transmitir valor).
• Re-indexación lenta de las páginas nuevas (semanas en lugar de días).

Para una pyme que recibe 2.000 visitas orgánicas al mes, perder el 50% son 1.000 visitas/mes durante 3 meses = 3.000 visitas perdidas. A coste equivalente de Google Ads (1-2€/clic), son 3.000-6.000€ que la web nueva tarda en recuperar.

Lo que sigue es cómo evitar eso.

Fase 1 — Antes de tocar nada (1-2 semanas)

1. Auditar la web actual

Necesitas un inventario completo antes de cambiar nada:

• Listado de todas las URLs vivas de la web actual. Con Screaming Frog (gratuito hasta 500 URLs), Sitebulb o, en pyme pequeña, exportando el sitemap.xml.
• Tráfico de cada URL durante los últimos 12 meses, desde Google Analytics o Search Console. Las URLs con tráfico significativo son las que no puedes perder en la migración.
• Backlinks que apuntan a cada URL, desde Search Console (Enlaces > Páginas más enlazadas) o desde herramientas como Ahrefs/SEMrush si tienes acceso.
• Posicionamiento actual por keywords, desde Search Console (Rendimiento > Páginas).

Resultado: una tabla con URL antigua + tráfico mensual + número de backlinks + keywords principales.

2. Decidir el mapa de redirecciones

Para cada URL antigua, decide a qué URL nueva irá. No es opcional: cada URL antigua con tráfico o backlinks tiene que redirigir a una URL nueva equivalente.

Reglas:

• URL antigua → URL nueva con contenido equivalente: redirección 301. Lo deseable.
• URL antigua sin equivalente directo → URL más cercana: 301 a la página padre (categoría, índice de blog, home). Aceptable pero pierde algo de relevancia.
• URL antigua a la que no quieres redirigir: 410 (gone) si no debe volver. Nunca 404 silencioso si tenía tráfico o backlinks: estás tirando autoridad.

Resultado: una tabla con URL antigua → URL nueva → tipo de redirección.

3. Preparar entorno de staging

La web nueva debe estar completamente terminada en un entorno de pruebas antes de migrar. No vale "vamos lanzando y completamos después". La migración pone toda la web bajo lupa de Google; los cambios post-migración inestabilizan el reaprendizaje.

Importante: el staging debe estar bloqueado para Google (con noindex o restricción por IP/contraseña). Más de una migración ha empezado fatal porque el staging se indexó como contenido duplicado.

Fase 2 — Pre-lanzamiento (el día antes y horas previas)

4. Validar el staging contra el checklist técnico

Antes de lanzar, la web nueva debe cumplir:

• Estructura URL definitiva (no cambiarás slugs después).
• Title y description únicos en cada página, con keywords correctas.
• Canonical correcto en cada página.
• Schema.org actualizado y validado.
• Sitemap nuevo generado y correcto.
• robots.txt nuevo correcto.
• Core Web Vitals por encima del objetivo en móvil.
• Imágenes con alt correcto.
• No quedan enlaces internos apuntando a URLs antiguas.

5. Tener listo el archivo de redirecciones

El archivo de redirecciones (en .htaccess para Apache, en nginx.conf para Nginx, en plugin o reglas del CMS si no toleras tocar servidor) debe estar escrito, probado y listo para subir junto con la migración. No improvisado el día siguiente.

Cada redirección debe ser 301 (permanente), no 302 (temporal). Google trata las 302 como temporales y no transfiere autoridad hasta convencerse de que es definitiva.

6. Avisar a Google Search Console

Si vas a cambiar también el dominio (no solo URLs dentro del mismo): usa la herramienta "Change of address" en Search Console. Si solo cambian URLs internas: no hace falta, pero sí asegúrate de tener acceso a la nueva web verificado en Search Console antes de migrar.

Fase 3 — Migración (el día D)

7. Hacer backup completo de la web actual

Tanto archivos como base de datos. Es obvio pero conviene escribirlo: si algo sale mal a las 3 horas, vas a querer poder volver atrás en 30 minutos.

8. Lanzar la web nueva con las redirecciones activas

El despliegue debe ser atómico: en el momento en que la web nueva sustituye a la vieja, las redirecciones ya tienen que estar funcionando. No "primero la web, luego añadimos redirecciones mañana". Mañana ya hay 200 errores 404 indexados.

9. Verificar inmediatamente

Las primeras 2-3 horas post-lanzamiento:

• Probar 10-15 URLs antiguas con curl -I o navegador con DevTools y comprobar que devuelven 301 hacia la nueva URL correcta.
• Comprobar que la web nueva carga sin errores 500 en las páginas principales.
• Mirar Search Console (no aparecerá nada en horas, pero hay que estar atento al "Informe de cobertura" en los próximos días).

Fase 4 — Post-lanzamiento (primeras 4 semanas)

10. Enviar el sitemap nuevo a Search Console

Manualmente, sin esperar a que Google lo descubra. Acelera el reaprendizaje en días.

11. Solicitar la indexación de las páginas críticas

Para las 10-20 URLs con más tráfico previo, usar la opción "Solicitar indexación" en Search Console. Acelera la reindexación de las páginas más importantes.

12. Monitorizar el informe de cobertura semanalmente

Durante 4-6 semanas:

• Páginas indexadas: debería subir a niveles equivalentes a la web vieja en 4-6 semanas.
• Páginas con errores: identificar 404 inesperados (suelen ser URLs antiguas sin redirección).
• Páginas excluidas: revisar si hay "Página redirigida" (bien) vs "Página con error" (mal).

13. Monitorizar el tráfico orgánico

Lo normal en una migración bien hecha: una caída del 10-20% durante 2-4 semanas, recuperación al nivel anterior en 6-8 semanas. Si la caída es mayor o no se recupera, hay algo que arreglar.

Lo anormal: caída del 50%+ o caída que persiste tras 2 meses. Suele indicar redirecciones rotas o contenido desaparecido.

Lo que casi siempre se olvida (y sale caro)

• Imágenes con URLs antiguas: si tu web tenía imágenes en /wp-content/uploads/2023/... y la nueva las pone en otro path, los enlaces directos a imágenes (por ejemplo, los que aparecen en Google Imágenes) se rompen. Considera redirecciones también para imágenes.
• PDF y otros documentos: catálogos, papers, descargables. Si tenían tráfico orgánico, mantenlos accesibles desde la URL antigua o redirige.
• Feeds RSS: si tu blog tenía RSS, manténlo en la misma ruta o redirige. Hay suscriptores que dejarán de recibir tus posts si lo cambias sin avisar.
• Páginas de campaña antiguas: a veces hay landings de campañas pasadas con tráfico residual de pago. Decide si redirigir a equivalentes nuevos o a la home.

Conclusión

Una migración web no es "rehacer la web y subirla". Es una operación con etapas claras, checklist verificable y monitorización post-lanzamiento durante semanas. Hacerlo bien cuesta más horas que hacerlo mal; perderlo cuesta meses de tráfico y, a veces, posicionamiento que no vuelve.

Si estás planteándote rediseñar una web con SEO acumulado, este es el documento que vale la pena dejar al equipo o proveedor que vaya a ejecutar el trabajo. Y si lo hace alguien que te dice "no te preocupes, eso lo gestiona el CMS solo", busca otro proveedor antes de empezar.