Como migrar una web sin perder SEO

Migrar una web es una de las operaciones tecnicas mas delicadas en SEO: en pocas horas se pueden borrar anios de autoridad si las URLs no se mapean bien, las redirecciones se aplican tarde o el sitemap antiguo se queda activo apuntando a paginas que ya no existen. La buena noticia es que una migracion bien planificada apenas mueve el trafico organico — y a menudo lo mejora, porque obliga a corregir deuda tecnica acumulada durante anios.

Este articulo desarrolla una metodologia operativa en cuatro fases para mover una web (cambio de dominio, de CMS, de estructura de URLs, paso a HTTPS o re-plataforma completa) sin sacrificar posicionamiento. Cubre lo que las guias generalistas suelen omitir: tipos de migracion clasificados por riesgo SEO, anatomia del mapa de redirecciones 301, gestion de hreflang multi-idioma, schema markup que viaja con las URLs, canibalizacion post-corte, propiedades en Google Search Console y, sobre todo, plazos realistas para recuperar el trafico. La diferencia entre una migracion que se nota y una que no es metodo, no suerte.

Tipos de migracion web y su impacto en el posicionamiento SEO

Antes de planificar, conviene clasificar la migracion segun lo que realmente cambia, porque cada tipo introduce un nivel de riesgo distinto sobre el posicionamiento organico. Confundir un cambio cosmetico con una re-plataforma completa es la primera causa de migraciones fallidas: se subestima la complejidad y no se asigna tiempo a las redirecciones.

Existen escenarios mixtos donde varios cambios ocurren a la vez (nuevo dominio + nuevo CMS + nueva estructura), y son los mas peligrosos: multiplican los puntos de fallo y dificultan diagnosticar despues que componente causo la caida. Cuando es posible, conviene fasear: primero cambio de protocolo, luego cambio de CMS manteniendo URLs, finalmente cambio de dominio. Cada fase aislada permite medir si Google ha asimilado el cambio antes de mover otra variable.

El cambio de hosting (mismo dominio, misma estructura, otro servidor) suele clasificarse como migracion, pero en terminos de SEO apenas tiene riesgo siempre que las URLs respondan igual, el TTL del DNS este reducido antes del corte y la velocidad de carga no empeore. No requiere redirecciones; si las requiere, no es solo cambio de hosting.

Por que se pierde posicionamiento SEO durante una migracion web

La autoridad organica que Google ha asignado a una URL durante anios — backlinks externos, senales de usuario, antiguedad, relevancia tematica — esta atada a esa direccion concreta. Cuando la URL cambia y no se le indica explicitamente a Google donde esta el nuevo recurso, esa autoridad se evapora: el bot encuentra un 404, no sabe a que pagina equivalente apuntar, y los enlaces externos que sostenian la posicion dejan de pasar valor.

Las causas concretas de perdida de posicionamiento en una migracion mal ejecutada se concentran en cinco fallos que se repiten en casi todos los proyectos fallidos. Conocerlos antes de empezar permite disenarlas como puntos de control explicitos en el plan de migracion.

• Mapa de redirecciones incompleto. Faltan URLs antiguas en la lista, normalmente las menos visibles (paginacion, archivos por etiqueta, parametros UTM, URLs huerfanas con backlinks externos). El crawl de la web vieja antes del corte debe ser exhaustivo, no solo del sitemap.
• Cadenas de redirecciones largas. Una URL antigua redirige a otra redirigida, que a su vez redirige. Google sigue como mucho tres o cuatro saltos antes de abortar; mas alla la autoridad se pierde. Cada redireccion debe apuntar directamente al destino final.
• Sitemaps obsoletos activos. El sitemap viejo sigue publicado y enviado a Search Console, indicando a Google URLs que ahora son 404 o redirecciones. Hay que sustituirlo el dia del corte y mantener el viejo accesible solo unas semanas para forzar el procesamiento de las redirecciones.
• Bloqueo accidental en robots.txt. El robots.txt del entorno de staging (con Disallow: /) llega a produccion. Google deja de rastrear durante dias y las URLs nuevas no se indexan. Este error es trivial de cometer y catastrofico en impacto.
• Etiquetas noindex que sobreviven. Las paginas de staging tienen meta robots noindex para no canibalizar; si esas etiquetas no se eliminan al ir a produccion, la web entera se desindexa progresivamente sin que nadie note la causa.

Fase 1: planificacion previa al corte (T-30 a T-14 dias)

Una migracion seria empieza al menos un mes antes del dia del corte. La fase de planificacion produce tres entregables obligatorios: inventario completo de URLs actuales, mapa de redirecciones 1:1, y arquitectura de la web nueva validada. Sin estos tres documentos cerrados, no hay corte que valga la pena ejecutar.

Inventario completo de URLs actuales

El crawl exhaustivo de la web actual con una herramienta tipo Screaming Frog o Sitebulb es el punto de partida. No basta con el sitemap del CMS: hay que cruzar varias fuentes para detectar URLs huerfanas que aun reciben trafico o tienen backlinks externos. Las fuentes minimas a cruzar son cinco.

1. Crawl propio con Screaming Frog en modo Spider configurado para seguir enlaces internos y respetar robots.txt.
2. Sitemap XML actual exportado en CSV.
3. Search Console: descarga de URLs con impresiones en los ultimos 12 meses desde el informe de rendimiento.
4. Analytics: URLs con sesiones organicas en los ultimos 12 meses.
5. Backlinks externos: URLs destino de enlaces externos (export desde Ahrefs, Semrush o Majestic).

El cruce de estas cinco listas en una hoja de calculo produce el universo total de URLs que deben recibir tratamiento. Una migracion que solo considera el sitemap interno deja fuera tipicamente entre un 15% y un 35% de URLs con valor SEO real: archivos por etiqueta, paginaciones profundas, fichas de producto descatalogadas pero con backlinks, paginas eliminadas que aun reciben trafico organico residual.

El cruce con un inventario tecnico previo coordina muy bien con una auditoria SEO basica previa al cambio: muchos problemas heredados (paginas zombi, canibalizaciones existentes, redirecciones internas en cadena) conviene resolverlos antes del corte, no durante, porque si no quedan camuflados bajo el ruido de la migracion y son indistinguibles de los problemas nuevos.

Arquitectura de la web nueva y mapeo intencional

La arquitectura nueva no se diseña improvisando: se mapea contra la intencion de busqueda existente. Cada cluster de keywords que ya tiene URL en la web antigua debe encontrar su equivalente en la nueva, ya sea con la misma URL, con una nueva con redireccion 1:1, o con una decision consciente de consolidar varias URLs en una sola (fusion controlada).

Este trabajo de mapeo es donde una buena agencia de diseño web en Las Palmas con criterio SEO marca diferencia frente a un proveedor que solo entrega plantilla: la nueva web debe nacer con la arquitectura semantica ya pensada para mantener (y mejorar) los rankings existentes, no como un sitio bonito al que despues hay que parchear redirecciones.

Construir el mapa de redirecciones 301 sin perder enlaces

El mapa de redirecciones es el corazon de la migracion. Su calidad determina el 80% del resultado SEO post-corte. Un mapa bien construido cumple tres reglas no negociables: cada URL antigua tiene un destino unico en la web nueva, el destino es semanticamente equivalente (no la home como cajon de sastre) y la redireccion es directa (sin cadenas).

Las redirecciones a la home como destino comodin son uno de los errores mas dañinos en migraciones reales. Google interpreta la redireccion masiva a la home como soft 404: la URL antigua no tenia equivalente, lo razonable es devolver 404 explicito (o redirigir a la categoria padre semantica), no diluir la autoridad enviando todo al inicio.

Tecnicamente las redirecciones se aplican en tres capas posibles: configuracion del servidor (.htaccess en Apache, configuracion de site en NGINX), plugin del CMS (Redirection en WordPress, modulos en PrestaShop o Magento) o CDN/edge (reglas en Cloudflare, page rules en Fastly). La capa de servidor es la mas rapida y robusta; los plugins son utiles para listas extensas y mantenimiento posterior. La capa CDN es ideal para cambios de dominio donde se quiere mover la regla cerca del usuario.

Fase 2: staging, validacion y pre-corte (T-14 a T-3 dias)

El entorno de staging es donde la web nueva se prueba antes de tocar el dominio real. Su mision es validar tecnicamente cada elemento — plantilla, plugins, schema, velocidad de carga — sin que Google rastree y empiece a indexar el duplicado. La regla durante toda esta fase es simple: staging siempre con Disallow: / en robots.txt, contraseña HTTP basica si es posible, y meta robots noindex en todas las paginas.

Los puntos de control criticos a validar en staging cubren todo lo que rompe migraciones cuando se descubre tarde: estructura tecnica, contenido y performance.

El enlazado interno tambien se valida en staging: todos los enlaces internos absolutos deben apuntar a las URLs nuevas (no a las viejas con redireccion), porque una web que se enlaza a si misma a traves de 301 obliga al usuario y al bot a un salto extra en cada navegacion. La regla operativa es buscar el dominio antiguo o el protocolo HTTP en el codigo y reescribir antes del corte.

La auditoria de schema y datos estructurados merece pausa especifica: muchas migraciones pierden rich results porque el CMS nuevo genera schema con sintaxis distinta o con identificadores rotos. Probar URLs criticas en la herramienta de pruebas de resultados enriquecidos de Google antes del corte evita perder estrellas, breadcrumbs visibles y FAQ snippets.

Fase 3: el dia del corte (T-0)

El dia del corte se ejecuta una secuencia controlada de operaciones, en este orden y nunca a la inversa. La ventana ideal es martes o miercoles por la maniana, en horario laboral pero antes del pico de trafico, con todo el equipo tecnico disponible para reaccionar. Viernes por la tarde o fin de semana se evitan: si algo falla, no hay capacidad de respuesta inmediata.

1. Backup completo de la web antigua (base de datos + ficheros) guardado fuera del servidor.
2. Bajada de la web antigua y subida del nuevo build a produccion.
3. Eliminacion del noindex y del Disallow: / que protegian staging. Este paso se hace MANUALMENTE despues del despliegue, nunca con automatismo, porque es el unico que cambia entre staging y produccion.
4. Activacion del mapa de redirecciones 301 en servidor o plugin.
5. Verificacion manual de 15-25 URLs criticas (home, paginas top trafico, fichas top conversion): respuesta 200, contenido visible, schema OK, enlaces internos funcionando.
6. Publicacion del nuevo sitemap XML y envio a Google Search Console.
7. Notificacion a herramientas de monitorizacion (Uptime, Pingdom, alertas internas) para marcar la ventana de cambio.

Durante las primeras horas post-corte el bot de Google detectara el cambio masivo, comenzara a procesar las redirecciones y la grafica de cobertura de Search Console reportara una oleada de URLs «redirigidas» — esto es comportamiento esperado, no error. La metrica a vigilar las primeras 24 horas no es el ranking (que tarda dias en ajustarse) sino el porcentaje de URLs respondiendo correctamente y la ausencia de errores 5xx, que indicarian problemas de servidor agravados por el pico de rastreo.

Fase 4: monitorizacion post-migracion (T+1 a T+90 dias)

Las semanas posteriores al corte son donde se mide si la migracion ha sido tecnicamente exitosa. La monitorizacion no es opcional: detectar y corregir un problema durante los primeros 14 dias permite recuperar trafico; detectarlo en el dia 60 ya implica perdida estructural mas dificil de remontar.

Los indicadores a vigilar se organizan en tres niveles: infraestructura, indexacion y rendimiento organico.

• Infraestructura (diaria, primeras 2 semanas): uptime, tiempo de respuesta del servidor, picos de 5xx, errores 4xx anomalos. Cualquier desviacion frente a baseline se investiga el mismo dia.
• Indexacion (semanal, primeros 60 dias): URLs indexadas en Search Console (informe Paginas), errores de rastreo, sitemap procesado, URLs descubiertas no indexadas, redirecciones procesadas.
• Rendimiento organico (semanal, primeros 90 dias): clics e impresiones por URL en Search Console, posiciones medias para las keywords top, comparacion contra el mismo periodo del anio anterior y contra la semana previa al corte.

La canibalizacion post-migracion es un fenomeno especifico que merece monitorizacion separada. Aparece cuando Google sigue indexando temporalmente tanto la URL vieja (todavia en cache, todavia citada en backlinks externos no actualizados) como la nueva: la SERP muestra ambas alternandose, las posiciones bailan y el CTR cae. Se resuelve manteniendo la redireccion 301 firme y, si persiste mas de seis semanas, revisando que la URL antigua devuelve correctamente el 301 sin cookies, sin user-agent dependencies y sin variaciones que confundan al bot.

La revision detallada del catalogo de keywords y del cluster de URLs nuevas tras la migracion es momento ideal para refinar el posicionamiento SEO en Las Palmas o donde quiera que la marca opere: las migraciones limpias suelen sacar a la luz oportunidades de optimizacion (paginas que estaban infraoptimizadas, intenciones de busqueda con URL equivocada) que en la web vieja quedaban camufladas bajo deuda tecnica acumulada.

Google Search Console: Change of Address y propiedades de dominio

Si la migracion implica cambio de dominio raiz, Google Search Console ofrece la herramienta Change of Address (Cambio de direccion) en propiedades URL-prefix. No es magia: simplemente avisa al equipo de rastreo de Google que el cambio es intencional y consolida senales mas rapido. Para que funcione, dominio antiguo y nuevo deben estar ambos verificados, las redirecciones 301 deben estar activas y la web nueva accesible.

El procedimiento operativo es claro: verificar la propiedad del dominio nuevo antes del corte (no esperar al dia D), confirmar que las redirecciones 301 estan activas sobre al menos un puniado de URLs muestra, y ejecutar Change of Address apenas concluida la migracion. La herramienta no acelera la indexacion ni recupera autoridad por arte de magia, pero sirve como senal explicita que reduce el periodo de ambiguedad para Google.

En migraciones que solo cambian estructura (mismo dominio, distintas URLs) Change of Address no aplica: solo cubre cambios de host. La estrategia ahi es enviar el nuevo sitemap, mantener el viejo accesible unas semanas (con redirecciones 301 sirviendose) y forzar el rastreo de las URLs nuevas criticas con la herramienta de Inspeccion de URL.

Las propiedades de tipo dominio (sc-domain:) cubren todos los subdominios y protocolos de un host, asi que migraciones HTTP a HTTPS o www a non-www no necesitan nueva propiedad si ya hay una de dominio configurada. Las propiedades URL-prefix solo cubren la combinacion exacta de protocolo + subdominio, por eso son las que pueden requerir verificacion adicional al cambiar el protocolo o subdominio.

Plazos realistas de recuperacion del trafico SEO

Una de las preguntas mas frecuentes — y peor respondidas en internet — es cuanto tarda Google en recuperar el trafico tras una migracion. La respuesta honesta depende de tres variables: tamaño del sitio, complejidad del cambio y calidad del mapa de redirecciones. No existe una cifra unica.

El patron tipico de recuperacion en una migracion bien ejecutada sigue tres fases temporales muy reconocibles que conviene comunicar al cliente o al equipo interno antes de empezar, para evitar panico injustificado en los dias 5-15 cuando la grafica luce peor de lo que estara despues.

• Dias 1-7: turbulencia controlada. Google empieza a procesar las redirecciones, la cobertura de Search Console reporta muchas URLs cambiadas, las posiciones oscilan +/- 3-5 puestos. El trafico organico cae entre 10% y 25% respecto a la baseline. Esperado.
• Dias 8-30: recuperacion progresiva. La mayoria de redirecciones se consolidan, las URLs nuevas se posicionan donde estaban las viejas. El trafico se estabiliza en torno al 85-95% de la baseline previa.
• Dias 30-90: cierre. Las ultimas URLs largas-tail se reasignan, las senales de usuario en las URLs nuevas se acumulan, el grafo de enlaces externos termina de procesarse. El trafico vuelve a baseline y, si la migracion mejoro arquitectura o velocidad, suele superarla.

Las migraciones que no recuperan ni siquiera al cabo de tres meses suelen tener problemas estructurales: redirecciones rotas no detectadas, sitemap mal configurado, paginas con noindex no eliminado o robots.txt bloqueando rutas criticas. En esos casos la solucion no es esperar mas: es auditar tecnicamente la web nueva y corregir.

Errores comunes a evitar en una migracion SEO

Tras revisar decenas de migraciones, hay errores que se repiten con tal frecuencia que merecen lista propia. Detectarlos en la fase de planificacion los neutraliza; descubrirlos en post-corte cuesta semanas de trafico.

• 1

  Redirigir toda la web vieja a la home

  Es el equivalente SEO a tirar el archivo historico. Google interpreta esa redireccion masiva como soft 404 y deja de transmitir autoridad. Cada URL antigua merece destino especifico (o 404 honesto si no hay equivalente).

• 2

  Olvidar eliminar el noindex de staging

  Si el meta robots noindex sobrevive al corte, la web entera se desindexa progresivamente. Es un fallo silencioso: el trafico cae sin error visible. Validar en la inspeccion de URL de Search Console las primeras 24 horas.

• 3

  Cadenas de redirecciones largas

  URL antigua → redireccion intermedia → redireccion final. Google sigue como mucho 3-4 saltos. Cada redireccion en el mapa debe apuntar directamente al destino final, no a otra redireccion. Auditar con Screaming Frog post-corte.

• 4

  Migrar varias variables a la vez sin necesidad

  Cambiar dominio + CMS + estructura + diseño en un solo corte multiplica los puntos de fallo y dificulta diagnostico. Cuando sea posible, fasear: una variable cada vez, validando indexacion entre fases.

• 5

  No actualizar enlaces internos absolutos

  Si los enlaces internos siguen apuntando al dominio o protocolo antiguo, cada navegacion del usuario y del bot pasa por una 301. Reescribir todos los enlaces internos a su forma final antes del corte (o con script de actualizacion en base de datos).

• 6

  Mantener el sitemap viejo enviado en Search Console

  Tras el corte hay que retirar el sitemap antiguo de Search Console y enviar el nuevo. Si el viejo sigue, Google encuentra URLs que ya redirigen, gasta crawl budget en procesarlas y retrasa la indexacion de las nuevas.

• 7

  No medir baseline antes del corte

  Sin metricas claras de trafico, posiciones y clics por URL los 30 dias previos al corte, no hay forma objetiva de saber si la migracion ha sido buena o mala. Exportar baseline antes del cambio es disciplina obligatoria.

Existe un octavo error que merece mencion especial por su frecuencia en ecommerce: no avisar a los partners y sitios con backlinks de alta autoridad. Cuando hay enlaces externos con autoridad real (medios, asociaciones, partners, directorios sectoriales), una notificacion proactiva pidiendo actualizar el destino del enlace al dominio nuevo evita depender solo del 301 y consolida senales mucho mas rapido. No siempre se consigue, pero el coste de pedirlo es minimo y el beneficio cuando hay enlaces top funciona muy bien.

La coordinacion con campañas activas es otro punto que se subestima: si en el momento del corte hay campañas de publicidad online activas en Google Ads o Meta Ads apuntando a URLs antiguas, conviene actualizar los anuncios el mismo dia o tener confianza absoluta en las redirecciones, porque una URL final que carga lenta o devuelve 404 por una redireccion mal configurada arruina el quality score y el CPL durante semanas.

Migracion como oportunidad, no como riesgo

Una migracion bien ejecutada no solo conserva el posicionamiento: lo mejora. Forzar el inventario completo de URLs, sanear la arquitectura, eliminar paginas zombi, corregir schema, mejorar Core Web Vitals y reducir cadenas de redirecciones internas son tareas que rara vez se priorizan en una web estable, y que la migracion convierte en condiciones de entrega. La diferencia entre las migraciones que se notan en negativo y las que pasan inadvertidas no esta en suerte ni en el tamaño del sitio: esta en metodo, planificacion y disciplina en la fase de pre-corte.

Esta misma logica conecta con la estrategia ampliada del proyecto digital: una vez la migracion se ha completado, conviene aprovechar el momento para revisar como elegir las keywords adecuadas para el negocio y consolidar la arquitectura semantica de la nueva web, ahora que esta limpia. Si la migracion ha incluido cambios fuertes de estructura, conviene tambien revisar la coherencia de los servicios de diseño web y catalogo de servicios con la nueva organizacion. Para sitios donde la analitica es decisiva (ecommerce, generacion de leads B2B), una revision del analisis de datos tras el corte cierra el ciclo: que metricas se han mantenido, cuales han mejorado y donde queda margen.