Guía de Migraciones SEO: cómo planteárselo y no morir en el intento

Igual que golondrinas, cigüeñas, gansos y muchas otras especies se desplazan miles de kilómetros cada año buscando mejores climas o recursos; en Internet muchas webs han de pasar por cambios de todo tipo para convertirse en algo mejor (a priori).

En todos esos casos solemos acuñar el nombre de “migración” para hacer alusión y referencia al cambio de estado de algo: lo que de inicio tenía un estado determinado, en su destino tiene otro muy diferente.

En el post de hoy nos zambullimos de lleno en el mundo de las migraciones y el impacto que pueden tener en el canal SEO principalmente, repasaremos tipos, impactos, riesgos y también procesos a llevar a cabo para intentar que todo salga bien.

Let’s go!

1. Tipos de migraciones: ¿cuándo es y cuándo no es migración?
2. Implicaciones, impactos y riesgos desde distintas perspectivas
3. ¿Cuáles son los impactos SEO de una mala migración SEO?
4. Proceso de migración paso a paso
5. Consideraciones y herramientas
6. Preguntas (y errores) Frecuentes
7. Algunos casos reales
8. Otros consejos de expertos
9. Conclusiones y recursos

Antes de meternos de lleno en el tema me gustaría empezar con una pregunta que mucha gente se puede hacer, ¿cuándo realmente se puede considerar migración y cuándo no?

Tipos de migraciones: ¿cuándo es y cuándo no es migración?

En general, no tiene por qué haber un cambio de urls necesariamente para ser considerado migración, ¡hay más cosas! Pero en esencia, uno de los mayores riesgos de pérdida de tráfico viene de situaciones en las que las urls del proyecto cambian y deben moverse hacia otro lugar.

A pesar de que no siempre existe cambio de urls, podemos hablar de situaciones que pueden ser más o menos familiares para quien esté leyendo estas líneas y que solemos considerar migración:

• Una marca cambia de nombre y como consecuencia, hay que mover el dominio hacia uno nuevo.

Incluso hay marcas que cambian de nombre y luego tienen que volver al nombre inicial, por razones que no siempre trascienden…

• Una empresa absorbe a otra y se integran bajo un mismo nombre. Nuevamente, uno de los dominios ha de integrarse en otro que albergará el contenido definitivo al paraguas de la marca que permanece.

Los ejemplos son innumberables: VivaGym comprando otras cadenas de gimnasios, CaixaBank fusionándose con Bankia y Unicaja Banco con Liberbank, entre otros.

Este tipo de movimientos tienen un origen meramente empresarial y las consecuencias en SEO, son claras y directas, si no se hace bien.

Un ejemplo de visibilidad tras una fusión de dominios:

• Una empresa decide cambiar la tecnología con la que tiene hecha su web. Cuando la tecnología de inicio es muy diferente a la de destino, suele generar cambio de urls casi siempre.

Como ejemplo, Adeslas Dental pasó de un desarrollo a medida a funcionar en WordPress.

También hay que considerar que en ocasiones este tipo de decisiones pueden radicar no solo en el SEO, sino en la mejor escalabilidad y facilidad en la gestión del proyecto, al pasar a tener un gestor de contenidos o backend que facilita el mantenimiento de contenidos.

• Una marca cambia su diseño y aspecto, pero mantiene su nombre como antes. Este cambio puede no requerir modificar urls, pero si cambiará parte de su maquetación y formateado de código, lo que tiene claras implicaciones a nivel SEO.

Abundan los ejemplos de rediseños y uno muy recordado fue el cambio de imagen de Correos, que, aunque parezca leve, tiene una implicación adicional al tener soportes físicos y múltiples establecimientos.

• Cambios de dominio sin cambiar la marca, ya sea pasar a una extensión de dominio diferente o pasar a un dominio más corto y memorable, por causas de internacionalización, etc.

Nuevamente, las razones detrás de este tipo de cambios no siempre trascienden, pero de todos es sabido que para poder posicionar internacionalmente, necesitamos un dominio local para cada mercado o bien una web global para albergar todas las versiones, por eso es habitual ver cambios de .es a .com.

También ocurre este tipo de cambios cuando se reorganizan activos digitales que se han usado en el pasado y ahora se dispone de ellos para tratar de afianzar estrategias digitales.

Algunos ejemplos conocidos:

Convertkit se transforma en Kit para acortar su dominio, acompañado de un rediseño

Jardiland pasa de .es a .com; la mejora de visibilidad no tiene por qué ser únicamente por este cambio, obviamente.

Vans pasa de .es a .com, el dominio .com ya había sido usado en el pasado:

• Una empresa cambia de proveedor de hosting y se muda a un nuevo continente para su contenido. A priori es el caso más inocuo de los explicados. 

Para esto no pongo ejemplos, porque es un cambio mucho más “invisible” de cara al exterior de la empresa 😀

Esto son solo algunos ejemplos de los tipos de migraciones que nos podemos encontrar, pero también merece la pena lo que no se considera una migración:

• Mantenimiento de contenidos y arquitectura, donde se pueden producir cambios puntuales de urls
• Optimización de contenidos que fusiona distintas piezas en una misma url, para evitar duplicidad y consolidar contenidos similares.
• Cualquier otra situación de cambio de urls, contenido o estética, que no sea a gran escala y solo afecte a urls puntuales.

Una vez vistos los tipos de migraciones, ten en cuenta que puede ocurrir que una misma migración englobe TODOS o casi todos los cambios descritos anteriormente… esto suele suponer un reto mayúsculo para el responsable SEO y para mucha más gente.

Porque, seamos honestos, la migración de una web suele impactar a muchos equipos y no es algo exclusivo del SEO, repasemos por un momento las implicaciones, impactos y riesgos desde la perspectiva de cada persona o perfil.

Implicaciones, impactos y riesgos desde distintas perspectivas

1. Perfil de gerencia

Para un CEO o dueño de un negocio, la decisión de migrar es puramente estratégica, con implicaciones directas no solo en los ingresos de la empresa, sino también en la reputación de la marca.

En términos de inversión, si se gestiona correctamente puede impactar e impulsar el crecimiento del negocio a todas luces: mejorar experiencia de usuario, la seguridad, la velocidad, el tráfico, las conversiones … .y los ingresos.

No obstante, también implica una inversión de tiempo y recursos sobre todo para planificar todo correctamente y minimizar todo lo que se pueda el riesgo mayor: una caída significativa en tráfico y conversiones.

Como mayor punto de dolor del área de gerencia, encontramos la posible afectación a la rentabilidad del negocio en casos de migraciones que salen mal.

2. Perfil de comunicación

Para el equipo de comunicación una migración es un evento potencial que puede afectar cómo los usuarios perciben la marca y cómo de fácil es para ellos acceder a la información de la empresa o del proyecto en sí.

Por tanto, es crucial tener un plan de comunicación que garantice y asegure la comunicación con la audiencia, que no se interrumpa y que no solo la imagen de marca se mantenga, sino que incluso mejore tras el cambio. Un ejemplo de esto lo vivimos en 2015 con el cambio de SegundaMano a Vibbo, ambas marcas estuvieron buscándose por lo que debemos garantizar que todo el mundo se entera del cambio y ambas marcas deben estar presentes en la web, conviviendo para conseguir el objetivo.

También suele ser un punto de inflexión para revisar y optimizar el contenido, los mensajes claves de marca y todos los procesos de comunicación de cara a que sean efectivos y la audiencia sepa en todo momento qué está pasando.

Los principales riesgos son los mensajes que pueden llegar como respuesta al cambio realizado, por ejemplo, si hay muchos errores en la web o si la experiencia es mucho peor que antes, puede conducir a la pérdida de confianza.

También puede ocurrir que se comunique mal el cambio efectuado (imaginemos que puede ser un cambio de marca, un rediseño, una fusión con otras empresas, etc.) y lo que generamos es mayor confusión aún.

Como mayor punto de dolor del área de comunicación encontramos la posible afectación a la reputación e imagen de marca por haber informado mal o porque los cambios aplicados empeoran la experiencia anterior.

3. Perfil de marketing

Para un perfil de marketing una migración puede conllevar impactos directos en el rendimiento de campañas de prácticamente todos los canales que no sean propios. Habitualmente canales como Paid o Email Marketing son controlados por nosotros mismos porque elegimos las urls de las distintas campañas y podemos pausarlas momentáneamente. Sin embargo, hay canales que no se pueden apagar y sufrirán de forma frontal las consecuencias de la migración.

Son los responsables SEO junto a los perfiles de dirección y decisión como gerencia o producto los que van de la mano para planificar la migración y tratar de ser ambiciosos en el cambio, aprovechando el movimiento, tratar de mejorar en todos los aspectos posibles.

El mayor riesgo al que se enfrentan es la pérdida de tráfico, y dicha pérdida, en el corto plazo, presumiblemente suele ser paliada con incrementos de inversión en publicidad pagada, lo que eleva los costes de adquisición.

Por tanto, la planificación para redirigir correctamente todas las urls, para asegurar que las herramientas de medición siguen funcionando correctamente son aspectos vitales de cara a evitar las tragedias de las prisas y la falta de conocimiento o planificación.

El mayor punto de dolor es que es demasiado habitual que estos perfiles no estén involucrados en los procesos de migración desde el primer día, lo que tristemente trae como consecuencia que entren cuando ya se ha materializado el desastre y la pérdida de tráfico evitable, se convierte en una losa que hay que levantar y muchos meses de recuperar algo que no debía haberse perdido.

4. Perfil de desarrollo o técnico

Desde el punto de vista más técnico, puede haber equipos de sistemas y de desarrollo involucrados en esto para abordar el desafío técnico a nivel de servidor, código y también la capa SEO, que es la que nos ocupa principalmente.

Sus principales misiones están relacionadas a hacer las mejoras que se les hayan indicado, incluidas las de SEO, también habilitar las redirecciones, ambas cosas son idílicamente mejor aplicarlas a un entorno de pruebas previo al lanzamiento definitivo.

Es esta colaboración y relación entre developers y SEOs fundamental para ir de la mano y que el proyecto tenga cubiertos los puntos más importantes y pueda abordar también otras mejoras de gran calado que le proporcionarán un salto de calidad al proyecto, lo que se traducirá en más posibilidades de que salga bien.

Riesgos hay muchos porque esta capa es la más visible y es habitual que puedan existir ciertos olvidos (noindex, disallow, etc.), por ese motivo la revisión en entornos de prueba es clave para solventar esas problemáticas antes de lanzar.

El mayor punto de dolor tiene que ver con la planificación temporal. Si los que gestionan y dirigen el proyecto han sabido cuantificar los tiempos que requiere cada tarea y cada mejora, por un lado los desarrollos globales de la web, por otro lado las implementaciones específicas de SEO, todo ello organizado desde el primer día, no tiene por qué haber problemas. 

Sin embargo, si la organización no ha sido fluida y se ha involucrado a SEO en últimas fases, lo habitual son las prisas y la necesidad de priorizar lo más importante, en vez de aplicar todas las mejoras con margen para hacer todo bien. De este punto, surge nuestro último perfil, el organizador, project manager o director de orquesta.

5. Perfil organizador o director de orquesta.

Ser el project manager en un proyecto con una migración por delante, es un reto mayúsculo, porque implica que tienes que saber un poco de todas las áreas, para entender los tiempos que le lleva a cada persona hacer su trabajo, para entender el deadline final que tiene la migración, para saber cómo priorizar lo importante y descartar lo accesorio, entre otras cosas.

El objetivo es saber manejar equipos, recursos y plazos, para que todo salga cuando tiene que salir y cada equipo haga su parte. Liderar este proceso, planificar al detalle y asignar los recursos, además de llevar la comunicación y seguimiento del estado del proyecto. Casi nada, ¿verdad?

Los riesgos casi siempre pasan por no llegar a las fechas establecidas, por no estimar correctamente los tiempos de cada recurso o por infravalorar los cambios a realizar.

El mayor punto de dolor suele radicar en falta de conocimiento de las tareas de cada participante, falta de comunicación clara y concisa para cumplir con lo planificado, falta de coordinación entre los equipos. Todo esto es lo que puede dinamitar el proceso de migración y añadir ruido y prisas a algo que debería haberse trabajado con tiempo y música celestial.

Vale, pero…

¿Cuáles son los impactos SEO de una mala migración SEO?

Este es otro melón y ya está abierto. Procedo a resumir riesgos e impactos en la siguiente tabla:

Tipo de cambio	Impacto	Riesgo
Arquitectura de la información	Cambios de enlazado internoProfundidad de contenidos	Pérdida de relevancia Pérdida de popularidad internaImpacto en rankings
Estructura de URL	Redirecciones	Pérdida de relevanciaPérdida de popularidad interna Impacto en rankings
SEO Tags	Maquetación y etiquetas  html	Pérdida de relevanciaPérdida de popularidad internaImpacto en rankings
Semántica	Modificación o eliminación de contenidosModificación o eliminación de marcados semánticos	Impacto en rankingsImpacto en CTR
Popularidad	Pérdida de enlaces externos	Pérdida de autoridad y popularidadImpacto en rankings

Ahora, a esta tabla también podemos añadirle idiosincrasias nuevas que añaden más ingredientes a nuestro rico plato de migración:

• Todas las urls con imágenes que nos traen tráfico o posicionan en Google Imágenes.
• Todas las urls que hayamos compartido por redes sociales debemos considerarlas para evitar que queden rotas o sin redirigir, sobre todo si han tenido impacto en dichas redes o han canalizado tráfico
• Todas las urls de tráfico directo con tráfico también nos importan mucho porque alguien las tiene guardadas para acceder a nuestro proyecto, no queremos perderlos, ¿verdad?
• Si hemos aparecido referenciados en medios o sitios de terceros y nuestros enlaces son valiosos, pero también nuestra reputación de ser recomendados, no lo perdamos.
• Si de paso, sabemos que hay urls de nuestra web que se recomiendan en Chat GPT, en AI Overviews o en otros chatbots, también hay que considerarlas para nuestra migración, incluso en nuestras estrategias de fusión de contenidos aun a riesgo de perder esas citas.

Con todas estas consideraciones en mente, podemos lanzarnos a desgranar paso a paso cómo abordar un proceso de migración y tenerlo todo controlado.

Proceso de migración paso a paso

Antes de migrar: la planificación 

Si hay una cosa importante cuando abordamos una migración SEO, esa es sin duda la planificación. Es vital, crucial, súper importante entender bien qué va a cambiar, poder estimar tiempos y recursos antes de tener una fecha tentativa de lanzamiento.

Ya sé que a veces los negocios pueden parecer que funcionan precisamente al revés, ponen la fecha de lanzamiento porque hay compromisos comerciales o de otro tiempo, y luego hay que apañarse para correr y sudar tinta china, para tener todo decente antes de publicar la nueva web.

Idealmente, deberíamos trabajar con esa revisión de necesidades, traducirla en recursos necesarios y en base a eso, poner fechas. Vamos a los puntos importantes.

Como mínimo necesitamos pasar por 4 puntos que en toda migración (o casi siempre) vamos a necesitar entender:

1. Objetivo

Parece obvio, no lo es. 

¿Qué cambios va a sufrir la web? ¿En qué consiste la migración? ¿Cuál es la necesidad que se quiere paliar y cuál es el impacto o mejora que se espera conseguir?

Solo con estas inocentes preguntas se puede desentrañar las verdaderas razones del cambio. Y en ocasiones, como imaginarás, no hace falta migrar.

Recuerda que cuando las urls de nuestro proyecto cambian, eso queda guardado en su historial, por lo que, idealmente, cuando creamos una url la estamos creando para que exista siempre.

Un ejemplo, si creaste una url de viajes, llamada /viajes/bajo-manhattan

Al tiempo piensas, “mejor debí crear la url en singular que queda mejor”

Modificar todas las urls de /viajes/ para convertirlas en /viaje/, ¿qué mejora presenta para el proyecto? Piénsalo bien: ninguna.

¿Cuáles son los objetivos más habituales que yo he visto en mi experiencia como SEO?

Objetivo	Implicaciones
Crear una nueva estructura o arquitectura	Investigación de keywords, entidades y search intents
Hacer un rediseño estético	Cambiar plantilla o adaptar el branding, coordinando las acciones con diseñadores principalmente
Internacionalizar el proyecto	Mover el sitio a una extensión de dominio global o del país que corresponda, haciendo la investigación oportuna en cada idioma correspondiente
Cambiar de plataforma para escalar	Entender cómo funciona el nuevo CMS y poder configurarlo correctamente además de hacer las redirecciones
Fusionar varias webs	Unificar estructuras y contenidos

Es importante resaltar algunas consideraciones adicionales:

• Cada vez que se hace una migración, los buscadores como Google aprovechan para reevaluar el sitio y revisarlo a fondo en términos de calidad, fiabilidad, aspectos técnicos…. 
• Si está muy claro que hay que migrar, hay que tratar de ver qué enfoque se puede llevar a cabo, en base a recursos y tiempos: migración defensiva o migración ofensiva. La segunda, como se deja intuir, consiste en tratar de mejorar el proyecto lo máximo para que el resultado nos beneficie a nivel SEO, aplicando mejoras ostensibles.
• Ser conscientes de todos los cambios que se van a aplicar a la vez para entender la magnitud de comprensión que vamos a necesitar de parte de Google y de los usuarios, que nadie se olvide de que son los usuarios los destinatarios de todas las mejoras que hacemos y deberíamos velar por su satisfacción en todo momento. Cuantos más cambios, más complejidad, más dificultad, y por qué no decirlo, más ruido para poder identificar los resultados y atribuirlo a causas objetivas.
• A veces las migraciones se pueden hacer por partes, pero no es lo más recomendable, en este caso «depende» mucho de la magnitud de la migración, se puede agilizar alguna parte o no. Plantear migraciones a 2-3 años suele ser muy complejo y complicado de hacer bien, porque hay muchos aspectos que no están en nuestra mano.
• Los timings elegidos también juegan su papel en varias direcciones. Por un lado, cuánto tiempo le hemos dedicado a planear y organizar la migración antes de ejecutarla. Por otro lado, cuando hemos decidido lanzar la nueva web, ¿tenemos en cuenta si han existido cambios de algoritmo de Google recientes o en curso? Y por último, ¿lo estamos lanzando un viernes? Esto es un peligro porque si algo no sale bien, el fin de semana nos va a ahogar o alguien va a tener que hacer horas extra.

Ahora vamos a comentar varias herramientas de las que disponemos a nivel metodológico que nos ayudarán a gestionar el proyecto de migración.

2. Definir el plan de migración con roadmap y kpis claros

Habitualmente confluyen muchos equipos en este tipo de proyectos de migración, por lo que es probable que cada equipo tenga su propia planificación o roadmap de acciones.

Es importante que se trabaje con una metodología común desde el principio, labor que debería asumir el director de proyecto o project manager.

Desde el punto de vista SEO, podemos optar por versiones más sencillas o  más completas, dependiendo de la necesidad del proyecto y la separación de tareas respecto al tiempo transcurrido.

Cabe señalar que ya deberíamos saber a estas alturas cuáles son las acciones que el equipo SEO quiere llevar a cabo, sobre todo entendiéndolo como mejoras a aplicar. En ocasiones se debe realizar análisis y auditorías previas para identificar el grado de mejora y el potencial orgánico a capturar, respecto a áreas semánticas, técnicas, de autoridad o popularidad…

Sea como sea, la planificación ya debe incluir todos estos análisis y trabajos, de cara a tener controlados todos los pasos a dar hasta que se lance el nuevo sitio.

Una versión sencilla de roadmap de trabajo puede incluir lo siguiente:

No obstante, podemos añadir prioridades, objetivos, deadlines e incluso el estado de las tareas con sus comentarios…. Personalizable en base a necesidades, aunque personalmente no suele ser necesario un roadmap tan completo.

Dejo dos ejemplos adicionales y la url para poder conseguirlos:

Roadmap by Ahrefs: https://ahrefs.com/blog/seo-roadmap/

Roadmap by Semrush: https://www.semrush.com/blog/seo-roadmap/

Con esto claro, hablemos de las KPIs y métricas que deberíamos estar teniendo en cuenta para una migración:

Métricas de Rastreo

Necesitamos entender cuáles son los ratios de rastreo que tiene el proyecto antes de migrar, para poder comparar los nuevos registros con los previos. Idealmente, esto requerirá un esfuerzo técnico y el análisis de logs del servidor, para poder comprender cada cuánto tiempo son rastreadas las páginas por los distintos bots (buscadores clásicos, chatbots). 

Algunos elementos que pueden ayudarnos a generar métricas o KPIs:

• Hits desde mobile
• Hits desde desktop
• Enlaces internos únicos
• Nivel de profundidad

Métricas de Indexación

También es preciso conocer a fondo qué páginas están indexadas, cuáles no y por qué motivos. Esto podremos saberlo con los informes de indexación de Google Search Console o revisando las páginas que efectivamente reciben impresiones, como elemento sintomático de indexación. Es importante tener una estrategia de indexación para la migración puesto que podemos aprovechar el momento para hacer limpieza de urls indexadas que no deberían estarlo y viceversa, crear páginas que no existían y que se deben indexar tras la migración. 

Algunos elementos que pueden ayudarnos a generar métricas o KPIs:

• Sitemaps
• Robots.txt
• Rel Canonical
• Meta Robots

Métricas de Performance

La velocidad de carga es otro elemento que es preciso conocer antes y después del cambio. Esto estará muy sujeto a los cambios que se realicen; si son de CMS o de tecnología, podemos impactar mucho en estas métricas.

Algunos elementos que pueden ayudarnos a generar métricas o KPIs:

• Tiempo de carga
• TTFB
• Core Web Vitals

Métricas de Ranking

Un control de rankings y posiciones aún es importante porque los buscadores siguen siendo la puerta de entrada de los visitantes. No obstante, también será importante fijarse en la visibilidad obtenida por otros canales como chatbots o resultados basados en IA como AI Overviews.

Algunos elementos que pueden ayudarnos a generar métricas o KPIs:

• Visibilidad Brand
• Visibilidad No Brand
• Visibilidad AI
• CTR
• Posición media
• Citas/menciones desde AI Overviews / AI Mode
• Citas/menciones desde Chat GPT

Métricas de Tráfico.

Desde nuestras herramientas de analítica web podremos crear métricas respecto a las páginas que reciben tráfico orgánico, tráfico directo y tráfico social, sobre todo, que son los canales que no podemos desconectar ni durante ni después de la migración. Este punto nos puede alertar sobre posibles problemas si vemos nuestras top páginas sufriendo caídas de tráfico.

Algunos elementos que pueden ayudarnos a generar métricas o KPIs:

• Tráfico total
• Tráfico orgánico
• Tráfico directo
• Tráfico social
• Conversiones / Tasa de conversión

Otras métricas

En este punto podemos añadir otras vías de generar métricas y KPIs más específicas, como por ejemplo:

• Volumen de búsqueda de marca
• Enlaces externos entrantes nuevos

Ya tenemos claro por qué migramos, ya sabemos qué acciones hay que poner en marcha, tenemos nuestro roadmap y métricas de seguimiento, ahora nos toca pasar al siguiente nivel: contar con un entorno de pruebas para comprobar que la futura nueva web está correcta antes de lanzar.

1. Tener la futura web en un entorno de pruebas

Este paso no ocurre en todos los proyectos, sobre todo cuando los cambios a acometer son muy controlados o muy acotados; en ocasiones se prescinde de este paso.

En mi experiencia, contar con un entorno de pruebas siempre es recomendable para hacer un control de calidad de lo que se ha desarrollado y poder aplicar mejoras en un entorno privado, previo a que se lance de forma definitiva la nueva web.

Para contar con este tipo de entorno, tenemos varias opciones:

1. Web accesible con usuario y contraseña
2. Web accesible solo desde una ip concreta
3. Web accesible solo con una cookie concreta
4. Web accesible a través de un subdominio, subcarpeta o dominio específicos, bloqueado por robots.txt y meta robots noindex

De estas opciones lo ideal es optar por una de las 2 primeras opciones, pues son las más robustas a nivel de seguridad y son las que nos permitirían replicar la web de forma más realista.

La opción 4 no sería recomendable, porque debería añadirse noindex en todas las urls, y eso, por desgracia, corre el riesgo de quedarse así para cuando se publique la nueva web y arrastre directivas críticas, produciendo uno de los errores más costosos de una migración: la desindexación.

Con el entorno de pruebas habilitado, nos toca trabajar con todos los equipos para que queden volcados el contenido definitivo y las implementaciones SEO aplicadas. El tiempo en que esté listo todo para ser lanzado suele depender de esto precisamente: que los equipos responsables de desarrollo y carga de contenido, hagan su parte, y que el equipo SEO, valide que todas las recomendaciones están bien aplicadas.

Lo ideal para evitar la sobresaturación o sobrecarga de equipos es establecer fechas para tener las distintas subidas de contenidos o mejoras, y tras las subidas, que se pueda hacer una revisión de las mismas. 

Si este punto no se acota, corremos el riesgo de estar revisando una y otra vez, lo cual no es eficiente en términos de proyecto y puede generar fricciones.

En ocasiones, también puede ocurrir que se llegue muy justo a las fechas establecidas y finalmente se tiene que priorizar qué implementaciones hacer y cuáles dejar para fases siguientes.

Es vital en este caso una correcta priorización para establecer diferencias entre lo que es necesario y lo que es deseable, también marcar los aspectos bloqueantes, para asegurarlos antes que otros.

2. Elaborar el documento de estrategia de urls y por ende, el mapeado de redirecciones

Para que lo entienda cualquiera, necesitamos hacer un documento que establezca y recopile las urls actuales a modo de inventario y establezca qué hay que hacer con ellas en el nuevo sitio, para ello, podemos separar en varias acciones:

• Hago el inventario de todas las urls existentes en el proyecto (incluyendo todos los formatos como html, imágenes y otras que puedan posicionarse o capturar tráfico).
• Punto importante: si la web ha tenido migraciones anteriores o se han hecho otras migraciones, debe haber un repositorio de las urls antiguas, para añadirlas también al listado y que no se pierdan. Con esto evitamos encadenar muchos saltos de redirección y modificamos redirecciones antiguas para que vayan de forma más directa a las urls nuevas.
• Establecer si van a seguir existiendo en la nueva web o no.
• Las que no vayan a seguir existiendo figurarán en nuestro documento de estrategia de urls con un código de respuesta 404 o 410.
• Las que sí vayan a seguir existiendo, y presumiblemente cambien su estructura de url, figurarán en nuestro documento de estrategia de urls con un código de respuesta 301, a priori. De estas urls, crearemos nuestro mapeado de redirecciones.

El mapeado de redirecciones surge de relacionar las urls actuales que se conservan en la nueva web con las urls definitivas que tendrá la nueva web.

Considera que en este punto en muchas ocasiones puede ocurrir que las urls definitivas aún no se conozcan, por lo que podemos comenzar haciendo la primera parte del mapeado: hacer la selección de urls que SI vamos a redirigir. Puedes fijarte en ciertos criterios númericos para garantizar que no te dejas urls valiosas fuera de tu documento y mapeado:

• Urls con tráfico orgánico en los últimos 12-24 meses
• Urls con tráfico directo en los último 12-24 meses
• Urls con conversiones/ingresos en los últimos 12-24 meses
• Urls con enlaces entrantes o refering domains de valor

Un tip de valor: añade una columna para saber el porcentaje acumulado de cualquiera de las métricas anteriores, por ejemplo, porcentaje acumulado de clicks, así tendrás una visión global de cuántas urls necesitas migrar para «salvar» el 90% del tráfico.

En la imagen, las urls candidatas a ser migradas, al ser valiosas (tienen tráfico, rankings, enlaces valiosos, etc.), se observa en la columna de porcentaje acumulado que 15 urls son las responsables del 90% de las sesiones.

Estos enfoques son los que nos facilitarán la vida a la hora de planificar las redirecciones.

Ahora, imaginando que ya conocemos toda las urls, tanto las de origen como las de destino, para llevar a cabo este “match” entre urls, tenemos varios métodos:

1. Métodos de coincidencia directa entre web de origen y de destino.

Este tipo de métodos buscan coincidencias directas entre los elementos específicos de ambas páginas; es el método más determinista.

Si usamos un ejemplo de ecommerce, por ejemplo, los productos se podrían hacer coincidir usando el SKU (ID de producto), que a veces está presente en la url, en los datos estructurados o en el cuerpo de la ficha. En otros casos podríamos usar elementos comunes entre versiones:

• Slug o estructura de urls o IDs
• Title
• H1
• Migas de pan
• Fragmento único del html
• ID de base de datos
• …

Para esta tarea podemos usar expresiones regulares o lenguaje xpath en crawlers como Screaming Frog, que facilitarán el proceso

Aquí radica la importancia de que el entorno de pruebas o staging tenga la información y contenidos definitivos lo antes posible, para poder no solo hacer el mapeado sino las distintas pruebas de calidad previas a lanzar.

Veamos un ejemplo sencillo de un mapeado de un blog, creado en Google Sheets, añadiendo la equivalencia entre urls de origen, url de entorno de pruebas y url final:

Para llegar a ese matcheo, previamente hemos extraído elementos comunes:

• entre la versión de origen

• y la versión de staging o pruebas

En este caso, la migración consiste en mover el contenido de un dominio .org a un dominio .ninja, por lo que el contenido y los etiquetados no cambian.

Por ese motivo, podemos utilizar el Title o el H1, para emparejar las urls, se podría hacer en Google Sheets con un BUSCARV o BUSCARX, de manera muy rápida.

Recuerda que antes de lanzar la nueva web, el mapeado debe incluir las urls finales como destino de las redirecciones, por tanto, añadir las urls del entorno de pruebas es un paso intermedio previo solo de control.

2. Métodos de coincidencia difusa.

Utiliza algoritmos de distancia de cadenas (Levenshtein o Jaro-Winkler) para encontrar similitudes aproximadas entre textos, aceptando pequeñas variaciones ortográficas y diferencias.

• Fuzzy Matching con Google Sheets, este es el tutorial de Lazarina Stoy que puedes usar: https://lazarinastoy.com/ultimate-guide-to-fuzzy-string-matching-for-seo-with-google-sheets-template/ 

3. Existen soluciones basadas en modelos de similaridad semántica. Esto podría ayudarnos para casuísticas menos claras o más difíciles de matchear de forma estática.

En esencia utilizan modelos de lenguaje y vectorización para capturar el significado contextual de contenido o urls, aunque se usen palabras diferentes.

• Embeddings + Score de Similaridad. Puedes hacerlo con la api key de un modelo como OpenAI y Screaming Frog, tienes un paso a paso en este tutorial: https://www.screamingfrog.co.uk/seo-spider/tutorials/how-to-use-vector-embeddings-for-redirect-mapping/
• Sistemas basados en LLMs como el modelo MiniLM de Microsoft, a través de un script de Python/Google Colab. Puedes seguir el tutorial paso a paso de Mark Williams-Cook: https://searchengineland.com/site-migrations-ai-powered-redirect-mapping-437793
• Se podría valorar usar otros modelos como BERT, Sentence-BERT y otros…

En general, estos métodos de similaridad nos ofrecerán un scoring o resultado que será un número entre 0 y 1 de cada par de urls, cuanto más cerca de 1, más similaridad entre pares de urls.

Esta traducción a embeddings se puede hacer usando los contenidos de cada página de origen y destino, o directamente, se puede hacer traduciendo las urls de origen y destino. 

En base al proyecto que tengas entre manos, elige el método que mejor aplique a tu caso.

Y por último, probablemente elijas el método o combinación de métodos que elijas, te va a tocar hacer una revisión manual para asegurarte de que todo está bien, por tanto, no hay ningún método 100% automatizado que garantice el éxito.

Dado que cada migración tiene sus propias idiosincrasias y características, partes del proceso pueden variar o adaptarse en cada caso, por lo que el proceso no es 100% idéntico y no permite una automatización de inicio a fin.

Durante la migración: la revisión y validación previas a lanzar

Vamos ahora a ver qué acciones debemos llevar a cabo en esta parte del proceso. Nos ubicamos enseguida.

• Ya tenemos el mapeado, si las urls de destino se conocen en este punto, deberíamos terminar el mapeado aquí, no antes.
• Ya tenemos el sitio de pruebas o staging, donde se han ido subiendo los contenidos y la estructura de urls definida.
• Ya tenemos claro cómo debe estar el contenido y arquitectura, respecto a SEO

¿Qué toca ahora?

• Revisar que las redirecciones funcionan en local, en la versión de pruebas. Aunque esto no suele ser muy habitual es altamente recomendable ya que poder probar las redirecciones antes de lanzar, nos da más garantías de que no habrá problemas.
• Revisar que todos los criterios SEO están aplicados, si no lo están, tocará seguir aplicando las mejoras hasta que tengamos todo listo, al menos, en los puntos que sean bloqueantes o altamente prioritarios.
• Asegurarnos de que el equipo de analítica ha implementado todas las configuraciones y marcados para no perder datos. Esto también es un aspecto crucial, porque si alteramos las atribuciones antes y después, tendremos problemas para comparar datos.

Cuando ambas cosas estén hechas, ya estaremos en disposición de lanzar la web.

Una buena herramienta para usar en esta fase es utilizar un checklist de comprobación de elementos para asegurarnos de que todo está correctamente aplicado:

• Aspectos de arquitectura
• Aspectos de enlazado
• Aspectos de maquetación
• Aspectos de contenido y su calidad
• etc.

Después de migrar: el lanzamiento y monitorización posterior

Una vez que hemos lanzado el nuevo sitio y está público y accesible en Internet, tenemos que ser conscientes de los tiempos y de las revisiones que debemos acometer, el orden de las mismas es importantísimo:

1. Primero lo bloqueante
   1. Comprueba que Robots.txt no está impidiendo el acceso a bots que nos interesan (Googlebot, Bingbot y otros).
   2. Comprueba que tus páginas más importantes no tienen “noindex”; podrías haber desindexado las top páginas sin querer; si eso ha ocurrido, elimina esa etiqueta de inmediato.
   3. Comprueba que los marcados “rel canonical” están correctos en tus páginas principales.
   4. Comprueba que las principales páginas están redirigiendo bien; puedes hacerlo a mano con las más importantes.
   5. Comprueba que no se están enlazando las urls del entorno de pruebas, ni en la navegación ni en los sitemaps.
   6. Comprueba que la configuración técnica principal se está ejecutando correctamente, por ejemplo sitios basados en JS, pueden estar funcionando como SSR, CSR o métodos híbridos.
   7. Comprueba que las herramientas de medición funcionan correctamente y están registrando datos.

2. Luego todo lo demás
   1. Rastrea el sitio, con permiso del equipo técnico, y revisa todos los aspectos SEO relevantes.
   2. Comprueba que los contenidos se muestran correctamente
   3. Comprueba que las url que no existen, responden 404 desde el servidor y hay página personalizada
   4. Comprueba que la herramienta de analítica registra bien tráfico, eventos, formularios, etc.

Y aquí va un mensaje muy importante, la monitorización posterior es vital porque nos permite identificar errores y resolverlos, si somos conscientes de ello, una migración que al ser lanzada empieza mal, puede acabar muy bien si actuamos a tiempo.

¿Cuánto es «a tiempo»? Si tardamos días, estamos a tiempo. Si tardamos semanas, en algunos casos, podríamos estar a tiempo. Si tardamos meses, en muchos casos no llegamos a tiempo. Si tardamos años, definitivamente no llegamos a tiempo.

Con esto lo que quiero decir es que podemos reconducir situaciones que van mal si vamos con los tiempos adecuados y estamos coordinados con los equipos implicados.

Ejemplo: web que solo redirigió un 10% de las urls con tráfico y las redirecciones no iban a la url más apropiada

¿Resultado? Caída de más del 80% del tráfico.

¿Cómo se levantó tan rápido? En menos de un mes se modificaron todas las redirecciones incorrectas hacia su destino correcto y se redirigieron el resto de urls pendientes. Por otros motivos no llegó a recuperarse al 100%, pero la mayoría de la caída se superó.

Consideraciones y herramientas

El proceso de migración puede variar en base a la razón por la que se migra, pero en esencia, es un proceso que involucra a múltiples equipos, por lo que el 80% del éxito radica en comprender los riesgos y en organizar las tareas.

Herramientas útiles: Basecamp, Jira, Asana

Existen tareas puramente de diagnóstico y de comprobación SEO; para esto las herramientas SEO habituales nos sirven de sobra.

Herramientas útiles: Screaming Frog, Sitebulb, Oncrawl y apis de GA y GSC.

Los mapeados históricamente se han trabajado en Excel o Google Sheets, pero en la actualidad tenemos a nuestra disposición herramientas que nos pueden acelerar esto.

Herramientas útiles: programación con Python, Node.js o incluso R, por supuesto, Claude, ChatGPT y otros, para ayudarnos en tareas de matcheo.

Algunos casos reales dignos de compartir, para hacer visibles las consecuencias de no hacer las cosas como se debería:

Preguntas (y errores) Frecuentes

1. ¿Y si no redirijo las urls? Si quieres conservar el tráfico y posicionamiento de tu proyecto, necesitas redirigir aquellas urls con valor. Lo habitual es que se redirijan las urls a no ser que estés pasando por una penalización y no quieras traspasarla al nuevo dominio o que no estés lanzando una nueva web, sino eliminando un proyecto que deja de existir.
2. ¿Y si redirijo solo las urls que más tráfico tengan? Despreciar el poder del long-tail suele ser una mala idea, al redirigir solo aquellas con mayor tráfico, estarás descartando el tráfico del 80% del sitio (como estimación). Esto supone un tráfico agregado importante en muchos casos. Solo deberías descartar redirigir lo que no tenga valor o no vaya a tener cabida en la nueva web.
3. ¿El tipo de redirección da igual, verdad? En términos generales solemos usar redirecciones de tipo permanente, 301 o 308. Hacerlo así garantiza una señal de «movido permanente» que indica que la url que deja de existir (la de origen) traspasa todas (o casi todas) sus señales a la nueva.
4. ¿Y si hago muchos cambios muy drásticos? Cuanto más compleja sea la migración, más difícil puede ser para usuarios y buscadores comprenderla. En estos casos, se puede intentar ir lanzando por partes distintos cambios. Por ejemplo, empezar con una reestructuración por secciones, luego un rediseño de las plantillas, luego con todo eso estabilizado, se puede ver un cambio de dominio. En cualquier caso, lo mejor en estos casos es asesorarse con expertos y evaluar los riesgos de hacerlo de una forma o de otra, con un ejercicio de escenarios.
5. ¿Y si el entorno de pruebas lo hago de otra forma? Puedes hacerlo realmente como quieras; lo principal es intentar evitar que el entorno de pruebas quede indexado en Google. No solo sería un problema SEO, sino que si estás lanzando un nuevo producto, servicio o marca, estás «desvelando involuntariamente» esa noticia exclusiva antes de tiempo y el equipo de comunicación tampoco estará contento con ello.
6. ¿Y si una vez migrado quiero volver atrás? Es fundamental en todos los procesos de migración tener un plan de «roll-back» por si hay que apretar el botón rojo y volver atrás para quedarnos como estábamos antes. Estos casos suelen ser críticos cuando se rediseñan partes clave del proyecto, como un checkout.
7. ¿Y siempre tengo que hacer este proceso para cualquier migración? No, existen cambios que son mucho más rápidos y ágiles, que no van a requerir un proceso tan exhaustivo como el explicado aquí. Por ejemplo, migraciones de http a https, son cambios muy sencillos de acometer y no requerirá una planificación tan detallada. A veces, cuando ya tenemos bien distintas áreas del proyecto y vamos a cambiar el diseño o el CMS, son cambios muy concretos, es probable que se pueda controlar sobradamente con metodologías más ágiles y express.

Algunos casos reales

• Proyecto con una tendencia negativa

En vez de arreglar los problemas que tiene, se decide migrar a un nuevo dominio para ver si así puede revertir la tendencia. La migración impecable, pero el problema de fondo, aún sigue sin arreglarse.

• Proyecto que cambia las urls sin mucha necesidad y olvida redirigir

Este proyecto con una marca muy conocida en su sector, decide modificar sus urls, son un motivo de peso aparente. A veces cambiar las urls en un CMS, no solo significa que las dejas «más bonitas» o «más cortas», significa que las urls anteriores generan un 404 a no ser que las redirijas. Este tipo de situaciones asociadas al CMS, hay que conocerlas, no hace falta ser muy técnico para entender que una url que antes se llamaba /a y ahora se llama /b, estamos «rompiendo» la url que ya existía.

En cualquier caso, sea quien sea el responsable, que no se haya redirigido en los días o semanas posteriores, denota que no son conscientes de los impactos o que pueden permitirse perder todo ese tráfico genérico.

• Proyecto que se deja olvidados unos cuantos noindex

Otra de las situaciones típicas: dejarse etiquetas noindex. En este tipo de casos, al ser algo técnico, suele suceder una recuperación en V, caída drástica y subida igual de drástica. El noindex actuaba como un dique; al quitarlo, prácticamente vuelve a tener los rankings que tenía antes. Esto nos vuelve a poner de relieve la importancia de la monitorización posterior a las migraciones y también de la velocidad de reacción que tengamos.

• Proyecto que tarda años en recuperarse después de una mala migración. A día de hoy, tiene una tendencia más o menos cercana a lo que tenía hace más de 7 años, cuando migramos, debemos aspirar a mejorar siempre.

• Proyecto que va y viene con cambios de dominio en el tiempo. Esto solo es el fruto de «corregir» malas decisiones iniciales. Lo peor de todo es que la tendencia que tenía en el pasado nunca la han recuperado. Es un gráfico para imprimir y poner a la vista, porque nos recuerda el impacto que tiene una decisión sobre la que hay que reflexionar mucho y bien. Sacrificar dominios locales líderes en cada mercado, es algo para poner en cuarentena y pensar bien, si no queremos sufrir consecuencias por años.

• Proyecto que redirige a un nuevo naming pero mantiene su home sin redirigir para conservar la marca temporalmente

Este caso muestra cómo se pueden personalizar las estrategias para los casos concretos que tengamos. Dejar la home indexada, sin redirigir, con un aviso informativo del rebranding y conservando las búsquedas de marca, en este caso, es una gran idea. Si en paralelo la nueva marca supera en demanda y popularidad, podrán plantearse redirigir la home próximamente.

• Proyecto que echa el cierre y tumba la web, sin redirigir

Este es el resultado de años de trabajo en crear una web, unos contenidos, en trabajar una audiencia y no poder salvarlo, ni en el espectro físico del negocio, ni en el digital (vendiéndolo, etc.). Se va a cero.

• Proyecto intervenido judicialmente que al final se queda un tercero pero no puede redirigir

Este es un caso muy muy muy especial ya que el proyecto no podría continuar por temas judiciales y, a pesar de que un tercero se iba a hacer cargo del negocio y de las deudas, se le impide poder mantener el nombre y redirigir. Esto es prácticamente empezar de cero.

• Proyecto que va siendo comprado por distintas empresas. A veces cuando observamos cómo se comporta un proyecto, tenemos dudas de cómo ha llegado hasta esa tendencia. Muchas veces obviamos el histórico pasado, las decisiones que se han ido tomando en materia de fusiones, adquisiciones, etc. Esto también marca el camino e histórico del SEO, arrastrar problemas de otros dominios, integrarlos en el nuestro….

Otros consejos de expertos

Alfonso Moure, Experto en SEO técnico y Web Analytics, CEO en bigmomo

«Las decisiones que se toman respecto a SEO durante una migración suelen depender de la respuesta a una pregunta: ¿por qué migras? ¿Es un cambio de tecnología, de marca o de negocio?

Si es lo primero, el cambio de tecnología marcará a dónde te mudas y qué dejas atrás. Esto determinará dónde vivirán las redirecciones que has de implementar para mantener tu indexación y a dónde apuntarán. Conocer de antemano si tu nuevo hogar permite redirecciones HTTP o si las hará mediante Javascript es vital.

En el secundo caso, los cambios de marca siempre son un reto. Mantener tu nombre original en el destino y citar siempre que sea viable el hecho de que cambias tu branding es absolutamente fundamental: X es ahora Y, X cambia de nombre a Y, Y, antes conocido como X, etc. Esto ayudará a los buscadores tradicionales y a los basados en IA a entender lo que pasa.

Finalmente, ante un cambio de negocio, lo más probable es que vayas a hacer modificaciones de arquitectura, trabajar un nicho semántico distinto y afrontar un enfoque bastante diferente al original. Quizá no todos tus contenidos actuales tengan cabida en tu nueva casa. En ese caso, has de afrontar la realidad: redirigir lo que tenga sentido y dejar morir lo que no. 

No tengas miedo a dejar cosas marchar, porque lo que importa más hoy en día es su valor semántico: redirigir por mantener enlaces externos ya no es tan importante.»

Nekane Abuelo, consultora SEO en Laika

Un mapeado de redirecciones preciso es la base para evitar caídas de tráfico durante una migración. Sin embargo, este proceso también representa una oportunidad estratégica: aprovechar el cambio para optimizar la parte técnica y elevar la calidad de los contenidos. De esta forma, no solo podemos mantener la visibilidad actual, sino que podemos impulsar un crecimiento orgánico significativo.

Pero si tuviera que destacar un factor clave en cualquier migración, ese sería la organización y dirección del proyecto a nivel de gestión. El éxito pasa por entender los impactos que la migración va a tener en el proyecto y trazar un planning realista en el que todos los implicados trabajen codo a codo con un objetivo común: salir en fecha con la web en las mejores condiciones.

Conclusiones y recursos

Una migración es una decisión importantísima que afecta prácticamente a todos los canales en los que un proyecto trabaja e invierte, por lo que es crucial migrar solo cuando sea estrictamente necesario, ya que el impacto y los riesgos son altos y podría pasar factura al rendimiento global del proyecto y del negocio.

Como ya hemos visto, existen migraciones mal concebidas o planificadas que tardan años en recuperarse, si es que lo llegan a conseguir. Este mensaje es el que deberían recibir los perfiles de decisión de cualquier proyecto pensando en migrar o en hacer cambios considerables.

Con esto no quiero decir que haya que ser conservador o defensivo, solo que hay que migrar cuando la ocasión lo justifica, ya se ha visto que un exceso de cambios de dominio no tiene por qué salir mal, pero va añadiendo complejidad y en algunos casos, ruido. Al final todas las muescas que le hagamos al proyecto, tendrán eco en el presente, estaremos influyendo en el proyecto con todo el histórico que le hayamos construido.

Para cerrar, las migraciones en la actualidad tienen ese riesgo añadido de la reevaluación que llevan a cabo buscadores como Google que revisan a fondo la web para comprobar que cumple con criterios de calidad para seguir en el índice. No olvidemos que el índice de Google es insustituible por las nuevas tendencias de búsqueda como ChatGPT.

Sin duda, las migraciones son algo de relación directa con el negocio, la experiencia de usuario y su satisfacción, y eso, no nos engañemos, siguen siendo las grandes aspiraciones del SEO: estar en el sitio donde los usuarios están, con el mejor contenido que les satisfaga.

Podremos agilizar parte del proceso y metodologías, pero sigue habiendo un componente humano de entendimiento, de gestión y priorización, y sobre todo, de experiencia, que no podemos poner en riesgo.

Si quieres ver más recursos y casos de estudio:

• Cómo trasladar un sitio (Google) https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=es
• Recursos sobre migraciones https://learningseo.io/seo_roadmap/deepen-knowledge/scenarios/seo-for-web-migrations/
• Migraciones SEO con Screaming Frog, paso a paso: https://www.youtube.com/watch?v=t_fuaKQEkHI&t=23s
• Puntos clave de una migración: https://ikaue.com/blog-seo/migraciones-seo-7-puntos-clave
• Análisis de 36 migraciones SEO https://www.sistrix.es/blog/migraciones-seo-espana-aprendizajes-seo/
• Las señales SEO en una migración: https://www.sistrix.es/blog/la-importancia-de-las-senales-seo-en-una-migracion/
• Migración SEO por fases: https://www.sistrix.es/blog/migracion-seo-fases-selecta-clubrural/
• Migración SEO Internacional: https://www.sistrix.es/blog/migracion-seo-internacional-clarks/
• Agilizar mapeado https://searchengineland.com/site-migrations-ai-powered-redirect-mapping-437793
• Mapear con Screaming Frog https://www.screamingfrog.co.uk/seo-spider/tutorials/how-to-use-the-seo-spider-in-a-site-migration/