Migración SEO: guía para no perder posicionamiento orgánico

Cada vez que una empresa decidís cambiar de dominio, migrar de CMS o simplemente rediseñar vuestra web, un profesional de SEO se coge una baja. No tenéis ni idea de todo lo que os jugáis, queridos. Todos esos años de trabajo SEO acumulados. Todo ese posicionamiento ganado que puede perderse. Puff. Se esfuma.

Y ahí es donde entra la migración SEO. Porque parece fácil pero no lo es. Sin embargo es necesario si no queremos perderlo todo. Un proceso técnico que requiere método, paciencia y, sobre todo, anticipación. Y eso justo es lo que vamos a ver, paso a paso. Cómo planificar una migración web sin que el posicionamiento orgánico se resienta, qué errores evitar y qué checklist seguir antes, durante y después del cambio. Dicho esto, al lío.

Una migración SEO es, dicho en plata, el conjunto de acciones técnicas y estratégicas que se ponen en marcha cuando una web sufre un cambio estructural relevante (de dominio, de CMS, de protocolo o de diseño) con el objetivo de que ese cambio no le cueste el posicionamiento ganado en Google. Es el seguro que evita que un proyecto digital se pegue un tiro en el pie justo cuando más visibilidad necesita.

¿Por qué le temen tantos profesionales? Pues porque Google tiene que volver a interpretar por completo tu sitio. Sus URLs, su arquitectura, su relación de enlaces internos y externos, su autoridad… todo se pone, de nuevo, sobre la mesa. Y eso da miedo. O no, si sabes hacerlo. Porque aquí es donde cobran protagonismo elementos técnicos como los códigos de respuesta HTTP, que son el lenguaje con el que tu servidor le dice a los buscadores si una página existe, si se ha movido o si ha desaparecido. Un mapeo erróneo de estos códigos durante la migración web es, con diferencia, una de las causas más comunes de pérdida de tráfico.

Hay que tener en cuenta que no todas las migraciones nacen igual ni conllevan el mismo nivel de riesgo. Por ejemplo, cambiar de dominio (véase, de un «.com» a un «.es», o por un rebranding completo) es, con diferencia, el movimiento más delicado, porque implica reconstruir desde cero toda la señal de confianza que Google asocia a esa URL raíz. Migrar de CMS, en cambio, suele ser algo más contenido si se hace bien, aunque tenemos que avisar que, como la vida, no está exento de sorpresas.

Tipos de migración web (cambio de dominio, CMS, HTTP a HTTPS, rediseño)

Conviene tener claro que el término migración engloba escenarios muy distintos entre sí, cada uno con su propio nivel de exposición:

• Cambio de dominio. Mover el contenido de un dominio a otro, ya sea por rebranding, fusión de marcas o expansión internacional. Es el tipo de migración de mayor riesgo SEO.
• Cambio de CMS. Pasar de una plataforma a otra (de WordPress a Shopify, por citar un caso) suele alterar la estructura de URLs, las etiquetas de forma automática y, en muchos casos, el propio sitemap.
• Migración de HTTP a HTTPS. Técnicamente es de las más sencillas, pero sigue exigiendo un mapa de redirecciones bien hecho para no perder señales de seguridad ni autoridad.
• Rediseño de sitio web. Aunque no cambien ni el dominio ni las URLs, un rediseño visual profundo puede tocar elementos on-page críticos si no se planifica con cuidado.
• Cambio de subdominio a dominio (o viceversa). Pongamos que tenemos un blog (blog.tuweb.com) y queremos moverlo a tuweb.com/blog. Eso afecta a la arquitectura de enlazado interno.
• Consolidación de varios sitios en uno solo. Habitual tras fusiones empresariales, donde hay que decidir qué contenido se conserva y cuál se descarta.

Para dimensionar el volumen de migraciones que se producen cada año solo por cambios de plataforma, basta con mirar la evolución del mercado de gestores de contenido:

Cada punto de cuota que gana o pierde una plataforma representa, en la práctica, cientos de miles de webs que en algún momento pasarán por un proceso de migración de CMS, con todo lo que ello implica a nivel de sitemap, plantillas y estructura de URLs.

Señales de que tu proyecto necesita una migración

No siempre la decisión de migrar es una elección estratégica bien meditada; a veces viene forzada por el propio negocio. ¿Cómo descubrirlo? ¿A qué tenemos que prestar atención?

• Tu web sigue en HTTP y los navegadores la marcan como no segura.
• Vas a lanzar un rebranding y necesitas rediseñar sitio web sin perder SEO en el proceso.
• Tu CMS actual se ha quedado obsoleto, es lento o ya no recibe soporte ni actualizaciones de seguridad.
• Has fusionado tu empresa con otra y necesitas consolidar dos (o más) dominios en uno.
• Quieres expandirte a otro país y necesitas una nueva estructura de dominios o subcarpetas por idioma.
• Tu arquitectura de URLs es un caos heredado de años de parches y necesitas empezar de cero.
• El tiempo de carga de tu web está penalizando tanto la experiencia de usuario como el posicionamiento.
• Necesitas escalar tu ecommerce a una plataforma con más capacidad técnica.

Cada una de estas señales conlleva un nivel de riesgo distinto, y es precisamente esa variedad la que obliga a plantear la migración SEO como un proyecto a medida, nunca como una checklist genérica copiada de otro caso. Si no sabemos cómo hacerlo, por favor, acudamos a profesionales. No es algo que puedas hacer con el Chat GPT de turno.

El principal problema es que no se le da la importancia que merece y por eso, la mayoría de migraciones no se plantean con ese nivel de rigor necesario, y ahí es donde empiezan a aparecer los problemas.

Como una venérea, los riesgos de una migración mal planificada no suelen manifestarse el mismo día del lanzamiento, sino semanas después, cuando Google ya ha tenido tiempo de rastrear la nueva estructura y detectar que algo no cuadra. Para entonces, revertir el daño cuesta mucho más tiempo y dinero que haberlo prevenido desde el principio. Y aquí no estamos hablando solo de un problema técnico, hablamos de un impacto directo, porque cada posición perdida en el buscador es tráfico, y cada visita perdida es una potencial conversión que ya no llega.

Pérdida de tráfico orgánico y rankings

Es, sin lugar a dudas, el miedo número uno de cualquier responsable de marketing antes de encarar un cambio de web. Y con razón, porque Google tiene que reprocesar miles de URLs de golpe y cualquier fallo en el mapeo supondrá caídas de visibilidad que pueden tardar semanas o meses en corregirse. Esto es el monstruo del saco de cualquier que haga SEO.

Y es que la causa más habitual son errores puramente evitables. Errores tontos como:

• Redirecciones mal configuradas.
• Contenido que desaparece sin sustituto.
• Una arquitectura nueva que no respeta la relevancia semántica que tenía la anterior.

Google necesita tiempo para reaprender. Entendamoslo. Es tu sitio, pero no es tu sitio. Aún no. Y ese margen de reindexación es, precisamente, el punto en que más se resiente el tráfico si algo se ha hecho mal.

Enlaces rotos y errores 404

Cuando una URL antigua deja de existir sin que exista una redirección hacia su equivalente nuevo, el servidor devuelve un código 404, y ese 404 le dice a Google (y al usuario) que ahí ya no hay nada que ver. Cogito, ergo sum que decía Descartes.

El problema es que, durante una migración, estos errores tienden a multiplicarse sin control porque no se hizo un inventario previo de URLs indexadas. Cuantos más enlaces rotos, más señales negativas recibe el buscador sobre la calidad y el mantenimiento del sitio, y más recursos de rastreo se desperdician en callejones sin salida. Por eso mismo conviene distinguir bien entre los códigos que se pueden encontrar en este escenario, porque cada uno comunica algo distinto a los motores de búsqueda:

• 200 (OK): La URL existe y responde correctamente. Es el único código que debería aparecer en tu sitemap.
• 301 (movido permanentemente): La opción correcta cuando una URL cambia de dirección de forma definitiva; transfiere la señal de relevancia a la nueva ubicación.
• 302 (movido temporalmente): Solo debería usarse cuando el cambio es realmente provisional, ya que no transmite la misma continuidad de posicionamiento que un 301.
• 404 (no encontrado): La página no existe y no se sabe si volverá. Aceptable solo si es puntual y controlado.
• 410 (eliminado permanentemente): Más preciso que el 404 cuando sabes con certeza que un contenido no va a volver, ya que ayuda a Google a desindexarlo antes.

Pérdida de autoridad de dominio (backlinks)

La muerte silenciosa la llaman, porque no siempre se ve reflejado de inmediato en las métricas de tráfico, pero sí en la capacidad de tu web para competir a medio plazo. Cada enlace externo que apunta a tu dominio es un voto de confianza acumulado durante años, y si esos enlaces apuntan a URLs que desaparecen sin redirección, ese voto se pierde por el camino.

La buena noticia, es que las redirecciones 301 y otras redirecciones permanentes no provocan pérdida de PageRank en sí mismas. Es decir, el problema no es usar un 301, sino usarlo mal encadenando varias redirecciones sucesivas en vez de apuntar directamente al destino final. Google es capaz de seguir hasta 10 saltos en una cadena de redirecciones, pero la propia compañía recomienda mantener esas cadenas lo más cortas posible, idealmente no más de tres y siempre por debajo de cinco.

Ojo este último punto porque muchas empresas retiráis las redirecciones a los pocos meses para limpiar el servidor, justo cuando todavía quedan enlaces externos y tráfico residual que dependen de ellas. Cortar ese puente antes de tiempo es como estar entrenando todo el año para un torneo y luego no ir a competir.

Auditoría previa: mapear todas las URLs indexadas

Antes de tocar una sola línea de código, necesitas saber exactamente qué tienes. Esto implica:

• Exportar el listado completo de URLs indexadas por Google (vía Search Console y un rastreo tipo Screaming Frog).
• Cruzarlo con las páginas que generan tráfico orgánico real.
• Anotar cuáles reciben enlaces externos de valor.

Sin este inventario, cualquier mapa de redirecciones que hagas después será, en el mejor de los casos, incompleto.

Crear el mapa de redirecciones 301

Seguramente el documento más importante de toda la migración. Se trata de una tabla URL a URL (origen → destino) que garantiza que cada dirección antigua apunta a su equivalente exacto en la nueva web, nunca a la home de forma genérica ni a una categoría aproximada.

Ahí os van unos tips para construirlo bien:

• Prioriza primero las URLs con tráfico, rankings o backlinks activos.
• Evita en todo momento las redirecciones en cadena ya que el destino debe ser siempre directo.
• Documenta también las páginas que decides no migrar y por qué (contenido obsoleto, thin content, duplicados).
• Haz que revisen el mapa al menos dos perfiles distintos (SEO y desarrollo), para detectar errores cruzados.

Preservar la arquitectura de enlazado interno

¿Por qué preservarlo? Fácil. El enlazado interno es la forma en la que se reparte autoridad entre las páginas de tu propia web, y es, como las personas con autismo tremendamente sensible a los cambios, en su caso, de estructura. Si el rediseño reorganiza menús, categorías o breadcrumbs sin cuidado, puedes acabar aislando páginas que antes recibían enlaces internos relevantes, dejándolas huérfanas a ojos de Google.

¿Nuestra recomendación? Replica en la nueva arquitectura la lógica de enlazado que ya funcionaba, y solo optimízala una vez confirmado que la migración se ha estabilizado.

Actualizar sitemap.xml y robots.txt

Uno de los cuellos de botella más habituales tras una migración web. Son literalmente las dos piezas técnicas que le dicen a Google por dónde puede y por dónde no debe pasar. Durante una migración, ambos archivos deben regenerarse desde cero:

• El sitemap debe reflejar exclusivamente las URLs nuevas y activas (recordemos que solo deben incluirse URLs con código de respuesta 200).
• El robots.txt no puede seguir bloqueando por error rutas que ahora sí quieres que se indexen.

El propio protocolo oficial de sitemaps y que los principales motores de búsqueda siguen a pies juntillas, establece límites técnicos muy concretos que conviene tener siempre presentes:

Vale, cambiamos de escenario. Ahora no vamos a cambiar de dominio o de CMS pero sí vamos a hacer un pequeño rediseño visual. Una nueva plantilla. Una nueva paleta. Una nueva experiencia de usuario. Cosas, vaya, pero cosas manteniendo las mismas URLs. Por eso es tan importante que el departamento de diseño y el equipo SEO trabajen codo con codo desde el primer boceto, en vez de que SEO entre a corregir errores cuando el proyecto ya está cerrado.

Qué elementos on-page no debes tocar sin plan (title, meta, H1)

Hay elementos que, aunque parezcan puramente de contenido, tienen un peso SEO directo y no deberían modificarse sin una razón estratégica de fondo:

• Title tags: cualquier cambio masivo sin justificación puede alterar el CTR en resultados de búsqueda.
• Meta descriptions: no son un factor de ranking directo, pero sí influyen en los clics.
• Encabezados H1: deben seguir reflejando la intención de búsqueda principal de cada página.
• Estructura de encabezados H2/H3: un rediseño que «aplana» la jerarquía visual puede confundir tanto a usuarios como a buscadores.

Migrar contenido y metadatos sin duplicidades

Versiones antiguas que quedan accesibles en paralelo a las nuevas, plantillas que arrastran metadatos genéricos, URLs con parámetros que crean múltiples copias de una misma página. Podríamos seguir todo el día, sin embargo sea la casuística que sea, la solución pasa por definir con claridad las etiquetas canónicas y auditar exhaustivamente cada plantilla antes de darla por buena.

Entorno de staging y pruebas antes del lanzamiento

Si antes de correr hay que andar, antes de exponer nada a Google toca comprobar que las redirecciones funcionan, que no hay errores 404 nuevos, que el sitemap se genera correctamente y que la velocidad de carga no se ha resentido con el nuevo diseño.

Ninguna migración debería probarse en producción. Jamás.

Si estabas pensando que el trabajo está hecho en cuanto se activa la nueva web, vas listo/a. Ahora es cuando empieza lo divertido. Espero que tengas buen pulso porque empieza la fase más delicada de todo el proceso. Las primeras semanas tras el lanzamiento son las que determinan si la migración ha sido todo un éxito o un problema que va a colear tiempo.

Monitorización de Search Console y errores de rastreo

¿Piensas que pasas mucho tiempo en Instagram o Tik Tok? Verás cuando descubras Google Search Console. ¿Por qué te decimos esto? Porque conviene revisar varios informes, como mínimo, a diario durante las primeras semanas.

Seguimiento de posiciones y tráfico las primeras semanas

Además de Search Console, es recomendable llevar un seguimiento diario de posiciones para el listado de keywords prioritarias, comparándolo con el snapshot tomado justo antes de la migración. ¿Cosas a tener en cuenta? Que la comparación no debe limitarse al tráfico total. Hay que fijarse también en las impresiones, porque una caída ahí suele anticipar problemas de indexación antes incluso de que se note en las visitas.

Cómo detectar y corregir caídas de tráfico a tiempo

Cuando aparece una caída, antes de tocar nada, conviene:

1. Confirmar si la caída es generalizada o afecta solo a un grupo concreto de páginas.
2. Revisar si coincide con URLs que no tienen redirección o que devuelven error.
3. Comprobar si Google ha indexado ya la nueva versión de esas páginas.

Detectar el problema a tiempo (y con esto nos referimos a que sea en cuestión de días, cuasi semanas y no de meses) hará que sea un ajuste rápido o bien, una pérdida de posicionamiento que costará recuperar.

El primero es obvio. No habernos contratado para hacerlo. Luego, casi siempre son las prisas o por falta de coordinación entre equipos. Pero también están…

Redirecciones en cadena o hacia páginas irrelevantes

Sí, ya lo hemos comentado antes, pero conviene insistir porque es, con diferencia, el error más extendido. En lugar de un mapa preciso URL a URL, muchas migraciones optan por el atajo de redirigir todo a la home o a una categoría genérica. Esto rompe por completo la relevancia semántica que Google esperaba encontrar y, en la práctica, equivale a tratar esas URLs como si hubieran desaparecido.

Olvidar el hreflang en proyectos multi-país

En proyectos con varias versiones de idioma o país, el hreflang es de los aspectos técnicos más propensos al error, y una migración es el momento perfecto para que esos fallos se multipliquen. Según un estudio de Ahrefs, que analizó cerca de 375.000 dominios que la utilizaban, un 67% presentaba al menos un problema de implementación. Entre los más habituales:

• Falta de reciprocidad entre páginas (la versión en español no enlaza de vuelta a la inglesa, o viceversa).
• Códigos de idioma o país mal formateados.
• Hreflang apuntando a URLs redirigidas o con error, en lugar de a páginas con código 200.

Por la tranquilidad. Por evitar liarla. Porque si has llegado hasta aquí, al menos tendrás clara una cosa. Una migración SEO no es un proyecto que se pueda improvisar ni delegar exclusivamente en quien diseña o desarrolla la nueva web. Lo lamentamos, pero no. Requiere una capa de análisis estratégico, técnico y de negocio que trabaje en paralelo.

Si tu empresa está valorando un cambio de dominio, una migración de CMS o un rediseño completo, el mejor momento para hablar con un equipo especializado en SEO técnico es antes de que el proyecto arranque, no después de ver caer el tráfico. Haznos caso, por favor, que lo hemos visto muchas veces. Proteger tu cuota de mercado online y maximizar el ROI de años de puro trabajo SEO merece ese nivel de cuidado, ¿no?

¿Y sabes a quienes se les da súper bien proteger? A nosotros.

¿Y bien? ¿Hablamos de ese proyecto?