Migrar de WordPress a Next.js Sin Perder Posiciones

Alguien lo dice en voz alta, siempre sobre el minuto veinte de la reunión: ¿y qué pasa con nuestro tráfico? Cuatro años de crecimiento orgánico en WordPress, una reconstrucción en Next.js encima de la mesa, y todos los de la sala imaginando lo mismo: la gráfica de Search Console cayéndose por un escalón en la semana dos y quedándose ahí abajo.

Es una preocupación legítima. Nos han llamado para limpiar migraciones que hicieron exactamente eso. Pero al repasar esas autopsias, el framework nunca fue lo que hizo el daño. Fue un mapa de redirecciones que alguien montó en una hoja de cálculo y no llegó a probar, o un puñado de páginas que se acortaron en silencio durante la reconstrucción porque la maqueta nueva quedaba mejor con menos texto. Ninguna de las dos cosas es un problema de React.

Por qué una migración de WordPress a Next.js pierde posiciones de verdad

Cuatro causas. Más o menos en el orden en que nos las encontramos.

1. 01Redirecciones mal hechas, o hechas a las cuatro de la tarde del día del lanzamiento. Las URLs antiguas dan 404. O todo apunta a la home, que Google lee como un soft 404 y se toma como motivo para soltar el conjunto entero.
2. 02Páginas que se quedaron más cortas. Alguien recortó la página de servicio que mejor funcionaba para que encajara en una maqueta más apretada y le quitó seiscientas palabras. Esas seiscientas palabras eran el posicionamiento.
3. 03La capa técnica planificada como fase dos. Canonicals, sitemap, datos estructurados, hreflang. No hay fase dos. Googlebot aparece el día uno y se forma una opinión.
4. 04Renderizado en cliente por accidente. Next.js te deja tranquilamente pedir el contenido principal dentro de un useEffect, y la página se ve impecable para ti y vacía para un rastreador.

El framework no te cuesta las posiciones. Te las cuestan las cuarenta URLs que nadie mapeó.

Antes de tocar nada: el inventario

Es un día de trabajo poco lucido y es el día de más valor de todo el proyecto, porque nada de esto se puede recrear una vez apagas la web antigua. Lo hemos intentado. Acabas adivinando desde la Wayback Machine, que es tan fiable como suena.

• Un rastreo completo de cada URL con su título, meta descripción, H1 y código de estado. Screaming Frog o similar, y no lo dejes en 500 URLs solo porque ahí se acabe la licencia gratuita.
• Search Console: dieciséis meses de consultas y páginas, exportados antes de cambiar nada. Es el fichero que te dice qué URLs se ganan el sueldo de verdad.
• Cada dominio de referencia y la página exacta a la que apunta. Los backlinks aterrizan en URLs concretas, y esas URLs tienen que seguir resolviendo después.
• Tus cincuenta páginas principales por tráfico orgánico, ordenadas. Es la lista de las que no pueden cambiar en sustancia, por muchas ganas que tenga alguien de reescribirlas.
• Core Web Vitals de referencia, para que después puedas enseñar la mejora en vez de limitarte a afirmarla.

La migración en sí, en siete pasos

Siete es un número algo tramposo, porque el paso cuatro lleva más tiempo que los otros seis juntos. Pero importa más el orden que la cuenta, y esta es la secuencia que seguimos.

1. 01Decide dónde va a vivir el contenido. Mantener WordPress como CMS headless, o mudarte a algo hecho a medida. Mantenerlo acierta más veces de las que la gente espera: los editores ya lo conocen y te ahorras entera la migración de contenido.
2. 02Construye plantillas, no páginas. Entrada, página, categoría, servicio, caso de estudio. Acierta con cinco plantillas y detrás salen bien doscientas páginas.
3. 03Porta el contenido con su estructura intacta. Mismos encabezados, misma profundidad, mismos enlaces internos. Mejóralo en una entrega posterior, para poder atribuirle el efecto a algo.
4. 04Escribe el mapa de redirecciones. Una fila por URL antigua, todas, incluidos los archivos paginados, las páginas de adjuntos y los enlaces cortos tipo ?p=123 que nadie recuerda haber publicado.
5. 05Publica la capa técnica en el primer despliegue. Canonical por página, sitemap, robots, JSON-LD y hreflang si eres bilingüe. En el primero, no en el siguiente.
6. 06Renderiza en servidor por defecto. Generación estática para todo lo que un rastreador deba ver, y deja el renderizado en cliente para las partes que de verdad son interactivas.
7. 07Móntalo en staging tras autenticación, rastréalo y compara ese rastreo con el antiguo. Títulos, H1, número de palabras, enlaces internos. Corrige lo que te enseñe la comparación antes de lanzar.

El mapa de redirecciones es el proyecto entero

Si te llevas una sola cosa de aquí, que sea esta: monta el mapa de redirecciones como un fichero del repositorio, no como una tarea en la cabeza de alguien ni como una hoja compartida con los comentarios de cuatro personas. El nuestro vive en la configuración de Next.js, así que pasa por revisión, se compara y se testea como cualquier otro código.

Unas cuantas reglas que nos siguen salvando. Usa 301, no 302. Un solo salto, porque la autoridad se escapa en cada paso y algunos rastreadores dejan de seguir después de unos pocos. Y manda cada URL antigua a su equivalente real más cercano en lugar de a la home. Cuando de verdad no existe equivalente, un 410 es más honesto que fingir que sí.

Y después pruébalo, que es donde casi todo el mundo se detiene. Coge el rastreo del paso uno, pasa cada URL antigua por el sitio nuevo y comprueba que cada una acaba en un 200 en el destino que habías previsto. Es un script de una tarde. Encuentra las cuarenta URLs que a una persona leyendo una hoja de cálculo se le habrían pasado, y encuentra el desajuste de la barra final, que lo tienen todas las migraciones y no lo prevé ninguna.

WordPress headless, y por qué suele ser la migración correcta

Merece la pena decirlo claro, porque sorprende en la primera reunión: migrar a Next.js no obliga a abandonar WordPress. Una migración a WordPress headless, con WP como API de contenido y Next.js como front end, es un destino perfectamente respetable y le quita casi todo el riesgo al asunto. Los editores conservan la interfaz que conocen. El contenido no se mueve. Y sigues teniendo el techo de rendimiento de un front end generado estáticamente.

La comparación completa la escribimos en headless CMS vs WordPress tradicional. Como estrategia de migración es la opción conservadora, y aquí lo conservador suele ser lo acertado. La alternativa, en la que el CMS, el front end y el modelo de contenido cambian en la misma entrega, son tres migraciones con una gabardina fingiendo ser un proyecto.

Migración de contenido: qué automatizar y qué hacer a mano

Si vas a salir de WordPress del todo, aquí es donde se suele ir el calendario. El instinto es programarlo todo. El instinto acierta en un ochenta por ciento.

Automatiza la cola larga. Entradas del blog, noticias, cualquier cosa con una forma que se repite: exportar, transformar, importar y revisar cincuenta al azar. Lo que buscas es la rotura silenciosa. Enlaces internos que siguen apuntando a rutas antiguas. Referencias de imagen con URLs absolutas del dominio viejo incrustadas dentro. Shortcodes que llegan como texto literal porque en el lado nuevo nadie sabe qué significa una etiqueta de galería. Comillas tipográficas que salen convertidas en caracteres raros. Las cuatro son habituales, y las cuatro siguen siendo invisibles hasta que un cliente escribe por una de ellas seis semanas después.

Haz a mano las páginas importantes. La home, las de servicio, las diez primeras por tráfico. Esas merecen una persona, porque una jerarquía de encabezados que se aplanó sutilmente por el camino es justo el tipo de daño que te cuesta posiciones sin parecer nada. Diez páginas hechas a mano son un día de trabajo. Recuperarse de un proceso automático que convirtió cada H2 en un párrafo es un mes.

• Conserva los niveles de encabezado donde estaban. Un H2 sigue siendo H2 aunque el diseño nuevo lo prefiera más pequeño.
• Reescribe las rutas de imagen y reexporta a dimensiones sensatas ya que estás. Casi todas las bibliotecas de WordPress están llenas de JPEG de 4000 px que nadie ha necesitado nunca.
• Preserva las fechas de publicación. Reiniciarlas le dice a los buscadores que tu archivo entero se escribió ayer, que no es la señal que buscas.
• Revisa las tablas. Las tablas son donde van a morir las migraciones de contenido, y siempre parecen correctas hasta que alguien abre una en el móvil.

Otra cosa que conviene meter en el presupuesto: alguien de contenido tiene que estar localizable durante el desarrollo, no solo al final. Las migraciones no suelen encallar en ingeniería. Encallan en decisiones que nadie estaba autorizado a tomar. Si dos páginas de servicio casi idénticas deberían fusionarse. Si las notas de prensa de 2019 merecen viajar. Conversaciones de diez minutos, todas ellas, que se convierten en bloqueos de dos semanas cuando la única persona que puede responder está fuera.

El día del lanzamiento y las cuatro semanas siguientes

Lanza un martes por la mañana. No un viernes por la tarde, diga lo que diga el calendario de entregas. Quieres dos días laborables completos con todo el mundo todavía en su sitio.

1. 01Envía el sitemap nuevo en Search Console dentro de la primera hora, y pasa la Inspección de URLs por tus diez páginas principales para empujar un nuevo rastreo en vez de esperarlo.
2. 02Lee los logs del servidor buscando 404 todos los días durante la primera quincena. Lo que el rastreador hace de verdad vale más que cualquier teoría sobre lo que se te pudo pasar.
3. 03Vigila los Core Web Vitals en datos de campo, no solo la puntuación de laboratorio. El laboratorio te dice qué puede hacer la página; el campo te dice qué hizo.
4. 04Cuenta con una caída sobre la semana dos. Es Google volviendo a rastrear y a puntuar, y debe ser poco profunda, y debe estar recuperándose en la semana cinco o seis.
5. 05Si en la semana seis no se ha recuperado, vuelve al mapa de redirecciones. Casi siempre es el mapa de redirecciones.

Qué pinta tiene el otro lado

Bien hecho, el tráfico vuelve y después sigue subiendo, porque la base que tiene debajo es mejor que la que dejaste. Nuestras builds en Next.js, Bay Eight Studios y ADS, se mueven en torno a 99 de media en Lighthouse, y ese número aguanta por cómo están construidas y no porque alguien las afine cada mes.

Sobre plazos, con honestidad: una web de marketing de treinta o cuarenta páginas son de seis a ocho semanas de principio a fin, y ahí van incluidos el inventario, las plantillas, el porte de contenido y el rastreo en staging. Añade un segundo idioma, un modelo de contenido complicado o cualquier cosa con carrito, y pasas a contar en meses. Si alguien te presupuesta dos semanas para un sitio con tráfico de búsqueda real, te ha presupuestado el desarrollo y te ha dejado a ti la mitad arriesgada.

Ese es el argumento real para mudarse, y no tiene nada que ver con que Next.js esté de moda. Después, las cosas aburridas se vuelven difíciles de romper: velocidad, rastreabilidad, un sitio que sigue siendo consistente según crece. Si tienes una migración encima de la mesa, así las llevamos nosotros. Y el día de inventario merece la pena hacerlo este mes, aunque no llegues a migrar nunca.