Migración de web sin perder posiciones: el plan y las pruebas

Respuesta breve

Una migración conserva resultados cuando cada URL antigua tiene un destino equivalente y ese destino responde igual de bien. El trabajo no está en el día del cambio, sino en el inventario previo, el mapa de redirecciones probado antes de publicar y la lectura de evidencia durante las semanas siguientes. Sin inventario no hay forma de saber qué se ha perdido, porque nadie echa de menos una URL que no sabía que existía.

Puntos clave

• Define qué tipo de migración es: dominio, protocolo, estructura de URLs, plataforma o rediseño.
• Inventaría URLs desde varias fuentes, no solo desde el sitemap del CMS actual.
• El mapa de redirecciones se prueba en preproducción antes del despliegue, URL a URL.
• Equivalencia significa misma tarea resuelta, no solo un 301 con estado correcto.
• Una fluctuación temporal es esperable; una pérdida sostenida por plantilla indica un fallo concreto.
• Conserva las redirecciones mientras sigan recibiendo peticiones, no unas semanas por calendario.

El trabajo no está en el día del cambio

1. Tipo de migraciónDominio, protocolo, URLs, plataforma o rediseño.
2. InventarioDesde varias fuentes, no solo el sitemap del CMS.
3. Mapa de redireccionesProbado en preproducción, URL a URL.
4. Lo que viajaCanonical, hreflang, feeds y datos estructurados.
5. Día del cambioOrden de operaciones y purga del CDN.
6. MedirSemanas, por plantilla; una caída sostenida es un fallo concreto.

Qué tipo de migración es

La palabra migración agrupa cambios muy distintos, y el riesgo no es el mismo en todos. Separarlos antes de planificar evita aplicar un procedimiento pesado a un cambio menor o, peor, uno ligero a un cambio estructural.

Tipos de migración: si cambian las URLs, el riesgo principal y la prueba clave de cada uno.

Cambio	Cambian las URLs	Riesgo principal	Prueba clave
Dominio	sí	pérdida de equivalencia y de señales externas	mapa uno a uno y cambio de dirección
HTTP a HTTPS	sí, en el esquema	contenido mixto y bucles	lectura de cabeceras
Estructura de URLs	sí	cadenas y páginas huérfanas	rastreo comparado
Plataforma o CMS	a veces	plantillas, metadatos y datos que no viajan	diferencia de HTML por plantilla
Rediseño sin mover URLs	no	contenido eliminado y enlazado roto	diferencia de contenido y grafo interno

Un proyecto real suele combinar varios a la vez, y esa combinación es la que complica el diagnóstico posterior: si cambias dominio, plantillas y arquitectura en el mismo despliegue, una caída no dice cuál de los tres la ha causado. Cuando el calendario lo permite, separar los cambios en fases hace que cada uno sea interpretable. Cuando no lo permite, hay que documentar qué se hizo a la vez para no atribuir el efecto a la causa equivocada.

Esta web pasó por dos de esos cambios en el mismo despliegue, plataforma y estructura de URLs, y el resultado está contado con sus cifras en el caso de la migración de WordPress a un sitio estático, incluida la parte que no mejoró.

Inventario antes de tocar nada

El inventario es el entregable que decide si la migración se puede verificar. Una sola fuente siempre deja fuera URLs: el sitemap no contiene lo que el CMS no publica, y el rastreo no encuentra lo que nadie enlaza. Cruza al menos estas:

• rastreo completo del sitio actual, con códigos de estado, canonical, robots y plantilla;
• sitemaps publicados, incluidos los de imágenes y los índices secundarios;
• URLs con impresiones o clics en Search Console en los últimos meses disponibles;
• páginas de destino con sesiones en analítica, que incluyen tráfico no orgánico;
• logs del servidor, la única fuente que muestra qué se rastrea de verdad;
• URLs con enlaces externos conocidos;
• redirecciones ya existentes, que se convertirán en cadenas si no se reescriben.

De cada URL interesa su destino previsto, su plantilla, si recibe enlaces externos y si debe sobrevivir. Ese último campo obliga a decidir en lugar de arrastrar: una parte del inventario suele ser contenido que ya no cumple ninguna función, y ahí conviene aplicar el criterio de cuándo actualizar, fusionar o retirar contenido antes de fabricar destinos artificiales.

El mapa de redirecciones

El mapa es una tabla de origen y destino, no una regla escrita de memoria. Las reglas por patrón son útiles cuando la transformación es regular, pero necesitan una lista de excepciones comprobada, porque un patrón que acierta en la mayoría de los casos genera destinos incorrectos en el resto sin avisar.

Equivalencia es el criterio, y no coincide con parecido de texto. La URL de destino debe resolver la misma tarea que resolvía la de origen. Redirigir cien fichas de producto retiradas a la portada produce cien redirecciones técnicamente correctas y cien tareas sin resolver; ese patrón acaba tratándose como una página no encontrada. Cuando no existe equivalente, un 404 o un 410 honesto es mejor que un destino falso.

Google documenta los tipos de redirección y su preferencia por las de servidor frente a meta refresh o JavaScript, que reserva para cuando no hay acceso a la configuración del servidor. Esa jerarquía importa en migraciones grandes: una redirección resuelta en el cliente depende de que el recurso se descargue y se ejecute.

Cadenas, bucles y defectos del mapa

Una migración sobre un sitio con historial hereda las redirecciones anteriores. Si la regla nueva apunta al origen antiguo y ese origen ya redirigía, se forma una cadena. Las cadenas funcionan en un navegador y por eso pasan desapercibidas en las revisiones manuales; la revisión de cadenas y bucles de redirección 301 explica cómo detectarlas.

• reescribe cada regla vieja para que apunte al destino final actual, no al intermedio;
• comprueba que ningún destino sea a su vez origen de otra regla;
• detecta bucles antes de publicar: son un fallo de servicio, no un matiz;
• revisa el orden de evaluación, porque una regla amplia puede capturar rutas destinadas a reglas específicas;
• verifica el comportamiento de la barra final y de las mayúsculas;
• confirma que los parámetros que deben conservarse llegan al destino.

El mapa se prueba entero y de forma automatizada, porque una lista de miles de filas no se revisa a mano de forma fiable. Lo que se registra en cada fila es el número de saltos y el código del destino final, no solo que la petición termine en una página que carga.

Lo que viaja además de las URLs

Una migración que solo cuida redirecciones deja fuera la mitad del trabajo. Cada elemento de esta lista ha causado incidentes por sí solo:

• Metadatos: titles, descriptions y etiquetas robots por plantilla, que en un cambio de CMS suelen quedarse en la base de datos antigua.
• Canonical: debe apuntar al dominio y al esquema nuevos; un canonical que sigue señalando el origen mantiene dos superficies vivas, como detalla la revisión de errores de canonical.
• Sitemaps: publicar el nuevo y mantener accesible el antiguo durante un tiempo ayuda a que se descubran las redirecciones.
• robots.txt: el de preproducción bloquea todo, y llega a producción con más frecuencia de la que parece.
• Enlaces internos: deben apuntar al destino final desde el primer día, no depender de la redirección.
• Datos estructurados, hreflang y feeds: con URLs absolutas actualizadas. Si el sitio publica varios idiomas señalados con hreflang, cada grupo debe volver a cerrarse con las URLs nuevas.
• Rendimiento: una plataforma nueva cambia el tiempo de respuesta, y eso afecta a experiencia y a rastreo.

Orden de operaciones el día del cambio

El despliegue tiene un orden que reduce el tiempo en que el sitio es incoherente. Antes de publicar, el mapa debe estar probado en preproducción con la lista completa de orígenes y sus destinos reales, y debe existir un plan de vuelta atrás que alguien haya ejecutado al menos una vez.

1. congelar cambios de contenido y capturar el estado de referencia: rastreo, HTML por plantilla, sitemaps y cabeceras;
2. publicar con las redirecciones activas desde el primer minuto, no como paso posterior;
3. retirar el bloqueo de robots.txt de preproducción y confirmar la respuesta real en producción;
4. purgar cachés de aplicación, servidor y CDN, y volver a leer la respuesta desde fuera de la red;
5. enviar el sitemap nuevo y, en un cambio de dominio, usar la herramienta de cambio de dirección de Search Console;
6. comprobar una muestra de cada plantilla con un usuario sin sesión y sin caché de navegador;
7. revisar analítica y monitorización en las primeras horas para detectar errores de servidor.

La guía oficial sobre cambios de sitio con cambio de URL describe el procedimiento y recuerda que el reprocesamiento no es inmediato: depende de que se vuelvan a rastrear las URLs antiguas, y eso ocurre a ritmos distintos según la importancia de cada una.

Qué medir después y durante cuánto tiempo

Después del despliegue, la pregunta no es si el tráfico ha bajado, sino si alguna URL ha dejado de tener destino equivalente. Compara el inventario previo con un rastreo nuevo y busca orígenes que respondan 404, que redirijan a un destino genérico o que hayan quedado fuera del sitemap.

En Search Console, el informe de páginas muestra cómo se reclasifican las URLs antiguas, y conviene leerlo por directorio y por plantilla en lugar de en agregado. Segmentar evita la conclusión de que ha caído todo cuando lo que ocurre es que una plantilla concreta perdió su etiqueta robots correcta; esa lógica está descrita en el diagnóstico de rastreo e indexación.

Sobre la duración de las redirecciones, el criterio prudente es conservarlas mientras sigan recibiendo peticiones. Los logs responden esa pregunta con datos en lugar de con una fecha arbitraria: mientras haya rastreo o visitas humanas llegando a la URL antigua, la redirección sigue haciendo un trabajo. Retirarlas en bloque a los pocos meses convierte en 404 lo que aún era útil.

Después del despliegue, la pregunta no es si el tráfico ha bajado, sino si alguna URL ha dejado de tener destino equivalente.

Cuándo una caída es esperable

Un periodo de inestabilidad tras un cambio de URLs es normal mientras se reprocesa el sitio, y conviene decirlo antes de migrar para que nadie interprete la primera semana como un fracaso. Lo que distingue una fluctuación de un problema es la forma: una fluctuación afecta de manera difusa y se recupera; un fallo afecta a un segmento identificable y no se mueve.

Si la caída se concentra en una plantilla, en un directorio o en un tipo de dispositivo, hay una causa técnica que buscar. Si coincide con la fecha del despliegue y afecta a URLs que no cambiaron, mira primero al rendimiento del servidor y a la configuración global. Y si al mismo tiempo hubo una actualización del algoritmo, conviene resistir la tentación de atribuirlo todo a la migración o todo a la actualización sin separar segmentos.

En cuatro láminas

CSV · probado URL a URL: origen;destino;codigo;probado / /servicios.html;/servicios-seo/;301;ok / /blog/2019/seo-local;/blog/seo-local-…/;301;ok / /antiguo;/nuevo;301;CADENA → /nuevo/ / /descatalogado;—;410;ok / / # la última columna es la que importa

curl -sI https://seonidas.com/blog. HTTP/1.1 301 / location: https://seonidas.com/blog/. Leído el 28 de septiembre de 2026.

1 destino equivalente por URL. Equivalencia significa la misma tarea resuelta, no un 301 con estado correcto.

Errores frecuentes

• Construir el inventario solo con el sitemap del CMS actual.
• Redirigir en masa a la portada o a la categoría padre lo que no tiene equivalente.
• Publicar el mapa sin probarlo y descubrir las cadenas después.
• Dejar el robots.txt o el noindex de preproducción en producción.
• Mantener enlaces internos apuntando a URLs antiguas porque ya redirigen.
• Olvidar canonical, hreflang, feeds y datos estructurados con URLs absolutas.
• No purgar la caché del CDN y validar sobre una copia antigua.
• Retirar las redirecciones por calendario en lugar de por uso medido.
• Cambiar dominio, plantillas y arquitectura a la vez sin poder aislar el efecto.
• Dar por buena la migración porque la portada carga bien.

Preguntas habituales

¿Basta con el sitemap del CMS para hacer el inventario?

No: el sitemap contiene lo que el CMS cree que existe, no lo que recibe visitas. Un inventario útil cruza sitemap, logs del servidor, Search Console, analítica y enlaces entrantes. Lo que falte en esa lista no se echará de menos el día del cambio, sino meses después, cuando ya no haya forma de saber qué había.

¿Cuánto tiempo hay que mantener las redirecciones?

Mientras sigan recibiendo peticiones, que es un dato medible, no un plazo de calendario. Retirarlas «al año» es una decisión tomada sin mirar: hay URLs con enlaces entrantes que siguen trayendo visitas años después. Lo razonable es revisar el uso periódicamente y retirar solo lo que lleva mucho sin recibir nada.

¿Es normal caer justo después de migrar?

Una fluctuación temporal es esperable mientras se reprocesa el sitio. Lo que no es normal es una pérdida sostenida y concentrada en una plantilla concreta: eso apunta a un fallo localizado —un canonical, un noindex heredado de preproducción, una cadena de redirecciones— y se diagnostica por plantilla, no esperando a que se recupere solo.

¿Puedo aprovechar la migración para rediseñar?

Se puede, pero se paga en diagnóstico: cambiando dominio, plantillas y arquitectura a la vez, ninguna variación posterior es atribuible. Si el calendario obliga a juntarlo, conviene al menos separar los despliegues por días y anotar qué entró cada uno, para poder aislar el efecto después.

Próximo paso

Antes de fijar fecha, construye el inventario cruzando rastreo, sitemaps, Search Console, analítica y logs, y añade a cada fila su destino previsto y si debe sobrevivir. Ese documento es el que después permite demostrar qué se conservó y qué no. Si el proyecto cambia dominio y plataforma a la vez, conviene ordenar el trabajo por fases y fijar de antemano qué evidencia se va a leer en cada una.

Fuentes

• Google Search Central, cambios de sitio y migraciones con cambio de URL — documentación oficial.
• Google Search Central, redirecciones y la Búsqueda de Google — documentación oficial.
• Ayuda de Search Console, herramienta de cambio de dirección — documentación oficial.

Servicio relacionado

Si esto es lo que te está pasando, migraciones seo es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver migraciones seo