Cómo proteger la conversión durante un rediseño de sitio web

La versión breve: la mayoría de los rediseños no fracasan porque el sitio nuevo se vea peor. Fracasan porque nadie midió lo que el sitio anterior realmente estaba logrando antes de ser reemplazado. Primero la línea base, cambie una cosa a la vez, proteja lo que ya convierte, y observe las semanas posteriores al lanzamiento con la misma atención que las semanas anteriores.

Déjeme contarle por qué me pongo nervioso cada vez que un cliente dice la palabra "rediseño", porque el instinto que sigue a esa palabra casi siempre es el equivocado.

¿Por qué la mayoría de los rediseños pierden terreno en lugar de ganarlo?

Aquí está la parte incómoda. Una investigación de la división SoftwareReviews de Info-Tech Research Group encontró que el 80 por ciento de los rediseños de sitios web no logran alcanzar todo su potencial, socavados por una brecha entre lo que la empresa construyó y lo que el visitante realmente necesitaba (SoftwareReviews via PR Newswire, pendiente de reverificar). Ese no es un resultado marginal. Es la norma.

El caso público más claro que conozco es el de Marks & Spencer. En febrero de 2014 el minorista lanzó un rediseño que tardó aproximadamente tres años y cerca de £150 millones en construirse. Las ventas en línea cayeron un 8,1 por ciento en el trimestre inmediatamente posterior al lanzamiento, y solo la mitad de sus seis millones de clientes registrados se había molestado en volver a registrarse en el sitio nuevo (IEEE Spectrum, pendiente de reverificar). El dinero y el tiempo no fueron el problema. El sitio simplemente pidió a los clientes existentes que empezaran de nuevo, y cambió tanto de una sola vez que después nadie pudo decir qué decisión causó qué pérdida.

Ese es el patrón que quiero que note. Rara vez se trata de una sola decisión catastrófica. Es un cúmulo de cambios sin probar lanzados juntos, de modo que cuando la cifra se mueve, nadie puede señalar por qué.

¿Qué debe medir realmente antes de tocar nada?

No se puede proteger lo que nunca se midió. Antes de que cambie un solo píxel, quiero una línea base limpia, sostenida el tiempo suficiente como para poder confiar en ella.

Eso significa, por página y por flujo clave, al menos de cuatro a seis semanas de:

• Tasa de conversión, y la tasa de cada paso significativo dentro del embudo, no solo la del paso final.
• Tráfico por fuente, para saber qué canales están enviando a los visitantes que actualmente convierten.
• Tiempo de carga, en los dispositivos reales que sus visitantes efectivamente usan.
• Visibilidad en buscadores y URLs indexadas, para tener un mapa de lo que actualmente posiciona y se encuentra.
• El puñado de páginas con mejor rendimiento, clasificadas por ingresos o leads, no por opinión.

Escríbalo. Póngale fecha. Este documento se convierte en el único juez honesto de si el rediseño funcionó, y sin él, cada conversación posterior al lanzamiento se convierte en una suposición disfrazada de debate.

¿Por qué cambiarlo todo de una vez es la jugada más arriesgada que puede hacer?

Porque destruye su capacidad de aprender. Si cambia la maquetación, los textos, el flujo de pago y la plataforma de alojamiento en el mismo lanzamiento, y la conversión cae, ahora tiene cuatro sospechosos y ninguna evidencia. Si sube, tampoco sabe qué cambio la generó, así que no puede repetir el resultado en la siguiente página.

Un rediseño no es una sola decisión. Son docenas de decisiones bajo un mismo abrigo. Sepárelas, láncelas en una secuencia que pueda observar, y conservará lo único que un lanzamiento de una sola vez descarta: la capacidad de decir, con evidencia, qué fue lo que realmente funcionó.

¿Qué ya funciona, y cómo se asegura de que sobreviva?

Antes de que nadie toque un wireframe, quiero una lista breve y jerarquizada de lo que el sitio actual está haciendo bien en silencio. En mi experiencia, este es el paso que más se salta, porque un proyecto de rediseño es emocionalmente sobre lo nuevo, y nadie quiere pasar la reunión de arranque admirando lo anterior.

Busque lo siguiente:

• Las dos o tres páginas que concentran una parte desproporcionada de los ingresos o los leads. Proteja su estructura y su mensaje aunque cambie su estilo visual.
• Las frases específicas dentro de los textos que más convierten. Un titular que convierte es un activo del negocio, no un marcador de posición para que un redactor lo mejore por instinto.
• El flujo con menos pasos hacia su mejor resultado. La simplicidad que ya funciona no es lo mismo que la simplicidad que se ve anticuada. No confunda las dos cosas.
• Cualquier elemento de confianza (reseñas, casos de estudio, credenciales) ubicado cerca de sus momentos de mayor intención. Estos se eliminan constantemente en las renovaciones visuales, y su ausencia rara vez se identifica correctamente como la causa después.

Lleve esta lista a cada revisión de diseño como una lista de verificación de cosas que necesitan una razón deliberada para cambiar, no la suposición por defecto de que todo lo antiguo es un problema.

¿Cómo se lanza un rediseño sin volar a ciegas?

Hágalo por etapas. Un reemplazo completo lanzado en un solo día, a todos los visitantes, sin exposición previa, es la versión de mayor riesgo de este proyecto que se puede ejecutar, y también es la versión a la que la mayoría de las agencias recurre por defecto, porque es la más fácil de programar.

La alternativa es un lanzamiento que puede observar mientras ocurre:

1. Lance primero la estructura y los cimientos técnicos, por separado del rediseño visual. Confirme que nada se rompió antes de agregar algo nuevo a lo que el visitante tenga que reaccionar.
2. Despliegue por segmento o por porción de tráfico. Muestre la nueva experiencia al diez por ciento de los visitantes, o a un solo canal, antes de que llegue a todos. Observe las métricas de esa porción antes de ampliarla.
3. Cambie componente por componente donde la plataforma lo permita: el hero, luego el bloque de precios, luego el formulario, cada uno contrastado con la línea base antes de lanzar el siguiente.
4. Ejecute una prueba real, no una vista previa. Una revisión de diseño en una sala de reuniones le dice lo que piensan las partes interesadas. Solo el comportamiento en vivo le dice lo que hacen los visitantes.

Booking.com es el ejemplo extremo y útil en este caso. Se reporta que, en un momento dado, ejecuta más de mil experimentos en vivo en su propia página de reservas, y la empresa ha mantenido su marco de experimentación interno, construido por sus propios ingenieros, en gran medida intacto desde mediados de la década de 2000, en lugar de reemplazarlo por completo (Silicon Canals, pendiente de reverificar). Su propia dirección ha dicho que ni siquiera un nuevo logotipo propuesto se adopta solo por autoridad. Primero se pone a prueba. No hace falta un millar de experimentos para aplicar ese mismo principio: nada de gran escala se lanza a todos antes de haberse demostrado ante alguien.

¿Qué causa la caída posterior al lanzamiento, y cuánto tiempo debería durar?

Casi todo rediseño presenta alguna caída inmediatamente después del lanzamiento. La pregunta que importa es si se trata de una caída superficial y explicable que se recupera en días, o de una caída profunda que sigue sangrando meses después. Cinco causas explican la mayor parte de lo que veo.

URLs perdidas y redirecciones rotas. Cambie la estructura de sus URLs sin un mapa de redirecciones completo, y perderá tanto visitantes como el posicionamiento en buscadores que esas páginas se habían ganado. Un análisis ampliamente citado de un único caso de redirección de 2016 encontró una pérdida de tráfico constante en la página redirigida, sin recuperación meses después (via Ann Smarty, orientativo, pendiente de reverificar). A mayor escala, un análisis de 2026 sobre 1.052 migraciones de dominio encontró que solo alrededor del 27 por ciento recuperó su tráfico orgánico en un plazo de 90 días (SALT.agency, pendiente de reverificar). Cada URL antigua necesita un destino asignado antes del lanzamiento, no un esfuerzo de último momento después.

Mensajes modificados. Un titular que convertía estaba haciendo un trabajo real, aunque nadie pudiera decir exactamente por qué. Reemplácelo por un texto más fresco que nunca se ha probado, y estará cambiando un activo conocido por uno desconocido, el día del lanzamiento, sin plan de contingencia.

Nueva fricción. Un clic adicional, un formulario más largo, un muro de inicio de sesión que el sitio anterior nunca tuvo. Cada adición parece pequeña en una revisión de diseño, y se acumula dentro de un embudo.

Regresiones de velocidad. Los frameworks nuevos, las imágenes más pesadas y los fondos en video suman peso rápidamente, y la velocidad no es un detalle cosmético. Un estudio de Google y Deloitte sobre 37 grandes sitios de retail, viajes y lujo, a lo largo de más de 30 millones de sesiones, encontró que incluso una mejora de 0,1 segundos en el tiempo de carga móvil elevó la conversión en retail un 8,4 por ciento y el valor promedio de pedido un 9,2 por ciento (Think with Google, pendiente de reverificar). Aplique esa misma lógica a la inversa y un rediseño que añade silenciosamente medio segundo no es un intercambio neutral. Es un costo.

Seguimiento roto. Si sus analíticas y eventos de conversión no sobreviven intactos a la migración, no verá una caída. No verá nada, lo cual es peor, porque no se puede arreglar lo que no se puede medir. Confirme que cada evento se dispara correctamente antes del lanzamiento, no después de que alguien pregunte por qué el panel se ve extraño.

La lista de verificación para proteger el rediseño

Antes

• Capture una línea base de 4 a 6 semanas para conversión, tráfico, velocidad y posicionamiento (sin ella, nada después del lanzamiento se puede juzgar)
• Clasifique sus páginas y frases con mejor rendimiento actual (estas necesitan una razón deliberada para cambiar, no una por defecto)
• Construya un mapa completo de redirecciones de URL (la causa más común de pérdida de tráfico posterior al lanzamiento)
• Confirme cada evento de analítica y conversión en la nueva versión (no puede ver un problema que su seguimiento no pueda reportar)

Durante

• Escalone el lanzamiento por segmento, sección o porción de tráfico (mantiene el cambio observable en lugar de todo o nada)
• Contraste el texto nuevo y la maquetación nueva con la línea base antes de ampliar la exposición (protege un activo que funciona de ser reemplazado sin verificación previa)

En el lanzamiento

• Observe la velocidad en dispositivos reales de gama media, no solo en una prueba de laboratorio (las pequeñas regresiones tienen un costo de conversión medible)

Después

• Compare la semana uno y la semana cuatro contra la línea base, no contra la esperanza (la caída que importa es la que sigue presente en la semana cuatro)
• Investigue cualquier caída contra las cinco causas habituales antes de volver a tocar el diseño (la mayoría de las caídas son fallas corregibles, no una prueba de que el rediseño fracasó)

La rutina que aplico en cada rediseño

1. Congele una línea base. De cuatro a seis semanas, cada métrica que importa, con fecha.
2. Enumere lo que ya funciona, en orden de prioridad, antes de que alguien diseñe algo nuevo.
3. Asigne cada URL existente a su destino, sin excepciones.
4. Escalone el lanzamiento. Por segmento, sección o componente, nunca todo de una vez a todos.
5. Contraste cada etapa con la línea base antes de ampliarla.
6. Vigile la velocidad y el seguimiento con la misma atención que le presta al resultado visual.
7. Dele al lanzamiento una ventana definida, y luego compárelo contra la línea base, no contra la sensación.

Nada de esto ralentiza un rediseño tanto como la gente teme. Ralentiza la parte que de todos modos iba a fallar, y es precisamente la disciplina que surge de tratar la optimización, la visibilidad y la conversión como un solo sistema, en lugar de tres traspasos separados, cada uno culpando al otro cuando la cifra se mueve.