La diferencia no está en el nombre del proyecto
«Optimización», «refresh», «rediseño» y «web nueva» pueden describir trabajos muy distintos. Comparar esas etiquetas conduce a presupuestos incompatibles. Lo que importa es qué capas cambian, qué se conserva y qué riesgo asume el negocio.
Una mejora modifica una parte sobre una base válida. Un rediseño cambia el recorrido y la presentación, pero puede conservar sistema, contenidos o URLs. Una sustitución cambia también la base técnica o el modelo de operación. Ninguna opción es superior por defecto.
Empieza con el diagnóstico, no con el nombre del proyecto
Usa la auditoría para escribir el problema con un efecto observable:
- «En móvil no se puede completar la reserva» es comprobable.
- «La web se ve vieja» necesita concretarse.
- «Queremos vender más» todavía no identifica dónde intervenir.
Si todavía no puedes concretarlo, empieza por las señales que conviene revisar. Cuando ya existe evidencia, separa cuatro capas para decidir el alcance.
Mensaje
¿El visitante entiende la oferta, el encaje y el siguiente paso? Si no, puede bastar con reorganizar contenido y probar una página prioritaria.
Recorrido
¿Puede completar la tarea sin perderse, repetir información o cambiar de canal? Si la navegación y varias plantillas comparten el problema, el alcance crece.
Sistema
¿El gestor, las integraciones y el despliegue permiten cambios seguros? Una interfaz nueva sobre una base frágil puede ocultar deuda sin eliminarla.
Operación
¿Quién publica, mide, mantiene accesos y responde cuando algo falla? Un proyecto terminado sin responsables claros vuelve a deteriorarse.
Cuándo mejorar
Mejorar suele ser la decisión sensata cuando:
- el problema está localizado;
- la arquitectura representa el negocio actual;
- las cuentas y el dominio están controlados;
- la base permite pruebas y despliegues reversibles;
- las URLs útiles pueden conservarse;
- existe una métrica o criterio de aceptación concreto.
Ejemplo: una página de servicio recibe tráfico relevante pero no explica alcance ni facilita contacto. Reescribir esa página, simplificar el formulario y medir el recorrido puede responder la pregunta sin rehacer el sitio.
Cuándo rediseñar
El rediseño gana peso cuando el problema atraviesa varias plantillas o recorridos:
- la navegación responde a una organización antigua;
- cada página presenta una oferta diferente;
- la experiencia móvil falla de forma repetida;
- accesibilidad y semántica requieren cambios estructurales;
- el sistema de componentes impide mantener coherencia;
- conservar la apariencia actual bloquea una jerarquía más clara.
Un rediseño responsable inventaría menos y preservaría más: URLs valiosas, contenido útil, datos de medición, accesos y señales que ya funcionan.
Cuándo sustituir la base
Cambiar plataforma o reconstruir tiene sentido si la base impide cumplir requisitos relevantes: seguridad, mantenimiento, rendimiento, edición, integración, propiedad o coste operativo. No basta con que otra tecnología sea más nueva.
La sustitución debe contestar:
- qué información y URLs se migran;
- qué funciones se retiran y por qué;
- cómo se validará antes de cambiar tráfico;
- qué redirecciones se necesitan;
- cuál es el plan de reversión;
- quién controla dominio, repositorio, alojamiento y cuentas.
Los requisitos esenciales de Google Search y su guía de SEO ayudan a proteger rastreo y comprensión, pero una migración también necesita inventario y comprobación propios.
Compara coste total, no solo construcción
Una mejora barata que perpetúa dependencia puede salir cara. Una reconstrucción mayor que elimina una base válida también. Para comparar, suma:
- diagnóstico y contenido;
- diseño y desarrollo;
- migración e integraciones;
- pruebas de accesibilidad y rendimiento;
- mantenimiento y licencias;
- formación y documentación;
- coste de futuros cambios;
- riesgo de transición.
Las métricas web principales sirven como una parte de la línea base técnica. No miden claridad, confianza ni calidad de una oportunidad comercial; esas dimensiones requieren señales propias.
La salida correcta cabe en una frase
La decisión debería expresarse así:
Mejoraremos/rediseñaremos/sustituiremos la web porque el problema X afecta al recorrido Y; conservaremos Z y aceptaremos el cambio cuando se cumpla W.
Si la frase no puede completarse, falta diagnóstico. Si puede completarse, el nombre comercial del proyecto deja de importar.
Para comparar proveedores una vez elegido el alcance, continúa con qué debe incluir un presupuesto web.