Una migración web es uno de los momentos de mayor riesgo SEO para cualquier sitio. Cambios de dominio, reestructuraciones de URL, migraciones de plataforma (WordPress a otro CMS, por ejemplo) o unificaciones de sitios pueden provocar caídas de tráfico orgánico del 30-80% si las redirecciones no se implementan correctamente. En esta guía encontrarás el proceso completo: desde la auditoría previa hasta la monitorización post-migración y la estrategia de borrado de redirects a largo plazo.
Tipos de migración y nivel de riesgo SEO
| Tipo de migración | Riesgo SEO | Redirects necesarios | Tiempo de recuperación estimado |
|---|---|---|---|
| HTTP → HTTPS (mismo dominio) | Bajo | Todas las URLs | 2-4 semanas |
| Cambio de estructura de URLs | Medio | Todas las URLs afectadas | 1-3 meses |
| Cambio de dominio | Alto | Todas las URLs del sitio | 3-6 meses |
| Migración de plataforma + URLs | Muy alto | Todas las URLs del sitio | 3-9 meses |
| Fusión de dos sitios | Muy alto | Todas las URLs de ambos sitios | 4-12 meses |
Fase 1: Auditoría de URLs antes de migrar
El primer paso es obtener un inventario completo de todas las URLs del sitio actual que tienen valor SEO. No todas las URLs merecen una redirección individual — las páginas sin tráfico orgánico, sin backlinks y sin importancia estructural pueden simplemente devolver un 404.
Qué URLs priorizar para redirección
- 1.URLs con tráfico orgánico en los últimos 12 meses (extrae de Google Search Console → Rendimiento → Páginas).
- 2.URLs con backlinks externos de valor (extrae de Ahrefs, Semrush o Google Search Console → Enlaces).
- 3.URLs enlazadas desde la navegación principal, el footer o el sitemap XML.
- 4.URLs que aparecen en resultados de búsqueda (las tienes en GSC → Páginas indexadas).
- 5.URLs con tráfico de referencia relevante (Analytics → Adquisición → Referral).
Regla práctica: si una URL ha tenido al menos 10 visitas orgánicas en los últimos 6 meses O tiene al menos un backlink externo, merece una redirección 301 individual hacia su equivalente en el nuevo sitio.
Fase 2: Mapeado de redirecciones
El mapeado consiste en asociar cada URL antigua con su equivalente en el nuevo sitio. Este proceso es manual y requiere criterio editorial — no se puede automatizar completamente.
Tipos de mapeado
- •Mapeado 1 a 1: cada URL antigua tiene una URL equivalente en el nuevo sitio. Es el caso ideal y el más sencillo de implementar.
- •Mapeado a categoría: una URL de producto descatalogado redirige a su categoría padre. Aceptable si no hay un equivalente relevante.
- •Mapeado a home: solo como último recurso y solo para URLs sin tráfico ni backlinks. Google considera el redirect a home como un "soft 404" para contenido que no tiene equivalente relevante.
- •Redirección wildcard: cuando toda una sección cambia de estructura de URL (/blog/año/mes/slug → /blog/slug), se puede usar una regla regex que capture el slug y lo reinserte en la nueva estructura.
Estructura del documento de mapeado
Crea una hoja de cálculo con estas columnas: URL origen, URL destino, Tipo de mapeado (1-a-1 / categoría / wildcard), Prioridad (alta/media/baja según tráfico+backlinks), Estado (pendiente/implementado/verificado) y Responsable.
Fase 3: Arquitectura de redirecciones
La arquitectura define cómo se implementan técnicamente las redirecciones. El objetivo es que cada URL antigua llegue al destino final en un único salto, sin cadenas.
Reglas específicas vs. reglas generales
Las reglas específicas (URL a URL exacta) siempre tienen prioridad sobre las reglas generales (regex o wildcard). Implementa primero las específicas y después las generales. Así evitas que una regla general intercepte una URL que tiene su propia redirección específica.
Ejemplo de implementación en Apache
# 1. Redirects específicos (mayor prioridad) Redirect 301 /blog/articulo-antiguo /recursos/articulo-nuevo Redirect 301 /productos/categoria-vieja /catalogo/nueva-categoria # 2. Regla wildcard para toda la sección /blog/ RewriteRule ^blog/(.*)$ /recursos/$1 [R=301,L] # 3. El resto de URLs /blog/ no mapeadas van a /recursos/ Redirect 301 /blog/ /recursos/
Fase 4: Testing en staging antes del lanzamiento
Nunca implementes las redirecciones directamente en producción sin haberlas testado. Un error en la configuración puede crear bucles de redirección o romper el acceso a secciones enteras del sitio.
Lista de verificación para testing en staging
- 1.Verifica una muestra representativa de URLs de cada tipo (específicas, wildcard, secciones completas).
- 2.Comprueba que no existen bucles de redirección (A → B → A).
- 3.Verifica que no existen cadenas (A → B → C cuando A debería ir directamente a C).
- 4.Confirma que los códigos HTTP son 301 (no 302) para redirecciones permanentes.
- 5.Prueba el comportamiento en versión móvil y desktop si tienes URLs m. separadas.
- 6.Verifica que los enlaces internos del nuevo sitio ya no pasan por las URLs antiguas.
- 7.Comprueba que el sitemap XML ya contiene solo las nuevas URLs.
- 8.Bloquea el staging para crawlers (robots.txt Disallow: /) durante el testing.
Usa el Analizador de cadenas de iRankly para verificar en bloque que las URLs más importantes del staging resuelven correctamente sin cadenas ni bucles.
Prueba la herramienta gratis
Analiza tus URLs con Analizador de cadenas de redirección de iRankly. Sin registro, sin tarjeta.
Fase 5: Monitorización post-migración
Los primeros 30-60 días después del lanzamiento son críticos. Google necesita tiempo para rastrear las nuevas URLs, procesar los redirects y actualizar su índice. Durante este período, monitoriza activamente las señales de advertencia.
Métricas a monitorizar semanalmente
- •Errores de cobertura en Google Search Console (URLs excluidas, errores 404, errores de servidor).
- •Impresiones y clics en GSC → Rendimiento. Una caída sostenida más allá de las 2-3 primeras semanas indica problemas.
- •Tráfico orgánico en Analytics segmentado por sección del sitio.
- •Posiciones de las keywords principales (herramienta de seguimiento de posiciones).
- •Errores de rastreo en GSC → Configuración → Estadísticas de rastreo.
- •Número de URLs indexadas (GSC → Índice → Páginas). Debería estabilizarse gradualmente.
Es normal ver una caída de tráfico del 10-30% durante las primeras 2-4 semanas tras una migración grande. Si la caída supera el 50% y no se recupera en 6-8 semanas, hay un problema que requiere intervención inmediata.
Cuándo y cómo eliminar las redirecciones antiguas
Las redirecciones no son gratuitas — consumen recursos del servidor y añaden latencia. Pero eliminarlas prematuramente puede provocar 404s que destruyan posicionamiento acumulado.
| Antigüedad del redirect | Acción recomendada |
|---|---|
| 0-6 meses | Mantener todos los redirects activos sin excepción |
| 6-12 meses | Eliminar los redirects de URLs sin tráfico ni backlinks (verificar en GSC y Ahrefs) |
| 12-24 meses | Eliminar la mayoría de redirects, conservar solo los que reciben tráfico o backlinks activos |
| Más de 24 meses | Revisar caso a caso. Solo conservar redirects de URLs con backlinks externos vigentes |
Antes de eliminar cualquier redirect, verifica en Google Search Console que la URL origen ya no aparece en informes de clics o impresiones, y en Ahrefs/Semrush que no tiene backlinks activos apuntando a ella.
Cómo implementar el mapa en tu plataforma, y qué vigilar después: