Cómo migrar un sitio web sin perder posicionamiento

· 11 min de lectura · Web Involved

¿Cómo migras un sitio web sin perder SEO?

Trátalo como el raro proyecto donde la meta es que nada cambie desde el punto de vista de tu cliente ni de Google, aunque todo por debajo haya cambiado. El único entregable que decide el resultado es el mapa de redirecciones: cada URL vieja con algún valor —tráfico, un estado indexado, o un backlink— recibe una 301 limpia a su equivalente más cercana, nunca una 302 y nunca una redirección en bloque a la home, que Google lee como un soft 404 y descarta por completo. Construye ese mapa en la fase de arquitectura, y migra tal-cual: copia las meta títulos, descripciones, H1 y cuerpo de tus páginas top textualmente, y lleva el mismo schema a las mismas URLs, porque “mejorar” una página que ya posiciona es el error más caro del manual. Toma una línea base de tus posiciones y tráfico antes de tocar nada, prueba todo en staging para cazar un noindex olvidado o un canonical apuntando al sitio viejo, y luego envía tu sitemap nuevo al lanzar y monitorea por treinta días. Espera una caída normal del 10-20% por unas semanas. Y si la migración duele, fíjate por qué — la dificultad de salir de una plataforma es el impuesto del lock-in que pagaste por no poseer tu sitio.

¿Por qué es tan riesgosa la migración para el SEO?

Una migración de sitio web es el raro proyecto donde la meta es que nada cambie desde la perspectiva de tus clientes, y nada cambie desde la perspectiva de Google, aunque casi todo por debajo haya cambiado (Kosmoweb, 2026). Quieres que Google entienda que te mudaste mientras concluye que nada importante es distinto — eres el mismo sitio confiable con el mismo contenido que la gente quería (Influize, 2026). Es un blanco estrecho, y un cambio de plataforma mal hecho puede borrar años de SEO acumulado en cuestión de semanas (Flyn, 2026).

La disciplina que acierta el blanco es poco glamorosa —audita a fondo, mapea cada URL, preserva los elementos on-page, valida el schema, monitorea sin descanso— y empieza antes de que algo se mueva (Kosmoweb, 2026). La razón por la que tantas migraciones fallan es que los equipos tratan la mudanza como un proyecto de diseño y descubren las consecuencias de SEO tras el lanzamiento, cuando son caras de revertir.

El mapa de redirecciones es lo único que debes acertar

Si haces una sola cosa bien durante una migración, acierta las redirecciones. Cada URL del sitio viejo que tenga algún valor —tráfico orgánico, un estado indexado, o un enlace interno o externo apuntándole— necesita una redirección 301 a su equivalente más cercana en el sitio nuevo, construida como una hoja de cálculo de tres columnas de URL vieja, URL nueva y estado durante la fase de arquitectura y no al final (Kosmoweb, 2026). La guía independiente trata el mapeo uno a uno, respaldado por un inventario completo de URLs, como obligatorio, porque preserva la equidad de enlaces y te da una línea base para detectar pérdidas (Baslon Digital, 2026).

El mapeo tiene que ser deliberado, no mecánico. Los mejores mapas de redirecciones son aburridos: una página de servicio redirige a la página de servicio equivalente, un producto al producto equivalente o su categoría, un post de blog al post equivalente (Baslon Digital, 2026). Y una sutileza que muchas guías se saltan: captura primero las redirecciones existentes del sitio viejo, porque las cadenas de redirección heredadas y las versiones olvidadas de URLs viejas crean problemas post-lanzamiento dolorosos de diagnosticar (Baslon Digital, 2026).

301 o 302 — y nunca redirijas todo a la home

Dos errores de redirección concentran gran parte de las posiciones perdidas. El primero es el código de estado: usa una 301, una redirección permanente que pasa la gran mayoría de la equidad de enlaces, y evita la 302, que es temporal y le dice a Google que mantenga la URL vieja indexada — muchas interfaces de CMS usan 302 por defecto, así que una perdida en una página de alto valor te puede costar meses (Flyn, 2026). Google confirmó que las 301 bien implementadas pasan la mayor parte de la equidad de enlaces, que es justo por qué son la herramienta para el trabajo (EarlySEO, 2026).

El segundo es redirigir todo a la home, una de las cosas más dañinas que puedes hacer. Google trata una redirección a una página irrelevante como un soft 404 y descarta la posición por completo, como si no hubiera redirección — la relevancia es lo que permite que la equidad se transfiera, así que cada URL vieja debe apuntar a su coincidencia temática más cercana (Flyn, 2026). Si una página no tiene equivalente cercano, decide de forma deliberada si la mandas a una categoría padre o la retiras, en vez de amontonar todo en la home.

Migra tal-cual: copia, no “mejores”

La regla más contraintuitiva de la migración es la contención. Para cada URL de tus páginas top, copia el meta título, la meta descripción, el H1 y el contenido principal del cuerpo al sitio nuevo textualmente, salvo que tengas una razón específica para cambiarlos — porque “mejorar” el título de una página que posiciona segunda para una keyword de alto valor es uno de los errores de optimización más caros que existen (Kosmoweb, 2026). Si una página ya rinde, la meta de la migración es preservar ese rendimiento, no reinventarlo.

El schema es la segunda responsabilidad on-page a vigilar. Si el sitio viejo llevaba marcado Article, FAQPage, BreadcrumbList, Organization o LocalBusiness, el sitio nuevo debe implementar los mismos tipos en las mismas URLs, validados con el Test de Resultados Enriquecidos de Google antes del lanzamiento (Kosmoweb, 2026). Por eso una migración y un rediseño deberían ser proyectos separados: hacer ambos a la vez significa que no puedes saber si un cambio de tráfico vino de la mudanza o del rediseño. Nuestra guía sobre cuánto cuesta un rediseño web cubre el lado del rediseño; la secuencia segura es migrar tal-cual, confirmar que las posiciones se mantienen, y luego optimizar en pasos medidos.

Toma una línea base de todo antes de tocar nada

Migrar sin datos de línea base es adivinar sin puntos de referencia, así que antes de cambiar nada, registra tus posiciones de keywords actuales, tráfico orgánico, rendimiento técnico y tasas de conversión (Influize, 2026). Rastrea todo el sitio con un crawler de SEO y exporta cada URL indexable — este conjunto de datos es a la vez el cimiento de tu mapa de redirecciones y la referencia contra la que medirás después (EarlySEO, 2026).

Combínalo con una auditoría de contenido, evaluando cada página para decidir qué preservar, actualizar, consolidar o quitar, para no arrastrar páginas obsoletas o de baja calidad al sitio nuevo y diluir su autoridad (EarlySEO, 2026). Presta atención especial a tus páginas de alto rendimiento y muy enlazadas, que puedes identificar en Google Search Console por clics y engagement — esas son las páginas cuyas posiciones más necesitas proteger (Influize, 2026).

Los pequeños errores que se esconden en staging

Los errores de migración más caros muchas veces se ven triviales en staging: una etiqueta noindex, una carpeta bloqueada, una regla canonical copiada del entorno viejo — y luego llega el lanzamiento y el sitio le dice cortésmente a los buscadores que se vayan (Baslon Digital, 2026). Los sospechosos habituales son robots.txt bloqueando carpetas importantes, directivas noindex olvidadas en plantillas de las pruebas, canonicals aún apuntando a URLs viejas, enlaces internos referenciando rutas de staging, y redirecciones que no están activas cuando el DNS cambia (Baslon Digital, 2026).

La defensa es correr varios rastreos de staging antes del lanzamiento, auditando el sitio de staging a fondo para que el sitio en vivo exponga exactamente las páginas correctas cuando bajas la palanca (EarlySEO, 2026). Vigila también los casos borde que muerden a cada equipo: cadenas de consulta, barras finales, sensibilidad a mayúsculas, y rutas de idioma, cada uno de los cuales puede romper una redirección en silencio (Kosmoweb, 2026).

El lanzamiento es el inicio, no el final

El mayor error tras toda esa preparación es tratar el lanzamiento como el momento de relajarse — las primeras semanas son cuando confirmas si las redirecciones se portan bien y Google indexa las URLs correctas (Baslon Digital, 2026). En las primeras 48 horas, envía el nuevo sitemap XML a Google Search Console, usa la herramienta de Inspección de URLs para pedir la indexación de tus páginas más importantes, verifica las redirecciones con un checker, y vigila los problemas de propagación de DNS, que pueden tomar la ventana completa de 48 horas (Wix SEO, 2026). Confirma que cada redirección resuelve en un solo salto, ya que las cadenas diluyen la equidad de enlaces y frenan el sitio (Influize, 2026).

Una cosa que no es SEO pero te arruinará la semana si la omites: el correo. Una mudanza de plataforma toca el DNS, y si no tratas tus registros MX, SPF, DKIM y DMARC como infraestructura crítica, puedes perder pedidos y leads en el momento en que el dominio cambia (DCHost, 2026). Prueba los formularios de contacto, el checkout y cada flujo crítico el día uno.

El impuesto del lock-in: por qué salir de un builder es difícil

Aquí es donde la dificultad misma te dice algo. Salir de Wix significa reconstruir a mano la mayoría de las páginas, porque Wix exporta solo el contenido del blog vía un feed RSS — las páginas estáticas, las imágenes, las apps y los metadatos de SEO no se transfieren de forma automática (WP Services, 2026). Esa fricción no es un accidente; es la forma del lock-in. La razón por la que la gente se va en primer lugar es que la plataforma limita el diseño a un editor propietario, esconde el código de fondo, y empuja las funciones avanzadas a apps de terceros con cuotas recurrentes que se vuelven muros a medida que creces (WP Services, 2026).

Relee eso y la lección es clara: cuanto más difícil es tu salida, más te estaba rentando la plataforma tu propio contenido. Un builder cerrado cobra su precio más alto a la salida, cuando descubres que tus páginas nunca fueron data portable que poseías sino una exhibición dentro de un sistema que licenciaste. Ese es el riesgo exacto que sopesa nuestro pilar sobre el mejor creador de páginas web, o el sitio que posees — comodidad ahora contra una extracción manual y costosa después.

La recompensa: una vez que lo posees, la siguiente mudanza es trivial

La otra cara es la recompensa por poseer tu sitio. Cuando tu contenido vive como data portable y tus redirecciones viven en un archivo de configuración que controlas, una mudanza futura es una transferencia sencilla en vez de una reconstrucción a mano — nunca vuelves a pagar el impuesto de salida. Salir de un builder también significa que por fin controlas todo el stack: dominio, DNS, hosting, SSL y muchas veces el correo (DCHost, 2026).

Nada de esto hace fácil una primera migración, y la honestidad es parte del consejo: si corres un mapa de redirecciones a mano por primera vez, el costo de un error suele ser mayor que el costo de ayuda experta, porque los equipos que aciertan las migraciones son los que han corrido el mismo manual muchas veces (Kosmoweb, 2026). Elegir a ese socio es su propia decisión, y nuestra guía sobre cómo elegir una agencia de diseño web cubre las preguntas específicas de migración que hay que hacer. Haz la mudanza una vez, con cuidado, hacia algo que poseas — y asegúrate de que sea la última migración forzada que corras.

Frequently asked

¿Perderé mis posiciones en Google si migro mi sitio web?
No si se hace bien. Con un mapa de redirecciones 301 completo, los elementos on-page preservados y la misma calidad de contenido, la pérdida de posiciones debería ser mínima — una caída temporal de tráfico del 10-20% por dos a cuatro semanas es normal mientras Google reprocesa el sitio, y las posiciones suelen recuperarse, y muchas veces mejorar, en cuatro a ocho semanas. Las pérdidas duraderas casi siempre las causan errores específicos: redirecciones omitidas, contenido que se 'mejoró' durante la mudanza, o errores técnicos como una etiqueta noindex olvidada. Una migración mal hecha puede tardar de tres a seis meses en recuperarse y quizás nunca recupere del todo lo perdido.
¿Qué es un mapa de redirecciones y por qué importa tanto?
Un mapa de redirecciones es una hoja de cálculo que empareja cada URL vieja con su URL nueva equivalente más cercana, y es el entregable más importante de la migración. Cada URL vieja que tenga algún valor —tráfico orgánico, un estado indexado, o un enlace interno o externo apuntándole— necesita una redirección 301 permanente a la página nueva más relevante. Se construye en la fase de arquitectura, no se pega al final, y es lo que preserva tu equidad de enlaces acumulada. Hazlo mal y usuarios, backlinks y buscadores empiezan a estrellarse contra muros 404.
¿Debería usar una redirección 301 o 302?
Para una migración, casi siempre una 301. Una 301 es una redirección permanente que pasa la gran mayoría de la equidad de enlaces a la URL nueva; una 302 es temporal y le dice a Google que mantenga la URL vieja indexada porque la mudanza no es permanente, lo que significa que tus páginas nuevas quizás nunca posicionen. La trampa es que muchas interfaces de CMS usan 302 por defecto, así que una perdida en una página de alto valor es un error común y costoso. Audita los códigos de estado de tus URLs top tras el lanzamiento para confirmar que todas son 301.
¿Puedo rediseñar mi sitio a la vez que lo migro?
Puedes, pero multiplica tu riesgo, y la disciplina más segura es migrar tal-cual primero y optimizar después. Durante una migración deberías copiar las meta títulos, meta descripciones, H1 y contenido del cuerpo de tus páginas top al sitio nuevo textualmente, porque 'mejorar' una página que ya posiciona bien es uno de los errores más caros posibles — si una página rinde, la meta es preservarla, no reinventarla. Haz la mudanza de plataforma como una transferencia limpia, confirma que las posiciones se mantienen, y luego haz cambios de diseño y contenido como pasos separados y medibles.
¿Por qué es tan difícil salir de un creador de webs como Wix?
Porque las plataformas cerradas hacen difícil llevarte tu contenido. Salir de Wix significa reconstruir a mano la mayoría de las páginas, ya que Wix exporta solo el contenido del blog vía un feed RSS — las páginas estáticas, las imágenes, las apps y los metadatos de SEO no se transfieren de forma automática. Esa fricción es el impuesto del lock-in: cuanto más difícil es tu salida, más te estaba rentando la plataforma tu propio contenido. Es también el argumento práctico más fuerte para construir sobre un sitio que posees desde el inicio, donde tu contenido es data portable y la siguiente mudanza, si alguna vez la hay, es sencilla.