Checklist de migración web SEO con redirecciones 301
Checklist de 15 puntos para proteger URLs valiosas, evitar cadenas y detectar errores antes de cambiar DNS en una migración web.

Una migración web suele fallar menos por diseño y más por disciplina de redirecciones. Antes de cambiar DNS, la pregunta importante es:
¿Cada URL vieja importante llega al destino nuevo correcto en un salto limpio?
Esta checklist sirve para equipos que migran:
- a un dominio nuevo
- a un CMS nuevo
- de monolito a headless
- de subdominio a dominio raíz
- blogs, docs o centros de ayuda a una estructura nueva
- tiendas ecommerce con catálogo, campañas y categorías activas
Si necesitas un ejemplo de ecommerce, lee cómo migrar una tienda sin perder tráfico SEO. Si tu migración también cambia dominio y debe conservar rutas o UTM, ten cerca la guía para redireccionar un dominio manteniendo rutas y parámetros.
El objetivo no negociable
Antes del lanzamiento, busca que estas cinco cosas sean ciertas:
- las URLs viejas valiosas apuntan a las URLs nuevas correctas
- los cambios permanentes usan redirecciones permanentes
- la ruta resuelve en un solo salto cuando es posible
- los enlaces internos ya apuntan a URLs canónicas nuevas
- el monitoreo post-lanzamiento está listo antes de mover tráfico
Si falta una, el riesgo sube.

Checklist de redirecciones
1. Inventaría tus URLs actuales
No planifiques desde memoria.
Saca URLs de:
- sitemaps XML
- páginas de entrada en analítica
- páginas top en Search Console
- URLs de campañas pagadas
- plantillas de email
- backlinks y docs de partners
- archivos de blog y documentación
- links usados por soporte o ventas
Si una URL recibe tráfico orgánico, conversiones o soporte, entra al inventario.
2. Decide pronto el hostname canónico
Define el destino final antes de crear reglas:
https://sitio-nuevo.com- o
https://www.sitio-nuevo.com
No dejes decisiones de host abiertas. Así nacen cadenas como http -> https -> www -> final.
3. Mantén un mapa real en hoja o CSV
Como mínimo:
old_url,new_url,status,priority,owner,notes
https://sitio-viejo.com/precios,https://sitio-nuevo.com/precios,301,high,marketing,landing principal
https://sitio-viejo.com/docs/api,https://sitio-nuevo.com/docs/api,301,high,engineering,migración docsMarketing, SEO, ingeniería y soporte necesitan una sola fuente de verdad.
4. Protege primero las URLs de mayor valor
Prioriza:
- home
- pricing
- docs
- páginas orgánicas top
- páginas de campaña
- URLs de soporte enlazadas desde emails
- productos o categorías con ventas
No trates una página de archivo sin tráfico igual que una landing que genera demos.
5. Mapea cada URL al mejor destino
El objetivo no siempre es preservar ruta exacta. Es llevar al usuario al destino más útil.
Buenos ejemplos:
- producto viejo -> producto nuevo equivalente
- doc vieja -> doc nueva equivalente
- campaña retirada -> oferta actual más cercana
Malos ejemplos:
- todo -> home
- docs retiradas -> home
- deep links rotos -> categoría genérica sin contexto
6. Usa redirecciones permanentes para cambios permanentes
Si una URL no volverá, usa intención permanente, normalmente 301.
Si dudas entre códigos, revisa 301 vs 302 vs 307 vs 308. El punto es no dejar una migración permanente corriendo como temporal por meses.
7. Conserva estructura cuando tenga sentido
Si el sitio nuevo mantiene estructura parecida, los wildcards reducen trabajo manual:
/docs/* -> /docs/*
/blog/* -> /blog/*
/features/* -> /features/*Cuando la estructura cambió bastante, usa mapeos uno a uno para rutas importantes.
8. Conserva query strings importantes
Importa para:
- atribución de campañas
- parámetros de afiliados
- links de lifecycle
- parámetros funcionales de la app o página
No todo query string merece vivir para siempre, pero los importantes deben manejarse deliberadamente.
9. Elimina cadenas antes de lanzar
No esperes a que PageSpeed, Search Console o usuarios te muestren el problema.
Esto:
old-url -> old-intermediate -> final-urldebe quedar:
old-url -> final-urlPara depurar mejor, lee cadenas y bucles de redirección.
10. Prueba en staging o hosts controlados
Antes del corte público, prueba:
- home
- páginas top
- docs
- posts de blog
- URLs con parámetros
- rutas mobile si hay reglas por dispositivo
Usa navegador y consola:
curl -IL https://sitio-viejo.com/docs/api11. Actualiza enlaces internos
Las redirecciones son red de seguridad. Los enlaces internos deben apuntar directo a la URL final.
Incluye:
- navegación
- footer
- enlaces dentro de artículos
- CTAs de producto
- sidebar de docs
- plantillas de email si cambian URLs públicas
12. Actualiza sitemap, canonicals y navegación
El mapa de redirecciones no es toda la migración. Revisa:
- sitemap XML
- canonical tags
- hreflang si aplica
- navegación principal
- structured data con URLs
Si las redirecciones dicen una cosa y los canonicals otra, estás creando deuda de SEO.
13. Prepara monitoreo antes del lanzamiento
Plan para los primeros 7 a 14 días:
- revisar 404
- inspeccionar URLs redirigidas top
- monitorear tráfico de páginas valiosas
- revisar campañas activas
- confirmar links de docs y soporte
Aquí analítica, Redirect Checker y Broken Link Monitor pasan a ser parte del control de lanzamiento.
14. Mantén la capa vieja el tiempo suficiente
Un error común es tratar las redirecciones como tarea de una semana. Links antiguos pueden seguir recibiendo tráfico meses o años.
Especialmente:
- backlinks
- bookmarks
- PDFs
- docs de partners
- posts sociales viejos
Planifica para meses de tráfico residual, además del día de lanzamiento.
15. Documenta excepciones
No toda URL debe redirigir. Algunas deberían devolver 404 o 410. Algunas páginas legales o de soporte pueden necesitar manejo especial. Algunas rutas de app pueden requerir lógica por dispositivo.
Documenta esas decisiones para que no parezcan errores después.
Orden práctico de trabajo
Si necesitas la versión corta:
- exporta URLs
- elige host canónico
- crea mapa de redirecciones
- prueba URLs top
- elimina cadenas
- actualiza enlaces internos y sitemap
- lanza
- monitorea 404 y tráfico redirigido
Este orden mantiene alineados a ingeniería, marketing, SEO y soporte.
Dónde ayuda UrlEdge
UrlEdge encaja cuando una migración necesita:
- importación masiva de redirecciones
- forwarding wildcard con rutas
- propagación global rápida
- QA de redirecciones
- visibilidad de tráfico post-lanzamiento
También ayuda cuando no quieres repartir lógica entre código de app, proxies, plugins de CMS y forwarding de proveedor DNS.
FAQ
¿Cada URL vieja debe redirigir?
No. Algunas URLs obsoletas pueden devolver un error real. Pero las que aún tienen valor comercial o expectativa de usuario deben mapear a un destino relevante.
¿Redirigir todo al home sirve?
Normalmente no. Borra intención de ruta y frustra tanto a usuarios como a crawlers.
¿Cuánto tiempo debo conservar redirecciones de migración?
Más de lo que muchos equipos esperan. Las redirecciones importantes suelen necesitarse bastante después del mes de lanzamiento.
¿Qué pruebo si tengo poco tiempo?
Home, pricing, docs, páginas orgánicas top, links de campaña y URLs con más tráfico histórico.
Guías relacionadas de UrlEdge
- Gestión masiva de URLs
- Redirecciones 301 permanentes
- Cadenas y bucles de redirección
- Migración ecommerce con redirecciones
Referencias
¿Listo para ordenar tus redirecciones?
Usa UrlEdge para gestionar tráfico desde el edge sin tocar servidores.
EmpezarArtículos relacionados
Ver todo
Alternativa a Firebase Dynamic Links para apps y campañas
Firebase Dynamic Links dejó de funcionar el 25 de agosto de 2025. Reemplázalo con links de marca, routing por dispositivo y fallbacks claros.

Redirección 301 vs 302 vs 307 vs 308: cuál usar
Usa 301 o 308 para cambios permanentes, y 302 o 307 para cambios temporales. La diferencia crítica es si el método HTTP debe conservarse.