UrlEdge
Volver al blog
2026-03-12 UrlEdge Editorial6 min read

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.

Equipo colaborando alrededor de una laptop para planificar y verificar una checklist de 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:

  1. las URLs viejas valiosas apuntan a las URLs nuevas correctas
  2. los cambios permanentes usan redirecciones permanentes
  3. la ruta resuelve en un solo salto cuando es posible
  4. los enlaces internos ya apuntan a URLs canónicas nuevas
  5. el monitoreo post-lanzamiento está listo antes de mover tráfico

Si falta una, el riesgo sube.

Equipo planificando una migración web alrededor de una laptop para revisar redirecciones, QA y pasos de lanzamiento

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 docs

Marketing, 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-url

debe quedar:

old-url -> final-url

Para 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/api

11. 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:

  1. exporta URLs
  2. elige host canónico
  3. crea mapa de redirecciones
  4. prueba URLs top
  5. elimina cadenas
  6. actualiza enlaces internos y sitemap
  7. lanza
  8. 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

Referencias

¿Listo para ordenar tus redirecciones?

Usa UrlEdge para gestionar tráfico desde el edge sin tocar servidores.

Empezar

Artículos relacionados

Ver todo