Migración de una tienda sin perder posiciones en Google: 43.943 pedidos, cero discrepancias

Qué se traslada en realidad

Cuando un cliente dice «trasladamos la tienda», normalmente piensa en productos y pedidos. Eso es quizá un tercio del trabajo. Una tienda que lleva años funcionando ha construido a su alrededor una capa de cosas que no parecen datos, y que deciden si el tráfico sobrevive al traslado.

En la última migración grande que hicimos —una tienda de combustible que vende en tres mercados— trasladamos de producción a la nueva arquitectura un conjunto completo:

Pedidos y clientes son lo evidente. Lo interesante son las otras dos líneas, porque son las que deciden su posición en el buscador y la confianza con la que alguien llega a una ficha de producto.

Redirecciones: 738 direcciones que nadie recuerda

Cada dirección bajo la que alguna vez hubo algo tiene su historia en Google. Algunas reciben enlaces de otros sitios, otras están en los marcadores de clientes, otras siguen vivas en boletines antiguos. Si tras la migración esa dirección devuelve «no encontrado», toda esa historia desaparece: no poco a poco, sino de un día para otro.

En esta tienda había 738. No eran direcciones de productos actuales —esas viajan con el catálogo—. Eran restos de reformas anteriores: categorías viejas, productos retirados, direcciones de cuando la tienda tenía otra estructura. Alguien configuró redirecciones para ellas y se olvidó, porque llevaban años funcionando en silencio.

Trasladar esas redirecciones no es trabajo creativo, es una casilla que marcar. Pero si no está en la lista, nadie lo hará, porque no se ve que falte nada. La tienda se ve bien tras el traslado, el tráfico cae durante tres meses y todos se preguntan por qué.

Opiniones: 375 reseñas fáciles de perder

Las opiniones de producto suelen vivir en una tabla distinta de la de productos y migran aparte. Muy a menudo no migran en absoluto, porque alguien con el plazo encima decide: «las opiniones ya las haremos, los clientes escribirán nuevas». No lo harán.

Trasladamos 375 reseñas junto con 1.825 valoraciones parciales, porque cada reseña de esta tienda puntuaba cinco dimensiones por separado. La trampa técnica estaba donde nadie la espera: las reseñas necesitaban un registro que las vinculara a la tienda con identificador cero. Sin ese registro los datos estaban en la base, pero el panel de administración mostraba una lista vacía, lo cual se parece exactamente a una pérdida de datos aunque no se hubiera perdido nada.

Lo menciono porque es la forma típica de los problemas de migración: nada explota, todo parece hecho, y falta una fila en una tabla auxiliar.

Tres países, tres monedas, un solo motor

Esta tienda vende en Polonia, Austria y Alemania: en tres monedas, con tres tipos impositivos y precios mostrados con impuestos, porque sus compradores son particulares. Encima hay un precio que depende del fabricante y del formato de entrega: palé, camión completo, saco a granel.

Con esa estructura, migrar no consiste en copiar precios. Consiste en que después del traslado la misma persona, entrando desde el mismo país, vea el mismo precio que antes. Suena trivial hasta que se cuenta cuántos puntos del código de una tienda pueden modificar ese precio.

Dejamos en la base los campos de precio antiguos aunque el mecanismo nuevo no los use. El motivo es poco vistoso: en el momento de la migración alguien puede tener un carrito a medio pagar. Borrar los datos antiguos rompería precisamente los pedidos que están en vuelo, los que menos conviene perder.

Cómo comprobar que la migración salió bien

El peor momento para descubrir un fallo es tres semanas después del cambio, cuando el tráfico ha bajado y nadie sabe cuál de cincuenta cambios lo provocó. Por eso la verificación no puede consistir en hacer clic por la tienda.

Comparar la lista completa de direcciones

Antes del cambio se prepara una lista de todas las direcciones a las que respondía la tienda antigua: del mapa del sitio, del panel, de los informes de Google. Después del cambio se consulta cada una por máquina y se compara la respuesta. No «si la página abre», sino: si responde igual que antes y, si redirige, si va al mismo sitio.

Con 738 redirecciones eso son unos minutos de máquina y la única forma de tener certeza. Hacer clic en diez direcciones al azar da la ilusión de control: si está roto el cinco por ciento, es probable que ninguna de esas diez lo detecte.

Cuadrar las sumas, no solo la presencia de datos

Tras la migración se comparan totales: número de pedidos, importe total, número de clientes, número de opiniones. No para comprobar si los datos están —casi siempre están—, sino para detectar el caso en que se trasladaron 43.900 de 43.943 pedidos porque cuarenta y tres tenían algo atípico en su estructura y cayeron en silencio.

La numeración por la que preguntará su asesoría

Pedidos y facturas llevan numeración continua y tras una migración no solo hay que conservarla: también tiene que continuar desde el punto correcto. El fallo clásico: los datos históricos se trasladan bien, el contador de documentos nuevos arranca en uno y el primer pedido tras el cambio recibe un número que ya existe en contabilidad.

El problema que no es de datos

Hay una categoría de problemas de migración que no tiene que ver con los datos, sino con el entorno donde vive la tienda. Dos ejemplos de este proyecto, caros de diagnosticar y triviales de arreglar:

Un servidor en un estado distinto del repositorio. Alguien activó un módulo directamente en el servidor, un fichero de configuración cambió fuera del control de versiones y el siguiente despliegue lo borró. Desde entonces cada despliegue empieza comprobando que el servidor no tiene nada que no esté en el repositorio.

Cambios que no surten efecto aunque se hayan subido. La tienda cachea el código compilado y un reinicio normal no lo limpia. El síntoma engaña: sube una corrección, comprueba, no cambia nada, así que la sube otra vez. La solución es borrar el código generado y recompilar; un paso que tiene que estar fijo en el procedimiento de despliegue, porque si no alguien pierde medio día cada pocos meses.

Cuándo hacer el cambio

Pasar el tráfico a la versión nueva es el único momento del proyecto que no se deshace sin dolor. Tres cosas que conviene cerrar antes:

• Qué pasa con los pedidos en curso. Alguien tiene ahora mismo un carrito abierto o está a medio pagar. El plan tiene que permitir que terminen; por eso en esta migración dejamos los campos de precio antiguos.
• Quién puede seguir accediendo a la versión antigua. Los primeros días la instalación anterior debería seguir accesible para el equipo, para poder comparar algo cuando un cliente llame por un pedido anterior a la migración.
• Cuándo exactamente. No un viernes por la tarde. No en plena temporada. En esta tienda la temporada de calefacción empieza a finales de verano: cambiar en agosto habría sido una decisión cara por muy bien preparada que estuviera.

La lista que conviene llevar a la reunión con el proveedor

1. ¿Cuántas redirecciones tienen? No «si tienen», sino «cuántas». La cifra se exporta en minutos.
2. ¿Dónde están las opiniones y en cuántas tablas? Si puntúan varias dimensiones, hay muchos más datos de los que muestra la ficha.
3. ¿Qué pasa con los pedidos en curso? Es decir: si el plan contempla que alguien tenga el carrito abierto.
4. ¿Se conserva la numeración de pedidos y facturas? Es una pregunta de su asesoría, pero hay que hacérsela al proveedor y antes de empezar.
5. ¿Quién comprobará que las direcciones antiguas siguen respondiendo? Por máquina y con la lista entera, no haciendo clic en tres al azar.

Si el proveedor responde a esas cinco con concreción, probablemente lo ha hecho antes. Si responde que «la plataforma lo gestiona», pregunte qué parte exactamente y qué ocurre cuando no lo gestione.