Allá por 2021, un gran retailer del Reino Unido le encargó a Seahawk una migración de un sitio con poco más de 22,000 URLs indexadas. El equipo de desarrollo ya llevaba cuatro meses trabajando en la nueva plataforma. Tenían una fecha de lanzamiento. Tenían un sitio de staging. Lo que no tenían, y genuinamente no habían ni pensado en ello, era un mapa de redirecciones. Ni uno aproximado. Ni nada. El plan del líder de SEO era "manejarlo después del lanzamiento". Todavía pienso en esa reunión a veces.
Retrasamos el lanzamiento tres semanas. Reconstruimos la estrategia de redirecciones desde cero. El sitio se lanzó limpio, mantuvo el 94% de su tráfico orgánico durante la transición, y el cliente nos envió una botella de Scotch. Esas tres semanas de retraso los salvaron de lo que casi con certeza hubiera sido un ciclo de recuperación de seis meses.
Bien. Aquí está cómo construyes un mapa de redirecciones para un sitio de este tamaño, el proceso, las herramientas, la lógica de priorización y las partes que la mayoría de guías de migración discretamente dejan de lado.
---
Comienza con un inventario completo de URLs
No puedes mapear lo que no has contado. Antes que nada, necesitas una exportación completa de cada URL en vivo e indexada del sitio de origen. No solo el sitemap. Los sitemaps mienten, a menudo están desactualizados, excluyen URLs paginadas y rutinariamente omiten páginas de productos o archivos que han acumulado enlaces a lo largo de años.
Ejecuto Screaming Frog SEO Spider en modo lista contra una fuente combinada: el sitemap XML más una exportación de Google Search Console de todas las URLs indexadas. Esas dos fuentes juntas casi siempre sacan a la luz URLs que la otra se pierde. Para un sitio de 20,000 URLs, espera que el conteo real del crawl regrese en cualquier lugar entre 18,000 y 35,000, paginación, filtros, navegación por facetas, todo.Screaming Frog SEO Spider in list mode against a combined source: the XML sitemap plus a Google Search Console export of all indexed URLs. Those two sources together almost always surface URLs the other misses. For a 20,000-URL site, expect the real crawl count to come back anywhere between 18,000 and 35,000, pagination, filters, faceted nav, all of it.
Exporta el rastreo a una hoja de cálculo. Quieres como mínimo: URL, estado HTTP, etiqueta de título, H1, conteo de enlaces internos entrantes, y si aparece en GSC con impresiones. Esa última columna importa más de lo que la gente admite.
No olvides los 404 que todavía reciben tráfico
Mientras estés en GSC, extrae el informe de Cobertura y obtén cada URL que Google ha intentado rastrear en los últimos seis meses, incluyendo los 404s existentes. Algunas de esas páginas rotas todavía tienen backlinks externos apuntando hacia ellas. He visto un 404 con 40 dominios que lo referenciaban en un sitio que no había sido mantenido en dos años. Esos también necesitan un destino.
---
Categoriza Antes de Mapear
Una lista plana de 20,000 URLs es inutilizable. Lo primero que hago después de la exportación del crawl es categorizar cada URL por tipo, porque la lógica de mapeo es completamente diferente dependiendo de qué sea una URL.is.
Aquí está la taxonomía aproximada que uso:
- Páginas de productos, mapeo 1:1 a la nueva URL de producto donde sea posible, 1:1 map to new product URL where possible
- Páginas de categoría / colección, mapeo a la categoría nueva equivalente o padre más cercano, map to equivalent new category, or nearest parent
- Posts de blog / artículos, coincidencia por slug, similitud de título o cluster temático, match by slug, title similarity, or topic cluster
- Las páginas de etiquetas y archivos, generalmente se consolidan a categoría o página de inicio, usually consolidate to category or homepage
- URLs paginadas (ej. /category/shoes/page/3), casi siempre → categoría padre (e.g.
/category/shoes/page/3), almost always → parent category - URLs generadas por usuarios o de cuenta, generalmente se eliminan o redirigen a login, usually drop or redirect to login
- Páginas de campaña antiguas, evalúa el link equity antes de decidir, evaluate link equity before deciding
- Variantes duplicadas/canónicas, redirige a la canónica, sin excepciones, redirect to the canonical, full stop
Hacer este paso de categorización en Google Sheets con una columna desplegable toma un par de horas. Ahorra días. Una vez que todo está escrito, puedes procesar cada categoría con un conjunto de reglas diferente en lugar de tomar 20,000 decisiones individuales.
---
La fase de emparejamiento: automatizada primero, manual después
Aquí es donde la mayoría de equipos se equivocan. Intentan hacer coincidir manualmente cada URL. Con 20,000 filas eso no es exhaustivo, es un colapso nervioso esperando pasar.
Mi proceso es coincidencia automatizada primero, revisión manual segunda, solo para las URLs que realmente importan.
Coincidencia automatizada con VLOOKUP y Python
Para sitios donde la estructura de URL es similar entre lo antiguo y lo nuevo (por ejemplo, /products/red-shoes/ convirtiéndose en /shop/red-shoes/), un simple VLOOKUP en Sheets en la porción del slug resuelve el 60–70% de la lista en menos de diez minutos. El find/replace basado en Regex maneja cambios de patrones estructurales./products/red-shoes/ becoming /shop/red-shoes/), a simple VLOOKUP in Sheets on the slug portion sorts out 60–70% of the list in under ten minutes. Regex-based find/replace handles structural pattern changes.
Para migraciones más complejas, cambios de plataforma, rediseños completos de IA, uso un script corto en Python que hace coincidencia de cadena difusa en títulos de página entre la exportación de crawl antigua y el crawl del sitio nuevo. La librería thefuzz (anteriormente FuzzyWuzzy) funciona bien para esto. Cualquier cosa por encima de una puntuación de coincidencia del 85% se asigna automáticamente. Cualquier cosa por debajo va a una cola de revisión manual.thefuzz library (formerly FuzzyWuzzy) does this well. Anything above an 85% match score gets auto-assigned. Anything below goes into a manual review queue.
La cola manual suele ser el 20–30% de la lista. No todo necesita atención de personal senior.
Priorizando la cola manual
No todas las 20,000 URLs merecen el mismo tiempo. Califico cada URL por:
- Impresiones de GSC en los últimos 90 días, si está generando tráfico de búsqueda, es prioridad alta, if it's driving search traffic, it's high priority
- Número de dominios referentes (obtenido de Ahrefs), link equity que no puedes permitirte perder (pulled from Ahrefs), link equity you can't afford to drop
- Recuento de enlaces internos del crawl, señala importancia estructural, signals structural importance
- Atribución de ingresos: si el cliente puede proporcionar datos de ecommerce de GA4, las páginas que generan conversiones suben a la cima., if the client can provide GA4 ecommerce data, pages driving conversions jump to the top
Cualquier cosa con impresiones, backlinks o ingresos obtiene una decisión de mapeo manual. Todo lo demás puede seguir una alternativa basada en reglas (generalmente → categoría padre o página de inicio). Honestamente, para un sitio de 20,000 URLs, tal vez 800–1,200 URLs realmente necesitan atención individual. El resto es contenido de cola larga sin valor.
---
Estructuración del documento de mapa de redireccionamiento
El mapa final vive en una hoja de cálculo. Simple. No se necesita herramientas sofisticadas en esta etapa, el archivo solo tiene que ser inequívoco e importable.
Las columnas que uso:
- URL de origen (URL completa y absoluta de la página anterior)
- URL de destino (URL completa y absoluta de la página nueva)
- Tipo de redirección (301 en casi todos los casos, 302 solo para lo genuinamente temporal, que es raro).
- Tipo de coincidencia (exacta / patrón / regex)
- Categoría (de la taxonomía)
- Nivel de prioridad (Alto / Medio / Bajo, basado en la puntuación anterior).
- Estado (Pendiente / Confirmado / Implementado / Probado)
- Notas
Esa columna "Notas" está subestimada. Es donde pones cosas como "cliente confirmó que este producto está descontinuado, redirigir a categoría" o "backlink de Forbes apuntando aquí, mapear al equivalente más cercano, no a la homepage". Tu yo futuro te lo agradecerá.
Mantén las URLs de origen exactamente como aparecen, con o sin barra diagonal al final, con query strings si es aplicable. La inconsistencia aquí causa coincidencias parciales y redirecciones perdidas que son pesadillas de diagnosticar después del lanzamiento.
---
Redirecciones Basadas en Patrón vs. Exactas
A esta escala absolutamente necesitas redirecciones basadas en patrones, no solo coincidencias exactas. Escribir 20,000 líneas individuales de Redirect 301 en un archivo .htaccess funciona, pero es frágil, lento de procesar y un desastre de mantenimiento.Redirect 301 lines in an .htaccess file is, well, it works, but it's fragile, slow to parse, and a maintenance disaster.
En configuraciones Apache/WordPress, uso RewriteRules basadas en regex para patrones estructurales. Por ejemplo, si cada URL antigua bajo /old-blog/[post-slug]/ se asigna a /insights/[post-slug]/, eso es una regla, no 4,000.regex-based RewriteRules for structural patterns. For example, if every old URL under /old-blog/[post-slug]/ maps to /insights/[post-slug]/, that's one rule, not 4,000.
En Nginx, el mismo principio aplica con directivas rewrite. En Cloudflare, puedes usar Bulk Redirects (su nivel gratuito maneja hasta 20 reglas de coincidencia exacta; Workers o el producto Redirect Rules de pago manejan lógica de patrones a escala).rewrite directives. On Cloudflare, you can use Bulk Redirects (their free tier handles up to 20 exact-match rules; Workers or the paid Redirect Rules product handles pattern logic at scale).
El documento de mapeo debe indicar cuáles redirecciones son elegibles para patrones versus cuáles necesitan coincidencia exacta. Típicamente: publicaciones de blog, productos y páginas de categoría siguen patrones. Páginas de campañas antiguas, subdominios heredados y URLs históricas extrañas necesitan coincidencia exacta.
Prueba patrones antes de que se publiquen en vivo
Ejecuto el conjunto completo de reglas de patrón contra la lista de URLs en un ambiente de staging y registro cada respuesta de redirección con una herramienta como Redirect Checker (en lote) o un loop de curl en bash. Cada redirección en cadena (antigua → intermedia → nueva) es un problema; Google las sigue pero pierde algo de equity de enlace en cada salto. Aplánalo antes del lanzamiento.Redirect Checker (bulk) or a curl loop in bash. Every chain redirect (old → interim → new) is a problem, Google will follow chains but loses some link equity at each hop. Flatten them before launch.
---
Manejando la Cola Larga: La Estrategia de Respaldo
Lo que pasa es que en un sitio de 20,000 URLs, varios miles probablemente tengan cero tráfico, cero backlinks y cero razón para que alguien los visite de nuevo. Redirigirlos todos a la homepage crea un problema diferente: se ve manipulador para Google y confunde a los usuarios que siguieron un enlace específico.
Mi jerarquía de respaldo:
- Si la URL es una página de subcategoría sin tráfico y sin enlaces → redirige a la categoría padre
- Si es un archivo de etiqueta o autor → redirige al índice del blog
- Si es una página verdaderamente huérfana sin equivalente lógico → déjala en 404, o redirige suavemente a una página 404 bien diseñada con navegación
Una buena página 404 personalizada con búsqueda contextual y enlaces a categorías populares recupera más de estas visitas que una redirección genérica a la homepage. Construí una para un cliente de Seahawk hace un año, tuvo una tasa de "recuperación" del 28% (usuarios navegando desde la 404 a otra página) versus alrededor del 9% antes.
---
Validación post-lanzamiento
El mapa de redirecciones no termina en el lanzamiento. Las primeras 72 horas son críticas.
Configuré la verificación de propiedad en GSC el día anterior al lanzamiento, y luego monitoreo el reporte de Cobertura diariamente durante las primeras dos semanas. Los 404s nuevos que aparecen después del lanzamiento generalmente significan URLs que se colaron en el inventario, variantes de parámetros no autorizadas, alternativas hreflang, o URLs antiguas en campañas de email externas.
Para cada 404 nuevo que encuentro, agrego una redirección y la publico. Incendios pequeños. Quieres atraparlos antes de que Googlebot abandone esas URLs por completo.
También, revisa tus logs del servidor. No solo GSC. Googlebot visita URLs que no están enlazadas en ningún lado basándose en sus propios datos de rastreo histórico. El análisis de logs (yo uso GoAccess para lecturas rápidas en configuraciones de servidor más pequeñas) identifica 404s que GSC a veces tarda una semana o más en reportar.
---
FAQ
¿Cuánto tiempo realmente toma construir un mapa de redirecciones para 20,000 URLs?
Realísticamente, presupuesta dos a tres semanas de esfuerzo a tiempo parcial, quizás 40–60 horas en total dependiendo de qué tan desordenada sea la estructura de URLs del sitio antiguo. La fase de coincidencia automatizada es rápida. La revisión manual de URLs de alta prioridad y la fase de validación consumen la mayor parte del tiempo. Nunca dejes que un cliente o PM te diga que esto se puede hacer "en un fin de semana".
¿Debería redirigir cada URL, o está bien dejar que algunas muestren 404?
Está bien dejar que URLs genuinamente muertas, sin tráfico, sin backlinks muestren 404 naturalmente. Forzar una redirección a una página irrelevante crea una señal de soft-404 que potencialmente es peor. Haz triage sin piedad. Redirige lo que importa e invierte en una sólida experiencia de 404 personalizado para el resto.
¿Qué tipo de redirección debería usar, 301 o 302?
301 (permanente) para casi todo en una migración. Un 302 le dice a Google que el traslado es temporal y preservará la URL antigua en el índice. He visto agencias usar 302 "para estar seguras" y luego ver el dominio antiguo seguir posicionándose mientras el nuevo se estanca durante meses. Usa 301.
¿Puedo usar un plugin para gestionar 20,000 redirecciones en WordPress?
Sí, pero elige con cuidado. Redirection de John Godley maneja grandes volúmenes bien y almacena reglas en la base de datos en lugar de .htaccess, lo cual es mejor para el desempeño a escala. Para cualquier cosa por encima de ~10,000 redirecciones de coincidencia exacta, seguiría recomendando migrar reglas basadas en patrones a la configuración del servidor en lugar de depender completamente de un plugin.Redirection by John Godley handles large volumes well and stores rules in the database rather than .htaccess, which is better for performance at scale. For anything above ~10,000 exact-match redirects, I'd still recommend migrating pattern-based rules to server config rather than relying entirely on a plugin.
¿Cuál es el error más común que cometen los equipos en migraciones grandes?
Empezar el mapeo de redirecciones demasiado tarde. Lo veo constantemente: el trabajo de desarrollo está 90% hecho, el lanzamiento es en dos semanas, y alguien pregunta "¿y qué hay de las redirecciones?" En ese punto te ves obligado a improvisar e inevitablemente pierdes cosas. El mapeo de redirecciones debería empezar a construirse en el momento en que se confirme la estructura de URLs del sitio nuevo. Flujo de trabajo en paralelo, no una ocurrencia tardía.
---
Tres semanas de retraso, una botella de Scotch, 94% de retención de tráfico. Las matemáticas de hacerlo bien son bastante directas.
El mapeo de redirecciones no es la parte glamorosa de una migración. Nadie lo pone en el banner hero del estudio de caso. Pero es la diferencia entre una migración y una recuperación, y sé cuál de las dos preferiría estar facturando.