Migrar de Wix o Squarespace a WordPress sin perder posicionamiento

Wix y Squarespace hacen muy bien aquello para lo que fueron diseñados: poner online una web correcta, rápido y sin desarrollador. El problema no aparece en el lanzamiento sino dos o tres años después, cuando quieres hacer algo que la plataforma no ha previsto — y descubres que no puedes.

La migración a WordPress es entonces una operación técnicamente corriente, pero con un punto de ruptura: si las redirecciones se hacen mal, vuelves a empezar de cero en posicionamiento. Es la única parte que no se puede arreglar después.

Las razones reales para dejar una plataforma cerrada

Los motivos que se alegan suelen ser el precio o el SEO. Rara vez son los correctos. La suscripción de una plataforma sigue siendo más barata que una web a medida durante varios años, y Wix ha mejorado mucho en lo técnico — una web Wix bien hecha posiciona correctamente.

Las razones que se sostienen están en otra parte. Se migra cuando se choca con un límite funcional: conectar la web a un software de gestión, manejar un catálogo con reglas de precio particulares, crear un área de clientes, automatizar un proceso. Y se migra cuando se quiere ser dueño de lo construido.

Hay una tercera razón, menos confesable y perfectamente legítima: el coste de salida sube con el tiempo. Una web de veinte páginas se migra en cuatro semanas; la misma web cinco años después, con doscientas páginas, un blog y una tienda, se migra en tres meses. Si el límite funcional está identificado y la decisión tomada, aplazarla un año solo la encarece.

Las redirecciones: el único paso irreversible

Cada plataforma tiene su convención de URL. Wix produce a menudo direcciones tipo /post/mi-articulo, Squarespace /blog/mi-articulo, WordPress /mi-articulo. Toda dirección que cambia sin redirección pierde por completo el valor acumulado.

El método es simple pero no admite aproximaciones: exportar la lista completa de URLs existentes antes de tocar nada, cruzarla con las nuevas direcciones y escribir una redirección 301 para cada correspondencia. Una a una, sin agrupaciones perezosas hacia la portada.

• Exporta las URLs desde Search Console y desde el sitemap antiguo — las dos listas siempre difieren
• Cada dirección antigua apunta a su página equivalente, nunca a la portada
• Una redirección a la portada Google la trata como página eliminada: lo pierdes todo
• Conserva las redirecciones al menos un año, idealmente para siempre

Lo que no se migra automáticamente

Las herramientas de importación recuperan texto e imágenes. Casi nunca recuperan el resto, y ese resto es lo que consume el tiempo.

• El maquetado: los bloques propietarios de la plataforma no tienen equivalente, todo se rehace
• Los formularios y sus destinatarios
• Las redirecciones ya existentes en la web antigua — se olvidan a menudo, y perderlas rompe enlaces entrantes antiguos
• Las etiquetas title y meta description, si estaban personalizadas
• Las reseñas y contenidos integrados desde servicios de terceros

Cuenta con que la mayor parte del esfuerzo de migración recaerá en estos elementos, no en trasladar el contenido. Eso explica la diferencia entre un presupuesto de 800 € y otro de 6.000 €: el primero migra el texto, el segundo migra la web.

El inventario de URLs, la primera hora del proyecto

Una migración empieza por una lista, no por una maqueta. Mientras no sepas cuántas direcciones existen y cuáles reciben tráfico, cualquier presupuesto es una apuesta. Esa lista lleva de una a tres horas en una web de cincuenta páginas, y es el único momento del proyecto en que todavía resulta fácil de conseguir: una vez apagada la web antigua, ya no se reconstruye.

Ninguna fuente basta por sí sola, y es justo ahí donde fallan la mayoría de las migraciones. El sitemap solo contiene lo que la plataforma quiso declarar. Search Console solo devuelve las páginas que recibieron al menos una impresión. Un rastreador solo encuentra lo que está enlazado desde otra página. Las huérfanas — páginas de campaña antiguas, PDF, páginas de agradecimiento — aparecen únicamente en los registros del servidor o en el archivo de la web.

El entregable es una hoja de cálculo de cuatro columnas: dirección antigua, tráfico de doce meses, dirección nueva, estado. Sirve de pliego durante el proyecto, de guion de pruebas el día del cambio y de prueba tres meses después, cuando alguien afirma que «hemos perdido tráfico» sin poder decir en qué páginas.

No todas las URLs merecen una redirección, y conviene decidirlo pronto. Las páginas de prueba, los duplicados de paginación y los contenidos eliminados a propósito funcionan mejor con un código 410, que le dice a Google que la supresión es deliberada y acelera la limpieza del índice. Redirigir por principio trescientas páginas sin valor dispersa el rastreo en lugar de concentrarlo.

Qué se pierde exactamente sin redirecciones

«Se pierde el posicionamiento» es una fórmula vaga que nunca dice qué desaparece. Desaparecen tres cosas distintas, y no se recuperan al mismo ritmo — dos de ellas, de hecho, no se recuperan en absoluto.

Primero los enlaces entrantes: cada enlace que apuntaba a una página ahora inalcanzable deja de transmitir nada. Suelen ser enlaces de diez años, conseguidos con una nota de prensa o un directorio profesional, imposibles de rehacer. Después la posición misma: la URL sale del índice, normalmente entre dos y ocho semanas después del primer 404. Y por último los marcadores, los enlaces en las firmas de correo, los códigos QR impresos en folletos y el enlace de tu ficha de Google Business Profile, que siguen enviando visitantes a una página de error durante años.

El tratamiento más caro no es el 404, es la redirección global a la portada. Da la ilusión de trabajo hecho, porque nada se rompe a la vista, mientras Google la interpreta como página eliminada y el visitante aterriza en una web que tiene que recorrer de nuevo para encontrar lo que buscaba. La tasa de rebote de esas llegadas roza el 100 %.

Existe pese a todo una excepción razonable. Cuando la web antigua tenía cientos de páginas sin equivalente — un blog abandonado, un catálogo descatalogado — redirigir a la página de categoría más cercana es mejor que redirigir a la portada, y un 410 limpio es mejor que ambas si el contenido no va a volver. Lo que importa es que el tratamiento sea coherente, no que sea uniforme.

Recuperar el contenido cuando no hay exportación

Squarespace produce una exportación XML parcial. Wix exporta las entradas del blog y nada más. Los constructores de webs que incluyen algunos alojamientos a veces no exportan absolutamente nada. En esos casos la pregunta ya no es «cómo exportamos» sino «cuánto tiempo lleva reescribirlo», y esa pregunta tiene un número detrás.

El método que aguanta es un rastreo de la web existente que devuelva, para cada página, el título, la meta description, los subtítulos, el cuerpo de texto y la lista de imágenes. La reintroducción en WordPress se hace después página a página: calcula de cinco a ocho minutos para una página simple y de quince a veinticinco para una compuesta de bloques maquetados. Cuarenta y cinco páginas simples son por tanto unas cinco horas de trabajo, no dos días — siempre que hayas extraído el texto de una sola pasada en lugar de navegar página por página.

Las imágenes merecen atención aparte. Las publicadas en la plataforma se redimensionaron y recomprimieron para su propia visualización; recuperarlas tal cual congela para siempre una calidad mediocre. Si los originales están en alguna parte — un disco externo, un Drive, el fotógrafo —, este es el momento de recuperarlos. Si no, asume la pérdida y presupuesta una sesión de fotos dentro del año en lugar de descubrir el problema seis meses después.

• Rastrea primero: títulos, meta descriptions, H1 y cuerpo de texto en una sola extracción
• Recupera cada imagen en el mayor tamaño disponible y renómbrala de paso
• El archivo de la web saca del apuro con páginas eliminadas hace poco pero aún enlazadas
• El texto de los formularios, los correos de confirmación y las páginas de agradecimiento se pierde siempre: haz una lista aparte

Es también el momento de decidir no trasladarlo todo. En una web de doscientas páginas, un tercio no recibe visitas desde hace un año. Migrarlas cuesta varios días y no aporta nada; eliminarlas limpiamente con un 410 aligera el sitio y concentra el rastreo de Google en lo que sí trabaja. Una migración es la única ocasión en que esa poda se hace sin discusión: seis meses después, ya nadie se atreve a tocarlo.

El calendario realista de una migración

Un plazo anunciado de diez días para migrar una web corporativa es un plazo de desarrollo, no un plazo de proyecto. La diferencia está en los ciclos de validación, en la disponibilidad del cliente para releer cuarenta páginas y en las pruebas de las redirecciones, que no se comprimen porque consisten en verificar líneas una a una.

En una web de quince a veinte páginas la secuencia sostenible es esta: una semana de inventario y maqueta, dos semanas de construcción y traslado de contenido, una semana de pruebas, redirecciones y cambio. Cuatro semanas naturales, de las cuales unos diez días son trabajo efectivo. En una tienda, trasladar el catálogo, las cuentas de cliente y el histórico de pedidos añade de dos a cuatro semanas por sí solo.

• Semana 1: inventario de URLs, exportación de Search Console, decisiones sobre qué eliminar
• Semanas 2 y 3: construcción en un subdominio cerrado a la indexación, traslado del contenido
• Semana 4: tabla de redirecciones probada línea a línea, revisión del cliente, cambio un martes por la mañana
• Semanas 5 a 10: vigilancia de 404, de la indexación y de las posiciones, corrigiendo sobre la marcha

Dos reglas de sentido común ahorran días. La primera: congelar el contenido de la web antigua durante la fase de traslado, o migrarás una versión caducada y repetirás los cambios dos veces. La segunda: cambiar un martes por la mañana, nunca un viernes por la tarde. Las veinticuatro horas siguientes al cambio son aquellas en las que salen los olvidos, y hace falta alguien disponible para corregirlos.

La época del año cuenta más de lo que se cree. Una web de fontanero no se migra en enero, una escuela de vela no se migra en mayo, una tienda no se migra en noviembre. La caída de dos a seis semanas que sigue a todo cambio es indolora en temporada baja y cara en plena campaña; suele ser el único argumento que mueve de verdad una fecha de lanzamiento.

Los siete días posteriores al cambio

El cambio no es el final del proyecto, es el principio de la única fase en la que los errores todavía se arreglan a coste cero. El más frecuente con diferencia es el robots.txt de preproducción que se queda en su sitio, o la casilla de WordPress «disuade a los motores de búsqueda de indexar este sitio» que se queda marcada. La web es perfecta e invisible, a veces durante tres semanas, antes de que alguien se dé cuenta.

• Día 0: comprobar que la indexación está permitida, el certificado, la redirección www y el paso a HTTPS
• Día 0: probar diez redirecciones al azar de la tabla, incluidas las cinco páginas más visitadas
• Día 1: enviar el nuevo sitemap en Search Console y pedir la indexación de la portada
• Día 1: mandar un formulario de prueba y comprobar que el correo llega, carpeta de spam incluida
• Día 7: revisar el informe de páginas 404 y completar la tabla de redirecciones
• Día 30: comparar impresiones y posiciones con el mismo periodo del año anterior, no con el mes pasado

El seguimiento del tráfico exige una precaución metodológica. Comparar con el mes anterior lleva a conclusiones falsas, porque la estacionalidad se mezcla con el efecto de la migración: un cambio a finales de agosto produce mecánicamente una subida en septiembre, incluso con redirecciones malas. La comparación útil es con el mismo periodo un año antes, y sobre impresiones más que sobre clics — las impresiones reaccionan primero y se leen dos semanas antes.

Por último, mantén la web antigua accesible en lectura durante un mes, en una dirección técnica cerrada a la indexación. Es el seguro más barato del proyecto: el día en que descubres, tres semanas después, que una página de tarifas no se trasladó, la encuentras en dos minutos en lugar de reescribirla de memoria.

Cuánto tiempo y a qué coste

Para una web corporativa de diez a veinte páginas: de dos a cuatro semanas, entre 3.000 y 7.000 €, redirecciones y pruebas incluidas. Para una tienda: de cuatro a ocho semanas y de 8.000 a 20.000 €, siendo la migración del catálogo y del histórico de pedidos la partida principal.

Prevé una caída de tráfico de dos a seis semanas tras el cambio, incluso con redirecciones perfectas: Google debe volver a rastrear y reasignar. Una caída que dure más de tres meses señala un problema de redirecciones, no un fenómeno normal.

FAQ — Migración a WordPress

¿Se pierde el posicionamiento al migrar?

No, si las redirecciones 301 se hacen dirección por dirección. Una caída de dos a seis semanas es normal mientras Google vuelve a rastrear todo y reasigna el valor a las nuevas direcciones. Una caída sostenida más allá de tres meses revela redirecciones ausentes o todas apuntando a la portada.

¿Se puede exportar el contenido desde Wix?

Parcialmente. Wix permite exportar las entradas del blog, pero no las páginas ni el maquetado, que dependen de bloques propietarios. En la práctica el texto se recupera y la estructura se reconstruye. Es una restricción que hay que meter en el presupuesto desde el principio.

¿Cuánto tiempo hay que mantener las redirecciones antiguas?

El máximo posible. Google acaba transfiriendo el valor en unos meses, pero los enlaces entrantes y los marcadores apuntan a las direcciones antiguas durante años. Una redirección no cuesta nada mantenerla: consérvalas indefinidamente.

¿Hay que cambiar de dominio a la vez?

No, en absoluto. Cambiar de plataforma y de dominio al mismo tiempo hace imposible saber de dónde viene un problema si el tráfico cae. Migra primero, deja que se estabilice dos o tres meses, y cambia de dominio después si de verdad hace falta.

¿Cómo se recupera la lista completa de las URLs antiguas?

Cruzando cuatro fuentes, nunca una sola: el sitemap XML de la web antigua, la exportación de páginas de Search Console de dieciséis meses, un rastreo completo del sitio y las páginas de destino de Analytics. Cada una se pierde lo que encuentran las otras — las huérfanas suelen aparecer solo en Analytics o en los registros del servidor. Hazlo antes de tocar nada: una vez apagada la web antigua, la lista se pierde para siempre.

¿Se puede migrar uno mismo una web corporativa pequeña?

Para cinco o diez páginas sin formularios complejos ni tienda, sí, siempre que te tomes en serio las redirecciones. Es la única parte donde improvisar sale caro, y exige acceso al fichero de configuración del servidor o a un plugin de redirecciones. Calcula dos o tres fines de semana para una primera vez, y mantén la web antigua accesible un mes: es lo que separa una migración fallida de una migración corregible.

Fuentes

• Google — Mudanzas de sitio con cambio de URL — procedimiento oficial y papel de las redirecciones 301
• Google — Redirecciones y la Búsqueda de Google — tipos de redirección y transferencia de señales
• Google — Mudanzas de sitio con cambio de URL — alcance real de la exportación
• Google — Herramienta de inspección de URLs — comprobar la indexación y las redirecciones tras el cambio
• Google — Crear y enviar un sitemap — enviar el nuevo mapa del sitio el día del cambio