Rediseño o migración web sin perder posicionamiento SEO

Rediseñar una página web o migrarla a otra plataforma es una de las operaciones con más riesgo para el tráfico orgánico: el riesgo principal no es que la web nueva sea peor, sino que Google deje de encontrar lo que antes posicionaba. La buena noticia es que casi todos los problemas de una migración web SEO se pueden prevenir con método: inventariar las URL, redirigir cada una a su equivalente con una redirección 301, mantener las señales técnicas (canonicals, hreflang, sitemaps), vigilar el rendimiento y, si cambia de dominio, avisar a Google con la herramienta de cambio de dirección de Search Console. Esta guía recoge el proceso paso a paso, basado en la documentación oficial de Google, con una lista de comprobación al final.

Una advertencia honesta: ninguna migración garantiza que el tráfico no se mueva. Google indica que las posiciones y la visibilidad pueden fluctuar durante el proceso y que, en un sitio de tamaño medio, puede llevar semanas o más que las URL nuevas sustituyan a las antiguas. Lo que sí puede hacer es reducir el riesgo y reaccionar rápido.

Qué tipo de cambio es: no todo es una migración

Los riesgos y los pasos dependen de qué cambie. Distinga:

• Rediseño visual sin cambiar URL ni contenidos: el riesgo es sobre todo de rendimiento y de estructura (menús, enlaces internos, encabezados).
• Cambio de CMS o de plataforma (por ejemplo, de una tienda a otra) con cambio de URL: exige un mapa completo de redirecciones.
• Cambio de dominio o de subdominio: además de las redirecciones, procede la herramienta de cambio de dirección.
• Paso de HTTP a HTTPS o de www a no-www: Google detecta el primero automáticamente y no hace falta la herramienta de cambio de dirección en ninguno de los dos casos; basta con redirecciones y canonicals.
• Reestructuración de contenidos o de idiomas: afecta a hreflang y a la arquitectura de enlaces.

Una regla de la propia documentación de Google sobre migraciones con cambio de URL: cambie una sola cosa a la vez y elija un periodo de poco tráfico. Si puede separar el cambio de dominio del rediseño, hágalo en dos fases.

Antes del lanzamiento: inventario y mapa de URL

1. Inventario de lo que existe

Reúna todas las URL del sitio antiguo desde fuentes distintas: el sitemap, el gestor de contenidos, el análisis web, los registros del servidor y Search Console. Incluya también imágenes, vídeos, PDF, CSS y JavaScript, como recomienda Google. Anote para cada URL su tráfico orgánico, sus enlaces externos y su posición para las palabras clave principales.

2. Mapa uno a uno

A cada URL antigua le corresponde una URL nueva equivalente. Si un contenido desaparece, decida qué hacer: redirigir a la página más parecida o dejar que devuelva un error 404 o 410. Google insiste en un punto: no envíe muchas URL no relacionadas a una sola página, como la portada, porque pierde el valor de esos contenidos y confunde al usuario.

3. Entorno de pruebas protegido

Trabaje la web nueva en un entorno de pruebas que no pueda indexarse (por contraseña o con las medidas adecuadas) y, al lanzar, compruebe que ha retirado cualquier bloqueo en robots.txt o etiqueta noindex que se hubiese puesto durante el desarrollo. Es un error clásico y devastador: lanzar una web con noindex.

4. Conserve lo que funciona

No rediseñe lo que posiciona sin saber por qué posiciona. Mantenga los títulos, los encabezados y los textos de las páginas con buen rendimiento, salvo que tenga motivo para cambiarlos. Si alguna página tiene un contenido que atrae tráfico, el nuevo diseño debe respetarlo.

Redirecciones 301: la pieza central

Google recomienda usar redirecciones permanentes en el servidor (301 o 308). Algunas reglas prácticas, todas tomadas de su guía de migraciones:

• Redirija cada URL antigua directamente a su destino final, sin cadenas de redirecciones.
• Mantenga las redirecciones como mínimo un año. Si cambió de dominio, además mantenga el dominio antiguo pagado el mayor tiempo posible.
• Actualice los enlaces internos de la web nueva para que apunten a las URL finales y no pasen por la redirección.
• Si puede, pida a los sitios que le enlazan que actualicen sus enlaces a las URL nuevas.
• Pruebe las redirecciones con una muestra amplia antes del lanzamiento y con la herramienta de inspección de URL de Search Console después.

Una redirección bien hecha traslada las señales de la URL antigua a la nueva, pero no sustituye a un contenido pobre ni a una estructura confusa.

Canonicals, hreflang y sitios multidioma

Si su web tiene varias versiones de idioma o país, la migración es el momento de más riesgo para el hreflang, la anotación que le dice a Google qué versión mostrar a cada usuario. Las reglas básicas, según Google:

• Enlaces recíprocos: si la página A señala a la B, la B debe señalar a la A. Las etiquetas sin retorno pueden ignorarse.
• Autorreferencia: cada versión debe incluirse a sí misma, y el conjunto de etiquetas debe ser el mismo en todas las versiones.
• URL completas: con protocolo (https://…), no rutas relativas.
• x-default: una página de reserva para usuarios cuyo idioma no coincida con ninguna versión.
• Un solo método: puede usar etiquetas en el <head>, una cabecera HTTP o el sitemap XML; Google los trata igual. Elija uno.
• Códigos válidos: idioma (ISO 639-1) con país opcional, como es-ES o en-GB. Un código de país solo no es válido.

En la migración, las URL de hreflang y los canonicals de la web nueva deben apuntar a las URL nuevas, no a las antiguas. En PDF Nova, que está disponible en seis idiomas, la coherencia entre versiones es precisamente lo que hay que cuidar en cada cambio de estructura.

Sitemaps: cómo ayudar a Google a descubrir el cambio

Un sitemap es un archivo que lista las páginas del sitio. Según la documentación de Google:

• Un sitemap admite hasta 50.000 URL y 50 MB sin comprimir; para sitios mayores se usan varios archivos y un índice.
• Google ignora <priority> y <changefreq>.
• Google solo usa <lastmod> si es coherente y verificable, es decir, si refleja cambios significativos reales.
• Puede enviarlo desde el informe de sitemaps de Search Console o indicarlo en robots.txt.

Durante la migración, Google propone conservar y vigilar los dos sitemaps: el antiguo, para ver cómo baja el número de URL indexadas, y el nuevo, para ver cómo sube. Enviar un sitemap es una pista, no una garantía de rastreo. Para sitios pequeños, enlazados internamente de forma completa, es menos crítico, pero en una migración conviene tenerlo.

Core Web Vitals: que la web nueva no sea más lenta

Un rediseño puede empeorar la velocidad sin que nadie lo note: imágenes más pesadas, scripts de terceros, fuentes personalizadas. Los Core Web Vitals son tres métricas con estos umbrales de «bueno», medidos en el percentil 75 de las visitas y separando móvil y escritorio:

Mida su sitio actual antes de empezar para tener una referencia, y vuelva a medir en el entorno de pruebas antes del lanzamiento. En nuestro caso de Kachouri Getränke-Service, una tienda de 812 productos migrada de Shopware 5 a WooCommerce, el CLS en móvil pasó de 0,44 a 0: un ejemplo de que una migración también puede ser la ocasión de mejorar la estabilidad visual, no solo de no empeorarla. Los Core Web Vitals son una de varias señales; un mal rendimiento no compensa un contenido que no responde a lo que busca el usuario, pero tampoco conviene ignorarlo.

El día del lanzamiento y la herramienta de cambio de dirección

Con todo preparado, la secuencia que describe Google es:

1. Active las redirecciones y compruebe que los canonicals, las reglas de robots.txt y las etiquetas meta robots son correctos.
2. Verifique en Search Console tanto el sitio antiguo como el nuevo, incluidas todas las variantes (con y sin www, http y https).
3. Envíe el sitemap nuevo.
4. Si cambia de dominio o de subdominio, use la herramienta de cambio de dirección.

Sobre este último paso, la ayuda de Search Console precisa:

• Sirve para decirle a Google que el sitio se ha movido de un dominio o subdominio a otro, después de haberlo trasladado y de configurar las redirecciones.
• Debe ser propietario de ambas propiedades de Search Console con la misma cuenta de Google, y solo funciona con propiedades de nivel de dominio, no de ruta.
• Antes de enviar la solicitud, hace una comprobación rápida de propiedad y de redirecciones 301, y un fallo grave debe corregirse antes.
• Sus efectos duran 180 días desde que se inicia; la ayuda recomienda mantener las redirecciones al menos ese tiempo y, si es posible, conservar el dominio antiguo durante al menos un año.
• No se usa para pasar de HTTP a HTTPS, de www a no-www, para mover solo algunas páginas dentro del mismo sitio ni para cambios de hosting con las mismas URL.
• No encadene movimientos (de A a B y enseguida a C) ni fusione varios sitios en un solo paso: mueva un sitio cada vez y deje que el tráfico se estabilice.

Después del lanzamiento: qué vigilar

Durante las primeras semanas, revise de forma periódica:

• Indexación: el número de URL indexadas del sitio antiguo debe bajar y el del nuevo subir, según los sitemaps. Revise el informe de indexación para detectar errores.
• Consultas y páginas: que las URL nuevas aparezcan en el informe de rendimiento de Search Console.
• Errores 404: URL antiguas con tráfico o enlaces que se hayan quedado sin redirección.
• Registros del servidor: actividad de Googlebot y códigos de error. Asegúrese de que el servidor aguanta el aumento de rastreo que suele producirse tras una migración.
• Análisis web: el tráfico debe pasar de las URL antiguas a las nuevas, y las conversiones deben mantenerse.

Si detecta un patrón de errores, corríjalo cuanto antes, sin esperar a que «se arregle solo».

Lista de comprobación

• Inventario completo de URL con tráfico y enlaces
• Mapa 1 a 1 de redirecciones, sin cadenas y sin destinos genéricos
• Sitio nuevo en entorno de pruebas no indexable
• Canonicals, hreflang y enlaces internos apuntando a URL nuevas
• Sitemap nuevo preparado; sitemap antiguo conservado para comparar
• Medición previa y posterior de Core Web Vitals
• Search Console verificado en ambos sitios (todas las variantes)
• Redirecciones 301 activas y probadas
• noindex y bloqueos de robots.txt retirados
• Cambio de dirección enviado (solo si cambia de dominio o subdominio)
• Redirecciones mantenidas al menos un año
• Monitorización semanal durante las primeras semanas

Preguntas frecuentes

¿Cuánto tarda Google en reflejar una migración?

Google indica que, en un sitio de tamaño medio, puede llevar unas semanas o más hasta que las URL nuevas sustituyan a las antiguas, y que los sitios grandes tardan más. No hay una cifra exacta para todos los casos.

¿Cuánto tiempo debo mantener las redirecciones 301?

Como mínimo un año, según la documentación de Google. Si cambió de dominio, mantenga también el antiguo el mayor tiempo posible.

¿Hace falta la herramienta de cambio de dirección si solo cambio de CMS?

No. Solo se usa si cambia de dominio o de subdominio. Para cambios de URL dentro del mismo dominio, las redirecciones y el sitemap son lo que cuenta.

¿Puedo rediseñar la web y cambiar el contenido a la vez?

Puede, pero aumenta el riesgo y dificulta saber qué causó un cambio de tráfico. Si es posible, separe el rediseño de los grandes cambios de contenido.

¿Qué hago si el tráfico cae después del lanzamiento?

Compruebe primero lo básico: redirecciones, noindex, robots.txt, canonicals y errores de rastreo. Una caída leve en las primeras semanas puede ser normal; una caída fuerte y persistente suele indicar un fallo técnico concreto.

Conclusión

Una migración sin pérdida de posicionamiento no es cuestión de suerte, sino de preparación: inventario de URL, redirecciones 301 uno a uno, hreflang y canonicals coherentes, sitemaps, Core Web Vitals controlados y, si se cambia de dominio, la herramienta de cambio de dirección de Search Console. Y después, vigilancia. Si va a rediseñar o migrar su web y quiere un plan a medida, consulte nuestro servicio de creación de páginas web o, si se trata de una tienda, el de desarrollo de tiendas online. También hicimos un rediseño del sitio de Club Photo Tunis, un club de fotografía con actividades, eventos y biblioteca de fotos. Para plantear su caso, puede escribirnos; y para decidir antes la plataforma, le puede servir nuestra comparativa WordPress o desarrollo web a medida.