Un sitio puede parecer antiguo y conservar una base sólida, o verse moderno mientras fallan el contenido, el rendimiento y las operaciones. La decisión correcta no depende solo de la apariencia. Un rediseño cambia la experiencia dentro de una base viable; una reconstrucción cambia la base porque bloquea resultados importantes. Ese límite debe quedar claro antes de fijar alcance y presupuesto.
Diagnosticar el problema antes de nombrar el proyecto
Empieza por la evidencia del sitio actual: recorridos críticos, visibilidad orgánica, publicación, accesibilidad, velocidad, integraciones y esfuerzo de soporte. Separa síntomas y causas. Una conversión baja puede venir de una propuesta confusa, un recorrido móvil roto, tráfico poco cualificado o un checkout inestable. Llamar rediseño a cualquier problema crea un briefing visual antes de comprender las restricciones de negocio y tecnología.
Identificar qué merece conservarse
Un rediseño suele ser adecuado cuando la plataforma es segura, mantenible y capaz de sostener la arquitectura de información necesaria. Las URL, los contenidos, las integraciones y el historial de medición pueden aportar mucho valor. Conserva lo que funciona y cambia las capas que dificultan comprender o completar una tarea. La reconstrucción gana sentido si las actualizaciones están bloqueadas, las plantillas impiden estructuras necesarias o la operación depende de parches manuales frágiles.
Auditar contenido y SEO antes de mover URL
Crea un inventario de páginas importantes con su objetivo, demanda, enlaces, conversiones y estado. Decide qué conservar, mejorar, fusionar, redirigir o retirar. Mapea cada URL antigua a su destino final antes de lanzar y evita cadenas. Reconstruir sin un modelo de contenido solo traslada la inconsistencia a nuevas plantillas. Una buena migración protege la demanda existente y elimina páginas que ya no ayudan a una audiencia o decisión clara.
Planificar la entrega alrededor del riesgo
Agrupa dependencias: modelo de contenido, sistema de diseño, plantillas principales, integraciones, migración y controles de publicación. Prototipa pronto el recorrido más arriesgado. Si la plataforma puede evolucionar con seguridad, publica mejoras por etapas. Si hay que reconstruir, define congelación de contenido, ensayo de migración, rollback y responsables para el lanzamiento. El número de páginas no refleja la complejidad de permisos, integraciones u operaciones editoriales.
Validar el modelo operativo después del lanzamiento
Un lanzamiento correcto no es solo una comparación visual. Los editores deben publicar con seguridad, las redirecciones y formularios funcionar, el monitoring mostrar errores y la propiedad de las actualizaciones estar clara. Compara rendimiento, finalización de recorridos y esfuerzo de soporte con la base inicial. Mantén un backlog controlado de mejoras en lugar de reabrir todo el rediseño ante cada solicitud.