¿Reparar o rehacer una web?

La decisión no es técnica, es de negocio

Una empresa puede pedir «arreglar la web» cuando en realidad necesita una estructura nueva, o pedir «hacer una nueva» por un fallo que se puede corregir. Las dos frases pueden describir el mismo malestar, pero llevan a alcances distintos.

Antes de elegir conviene separar dos preguntas:

• ¿Qué está roto o frena? Si existe una lista concreta de fallos, casi siempre se puede reparar.
• ¿Qué ha cambiado en el negocio? Si la empresa ya no vende lo que la web explica, el problema no está en el código.

Reparar y rehacer responden a problemas distintos. Rehacer algo sano consume presupuesto innecesario; parchear una base agotada puede aplazar el problema y encarecer su solución.

Señales de que conviene reparar

Una reparación es la opción razonable cuando el problema está delimitado y el resto de la web sigue siendo válido:

• La estructura de contenidos funciona. Las secciones y las páginas responden a lo que busca la gente; solo fallan detalles.
• El fallo es localizable. Un formulario que no envía, un checkout que abandona, una página lenta o un error de maquetación en móvil.
• El SEO actual sostiene resultados. Hay páginas posicionadas y un histórico de indexación que merece la pena conservar.
• La funcionalidad cubre el día a día. El gestor de contenidos o la tienda permiten publicar y vender sin bloqueos graves.
• El equipo sabe usar la web. Reparar no obliga a reaprender herramientas ni a repetir formación.

En estos casos, tocar lo mínimo es una ventaja, no una falta de ambición: menos superficie de cambio, menos riesgo y una entrega más rápida.

Señales de que conviene rehacer

Rehacer deja de ser un capricho cuando la web ya no admite el negocio actual:

• La estructura estorba. Añadir una sección obliga a forzar el diseño y el contenido nuevo no encaja en ningún sitio.
• La plataforma limita. Funciones esenciales dependen de complementos frágiles o de parches que se pisan entre sí.
• El rendimiento no se recupera. El sitio carga mal incluso después de depurar imágenes, caché y código.
• El diseño comunica mal. La web no representa lo que la empresa es hoy, y arreglarlo por partes deja un resultado incoherente.
• El mantenimiento cuesta más que construir. Cada actualización rompe algo: se paga por sostener una base que ya no evoluciona.

Si coinciden varias señales, compara el alcance de ambas opciones. Su número no decide por sí solo: importan la causa, el riesgo y el coste comprobable de mantener la base actual.

Un escenario tipo

Imagina una web corporativa hecha con un gestor de contenidos, con unas cuarenta páginas, un formulario de contacto y un blog que casi nadie actualiza. La empresa pide «arreglarla»: el sitio tarda en cargar, se ve antiguo en móvil y el formulario falla de vez en cuando.

Aquí la respuesta no es automática:

• Si el contenido sigue siendo correcto y solo hay problemas de rendimiento y de formulario, conviene reparar: limpiar complementos, optimizar imágenes, corregir el envío y revisar la jerarquía en móvil. Es un alcance acotado y verificable.
• Si además el negocio ha cambiado de servicios, las páginas ya no corresponden a lo que vende y cada sección nueva obliga a rehacer el diseño, conviene rehacer: se conserva lo que funciona —textos, URLs con tráfico, dominio— y se reconstruye la estructura.

El mismo síntoma, «la web va mal», lleva a dos presupuestos distintos según el diagnóstico, no según el gusto.

Cómo lo decido yo: tres comprobaciones

Antes de recomendar nada compruebo tres cosas. Son las que cambian la decisión:

1. Inventario de lo que se rompe. Listo fallos concretos y comprobables, no impresiones. Un problema que no puedo describir con precisión no guía ninguna decisión.
2. El coste de dejarlo como está. Cuánto tiempo pierde el equipo, cuántas consultas o ventas se escapan y cuánto se paga por mantener algo que no avanza.
3. El coste de romper lo que funciona. Si rehacer implica cambiar URLs, hay riesgo de indexación y de perder posiciones. Ese riesgo se planifica; no se ignora.

Con esas tres respuestas la decisión suele caer sola. Si el punto 1 es una lista corta y el punto 3 es alto, se repara. Si el punto 1 es largo, el punto 2 es creciente y el punto 3 se puede gestionar con redirecciones, se rehace.

Lo que se pierde al rehacer

Rehacer tiene un coste que rara vez aparece en la primera conversación:

• Indexación y posiciones. Las URLs cambian y hay que planificar redirecciones y volver a validar.
• Contenido acumulado. Textos, imágenes y páginas antiguas que posicionan o responden a dudas reales.
• Confianza operativa. Si nadie puede publicar durante una mudanza larga, la empresa se queda quieta.
• Trabajo invisible. Copiar, migrar y volver a probar consume tiempo que no se ve en el diseño final.

Reparar también tiene costes: arrastrar decisiones antiguas, trabajar sobre una base que no controlas del todo y compensar deuda técnica. La diferencia es que esos costes son acotados y medibles, mientras que los de un rehacer mal planificado aparecen más tarde.

Una regla práctica

Pide una comparación por escrito: qué se conserva, qué se cambia, qué riesgos tiene cada opción y cuánto trabajo exige. Un fallo breve de describir puede ser complejo de reparar; una lista larga puede resolverse con cambios acotados.

Y si la respuesta no está clara, no se decide gastando a ciegas: se paga un diagnóstico acotado que devuelva una recomendación por escrito. Es lo que hago en el Diagnóstico Web 360: reviso la web, separo los fallos reparables de lo que ya no sostiene el negocio y planteo el siguiente paso.