Hace tres años me entregaron una migración que ya estaba en vivo. Sin ambiente de prueba. Sin mapa de redirecciones. Un catálogo de comercio electrónico de 22,000 páginas que alguien acababa de apuntar a un nuevo dominio y llamó "listo". El tráfico orgánico cayó 74% en seis semanas. El cliente me llamó en pánico moderado, y pasé la mejor parte de cuatro meses desenredándolo.
Punto clave: Las migraciones de sitios pierden posicionamiento por auditorías de redirecciones omitidas, no por cambios de plataforma; la lista de verificación incluye mapeo de redirecciones, transporte de metadatos, continuidad de esquema, y verificación posterior al lanzamiento.
Esa experiencia, por dolorosa que haya sido, es básicamente por qué existe esta lista. Desde entonces he migrado sitios que van desde 800 páginas de folleto hasta un editor de 31,000 páginas con subdominios regionales, y los fundamentos son los mismos cada vez. Comete el orden incorrecto, saltate un paso, y Google te lo dirá en Search Console de la manera más desagradable posible.
Así que aquí está. El checklist actual que uso en Seahawk Media, no un marco teórico.
---
1. Comienza con un Rastreo Completo Antes de Tocar Nada
¿Obvio? Sí. ¿Omitido? Constantemente.
Antes de que se mueva un solo archivo, rastreo todo el sitio en vivo con Screaming Frog SEO Spider. En un sitio de 20,000 páginas esto toma un par de horas, normalmente lo lanzo de noche con el rastreo guardado en modo base de datos para que la memoria no se vuelva un problema. Lo que estoy capturando:
- Cada URL indexable (la versión canónica, no ruido de paginación)
- Códigos de respuesta de todo tipo, 200s, 301s, 302s, 404s, todo
- Estructura de enlaces internos existente
- Etiquetas canónicas, atributos hreflang si aplica
- Títulos de página y meta descripciones (para verificar que sobrevivan la migración)
Exporto el rastreo completo a CSV y lo conservo. Este es mi punto de referencia. Es el documento que compararé tres semanas después de que el nuevo sitio esté en vivo.
Mucha gente se salta este paso porque "ya conocemos el sitio." No, no lo conocen. Yo creía que conocía el sitio de un cliente de viajes allá en 2021, resultó que tenían 4,000 URLs siendo servidas desde un subdirectorio de un CMS heredado que nadie había mencionado en el brief. Lo encontré en el rastreo. Hubiera sido un desastre.
No olvides los propios datos de Google
Extrae todo de Google Search Console, datos de rendimiento de los últimos 16 meses como mínimo, el reporte de cobertura de índice, cualquier acción manual, todos los sitemaps. Y extrae de Google Analytics (GA4 ahora, obviamente) para tener tus benchmarks de tráfico orgánico cerrados antes de que algo cambie. Las capturas de pantalla funcionan bien aquí; también exporto los CSVs en bruto.
---
2. Construye el Mapa de Redirecciones. Luego Verifica de Nuevo.
Aquí es donde las migraciones viven o mueren. En sitios grandes, el mapa de redirecciones es una hoja de cálculo real, normalmente compartida en Google Sheets con el cliente, su equipo de desarrollo, y cualquiera que pudiera sobrescribir accidentalmente una fórmula a las 11pm.
La estructura es simple:
- Columna A: URL Anterior (exacta, incluyendo barra diagonal final o su ausencia)
- Columna B: URL Nueva (exacta)
- Columna C: Tipo de redirección (301 en casi todos los casos)
- Columna D: Estado (mapeado, verificado, en vivo)
- Columna E: Notas (redirecciones generales, consolidaciones de categorías, descartes intencionales)
En un sitio de 20,000 páginas obviamente no puedes mapear cada URL individualmente. Aquí está el orden en que trabajo:
- Mapea primero todas las URLs con mejor rendimiento (por tráfico orgánico de GSC, las top 500 usualmente generan 80%+ del tráfico)
- Mapea páginas de categoría y taxonomía
- Mapea cualquier URL que tenga backlinks significativos (usa Ahrefs para esto, filtra por dominios de referencia, no solo links en bruto)
- Maneja redirecciones basadas en patrones para todo lo demás (por ejemplo, /product/old-slug/ → /shop/old-slug/)
- Documenta 410s intencionales para páginas que estás retirando
Las redirecciones basadas en patrones son lo que la mayoría de desarrolladores junior hacen mal. Escribirán una regla con comodín demasiado amplia y accidentalmente redirigirán URLs que no tenían intención de redirigir. Prueba cada regla de patrón en staging antes de que vaya cerca de producción.
---
3. Staging No Es Opcional
Voy a mantener esto breve porque no debería necesitar mucha explicación. Cada migración obtiene un entorno de staging. Punto.
Seahawk tuvo un cliente fintech en 2022 que se opuso a esto, quería "simplemente hacerlo en vivo porque el sitio es pequeño." El sitio tenía 6,000 páginas. Lo hicimos en staging. Encontramos un conflicto de plugin que estaba eliminando etiquetas canónicas de todas las páginas de productos. Hubiera sido invisible hasta que Google rastreara todo de nuevo, lo que en un dominio de baja autoridad puede tomar semanas.
En staging estás verificando:
- Todos los redirects se ejecutan correctamente (uso Screaming Frog de nuevo, apuntado a staging, para verificar el mapa de redirects en lote)
- El robots.txt está bloqueando el entorno de staging de la indexación (importante, usa Disallow: / pero también añade un header noindex para doble protección)
- El nuevo sitemap es preciso y no contiene URLs de staging
- Las etiquetas canónicas apuntan a las URLs de producción correctas
- Establecer baselines de velocidad de página con PageSpeed Insights, las migraciones se usan frecuentemente como oportunidades de rediseño, y los rediseños destruyen constantemente Core Web Vitals
---
4. La Secuencia de Go-Live (El Orden Importa Más de Lo Que Crees)
Esta es la parte donde la gente improvisa y se causa problemas a sí misma. Hay un orden específico. No me desvío de él.
Paso 1: Previa al lanzamiento (48 horas antes)
- Reduce el TTL en todos los registros DNS a 300 segundos (5 minutos). Acelera significativamente la propagación.
- Briefea al cliente: sin cambios de contenido, sin nuevas páginas, sin actualizaciones de plugins durante la ventana de migración.
- Notifica a cualquier integración de terceros (CDNs, plataformas publicitarias, herramientas de monitoreo) sobre el cambio próximo.
Paso 2: Ventana de lanzamiento
- Actualiza el DNS
- Despliega los redirects antes de que el contenido nuevo se propague completamente, los redirects deben estar activos a nivel de servidor, no solo en WordPress
- Habilita el nuevo sitemap, desactiva el antiguo
- Verifica que robots.txt sea correcto (archivo de producción, no el de staging)
Paso 3: Inmediatamente después del lanzamiento
- Rastrear el nuevo sitio dentro de dos horas. Screaming Frog, apuntando a producción, respetando redirecciones. Busco 404s inesperados, cadenas de redirecciones más largas de dos saltos, y cualquier página que debería ser indexable mostrando una etiqueta noindex.
- Enviar el nuevo sitemap en Search Console
- Obtener la página de inicio a través de la herramienta URL Inspection de GSC para solicitar a Googlebot que la visite
Una cosa que siempre señalo a los clientes: Google no va a reflejar inmediatamente las nuevas URLs en los resultados de búsqueda. Hay un retraso en el rastreo y reprocesamiento. En un sitio grande, presupuesta entre dos y seis semanas antes de tener una imagen clara. Entrar en pánico el día cuatro porque los rankings se movieron es normal, no significa que algo esté roto.
---
5. Auditoría de Cadenas de Redirecciones (El Paso que la Mayoría de Agencias Facturan por Separado)
Las cadenas de redirecciones son un sangrado lento. Una URL que va A → B → C → D está haciendo que Googlebot haga trabajo extra, y también está diluyendo el equity de enlaces a través de múltiples saltos. En un sitio que ha tenido múltiples migraciones previas o cambios de plataforma, las cadenas pueden ser sorprendentemente profundas.
Post-lanzamiento, exporto el rastreo completo de Screaming Frog y filtro por cadenas de redirecciones. Cualquier cosa más allá de dos saltos se colapsa. Si la URL original estaba en el mapa de redirecciones, la actualizo para que apunte directamente al destino final. Si era una cadena heredada de una migración que nadie documentó, la agrego.
Este paso solo, en un cliente que migramos de Magento a WooCommerce a principios de 2023, tomó dos días. Habían tenido tres migraciones en ocho años. Algunas URLs pasaban por cinco redirects antes de llegar a la página correcta. Las colapsamos todas, y sus métricas de crawl budget en Search Console mejoraron notablemente dentro de un mes.
---
6. Verificación de Contenido a Escala
No puedes revisar manualmente 20,000 páginas. Pero puedes verificar sistemáticamente lo que importa.
Esto es lo que verifico en las primeras dos semanas después del lanzamiento:
- Etiquetas de título y meta descripciones: Compara una muestra aleatoria de 200 páginas contra la exportación de Screaming Frog previa a la migración. Los desajustes se marcan inmediatamente.
- Datos estructurados: Ejecuta una muestra de páginas de productos, páginas de artículos y la página de inicio a través de Google's Rich Results Test. Las migraciones rompen el markup de esquema más frecuentemente de lo que piensas, especialmente si el tema nuevo usa un plugin diferente.
- Enlaces internos: Rastreo de Screaming Frog, filtra por inlinks. Las páginas de alto valor deben mantener recuentos sólidos de enlaces internos. Si una página de categoría que previamente tenía 400 enlaces internos ahora tiene 12, algo salió mal en la plantilla.
- Imágenes y texto alternativo: No es estrictamente crítico para SEO, pero las imágenes rotas afectan las señales de experiencia del usuario y son fáciles de pasar por alto en sitios basados en plantillas.
---
7. Monitoreo para los 90 Días Posteriores
La migración no termina el día del lanzamiento. Se extiende por un mínimo de 90 días.
Establecí cadencias de reporte semanales con el cliente durante el primer mes, luego quincenales después. Esto es lo que estoy monitoreando:
- GSC Index Coverage: ¿Se está recuperando el número de páginas indexadas hacia el conteo anterior a la migración? Una caída significativa que persiste más allá de tres semanas necesita investigación.
- Tráfico orgánico vs. baseline: Segmentado por tipo de página de destino (producto, categoría, blog). Las caídas de tráfico suelen ser desiguales, a veces las páginas de categoría se desploman mientras que las páginas de producto se mantienen.
- Crawl budget: El reporte de estadísticas de crawl de GSC muestra el promedio de páginas rastreadas por día y los tiempos de respuesta del servidor. Si Googlebot está recibiendo muchos 404s, se ve aquí.
- Seguimiento de posición de ranking: Uso una combinación del rank tracking de Ahrefs y el reporte de desempeño de Google Search Console. La volatilidad de rankings en las primeras dos a tres semanas es común y no es necesariamente un problema. Las caídas sostenidas más allá de la semana cuatro justifican una acción.
- Perfil de backlinks: Usando Ahrefs, verifica que los backlinks de alto valor que apunten a URLs antiguas estén ya redirigidos correctamente o marcados para contacto y actualización.
¿La verdad honesta? La mayoría de los problemas SEO en migraciones son detectables dentro de 30 días si estás monitoreando las métricas correctas. Los que sorprenden a la gente son aquellos donde nadie configuró el monitoreo y el cliente se da cuenta ocho meses después.
---
8. Las Cosas en las que He Fallado (Para que Tú No Tengas Que Hacerlo)
Allá por 2019, me perdí una implementación de hreflang en una migración para un cliente con subcarpetas de Reino Unido, Australia y Canadá. Las etiquetas canonical eran correctas. Los redirects funcionaban bien. Pero las anotaciones de hreflang en el nuevo sitio tenían los códigos de región equivocados, en-au en lugar de en-AU (aparentemente las mayúsculas importan en algunas implementaciones). Google comenzó a servir las páginas del Reino Unido a buscadores australianos. Nos tomó seis semanas descubrir por qué el tráfico orgánico australiano se había reducido a la mitad. Desde entonces hemos tenido un paso de validación de hreflang en cada migración internacional.
Otro más: sitemaps XML que contienen URLs con noindex. Suena como una inconsistencia menor pero envía señales conflictivas y definitivamente vale la pena limpiar. Screaming Frog puede auditar tu sitemap e identificar cualquier URL que devuelva una etiqueta noindex.
Y probablemente la lección más cara: no tener un plan de reversión. En una migración que está saliendo mal, la capacidad de cambiar el DNS de vuelta al servidor antiguo en una hora vale su peso en oro. Siempre insisto en que el entorno antiguo siga activo e intacto durante al menos 30 días después de la migración. Los clientes a veces se quejan del costo del hosting. Les explico cuánto cuesta en ingresos una caída del 70% en tráfico y dejan de quejarse.
---
FAQ
¿Cuánto tiempo toma realmente planificar una migración de sitio de 20,000 páginas?
¿Realísticamente? Seis a diez semanas de preparación antes de la fecha de lanzamiento. Solo el mapa de redirecciones en un sitio de ese tamaño puede tomar dos a tres semanas construirlo correctamente, especialmente si estás auditando backlinks para cada URL. Apresurarse en la preparación es cómo terminas gastando meses en recuperación.
¿Necesito enviar un archivo disavow después de una migración?
Usualmente no, a menos que el dominio antiguo tuviera enlaces tóxicos y estés migrando específicamente para escapar de ellos. Si estás migrando a un nuevo dominio y quieres un perfil de enlaces limpio, maneja el disavow en la propiedad nueva en GSC. Pero para la mayoría de migraciones de plataforma o rediseño en el mismo dominio, disavow es irrelevante.
¿Cuál es el error más grande que ves que cometen las agencias en migraciones grandes?
Tratar el mapa de redirects como una tarea de desarrollo. Los redirects son una tarea de SEO que un desarrollador implementa. El equipo de SEO, o quienquiera que posea la estrategia de búsqueda, debe ser dueño del mapa, revisarlo y aprobarlo. He visto desarrolladores construir reglas de redirect técnicamente correctas que eran SEO-incorrectas porque nadie les dijo cuál era la variante de URL canónica.
¿La velocidad del sitio afecta el SEO en migraciones?
Sí, más de lo que la mayoría de personas contabiliza. Core Web Vitals son un factor de ranking, y los rediseños, que frecuentemente acompañan las migraciones, introducen JavaScript más pesado o imágenes no optimizadas. Siempre ejecuta una comparación de PageSpeed Insights entre el sitio antiguo y nuevo antes del lanzamiento. Si el nuevo sitio es notablemente más lento en móvil, arréglalo antes de hacer el cambio.
¿Cómo manejas las migraciones para sitios con mucho contenido generado por usuarios?
Con cuidado. Las páginas de UGC son frecuentemente de baja calidad individualmente pero en conjunto generan tráfico de cola larga. Generalmente recomiendo un paso de rastreo y análisis: identifica qué URLs de UGC tienen algo de tráfico orgánico, redirige esas específicamente, y usa 410 para el resto en lugar de dejarlas como 404s. Un 410 le dice a Google que la página se ha eliminado intencionalmente; un 404 es ambiguo.
---
Las migraciones son una de esas cosas donde la diferencia entre bueno y catastrófico está casi enteramente en la preparación. La implementación técnica usualmente es la parte fácil. El trabajo previo al lanzamiento, el rastreo, el mapa de redirects, la verificación de staging, es donde ocurre el trabajo real. Y si alguna vez te asignan una migración que ya está en vivo y ya está rota, la lista de verificación sigue siendo válida. Solo la estás haciendo al revés.