Una migración web segura necesita tres cosas antes de tocar nada: un inventario completo de URLs que ya posicionan, un mapa de redirecciones 301 que conecte cada URL vieja con su nueva equivalente, y un plan de pruebas en staging que valide contenido, canonicals, sitemaps y datos estructurados antes del lanzamiento. Sin esto, el tráfico puede caer y la recuperación puede tardar semanas o meses.
Ideas clave
- El riesgo principal no es la nueva web: es perder URLs que ya traen tráfico.
- Las redirecciones 301 deben ser 1 a 1, no a la home ni a categorías genéricas.
- Después de migrar hay que monitorizar indexación, impressions y clics durante semanas.
Qué se pierde en una migración y por qué
El tráfico orgánico se pierde en una migración por cuatro causas principales: URLs que desaparecen sin redirección, contenido que cambia de dirección o se elimina, datos estructurados que se rompen y canonicals que dejan de apuntar al lugar correcto. Google necesita tiempo para entender la nueva estructura. Si las señales no son claras, desindexa URLs viejas antes de indexar las nuevas y el tráfico cae.
Una auditoría SEO previa ayuda a entender qué URLs traen impresiones y clics antes de tocar nada. Sin esa línea base, es imposible saber si la migración ha ido bien o mal. Antes de migrar, exporta datos de Search Console: URLs con impresiones, clics, posición media y consultas. Ese es tu punto de partida.
Inventario de URLs antes de tocar nada
El primer paso es listar todas las URLs que existen. No las que crees que importan, sino todas las que Google ha indexado. Esto incluye páginas de servicios, artículos, categorías, etiquetas, archivos paginados, variantes con parámetros y URLs que ya no existen pero siguen recibiendo enlaces externos.
| Fuente | Qué encontrarás |
|---|---|
| Google Search Console | URLs con impresiones, clics y posición media |
| Sitemap XML | URLs declaradas como indexables |
| Google Analytics | URLs que reciben tráfico orgánico real |
| Site:search en Google | URLs indexadas que quizá no esperabas |
| Bing Webmaster Tools | Cobertura complementaria |
| Herramientas de crawling (Screaming Frog) | URLs internas enlazadas desde la propia web |
| Backlinks externos | URLs que reciben enlaces desde otros sitios |
Con esta lista, clasifica cada URL: ¿se mantiene igual, se mueve a una nueva ruta o se elimina? Esa clasificación es la base del mapa de redirecciones.
Redirecciones 301: mapa, orden y errores comunes
Una redirección 301 le dice a Google que una URL se ha movido permanentemente. Transfiere la mayor parte de la autoridad y permite que la nueva URL herede el historial de la vieja. Los errores más comunes son:
- Redirigir todo a la home: Google interpreta esto como soft 404 y pierde la relevancia específica de cada URL.
- Redirigir a categorías genéricas: el usuario no encuentra lo que buscaba y rebota.
- Usar 302 en vez de 301: la 302 es temporal y no transfiere autoridad de forma permanente.
- Cadenas de redirecciones: A → B → C. Cada salto pierde señal. Mejor A → C directo.
- Olvidar URLs con parámetros: URLs con ?page=2 o ?sort=price que tenían tráfico y se quedan sin destino.
El mapa de redirecciones debe ser 1 a 1 siempre que sea posible. Si una URL antigua no tiene equivalente exacto, redirige a la página más cercana por tema, no a la home. Y si una URL antigua ya no tiene sentido, una página 410 es más honesta que una redirección engañosa.
Canonical, sitemaps y robots durante la migración
El canonical de cada página nueva debe apuntar a sí mismo. Si la página vieja sigue online temporalmente, su canonical debe apuntar a la nueva URL para que Google entienda la migración. Después de confirmar indexación, la URL vieja puede redirigir o eliminarse.
El sitemap XML debe actualizarse con las nuevas URLs y enviarse a Search Console inmediatamente después del lanzamiento. El robots.txt debe permitir el rastreo de todas las URLs nuevas y no bloquear accidentalmente secciones migradas. Si la arquitectura SEO cambia, asegúrate de que el menú, el footer y los enlaces internos apuntan a las nuevas URLs.
Contenido, metadatos y datos estructurados
El contenido visible debe migrarse completo: títulos, descripciones, encabezados, texto, imágenes, enlaces internos y datos estructurados. Los errores más frecuentes son:
- Title y meta description que no migran o se generan automáticamente sin revisión.
- JSON-LD que se pierde en el cambio de CMS y deja la página sin datos estructurados.
- Imágenes que cambian de ruta sin alt ni dimensiones.
- Enlaces internos que apuntan a URLs viejas sin redirigir.
- Contenido que se reescribe de forma tan distinta que Google lo interpreta como otra página.
Si la URL nueva tiene el mismo propósito que la vieja, el contenido debe ser equivalente. No es el momento de reescribir todo: primero migra, luego mejora.
Pruebas antes del cambio: staging, validación y pruebas
Antes de lanzar, prueba la nueva web en un entorno de staging o preproducción. No en producción. Verifica:
- Cada URL nueva responde con 200.
- Cada redirección funciona y va al destino correcto.
- Canonicals apuntan a la URL correcta.
- Sitemap XML está bien formado y contiene las URLs correctas.
- Datos estructurados son válidos (usa la herramienta de prueba de Google).
- Core Web Vitals son aceptables en la nueva versión.
- Enlaces internos no apuntan a 404 ni a URLs viejas.
- Robots.txt permite rastreo de todas las secciones.
Si la nueva web es más lenta que la anterior, revisa el rendimiento web antes de lanzar. Una migración que empeora Core Web Vitals puede afectar a posiciones.
El día de la migración: checklist de lanzamiento
| Paso | Acción |
|---|---|
| 1 | Subir la nueva web a producción |
| 2 | Activar redirecciones 301 |
| 3 | Actualizar sitemap XML y enviar a Search Console |
| 4 | Actualizar robots.txt si ha cambiado |
| 5 | Comprobar que la home y las páginas principales responden 200 |
| 6 | Hacer crawling completo con Screaming Frog o similar |
| 7 | Revisar Search Console en busca de errores de rastreo |
| 8 | Verificar que las redirecciones no encadenan |
| 9 | Comprobar datos estructurados en la herramienta de Google |
| 10 | Anunciar la migración internamente y documentar lo hecho |
Monitorización posterior: qué vigilar y durante cuánto tiempo
Después de migrar, monitoriza durante al menos 4 a 8 semanas. Los indicadores clave son:
- Indexación: Google debe indexar las nuevas URLs y desindexar las viejas progresivamente.
- Impresiones y clics en Search Console: si caen más de un 20% respecto a la línea base, hay un problema.
- Errores de rastreo: 404s, 500s y redirecciones rotas deben corregirse en 48 horas.
- Core Web Vitals: si empeoran, el rendimiento puede afectar a posiciones.
- Tráfico orgánico: comparar con la línea base pre-migración.
- Enlaces internos rotos: buscar enlaces a URLs viejas que no redirigen.
Si el tráfico cae, no entres en pánico. Revisa redirecciones, canonicals, contenido y datos estructurados. La mayoría de las caídas post-migración se recuperan en 2-4 semanas si las redirecciones y la estructura son correctas.
Como explicamos en cómo medir si una web genera oportunidades, separa señales de rastreo (indexación, errores) de señales de negocio (clics, consultas, leads). Una caída de indexación puede ser temporal; una caída de clics sostenida necesita investigación.
Errores frecuentes y cómo recuperar tráfico perdido
- No hacer inventario de URLs antes de migrar.
- Redirigir todo a la home en vez de 1 a 1.
- No actualizar el sitemap XML.
- Migrar contenido sin revisar metadatos ni datos estructurados.
- No probar en staging antes de lanzar.
- No monitorizar después de la migración.
- Reescribir contenido al mismo tiempo que se migra, sin poder aislar el efecto de cada cambio.
- No comunicar a Google la nueva estructura vía sitemap y Search Console.
Si el tráfico ya ha caído: revisa redirecciones primero, luego canonicals, luego datos estructurados, luego contenido. Muchas veces el problema es una redirección que no funciona o un canonical que apunta al sitio equivocado.
Checklist final de migración
| Fase | Debe estar listo |
|---|---|
| Antes | Inventario completo, mapa de redirecciones, línea base de Search Console |
| Antes | Staging probado: URLs, canonicals, sitemap, datos estructurados, rendimiento |
| Durante | Redirecciones activadas, sitemap enviado, home y páginas clave responden 200 |
| Después | Monitorización 4-8 semanas: indexación, errores, impresiones, clics, CWV |
| Después | Corrección de 404s y redirecciones rotas en 48 horas |
| Después | Documentación de lo hecho, lo que falló y lo aprendido |
Conclusiones
Una migración web segura no es una aventura: es un plan de supervivencia. Necesita inventario, redirecciones 1 a 1, pruebas en staging, monitorización post-lanzamiento y capacidad de corregir rápido. Si ya decidiste entre web nueva o mejorar la actual y el camino es migrar, este plan reduce el riesgo de perder tráfico y acelera la recuperación si algo falla. No promete cero riesgo: promete orden, comprobación y control.
Preguntas frecuentes
¿Cuánto tarda Google en procesar una migración?
Entre 2 y 8 semanas para la mayoría de webs pequeñas y medianas. Depende del tamaño, la frecuencia de rastreo y la claridad de las señales (redirecciones, sitemap, canonical).
¿Es mejor redirigir 301 o 302?
301 para migraciones permanentes. La 302 es temporal y no transfiere autoridad de forma estable. Usa 302 solo si la migración es provisional.
¿Qué pasa si no tengo mapa de redirecciones?
Google intentará averiguarlo, pero puede equivocarse. El resultado suele ser pérdida de tráfico y desindexación de URLs valiosas. Mejor preparar el mapa antes.
¿Puedo reescribir el contenido al mismo tiempo que migro?
No es recomendable. Si migras y reescribes a la vez, no sabrás qué causó una caída: la estructura o el contenido. Migra primero, mejora después.
¿Cuándo debo preocuparme por una caída de tráfico?
Si a las 2 semanas el tráfico orgánico cae más de un 20% respecto a la línea base y no recupera tendencia. Revisa redirecciones, canonicals y datos estructurados primero.
