Migrar de WordPress a una arquitectura moderna sin perder SEO

La objeción que detiene casi todas las migraciones es la misma: «¿y si perdemos el tráfico?». Es una preocupación razonable. Una migración mal ejecutada puede borrar años de posicionamiento en un fin de semana, y la recuperación se mide en meses.

Lo que sigue es el proceso que usamos, en orden, con las decisiones que importan y las que no.

Antes de tocar nada

El error más caro de una migración se comete el primer día: empezar a construir sin haber medido lo que había. Sin línea base no hay forma de saber si la caída del día quince es normal o es un problema, ni de demostrar después que el proyecto salió bien.

Cuatro cosas hay que tener guardadas antes de escribir una línea de código:

1. Exportación de Search Console de los últimos dieciséis meses, a nivel de URL, con impresiones, clics, posición media y CTR. Dieciséis meses es el máximo que ofrece la herramienta y conviene aprovecharlo entero.
2. Rastreo completo del sitio con Screaming Frog o similar, guardando títulos, meta descripciones, códigos de estado, canonicals y estructura de enlazado interno.
3. Línea base de Core Web Vitals, tanto de laboratorio como de campo. Los datos de campo del Chrome UX Report son los que cuentan para posicionar.
4. Copia de seguridad completa de archivos y base de datos, verificada restaurándola en otro sitio. Un respaldo sin probar es una hipótesis.

Search Console solo recuerda dieciséis meses y el rastreo solo ve lo que hoy está enlazado. Las URLs más antiguas, las que siguen recibiendo enlaces de otros sitios, se recuperan del archivo de Internet Archive; nuestra utilidad de URLs antiguas de un dominio las saca en una lista lista para cruzar con el inventario.

Este paso son unas horas de trabajo. Después de la migración ya no se puede recuperar.

Decidir qué pasa con cada URL

Aquí es donde se gana o se pierde el posicionamiento. Cada URL del inventario recibe una de cuatro decisiones:

Se mantiene. La página existe en el sitio nuevo con la misma dirección. Es el caso ideal y hay que buscarlo siempre que la estructura lo permita.

Se redirige con 301. La página desaparece pero hay una equivalente en intención. La redirección debe ser de un solo salto: si la URL A redirige a B y B redirige a C, hay que corregir A para que apunte directamente a C.

Se consolida. Varias páginas débiles sobre el mismo tema se funden en una guía más completa, y todas redirigen a ella. Es habitual en blogs con años de artículos cortos.

Nuestra propia migración es un ejemplo del segundo caso. Los artículos de la guía de posicionamiento colgaban de la raíz del dominio; hoy viven bajo /blog/ y cada URL antigua redirige a la nueva conservando el slug, que es lo que permite que el salto sea uno solo y que la señal se entienda.

Se retira con 410. La página desaparece y no hay equivalente posible — una pasarela de compra descontinuada, una promoción caducada. El código 410 le dice a Google que la retirada es definitiva y acelera la desindexación.

La tentación que hay que resistir

Redirigir todas las URLs retiradas a la home es rápido y es un error. Google trata esa redirección masiva como un soft 404: entiende que la página de destino no responde a la intención de la original, descarta la señal y en la práctica es como si hubieras devuelto un 404, pero además con peor experiencia de usuario.

Redirigir a la página más cercana en intención cuesta más trabajo — hay que revisar URL por URL — y es lo único que conserva la señal.

La semana del lanzamiento

D-7. Sitio nuevo completo en un entorno de pruebas con noindex. Rastreo del entorno de pruebas y validación de las redirecciones contra el inventario exportado: cada URL antigua debe devolver 301 hacia una URL que devuelva 200.

D-1. Bajar el TTL del DNS a 300 segundos para poder revertir rápido. Congelar cambios en el sitio antiguo.

D-0. Desplegar, quitar el noindex, verificar robots.txt, enviar los sitemaps nuevos en Search Console y comprobar que el SSL y la resolución entre www y dominio raíz funcionan con un solo salto.

D-0 más dos horas. Recorrer manualmente las veinte URLs con más tráfico del inventario y confirmar que cada una llega a destino en un único 301, sin cadenas. Es media hora de trabajo y detecta la mayoría de los errores graves. El comprobador de redirecciones enseña la cadena completa de cada URL, salto por salto, con su código.

D+1 a D+30. Revisar a diario el informe de cobertura y el de errores 404 durante la primera semana, luego semanalmente. Toda URL que aparezca en el informe de 404 se añade a la matriz y se redirige.

D+30. Comparar posiciones y tráfico contra la línea base.

¿Qué es normal y qué no?

Una caída del diez al veinte por ciento durante dos a cuatro semanas es esperable en cualquier migración: Google necesita reprocesar el sitio, seguir las redirecciones y actualizar su índice. Ver esa caída y entrar en pánico revirtiendo la migración es el peor desenlace posible, porque añade una segunda migración a la primera.

Lo que no es normal es una caída superior al treinta por ciento, o una caída que no empieza a recuperarse a partir de la cuarta semana. En esos casos hay que revisar, por este orden: URLs con 404 en el informe de cobertura, cadenas de redirección, bloqueos en robots.txt y etiquetas noindex que se quedaron del entorno de pruebas.

Esa última es más frecuente de lo que parece y explica una fracción sorprendente de las migraciones que salen mal.

Las redirecciones no son temporales

Un año como mínimo, y en la práctica indefinidamente si el coste de mantenerlas es bajo. Los enlaces entrantes desde sitios de terceros apuntan a las URLs antiguas y no se van a actualizar solos. Cada redirección que se retira convierte esos enlaces en errores 404.

En una arquitectura estática servida desde el borde de la red, mantener cuarenta redirecciones no cuesta nada — es un archivo de configuración. No hay razón operativa para retirarlas.