La mayoría de las migraciones de plataforma a las que nos llaman para evaluar tienen la misma forma: el tráfico estaba sano antes del lanzamiento, el tráfico cayó entre 30 y 80 por ciento en el lanzamiento, y el equipo está ahora en la dolorosa fase de preguntarse qué salió mal. El patrón es tan constante que convertimos el trabajo de prevención en una metodología definida de siete etapas, que aplicamos desde el momento en que un cliente considera cambiar de plataforma, no desde el momento en que el nuevo sitio sale en vivo.
El principio organizador de la metodología es la preservación canónica: cada URL, cada redirección, cada entidad de schema, cada enlace interno y cada señal externa que apuntaba al sitio anterior debe tener un mapeo definido y sin pérdidas hacia el nuevo sitio para el día del lanzamiento. Donde falla la preservación canónica, el tráfico cae. Donde se mantiene, el lanzamiento puede ser casi imperceptible desde el punto de vista del tráfico de búsqueda.
Estas son las siete etapas, lo que protege cada una y dónde suelen esconderse los modos de falla.
Etapa 1: Auditoría previa a la migración
Antes de que cualquier decisión de plataforma sea definitiva, hacemos una auditoría completa del sitio existente previa a la migración. La auditoría cubre:
Inventario de URLs. Cada URL indexada, con su tráfico actual, su posición actual, el peso actual de sus enlaces internos y el número actual de enlaces externos entrantes. Este es el inventario de "lo que tenemos que preservar".
Inventario de schema. Cada tipo de datos estructurados que se emite actualmente, con las plantillas de página que emiten cada uno.
Inventario de contenido. Cada página de contenido relevante, con su profundidad de contenido, fecha de última actualización y cualquier dato único que la página muestre (casos de éxito, fichas técnicas, bloques de preguntas frecuentes, etc.).
Inventario de señales externas. Perfil de backlinks, citas, perfiles sociales, relaciones en el knowledge graph: todo lo que apunte al sitio existente.
El inventario es la fuente de verdad para el resto de la metodología. Las etapas 2 a 7 se remiten a él.
Etapa 2: Elección de plataforma y alineación de la arquitectura
La nueva plataforma no es solo un vehículo para la migración: es una decisión de arquitectura que define qué se puede preservar. Estas son las preguntas que revisamos en esta etapa:
¿La nueva plataforma admite las estructuras de URL que necesitamos? Algunas plataformas (Shopify en particular) imponen patrones de URL que quizá no coincidan con la estructura anterior. Cuando no se puede, planificamos el mapa de redirecciones desde el principio.
¿La nueva plataforma admite el schema que necesitamos? Algunas plataformas generan schema automáticamente (con calidad variable); otras requieren trabajo personalizado. No aceptamos "el schema después" como plan de lanzamiento.
¿La nueva plataforma admite la estructura de enlaces internos que necesitamos? La navegación por facetas, las migas de pan, los productos relacionados, los enlaces cruzados entre contenido y productos: todo esto debe diseñarse antes del lanzamiento, no improvisarse después.
En esta etapa también surge la conversación comparativa del tipo BigCommerce vs. Shopify para B2B. La decisión de plataforma cambia lo que será posible más adelante.
Etapa 3: Mapeo de URLs y estrategia de redirecciones
Esta es la etapa que sostiene toda migración. Cada URL del inventario previo a la migración debe tener un destino definido en el nuevo sitio. Los destinos entran en una de tres categorías:
URLs preservadas: la misma ruta en el nuevo sitio, no se necesita redirección.
URLs mapeadas: una ruta distinta en el nuevo sitio, requiere una redirección 301.
URLs retiradas: la página va a desaparecer. La redirección apunta al equivalente semántico más cercano (una página de categoría, una página padre o, como último recurso, la página de inicio). Evita redirigir todo en masa a la página de inicio; eso dispara errores soft 404.
Para cada URL mapeada, el tipo de redirección importa: 301 (permanente) para transferir la canonicidad, no 302 (temporal). La redirección debe ser de un solo salto, sin cadenas de redirecciones que pasen por dos o tres URLs intermedias antes de llegar al destino.
El mapa de redirecciones se finaliza antes de construir la nueva plataforma, no después. Construir el nuevo sitio sin un mapa de redirecciones claro abre la puerta al modo de falla en el que las nuevas URLs no tienen equivalentes semánticos de las anteriores.
Etapa 4: Paridad de schema, contenido y metadatos
Cada página preservada o mapeada debe conservar su schema, su contenido y sus metadatos. La lista de paridad por página:
Etiqueta de título: se preserva o se mejora, nunca se elimina sin aviso.
Meta descripción: se preserva o se mejora.
H1: se preserva, salvo que haya una razón editorial para cambiarlo.
Contenido principal: se preserva al menos con la profundidad que tenía antes de la migración. Las migraciones a menudo van acompañadas de reescrituras de contenido; si es así, la reescritura no debe dejar el contenido más escaso.
Esquema: todos los datos estructurados se preservan o se mejoran. Una migración es el momento de mejorar el schema, no de perderlo.
Enlaces internos: cada enlace interno entrante desde otras partes del sitio se actualiza a la nueva URL.
El error que debes evitar: confiar en que "el CMS se encargará". La mayoría de las migraciones incluyen al menos un paso de conversión en el CMS donde el contenido se normaliza o transforma, y esa transformación a menudo elimina sin aviso campos que el equipo de SEO necesitaba conservar.
Etapa 5: Auditoría de staging antes del lanzamiento
Antes del lanzamiento, el entorno de staging se audita de la misma manera en que se auditará el sitio de producción después del lanzamiento. La auditoría cubre:
Rastrear el sitio de staging para confirmar que cada página preservada o mapeada carga correctamente con su contenido, título, meta, H1 y schema esperados.
Revisar el mapa de redirecciones visitando una muestra de URLs antiguas y confirmando que hacen 301 a las URLs nuevas correctas.
Validar el schema con el Rich Results Test y el validador de Schema.org.
Revisar el robots.txt, los sitemaps XML y las etiquetas canónicas del nuevo sitio, y confirmar que el robots.txt de staging no se pasará por accidente a producción.
Confirmar que los user-agents de los motores de IA (ChatGPT-User, PerplexityBot, ClaudeBot, GoogleOther) estén permitidos en el nuevo robots.txt.
Hacer una revisión de Core Web Vitals en plantillas representativas.
La auditoría de staging es la última oportunidad de detectar un problema estructural de forma barata. Detectarlo después del lanzamiento cuesta varias veces más.
Etapa 6: Ejecución del lanzamiento
El día del lanzamiento tiene su propia disciplina. La lista de ejecución:
Cambio de DNS en una ventana planificada de bajo tráfico (normalmente de noche en el mercado principal de la marca).
Mapa de redirecciones 301 activado en el momento del cambio, no "poco después" ni "antes de que termine el día".
Enviar el nuevo sitemap a Google Search Console y Bing Webmaster Tools de inmediato en el lanzamiento.
Verificar el mapa de redirecciones visitando una muestra de URLs antiguas y confirmando que los 301 se están ejecutando.
Monitorear Search Console cada hora durante las primeras 24 horas en busca de errores de indexación, y a diario durante la primera semana.
Monitorear las Core Web Vitals con métricas de usuarios reales, no solo con datos de laboratorio.
Monitorear la analítica en busca de cambios inesperados en el patrón de tráfico: las caídas bruscas en tipos de página específicos suelen indicar una brecha de redirección o de contenido que la auditoría de staging no detectó.
El día del lanzamiento no es momento para trabajar en nuevas funciones. El día del lanzamiento es para verificar el trabajo ya hecho.
Etapa 7: Validación y recuperación después del lanzamiento
Los primeros 30 a 90 días después del lanzamiento son cuando la migración se confirma como exitosa o cuando ocurre el trabajo de recuperación. La revisión de validación posterior al lanzamiento cubre:
Convergencia de la indexación. El índice de Google pasa de las URLs antiguas a las nuevas a lo largo de varias semanas. Monitorea ese cambio; marca cualquier URL que no esté haciendo la transición.
Continuidad de las posiciones. Para las palabras clave que sigues, las nuevas URLs deben mantener su posición. Cualquier posición que no haga la transición se marca para investigarla; normalmente es un problema de paridad de contenido o de enlaces internos.
Patrón de tráfico. Compara los patrones de tráfico por día de la semana y por hora del día antes y después del lanzamiento. Las diferencias suelen indicar una brecha de redirección o un cambio no intencional en el tipo de página.
Participación en citas de los motores de IA. Los motores de IA tienen su propio ritmo de indexación. La participación en citas suele bajar de dos a cuatro semanas después del lanzamiento y luego se recupera, si se preservó la paridad de contenido y de schema. Si no se recupera, hay un problema estructural que atender.
La metodología completa, con los entregables por etapa y los patrones específicos de cada plataforma, está en metodología de SEO en migraciones.
Dónde falla con más frecuencia la preservación canónica
En las migraciones que evaluamos después de los hechos, los modos de falla se agrupan así:
Brechas en el mapa de redirecciones: URLs que existían antes de la migración y no tienen destino de redirección en el nuevo sitio, por lo que devuelven 404 o se redirigen en masa a la página de inicio.
Pérdida de profundidad de contenido: el CMS de la nueva plataforma recortó el contenido largo durante la importación, o la reescritura que acompañó a la migración dejó el contenido más escaso sin querer.
Regresión del schema: la generación de schema de la nueva plataforma es más superficial que la del sitio anterior y elimina propiedades que los motores estaban usando.
Enlaces internos rotos: los enlaces internos se actualizaron solo en la navegación, y los enlaces dentro del contenido siguen apuntando a URLs antiguas.
Accidente con robots.txt: el robots.txt de staging (normalmente
Disallow: /) se pasó por accidente a producción en el lanzamiento.Bloqueo de user-agents de IA: el nuevo robots.txt bloquea rastreadores de motores de IA que el sitio anterior permitía, lo que hace que la tasa de citas en IA caiga sin que nadie lo note.
Conflictos de etiquetas canónicas: la nueva plataforma emite etiquetas canónicas que apuntan a URLs distintas de las reales, lo que fragmenta el índice.
Cada uno de estos se puede prevenir con la metodología anterior. Cada uno es caro de corregir después.
Cuándo rinde más la metodología
Las migraciones varían en alcance. Pasar de un sitio HTML plano a WordPress es un proyecto distinto a pasar de un sitio en Magento 1 a BigCommerce o de una plataforma a la medida a Shopify Plus. La metodología de siete etapas funciona igual en todos los casos, pero el peso relativo de cada etapa cambia. En sitios con mucho contenido y archivos editoriales profundos, la paridad de contenido (etapa 4) es el riesgo principal. En catálogos con muchos SKUs, el mapeo de URLs (etapa 3) es el riesgo principal. En sitios con datos estructurados ricos, la paridad de schema es el riesgo principal.
Para los equipos que planean una migración, el momento correcto para incorporar la metodología de SEO es la selección de plataforma (etapa 2), no el staging. Las decisiones que se toman al elegir la plataforma definen lo que será posible en cada etapa posterior.
La visión central está en metodología de SEO en migraciones. El enfoque desde la auditoría (cuando una migración no salió bien y el diagnóstico es la prioridad) está en servicios de auditoría SEO.
Si tienes una migración en curso o en etapa de planificación y quieres una segunda opinión guiada por metodología, nos encantaría saber de ti.