Migración web SEO: la checklist para cambiar URL sin perder tráfico

Para hacer una migración web sin perder posiciones en Google, cada URL antigua debe llevar directamente a su nueva equivalente con una redirección permanente del lado del servidor (301 o 308). Mantén los contenidos, quita los bloqueos del entorno de pruebas al lanzar y cambia canonical, hreflang, enlaces internos y sitemap a las nuevas direcciones. Después conserva las redirecciones al menos un año y sigue Search Console durante semanas. Te mostramos cada paso con nuestra propia web: en octubre de 2026 cambiamos 35 de nuestras URL y registramos cómo respondieron el servidor y Google.

Qué supone una migración web para Google

Una migración puede ser un diseño nuevo, otro gestor de contenidos (CMS), un dominio nuevo, el paso a HTTPS o URL nuevas. Para el SEO, un diseño nuevo sobre las mismas URL es un cambio pequeño; una estructura de URL nueva es un traslado.

Según la guía de Google «Cómo trasladar un sitio», su robot tiene que visitar al menos una vez todas las URL antiguas y nuevas, y el traslado se procesa URL a URL. Las señales, como los enlaces, pasan por las redirecciones, y Google afirma que las redirecciones 301 y otras permanentes no afectan negativamente al PageRank. Sus tres reglas básicas: hacer los cambios de uno en uno (primero el dominio, luego el diseño), aprovechar un periodo de poco tráfico y contar con que el posicionamiento fluctúe mientras Google vuelve a rastrear el sitio.

Nuestro caso: 35 URL cambiadas en dos días

Polytested pasó a ser indexable el 13 de octubre de 2026 y, pocas horas después, cambiamos la dirección de la página del autor. El 14 de octubre, nuestras nueve guías en alemán recibieron slugs más largos y descriptivos el mismo día de su publicación, y más tarde, cerca de un día después del lanzamiento, les siguieron nuestras 25 guías en inglés. Ninguna de nuestras direcciones en español ha cambiado.

El 17 de octubre, las 35 URL antiguas respondían todas con un 308 hacia la dirección nueva correcta, y las nuevas, con 200. Eso sí, esas URL tenían entre unas horas y un día, casi sin enlaces: mostramos la mecánica y los primeros días en Search Console, no un efecto duradero en el posicionamiento. Las cambiamos pronto a propósito, porque cuanto más vieja es una URL, más señales dependen de ella.

Paso 1: reunir todas las URL antiguas

Solo puedes redirigir las direcciones que conoces, y ninguna fuente está completa por sí sola. Google aconseja combinar:

• los sitemaps XML del sitio antiguo;
• los registros del servidor, en un periodo que incluya las páginas de temporada;
• tu herramienta de analítica, para las páginas con más tráfico;
• el informe «Enlaces» de Search Console (sus tablas muestran como máximo 1000 filas);
• tu CMS;
• un rastreo del sitio antiguo: la versión gratuita de Screaming Frog SEO Spider llega a 500 URL.

Google pide incluir también imágenes, vídeos y archivos JavaScript y CSS, y los PDF pueden tener su propio tráfico. Guarda además el punto de partida (clics, impresiones y posición por página en el informe «Rendimiento», títulos y meta descripciones), o no sabrás después qué página perdió tráfico.

Paso 2: crear el mapa de redirecciones

El mapa de redirecciones tiene dos columnas, URL antigua y URL nueva, y unas pocas reglas:

1. Una a una: cada página antigua apunta a la página nueva equivalente; las páginas fusionadas apuntan a la página común.
2. Eliminada: si no tiene sucesora, la URL antigua devuelve 404 o 410. Google trata igual todos los errores 4xx, salvo el 429.
3. No todo a la portada: Google desaconseja redirigir muchas URL antiguas a un único destino que no sea relevante, como la página principal; puede considerarse un error soft 404.
4. Directo al destino: cada regla apunta a la URL final, nunca a una dirección que vuelva a redirigir.

Nuestro mapa vive en el archivo next.config.ts de la web, un par de slugs por línea, cada uno marcado como permanente. Las reglas quedan fechadas, pero solo se publican con un despliegue: un slug cambiado solo en el CMS habría dado un 404 mientras tanto. Comprueba si tu CMS crea las redirecciones por sí mismo.

301, 308, 302 o 307: qué redirección elegir

Con una redirección permanente, Google muestra el nuevo destino en los resultados; con una temporal, la página de origen.

Para una migración, por tanto, 301 o 308. La diferencia está fuera del SEO: según el estándar HTTP RFC 9110, un cliente puede convertir una petición POST en GET tras un 301 o un 302, pero no tras un 307 o un 308; por eso Next.js, el framework de nuestra web, usa el 308. JavaScript, solo como último recurso.

Ojo con los valores predeterminados: en Apache, una directiva Redirect sin código de estado da un 302; en Next.js, permanent: false da un 307; y muchos proveedores de alojamiento te dejan elegir el código de una redirección de dominio en su panel. Bing recomienda el 301 para cambios permanentes y el 302 solo para cambios de menos de dos días.

Bloquear el entorno de pruebas sin arruinar el lanzamiento

El sitio nuevo suele construirse en un entorno de pruebas (staging) que no debe aparecer en los resultados. De tres bloqueos habituales, solo dos son fiables:

• robots.txt no basta. Google aclara que no sirve para impedir que una página aparezca en sus resultados; una URL bloqueada puede indexarse si otras páginas enlazan a ella.
• noindex solo funciona si Google puede rastrear la página, como etiqueta meta o como encabezado HTTP X-Robots-Tag. Detrás de un bloqueo en robots.txt, el rastreador no lo ve.
• Una contraseña es el bloqueo más seguro.

El riesgo de verdad está en el desbloqueo: un noindex o un Disallow: / olvidado saca el sitio nuevo de los resultados, y Google pone estos restos en primer lugar en su tabla de errores habituales al trasladar un sitio. Prepara el robots.txt del lanzamiento y la lista de reglas noindex que habrá que quitar.

Nosotros usamos un solo interruptor. Hasta el lanzamiento, cada respuesta llevaba el encabezado X-Robots-Tag: noindex, nofollow, y robots.txt permitía el rastreo sin anunciar el sitemap: así Google veía la regla noindex. El día del lanzamiento, una variable de entorno y una nueva compilación quitaron el encabezado y añadieron el sitemap, sin nada que retirar a mano.

Canonical, hreflang, enlaces internos y sitemap

Todo lo que Google lee en el sitio nuevo debe apuntar a las URL nuevas:

• Canonical: cada página nueva apunta a sí misma, no a su dirección antigua (lo explicamos en nuestra guía sobre la etiqueta canonical).
• hreflang: todas las versiones de idioma apuntan a las URL nuevas, en ambas direcciones, como pide la guía de Google; cuando cambiaron nuestras URL en inglés, también las páginas en alemán, francés y español pasaron a apuntar a las nuevas. Lo detallamos en nuestra guía de la etiqueta hreflang, y si tienes versiones para España y Latinoamérica, en la de hreflang para español.
• Enlaces internos: directos a las URL nuevas; cada enlace que pasa por una redirección cuesta tiempo de carga y rastreo.
• Sitemap: solo las URL nuevas y canónicas.

En nuestra web, los cuatro cambiaron solos, porque se generan desde el CMS: los enlaces internos se guardan como referencias a la clave de un artículo y reciben el slug actual al mostrarse la página. El 17 de octubre, ni el sitemap inglés ni el alemán contenían una sola URL antigua. Para estructuras de URL con varios idiomas o países, consulta nuestra guía de SEO internacional.

¿Y el sitemap antiguo? Google describe enviarlo un tiempo junto al nuevo para ver cómo sus páginas indexadas bajan a cero; Bing pide quitar pronto las URL redirigidas de los sitemaps. Nuestra propuesta: sitemap público solo con URL nuevas, y uno de las antiguas en Search Console solo temporalmente, para medir.

Probar las redirecciones: curl, navegador y rastreador

Lo más fiable es la respuesta en bruto del servidor. La herramienta de línea de comandos curl viene preinstalada en Windows 11 y macOS, y en la mayoría de sistemas Linux:

# Código de estado y encabezado Location de la primera respuesta
curl -sI https://ejemplo.es/pagina-antigua

# Seguir toda la cadena y mostrar los encabezados de cada salto
curl -sIL https://ejemplo.es/pagina-antigua

# Una línea por URL: código de estado y destino, útil para listas
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://ejemplo.es/pagina-antigua

En Windows, escribe NUL en lugar de /dev/null; en Windows PowerShell 5.1, escribe curl.exe, porque allí curl a secas es otro nombre del cmdlet Invoke-WebRequest.

Prueba también las variantes por las que llegan visitantes y rastreadores (http, www, mayúsculas): ahí se esconden los saltos de más. Esta es nuestra sección de SEO en español pedida así:

Nuestra web redirige cualquier URL con mayúsculas a su versión en minúsculas, para que /Blog y /blog no sean dos copias de la misma página. Una URL antigua de nuestras guías en inglés da un salto pedida con https, dos con http y tres con http y www.

El robot de Google sigue hasta 10 saltos, pero Google recomienda redirigir directamente al destino final. Si no es posible, la versión española de su guía pide idealmente menos de tres redirecciones y como máximo cinco (la inglesa, no más de tres y menos de cinco): según la española, nuestra cadena de tres saltos ya pasa del ideal. Si apilas una migración sobre antiguas redirecciones de protocolo y dominio, lo superas enseguida. Las reglas también pueden jugar a tu favor: /Blog/SRT-File llega al slug nuevo en un solo salto, porque la regla del slug antiguo se aplica primero.

El navegador prueba mal. Según la documentación de Next.js, un 308 indica a los clientes que guarden la redirección en caché para siempre; las nuestras envían Cache-Control: public, max-age=0, must-revalidate, pero prueba igualmente con curl. Además, cuando Chrome sabe que un sitio usa HSTS, como el nuestro, cambia él mismo los enlaces http a https: en nuestra comprobación del 14 de octubre de 2026, su registro de red mostraba «307 Internal Redirect» por HSTS, aunque nuestro servidor nunca envió un 307.

Para muchas URL, recorre con curl un archivo de texto con las direcciones antiguas o usa el modo lista de un rastreador, y busca cualquier 302 o 307 que debería ser permanente, cualquier 404 que debería redirigir y cualquier cadena con https. La herramienta de inspección de URLs sirve poco aquí: su ayuda dice que la prueba de la URL publicada sigue las redirecciones sin indicarlo, mientras que otra página de Google afirma que las herramientas de inspección no las siguen.

Después del lanzamiento: Search Console y plazos realistas

Tres informes muestran si el traslado avanza:

• Indexación de páginas: «Página con redirección» es el estado esperado para las URL antiguas. Vigila «No se ha encontrado (404)» en páginas que solo se movieron, «Soft 404» (a menudo una redirección a la portada), «Error de redirección» (cadena demasiado larga, bucle o URL no válida) y, en páginas nuevas, «El archivo robots.txt ha bloqueado la URL» o «La URL se ha marcado como "noindex"».
• Estadísticas de rastreo (en la configuración de la propiedad): un 308 cuenta como «Movido permanentemente (301)», un 307 como «Movido temporalmente (302)», y cada salto como una solicitud independiente. Si sube la parte de redirecciones temporales, hay un ajuste equivocado.
• Sitemaps: URL enviadas e indexadas, sitemap por sitemap.

Nuestros propios datos muestran lo gradual que es el proceso:

Google apenas había visto las URL antiguas en alemán, y las nueve nuevas estaban indexadas dos días después. Muchas en inglés ya estaban indexadas con su dirección antigua, y dos días después del cambio cuatro páginas nuevas, entre ellas nuestra guía sobre archivos SRT, aparecían como «Duplicada: Google ha elegido una versión canónica diferente a la del usuario». No es un error, es el traslado URL a URL que describe Google, y una buena razón para cambiar las direcciones pronto.

¿Cuánto tarda? Según Google, la mayoría de las páginas de un sitio pequeño o mediano pueden tardar varias semanas en trasladarse, y los sitios grandes, más; depende sobre todo del número de URL y de la rapidez del servidor. En un vídeo de 2022 recogido por Search Engine Land, John Mueller, de Google, explicó que procesar por completo un cambio de URL puede llevar varios meses. Calcula semanas para la mayoría de las páginas y meses para el resto, y mídelo.

Cuánto tiempo mantener las redirecciones y cuándo usar Cambio de dirección

Google es claro: «Conserva las redirecciones todo el tiempo que puedas, normalmente durante 1 año como mínimo». Para el usuario, recomienda incluso mantenerlas indefinidamente, y las nuestras no tienen fecha de fin. Dos momentos las ponen en peligro: el siguiente rediseño, cuando nadie recuerda para qué sirven (documenta cada regla con fecha y motivo), y la limpieza de cadenas. Si un segundo traslado crea una cadena de A a B y de B a C, haz que A apunte directamente a C, sin borrar nunca la regla de A.

La herramienta Cambio de dirección de Search Console solo sirve para pasar de un dominio o subdominio a otro, por ejemplo de un .es a un .com; no para el paso a https, para mover páginas dentro de un sitio ni para cambiar entre www y sin www. En un cambio de dominio, envía la solicitud para cada variante verificada del dominio antiguo, www incluida. Search Console muestra un aviso durante 180 días; mantén las redirecciones al menos ese tiempo, más si aún traen tráfico de Google, y sigue pagando el dominio antiguo al menos un año para que nadie lo use con fines malintencionados.

Checklist de migración web SEO

Antes del lanzamiento

1. Decide qué cambia, sin cambiarlo todo a la vez.
2. Reúne todas las URL antiguas, imágenes y PDF incluidos, y guarda el punto de partida.
3. Crea el mapa de redirecciones: una a una, 404 o 410 para lo eliminado, nada en bloque a la portada.
4. Usa 301 o 308, en el servidor, directo a la URL final; revisa los valores predeterminados.
5. Bloquea el entorno de pruebas con contraseña o noindex y prepara el desbloqueo.
6. Revisa canonical, hreflang, enlaces internos y el sitemap nuevo.
7. Verifica todas las variantes del sitio en Search Console y prepara el servidor: según Google, tras un traslado rastrea más de lo habitual.

El día del lanzamiento

8. Activa las redirecciones y quita los bloqueos en el mismo paso.
9. Revisa robots.txt: si devuelve un error de servidor, Google deja de rastrear el sitio durante las primeras 12 horas.
10. Prueba cada URL antigua, también con http y www.
11. Envía el sitemap nuevo en Search Console y en Bing Webmaster Tools.
12. Solo si cambias de dominio: solicita el cambio de dirección.
13. Actualiza tus propios enlaces y pide a los sitios que más visitas te envían que corrijan los suyos.

Después del lanzamiento

14. Cada semana: indexación de páginas, estadísticas de rastreo y sitemaps; corrige los 404 y soft 404 de páginas trasladadas.
15. Resuelve las cadenas apuntando las reglas antiguas directamente a la URL final.
16. Mantén las redirecciones al menos un año, mejor para siempre, y documéntalas.