Una web que tiene problemas no siempre necesita reemplazarse por completo. Conviene distinguir si la dificultad está en el contenido, en un recorrido, en la interfaz o en la base técnica. Un cambio general puede ser necesario, pero también puede sumar trabajo de migración sin resolver la causa que motivó el proyecto.
La decisión debería partir de un diagnóstico acotado y de objetivos verificables. “Modernizar” no explica qué debe funcionar distinto. Es más útil identificar una tarea que hoy falla, el lugar donde aparece el obstáculo y qué información falta para entenderlo. Después se puede evaluar cuánto del sistema actual permite una corrección sostenible.
Separar las capas del problema
Estructura y contenido
Si los servicios están mezclados, las páginas no responden preguntas o el menú no refleja cómo se busca información, hay un problema de organización. A veces se resuelve reorganizando contenido dentro de la base existente. Otras veces requiere nuevas plantillas porque la estructura actual obliga a presentar cosas diferentes como si fueran iguales.
Interfaz y recorridos
Un formulario difícil de usar, estados poco claros o controles que no funcionan en móvil pueden necesitar ajustes de componentes. Antes de rediseñar todo, conviene comprobar si el problema está aislado o aparece en muchos recorridos. La repetición indica que quizá hace falta revisar el sistema, no corregir una sola pantalla.
Rendimiento y tecnología
Imágenes mal dimensionadas o scripts innecesarios pueden ajustarse sin cambiar plataforma. Una base que impide editar contenido, mantener dependencias o implementar una función necesaria exige otra evaluación. No conviene confundir lentitud con una obligación de migrar: primero hay que identificar qué recursos y decisiones están contribuyendo al problema.
Una matriz para orientar la decisión
| Situación | Mejora puntual | Cambio de base |
|---|---|---|
| Oferta poco clara | Revisar textos y jerarquía si las plantillas sirven. | Evaluar nuevas plantillas si la oferta no cabe en la estructura. |
| Problema en un formulario | Corregir campos, errores y continuidad. | Considerarlo si el flujo exige capacidades ausentes. |
| Imágenes pesadas | Exportar y servir tamaños apropiados. | No es, por sí solo, motivo suficiente para migrar. |
| Edición frágil | Ordenar componentes y capacitación. | Evaluarlo si toda actualización depende de soluciones provisionales. |
| Nueva operación | Comprobar si puede incorporarse de manera mantenible. | Revisar plataforma si las dependencias no encajan con el nuevo alcance. |
Esta matriz no asigna una respuesta automática. Permite discutir qué conservar y qué necesita reemplazo. También ayuda a no mezclar una preferencia estética con una limitación funcional. Si la estructura funciona, el contenido puede editarse y las dependencias son mantenibles, un ajuste puede ser una decisión razonable.
Cuándo empezar por mejoras puntuales
Conviene considerar una intervención acotada cuando hay un problema identificable y la base permite corregirlo sin crear excepciones por todos lados. Por ejemplo, clarificar una página de servicio, reducir campos innecesarios o revisar recursos de una plantilla. La intervención debería tener un criterio de aceptación y una forma de comprobar que no afecta otros recorridos.
Un cambio puntual no significa trabajar sin contexto. Hay que revisar variantes, móvil, estados y contenido relacionado. Si se modifica un componente compartido, la prueba debe incluir las páginas que lo usan. De lo contrario, una corrección local puede trasladar el problema a otro lugar del sitio.
Cuándo tiene sentido revisar la base
Un cambio de base puede ser adecuado cuando la arquitectura ya no representa la oferta, la edición impide tareas habituales o una nueva operación exige capacidades distintas. También cuando muchas correcciones dependen de excepciones que vuelven difícil mantener el conjunto. La decisión requiere comprender qué limita la base y qué alternativa resuelve esa limitación.
Migrar implica conservar contenido útil, revisar URLs, redirecciones, formularios y medición. No es empezar de cero sin consecuencias. Antes de aprobarlo, conviene saber qué material se traslada, qué se elimina y quién valida el resultado. Un rediseño visual no debe borrar información necesaria solo porque no encaja en la nueva composición.
Ejemplo hipotético: catálogo de servicios
Una empresa recibe consultas que no coinciden con su oferta. La revisión encuentra una home clara, pero páginas de servicio con títulos internos y un formulario sin contexto. La base permite editar plantillas y conservar el servicio elegido. Una primera etapa podría corregir esas páginas y el recorrido de consulta, sin reemplazar todo el sitio.
Si además cada actualización rompe el listado y el equipo no puede cargar un servicio sin duplicar código, hay otro problema. En ese caso habría que revisar el modelo de contenido y la edición. Ambas dificultades pueden convivir, pero no conviene resolverlas con el mismo argumento: una afecta la comunicación; la otra, la sostenibilidad del sistema.
Definir prioridades y comprobarlas
Ordená los cambios por impacto en una tarea, riesgo y dependencias. Una mejora importante puede esperar si requiere información que todavía no existe. Registrá qué se modifica y qué señales permitirían evaluar la decisión, sin prometer una cantidad de consultas ni una posición en Google. Los resultados dependen también de factores externos al diseño.
Podés empezar por revisar el recorrido de consulta, la estructura para buscadores y el uso de imágenes. Si necesitás decidir dónde intervenir, una revisión de diseño y optimización puede delimitar qué conservar antes de encarar un cambio completo.
