Cómo migrar una web sin perder posicionamiento
Cómo migrar una web sin perder posicionamiento: el inventario previo, el mapa de redirecciones y lo que se rompe con más frecuencia.
En una auditoría sobre un sitio de 312 páginas que nadie había migrado nunca, la estructura interna ya no llegaba a 35 páginas con unas 180.000 impresiones al trimestre, y había 9 enlaces internos rotos. Sin tocar el dominio ni la plantilla. Una migración produce ese daño en una tarde, sobre todas las URL a la vez, con una diferencia que lo decide todo: si el inventario no se tomó antes, ya no hay forma de saber cuáles eran esas 35 páginas. Lo que mata una migración no es la migración. Es no haber inventariado antes.
Respuesta rápida
- El inventario previo es lo único que no se puede hacer después. Qué URL existían y quién las enlazaba solo se levanta mientras el sitio viejo sigue en pie.
- Redirección 1 a 1 hacia el equivalente real. La guía de cambios de sitio de Google pide emparejar cada URL antigua con su nueva. En bloque a la portada no vale.
- Una variable por migración. Dominio, plantilla y URL a la vez vuelven imposible el diagnóstico de cualquier caída.
- La verificación se hace sobre la página publicada. La base de datos dice lo que se guardó; la página, lo que se sirve.
| Fase | Momento | Produce | Si se salta |
|---|---|---|---|
| Inventario | Antes de tocar nada | URL con impresiones y enlaces | No hay línea base |
| Redirecciones | Antes del despliegue | Emparejamiento 1 a 1 | Señales sin destino |
| Despliegue | Baja volatilidad | El sitio nuevo sirviendo | Se mezcla con un update |
| Limpieza | Primeros días | Canónicas y enlaces al día | Fallos sin error |
| Verificación | Semanas siguientes | Cotejo de la cohorte | La pérdida se ve tarde |
Qué tipo de problema es esto
El modelo mental heredado trata la migración como una tarea de desarrollo: termina cuando el sitio nuevo se ve bien y los formularios funcionan. Bajo ese modelo, el inventario parece burocracia.
El modelo correcto es otro. Una migración no traslada un sitio: traslada un historial. Lo que un dominio acumuló durante años no vive en los archivos, vive en asociaciones entre URL concretas y consultas concretas, más los enlaces que otros pusieron hacia esas URL exactas. El código se copia. El historial se transfiere por correspondencia, una URL a la vez, y solo si alguien la declara. Por eso el sitio nuevo es la parte fácil: la difícil es demostrar seis semanas después si la caída del martes fue estacional o estructural, contra una lista levantada antes.
¿Cómo se migra una web sin perder posicionamiento?
Una web se migra sin perder posicionamiento inventariando antes las URL antiguas con sus impresiones y enlaces entrantes en Google Search Console, redirigiendo cada una con un 301 a su equivalente exacto, cambiando una sola variable por migración y verificando después sobre la página publicada que canónicas, noindex y enlaces internos apuntan ya al destino nuevo.
El inventario previo, el paso que no se puede repetir
El inventario tiene una propiedad rara en este oficio: caduca. El sitio viejo se puede rastrear hoy y no mañana, porque mañana devuelve redirecciones y ya no enseña su propia estructura.
Qué columnas lleva
Cinco por URL: dirección completa, impresiones y clics de los últimos doce meses, enlaces internos entrantes, dominios externos que la enlazan y estado de indexación en Google Search Console. Con eso se ordena, y ordenar es todo el valor del ejercicio.
En aquella auditoría, las 35 huérfanas acumulaban unas 180.000 impresiones al trimestre, pero dos concentraban unas 106.000, casi el 60 %. Sin la columna de impresiones parecen 35 problemas iguales. Con ella son dos urgencias y 33 pendientes.
El tamaño cambia el método, no el criterio
- Menos de 100 URL. Una hoja de cálculo y una exportación de Search Console; el mapa 1 a 1 cabe en una tarde.
- De 300 a 3.000 URL. Rastreo del sitio cruzado con la exportación de rendimiento, revisado por lotes según impresiones.
- Decenas de miles. El emparejamiento se genera por reglas de patrón y se audita a mano solo el tramo alto. Nadie revisa 40.000 filas, y fingirlo da un mapa peor que uno declarado parcial.
El mapa de redirecciones, una a una
Una redirección 301 no es un cartel de "nos hemos mudado". Es una declaración de equivalencia: esta dirección responde a lo mismo que respondía la antigua. El destino importa tanto como el hecho de redirigir.
Por qué "todo a la home" no es un atajo
Redirigir cien URL de artículo a la portada no traslada nada. La portada no responde a las consultas que traían esas URL, la equivalencia declarada es falsa y el buscador acaba tratando la redirección como una página que no existe. Los enlaces externos que apuntaban a cada artículo dejan de sostenerlo. La portada solo sirve de destino cuando el contenido desapareció, y ahí suele ser más honesto un 410.
Cadenas y migraciones encadenadas
Cada migración deja un salto. Dos dejan dos: la URL de 2019 apunta a la de 2023, que apunta a la de 2026. Funciona para el usuario y se degrada para el rastreo, porque cada salto gasta presupuesto que no se dedica a descubrir contenido. La regla que lo evita es aplanar, reescribiendo las redirecciones viejas hacia el destino final.
Lo que se rompe con más frecuencia
Los tres fallos siguientes comparten algo incómodo: ninguno produce un error visible. El sitio responde 200 y se ve bien.
La canónica heredada
La plantilla nueva copia la etiqueta link rel="canonical" con el dominio antiguo dentro, o el gestor la guarda como valor absoluto en base de datos y la sirve tal cual. La página nueva declara entonces que la canónica buena es la antigua, que a su vez redirige a la nueva. Dos instrucciones contradictorias.
El noindex de staging que sobrevive
Es el fallo silencioso más caro y el más fácil de cometer. El entorno de pruebas se protege con una etiqueta noindex o una cabecera X-Robots-Tag, la migración copia esa configuración a producción y la etiqueta viaja con ella. El sitio funciona, se ve, se navega y no se indexa. Como no hay error en ninguna parte, se descubre cuando el informe de páginas empieza a mover URL a excluidas por etiqueta.
Los enlaces internos que apuntan al sitio viejo
Las redirecciones funcionan, así que nadie los actualiza. El coste no lo paga el usuario, que llega igual: lo paga la estructura interna, que pasa entera por un salto intermedio y se vuelve enlaces rotos el día que alguien toca las reglas. Aquel sitio ya tenía 9 sin haber migrado nunca.
Una variable por migración
Cambiar de dominio, de plantilla y de estructura de URL en el mismo despliegue convierte un problema medible en uno opinable. Si el tráfico cae un mes después, las causas candidatas son la equivalencia perdida entre dominios, el contenido que la plantilla nueva dejó de mostrar, el mapa de URL o cualquier combinación. Ninguna se aísla: no hay ningún tramo del histórico en el que cambiara una sola cosa.
La alternativa cuesta más calendario y menos incertidumbre. Se cambia el dominio manteniendo estructura y plantilla, se espera a que el histórico se estabilice y solo después se toca lo siguiente. Es el criterio que ordena una auditoría de SEO técnico: primero la capa que condiciona a las demás.
Cuándo NO hacer esto
- Durante el despliegue de un core update. En 2026 Google confirmó cuatro actualizaciones, dos de ellas core: el 27 de marzo (12 días) y el 21 de mayo (11 días y 21 h). Según SE Ranking, el de marzo fue el más volátil registrado, con un 79,5 % del top 3 cambiando de posición. Migrar en esa ventana mezcla dos causas que después nadie separa; qué hacer si ya estás dentro está en qué hacer ante un core update.
- Cuando el problema real es de clics. Si las impresiones son altas y estables y los clics no llegan, la causa suele estar en los títulos, y una plataforma nueva no arregla un título que no contiene lo que la gente busca.
- Cuando nadie va a mantener las redirecciones. Un mapa retirado mientras los registros del servidor todavía muestran peticiones a las URL antiguas devuelve el sitio al punto de partida, con el trabajo ya pagado.
La verificación posterior
No es un paso más al final: es el que cierra los anteriores. En un proyecto propio hubo cambios que el sistema daba por aplicados y no lo estaban, y solo aparecieron al abrir la página publicada.
Sobre una muestra encabezada por las URL de más impresiones se comprueba que la antigua devuelve un solo salto 301 al destino previsto, que el destino responde 200, que su canónica se apunta a sí misma, que no lleva noindex ni en etiqueta ni en cabecera y que el sitemap no contiene ninguna URL antigua. Sobre el HTML servido, nunca sobre el panel.
Lo que la documentación de Google añade, y casi ningún resultado recoge
Los primeros resultados en español para esta consulta convergen en el servidor: el archivo .htaccess, el plugin de redirecciones, aplanar las cadenas a un solo salto. Todo eso es correcto, y nada de eso es lo que más se salta.
Lo que la guía de cambios de sitio de Google añade no es de servidor. Es de calendario y de propiedad.
- Las dos propiedades verificadas, con todas sus variantes. Sin eso no se puede usar la herramienta de cambio de dirección, y es lo que más veces llega tarde, porque el dominio antiguo suele estar verificado a nombre de quien montó el sitio hace ocho años.
- 180 días de control del dominio antiguo es el plazo que da la documentación. No es lo que tarda la migración: es cuánto tiempo tiene que seguir respondiendo el dominio viejo.
- Vigilar a la vez el tráfico de las URL antiguas y el de las nuevas. Eso es lo que convierte la migración en un periodo en lugar de un evento, que es justo el modelo mental que falla.
Y una corrección a lo que repiten varios de esos resultados: que una redirección 301 "transmite casi toda la autoridad". Ese casi lleva detrás un número que nadie cita, porque no existe. Google documenta que las redirecciones permanentes no causan pérdida de PageRank, comprobado el 12 de agosto de 2026.
La diferencia importa por dónde manda mirar. Si crees que cada salto se lleva un pellizco, presupuestas recuperación y vigilas el servidor. Lo que de verdad se pierde en una migración no es un porcentaje por redirigir: es todo lo que traía una URL cuyo destino no responde a lo mismo que respondía ella.
Errores que se repiten
- Migrar sin inventario previo. Cuando el tráfico cae no hay lista contra la que comparar y el diagnóstico se vuelve opinión.
- Redirigir en bloque a la portada. La equivalencia declarada es falsa y el historial de cada URL se queda sin quien lo herede.
- Cambiar dominio, plantilla y URL a la vez. Vuelve inseparables tres causas posibles de la misma caída.
- Dejar el
noindexdel entorno de pruebas. No produce error visible y se detecta con semanas ya perdidas. - Confiar en las redirecciones en vez de actualizar los enlaces internos. La estructura depende entonces de un salto que algún día se retira.
- Verificar en el panel de administración. Lo que decide es el HTML que sirve el servidor.
Datos y transparencia
Los 180 días de control del dominio antiguo, la exigencia de verificar ambas propiedades con todas sus variantes y la recomendación de vigilar el tráfico de las URL antiguas y las nuevas a la vez proceden de la guía de cambios de sitio con cambio de URL de Google, comprobada el 12 de agosto de 2026. Que las redirecciones permanentes no causan pérdida de PageRank procede de su página sobre redirecciones, comprobada el mismo día; la fórmula «transmite casi toda la autoridad» que circula en los primeros resultados de esta consulta se recoge aquí como ejemplo de matiz sin cifra detrás, no como fuente.
Las cifras de auditoría proceden de un trabajo propio de 2026 sobre un recetario de cocina colombiana en inglés, 312 páginas en WordPress. Es trabajo de cliente: el sitio no se nombra y las impresiones van redondeadas. Son 35 páginas huérfanas con unas 180.000 impresiones al trimestre, dos de ellas con unas 77.000 y unas 29.000, y 9 enlaces internos rotos. Las fechas de las actualizaciones de Google de 2026 y el 79,5 % de volatilidad del top 3 en la de marzo salen del seguimiento público de SE Ranking. El emparejamiento 1 a 1 está en la documentación de cambios de sitio de Google. El criterio general sale del trabajo sobre una cartera de más de 300 millones de impresiones al año en Google, en los sitios que opero. Verificado a agosto de 2026.
Fuentes primarias, abiertas el 13 de agosto de 2026: la encuesta de SE Ranking.
Lo que esto cambia
Hay una asimetría que explica por qué esta operación sale mal tan a menudo. El presupuesto se concentra en el sitio nuevo, que es la parte visible y la que se enseña en una reunión. El inventario previo no se ve y solo demuestra su valor cuando algo falla.
Merece la pena darle la vuelta a la pregunta antes de aprobar el siguiente rediseño. No es "¿cuánto cuesta la web nueva?", sino "si dentro de dos meses el tráfico cae, ¿con qué lista voy a comparar?". Si no hay lista, el proyecto todavía no ha empezado, por muy avanzado que esté el diseño.
Preguntas frecuentes
¿Qué es lo primero que hay que hacer antes de migrar una web?
Levantar el inventario de URL antiguas mientras el sitio viejo sigue publicado: dirección de cada página, impresiones y clics en Google Search Console, enlaces internos entrantes y dominios externos que la enlazan. Es el único paso que caduca, porque en cuanto el sitio antiguo redirige deja de enseñar su estructura.
¿Redirigir todas las URL antiguas a la home es válido?
No para conservar posicionamiento. La portada no responde a las consultas que traían esas URL, así que la equivalencia que declara la redirección 301 es falsa y el buscador acaba tratándola como una página inexistente. La documentación de cambios de sitio de Google pide emparejar 1 a 1 con la página equivalente.
¿Cuánto tarda Google en procesar una migración?
Depende del tamaño del sitio, de su frecuencia de rastreo previa y de cuántas URL cambian, y por eso ningún plazo prometido de antemano es honesto. Lo observable es el avance: Google Search Console muestra el traspaso de impresiones entre las URL antiguas y las nuevas, y ese cruce es la señal a vigilar.
¿Se puede migrar durante un core update de Google?
Técnicamente sí, y el coste es perder la capacidad de diagnosticar. En 2026 Google desplegó dos core updates, el 27 de marzo y el 21 de mayo, con una volatilidad que SE Ranking midió en un 79,5 % del top 3 cambiando de posición en el de marzo. Migración y algoritmo se vuelven indistinguibles.
¿Cómo se detecta un noindex heredado del entorno de pruebas?
Abriendo el HTML que sirve el servidor y buscando la etiqueta meta robots y la cabecera X-Robots-Tag, que es donde suele esconderse porque no aparece en la plantilla. El informe de páginas de Google Search Console lo confirma después, con URL movidas a excluidas por etiqueta noindex, pero con semanas de retraso.
La mayoría de sitios no tienen un problema de posicionamiento
Tienen un problema de qué pasa cuando alguien llega. Se puede estar primero en Google y no vender nada. El diagnóstico mira las dos cosas y te dice cuál de ellas te está costando dinero.
Ver el diagnóstico